From owner-freebsd-hackers Sun Jan 7 0:19: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smurftarget.net (unknown [216.34.142.180]) by hub.freebsd.org (Postfix) with ESMTP id 739CC37B404 for ; Sun, 7 Jan 2001 00:18:47 -0800 (PST) Received: from loki by smurftarget.net with local (Exim 3.20 #1) id 14FB2M-000B5w-00 for freebsd-hackers@FreeBSD.org; Sun, 07 Jan 2001 00:18:46 -0800 Date: Sun, 7 Jan 2001 00:18:46 -0800 From: Jonas Luster To: freebsd-hackers@FreeBSD.org Subject: Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap Message-ID: <20010107001846.A42548@netwarriors.org> Mail-Followup-To: Jonas Luster , freebsd-hackers@FreeBSD.org References: <200101070509.f0759uw74992@green.dyndns.org> <001801c0786c$e5d55b60$aa240018@cx443070b> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001801c0786c$e5d55b60$aa240018@cx443070b>; from jgowdy@home.com on Sat, Jan 06, 2001 at 09:44:20PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -- 06/01/01 21:44 -0800 - Jeremiah Gowdy : > Claiming that software isn't "free" because it's not valuable is redefining > the word "free" to mean something that has no cost, yet has value. > > free (fr) adj. Costing nothing; gratuitous: Yeah, and 'gay' means 'joyful'. > The word has absolutely nothing to do with your value judgements. Useful != > Free. No cost == Free. So, how much money will 'Free Tibet' charge you for a country? Now, I am not a native english speaker and even I have realized that 'free' means a bit more than just 'free beer' in the english language. > software, and that's a pretty damned closed minded point of view. I've > written hundreds of DOS and Windows applications, which are FREE, although I > didn't include the source code with them. Your massive generalization that So they are 'free' to modify, 'free' to distribute, 'free' to look into? Maybe I'm missing something here, but despite not being an English major, I seem to recognize the word 'free' in 'freedom'. What does a programmer gain from mislabeling his products? Freeware != free software, not just because 'free' is more than just 'free beer'. > you can't start redefining words like "free" to push your rabid open source > agenda. The people of the past who contributed their software to the scene > in the form of public domain, freeware, and shareware were writing code in > the same spirit as those of us who write open source code today. So why No. While (with the exception of 'Shareware' to a certain point), Freeware is a gift, 'free software' is more than that. It is a 'call to participate', to 'evaluate', to learn. One cannot learn much from closed source, no matter how much the author charges for its use. 'Free', for me and for a lot of people out there, means my freedom to extend my horizon by looking inside the program. My freedom to enhance and contribute, my freedom to borrow and my freedom to give. This is freedom, this is what 'free software' is all about. Not just a gift from one programmer to his/her users, it's much more. Even pay-ware with open source gives me that freedom. One of the most misinterpreted sentences in '90 is "Information wants to be free". This is not about money, it's about freedom. > don't you get off your goddamned high horse and stop belittling the "free" > software for other platforms simply because it doesn't comply with your open > source jihad bullshit. Whohoho, insults? Well, I guess it's what has to follow if arguments are amiss. I guess this is a thread that should not be here and I apologize for adding my $0.02 to it, even though I know it's wrong, but I am one of these 'open source jihad bullshit assholes' and I don't like it if someone belittles the efforts of my fellow coders out there. jonas -- http://www.advogato.org/person/jLoki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 1:43:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 7CA5337B400; Sun, 7 Jan 2001 01:43:42 -0800 (PST) Received: from newsguy.com (p22-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.87]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id SAA26183; Sun, 7 Jan 2001 18:43:29 +0900 (JST) Message-ID: <3A5839B7.2ABBD912@newsguy.com> Date: Sun, 07 Jan 2001 18:41:11 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: John Baldwin Cc: Poul-Henning Kamp , FreeBSD hackers , "Walter W. Hop" Subject: Re: Boot process robustness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > /boot/loader.conf perhaps, but how does the loader know that the previous boot > failed so that it knows to fall back? This is much harder, as a failed kernel > boot usually results in a hang or an instant CPU reset. Loader sets a flag before booting, and the boot process resets it at the end. Of course, loader doesn't have write capability. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 3:29:46 2001 Delivered-To: freebsd-hackers@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 5964937B69D; Sun, 7 Jan 2001 03:29:24 -0800 (PST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:uTGO8sUGIzXr4xJ/LIMBqeXpaqQ7STZa@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.11.0/3.7Wpl2) with ESMTP id f07BTEH24632; Sun, 7 Jan 2001 20:29:15 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:GI6eRNa4IN4CGhG0sr7jw4zW86n4YgPD@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 UAA24356; Sun, 7 Jan 2001 20:36:55 +0900 (JST) Message-Id: <200101071136.UAA24356@zodiac.mech.utsunomiya-u.ac.jp> To: Robert Watson Cc: hackers@freebsd.org, John Polstra , yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: KVM switch vs. FreeBSD psm driver (Solved!) In-reply-to: Your message of "Sat, 06 Jan 2001 22:10:40 EST." References: Date: Sun, 07 Jan 2001 20:36:54 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Do you know if this fixes the problem the following problem that I started >experiencing somewhere in the RELENG_4 line? For some machines, if the >KVM is not pointed at the box, the keyboard will not probe properly, and >does not respond for that session. As long as I boot with the KVM pointed >at the machine during the boot process, it probes fine. This doesn't seem >to impact the boot loaders, only after the kernel has loaded and probed. >It's really annoying as my crashbox has this problem, so I have to swap to >it every time I boot, and given the need to type continue in the serial >gdb, I often miss the window. I guess your KVM switch won't let the kernel talk to the keyboard, if the switch wasn't pointed to the FreeBSD box. Remove the flags 0x1 from atkbd in your kernel config file. This flag makes atkbd fail, if it doesn't detect a keyboard. Without the flag, atkbd will install regardless of the absence of the keyboard. In RELENG_2 and RELENG_3, this flag wasn't specified to atkbd by default. In RELENG_4, the flag was added to GENERIC so that syscons will use a USB keyboard, if any, when there is no AT keyboard. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 4:28:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from shadowmere.student.utwente.nl (wit401305.student.utwente.nl [130.89.236.145]) by hub.freebsd.org (Postfix) with ESMTP id 586F737B70E for ; Sun, 7 Jan 2001 04:08:35 -0800 (PST) Received: by shadowmere.student.utwente.nl (Postfix, from userid 1000) id 1784E207D; Sun, 7 Jan 2001 13:08:33 +0100 (CET) Date: Sun, 7 Jan 2001 13:08:33 +0100 From: Pascal Hofstee To: Doug White Cc: Rafael Barrero , hackers@FreeBSD.ORG Subject: Re: BSD dlopen and such Message-ID: <20010107130833.A2840@shadowmere.student.utwente.nl> Reply-To: daeron@shadowmere.student.utwente.nl References: <20010102152714.A3189@lokigames.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dwhite@resnet.uoregon.edu on Thu, Jan 04, 2001 at 10:19:56AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 04, 2001 at 10:19:56AM -0800, Doug White wrote: > No. The linux compatbility is through the image activator. The syscalls > have to be translated, otherwise if you were running as root and loaded a > linux lib into a freebsd binary, then that lib called fcntl(), your system > would reboot :) Ok ... I guess i will have to hear that blunder of mine for eternity :-)) -- Pascal Hofstee < daeron @ shadowmere . student . utwente . nl > begin LOVE-LETTER-FOR-YOU.TXT.vbs I'm a signature virus. Please copy me and help me spread. end To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 4:52:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id 2037637B6BD for ; Sun, 7 Jan 2001 04:45:07 -0800 (PST) Received: (qmail 18349 invoked by uid 1078); 7 Jan 2001 12:45:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Jan 2001 12:45:18 -0000 Date: Sun, 7 Jan 2001 04:45:17 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Frederik Meerwaldt Cc: Subject: Re: natd bug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Scratch that, I still get the error messages. For some reason they didn't show up for an hour or two. They usually show up immediately. -gordon On Sat, 6 Jan 2001, Gordon Tetlow wrote: > I used to get this exact same message, although my natd setup worked just > fine. It was just filling up the logs. I then added -log_denied to the > arguements for natd and it stopped spewing log messages. Here's what I > run: > > /sbin/natd -unregistered_only -use_sockets -punch_fw 5050:10 -log_denied -n vx0 > > I don't know if this helps out your problem or not, but at least I don't > get really annoying syslog messages every minute. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 5: 7:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id 445F237B402 for ; Sun, 7 Jan 2001 05:06:55 -0800 (PST) Received: (qmail 23734 invoked by uid 1078); 7 Jan 2001 13:07:06 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Jan 2001 13:07:06 -0000 Date: Sun, 7 Jan 2001 05:07:06 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Doug Barton Cc: Gerhard Sittig , Subject: Re: OT: silence as an answer? (was: how to test out cron.c changes?) In-Reply-To: <3A564E90.A49E1BE1@gorean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello there! On Fri, 5 Jan 2001, Doug Barton wrote: > Gerhard Sittig wrote: [snip] > > Consider the following. We are in the spring and DST is "springing > forward" at 2am. We have a job scheduled at 2:15 that takes one hour to > run. There is another job scheduled at 3:20 that ABSOLUTELY POSITIVELY > cannot run unless the first job finishes. Aside from the fact that this > is bad design, how should cron handle this situation? You can (and > probably should) respond that this is not cron's responsibility, and > come up with all kinds of ways to ameliorate this situation. My response > will then be that if you can "fix" this situation without "fixing" cron, > then cron doesn't really need to be "fixed." I think this is a really horrible example. It is impossible for FreeBSD to expect to catch bad design on a local administrator's part. The admin should implement some sort of semaphore (a file in /tmp) or just append the dependent job to the first job. We can't insulate stupidity, at least we shouldn't, otherwise FreeBSD is going to start looking more like Windows. I think that cron is broken because it doesn't handle DST shift properly. Just my opinion though, and we seem to get plenty of those around here =) > With very little imagination you could easily come up with other > situations where your proposed changes will cause more harm than good. > On the other hand, the "damage" that cron is doing in these situations > can easily be repaired by proper system design. Therefore your changes > should not be incorporated. I'm rather confused by the paragraph there. It almost seems like your second sentence is contradicting the other two. Can you clarify "these" in the second paragraph? Of course, I have a horrible head cold that's keeping me from sleeping, so if it's perfectly obvious to everyone else, I'll be quiet and go back to bed. OpenBSD seems to get by with these changes just fine. I have a lot of respect for them and I think if they come up with a good solution to the DST problem, we should seriously consider it. I'm having a hard time coming up with good examples of harm, but then again, this head cold is somewhat impairing my faculties. Cheers, -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 5:35:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from viemta05.chello.at (viemta05.chello.at [195.34.133.55]) by hub.freebsd.org (Postfix) with ESMTP id 52C7637B400; Sun, 7 Jan 2001 05:35:29 -0800 (PST) Received: from chello.at ([212.186.125.116]) by viemta05.chello.at (InterMail vK.4.03.01.00 201-232-122 license 9caa03a7df1d31c048ffcc0d31ac5855) with ESMTP id <20010107133525.HYWQ29538.viemta05@chello.at>; Sun, 7 Jan 2001 14:35:25 +0100 Message-ID: <3A5870B9.D4402452@chello.at> Date: Sun, 07 Jan 2001 14:35:53 +0100 From: cristian nicolae X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: SCSI DAT tape detection on Compaq DL380 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear all, I have a Compaq DL380 with an integrated Compaq Smart Array Controller. I have succesfully managed to install the FreeBSD 4.2-20010104 and everything is fine but the DAT drive which is not detected. The DAT is connected to the same Controller as the RAID system. I have checked the archives and noticed that I am not the first one who has this problem. But I could not find any resource which could lead me to a solution. If any of you could give me any hints on that, I would be very grateful. I am at the point where I am considering switching to Linux because of that. On the other hand does any of you have info whether Compaq will support officially FreeBSD in the future? TIA, Cristian Nicolae To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 6:50:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 2431C37B6DA; Sun, 7 Jan 2001 06:21:12 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f07EKQw92530; Sun, 7 Jan 2001 06:20:26 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: "Michael C . Wu" , Devin Butterfield , freebsd-small@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: StrongARM support? In-Reply-To: Message from "Michael C . Wu" of "Tue, 19 Dec 2000 12:56:58 CST." <20001219125657.A94588@peorth.iteration.net> Date: Sun, 07 Jan 2001 06:20:26 -0800 Message-ID: <92527.978877226@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm definitely interested in both StrongARM and PPC. (and so are very > many people) My understanding is that FreeBSD *wants* a FreeBSD/ARM, > but lack the resources/man-power to do so. I'd prefer to see an > official decision on the above by someone (hint hint -core :)) though. I don't think any "official decision" would say anything we in core haven't already said individually and many times over the years. Sure, FreeBSD wants ARM and PPC ports but currently lacks, at least to our knowledge, the man-power to lead and support such a project. You said it yourself. If some motivated individuals out there would like to change that situation, you have our full support! - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 7: 8:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 48D6A37B69B for ; Sun, 7 Jan 2001 07:07:58 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 7 Jan 2001 15:07:55 +0000 (GMT) To: Jaye Mathisen Cc: hackers@freebsd.org, iedowse@maths.tcd.ie, Kirk McKusick Subject: Re: fsck problem on large vinum volume In-Reply-To: Your message of "Sat, 06 Jan 2001 15:01:07 PST." <20010106150106.X32287@apocalypse.cdsnet.net> Date: Sun, 07 Jan 2001 15:07:54 +0000 From: Ian Dowse Message-ID: <200101071507.aa79033@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010106150106.X32287@apocalypse.cdsnet.net>, Jaye Mathisen writes: > >I have a 930GB vinum volume >However, I can't fsck it, I have to always use the alternate block. >newsfeed-inn2# fsck /dev/vinum/v-spool >** /dev/vinum/v-spool >BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE >/dev/vinum/v-spool: CANNOT FIGURE OUT FILE SYSTEM PARTITION Jaye sent me a ktrace.out for the fsck that was failing. It appears that the kernel had overshot the end of the superblock fs_csp[] array in ffs_mountfs(), since the list of pointers there extended through fs_maxcluster, fs_cpc, and fs_opostbl. This caused the mismatch between the master and alternate superblocks. The filesystem parameters were 8k/1k, and the total number of cylinder groups was 29782. fs_cssize was 29782*sizeof(struct csum) = 477184 bytes. Hence 477184/8192 = ~59 entries were being used in fs_csp, but fs_csp[] is only 31 entries long (15 on alpha). A larger block size should fix Jaye's case, but I think the correct solution is to fix the kernel so that it is not constrained by the MAXCSBUFS limit. There are a few ways to do this: - Store the fs_csp information in struct ufsmount rather than in the superblock. - Make use of the fact that the summary information is stored in one contigous region, and update the 'fs_csp' macro to find the right offset directly. I'll have a look and see which way looks neatest. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 7:47:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail12.svr.pol.co.uk (mail12.svr.pol.co.uk [195.92.193.215]) by hub.freebsd.org (Postfix) with ESMTP id 5EBFC37B6DB for ; Sun, 7 Jan 2001 07:42:25 -0800 (PST) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by mail12.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14FHxg-0007Ln-00 for hackers@freebsd.org; Sun, 07 Jan 2001 15:42:24 +0000 Received: from modem-14.powder-brown-tang.dialup.pol.co.uk ([62.137.51.142] helo=henny.webweaving.org) by mail18.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14FHxd-0007dN-00 for hackers@FreeBSD.ORG; Sun, 07 Jan 2001 15:42:22 +0000 Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id OAA17665; Sun, 7 Jan 2001 14:31:02 GMT (envelope-from n_hibma@calcaphon.com) Date: Sun, 7 Jan 2001 14:31:02 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: Jon Simola , Doug Rabson Cc: FreeBSD Hackers Mailing List Subject: Re: Broken-by-design USB device? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1089154843-978875662=:17540" Content-ID: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1089154843-978875662=:17540 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: There is, I think, at least a bug in subr_bus.c that might cause this, although, this is just a hunch. I've not been able to explain what's happening yet. What is happening is that device_probe_child sets the device class, and in case of an error unsets it. But in this case attach (instead of probe) returns an error and hence the devclass _should_ be unset for that device (it didn't have a devclass to start with) to force it back to its virgin state, but isn't. If you could review his patch dfr, that would be appreciated. This is an issue in current as well. Jon, could you try the attached patch and tell me whether that works for you? Cheers, Nick On Tue, 2 Jan 2001, Jon Simola wrote: > On Sat, 30 Dec 2000, Nick Hibma wrote: > > > The panic is definitely bad. It happens straight after failing the > > attach? > > Yep, but only during the kernel boot. Hot plugging the device after the system > is booted spews the same errors to the console but does not cause a panic: > > uhid0: no report descriptor > device_probe_and_attach: uhid0 attach returned 6 > > > plug the device in again, and after it has panicked (it will drop into > > the debugger), type trace. That would give me a hint at where it > > crashes. > > Here you go. If you need anything else, please ask. > > kernel: type 12 trap, code=0 > Stopped at DEVICE_PROBE+0xe: cmpl 0(%edx),%eax > db> trace > DEVICE_PROBE(c1142d00,c1142d00,c1139100,0,0) at DEVICE_PROBE+0xe > device_probe_child(c1139100,c1142d00,c1142e00,0,c1142e30) at > device_probe_child+0xc1 > device_probe_and_attach(c1142d00) at device_probe_and_attach+0x29 > usbd_probe_and_attach(c1139100,c1142e00,2,3,c1142e00) at > usbd_probe_and_attach+0xef > usbd_new_device(c1139100,c113a000,1,200,2,c11390c0) at usbd_new_device+0x1dd > uhub_explore(c1139280,c1139300,c1139e80,0,c0456e64) at uhub_explore+0x1d4 > usb_attach(c1139300,c0456e7c,c01afc0b,c1139300,c113a000) at usb_attach+0xf1 > DEVICE_ATTACH(c1139300,c113a000,c1139e80,0,c0456ea0) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c1139300) at device_probe_and_attach+0x4f > uhci_pci_attach(c1139e80,c0456ec4,c01afc0b,c1139e80,c1139e80) at > uhci_pci_attach+0x33f > DEVICE_ATTACH(c1139e80,c1139e80,c1136400,0,c0456ed4) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c1139e80) at device_probe_and_attach+0x4f > bus_generic_attach(c1136380,c0456ef8,c01afc0b,c1136380,c1136380) at > bus_generic_attach+0x16 > DEVICE_ATTACH(c1136380,c1136380,c1136580,0,c0456f08) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c1136380) at device_probe_and_attach+0x4f > bus_generic_attach(c1136400,c0456f2c,c01afc0b,c1136400,c1136400) at > bus_generic_attach+0x16 > DEVICE_ATTACH(c1136400,c1136400,c0e25800,0,c0456f3c) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c1136400) at device_probe_and_attach+0x4f > bus_generic_attach(c1136580,c1136580,c0456f58,c012740e,c1136580) at > bus_generic_attach+0x16 > nexus_attach(c1136580,c0456f70,c01afc0b,c1136580,c1136580) at nexus_attach+0xd > DEVICE_ATTACH(c1136580,c1136580,c039a710,45b000,c0456f80) at > DEVICE_ATTACH+0x2e > device_probe_and_attach(c1136580) at device_probe_and_attach+0x4f > root_bus_configure(c0e25800,c036d38c,0) at root_bus_configure+0x16 > configure(0,454c00,45b000,0,c0126df4) at configure+0x33 > mi_startup(c0456fb4,b0206,ffe,45b000,c01b42f9) at mi_startup+0x70 > begin() at begin+0x4b > > > The controller probably requires some work because a fake report > > descriptor is needed to make it possible for the uhid driver to talk to > > it. It does not provide any information on where the information for the > > buttons and axes is stored in the descriptor returned on the interrupt > > pipe. > > --- > Jon Simola | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ --0-1089154843-978875662=:17540 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="subr_bus.c.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="subr_bus.c.patch" SW5kZXg6IHN1YnJfYnVzLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD UyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMva2Vybi9zdWJyX2J1cy5jLHYN CnJldHJpZXZpbmcgcmV2aXNpb24gMS41NC4yLjcNCmRpZmYgLXUgLXIxLjU0 LjIuNyBzdWJyX2J1cy5jDQotLS0gc3Vicl9idXMuYwkyMDAwLzA4LzAzIDA2 OjM2OjM4CTEuNTQuMi43DQorKysgc3Vicl9idXMuYwkyMDAxLzAxLzA3IDEz OjUxOjE1DQpAQCAtMTE0MCw2ICsxMTQwLDcgQEANCiB7DQogICAgIGRldmlj ZV90IGJ1cyA9IGRldi0+cGFyZW50Ow0KICAgICBpbnQgZXJyb3IgPSAwOw0K KyAgICBpbnQgaGFzY2xhc3MgPSAoZGV2LT5kZXZjbGFzcyAhPSAwKTsNCiAN CiAgICAgaWYgKGRldi0+c3RhdGUgPj0gRFNfQUxJVkUpDQogCXJldHVybiAw Ow0KQEAgLTExNTUsNiArMTE1Niw5IEBADQogCSAgICBlbHNlIHsNCiAJCXBy aW50ZigiZGV2aWNlX3Byb2JlX2FuZF9hdHRhY2g6ICVzJWQgYXR0YWNoIHJl dHVybmVkICVkXG4iLA0KIAkJICAgICAgIGRldi0+ZHJpdmVyLT5uYW1lLCBk ZXYtPnVuaXQsIGVycm9yKTsNCisJCS8qIFVuc2V0IHRoZSBjbGFzcyB0aGF0 IHdhcyBzZXQgaW4gZGV2aWNlX3Byb2JlX2NoaWxkICovDQorCQlpZiAoIWhh c2NsYXNzKQ0KKwkJICAgIGRldmljZV9zZXRfZGV2Y2xhc3MoZGV2LCAwKTsN CiAJCWRldmljZV9zZXRfZHJpdmVyKGRldiwgTlVMTCk7DQogCQlkZXYtPnN0 YXRlID0gRFNfTk9UUFJFU0VOVDsNCiAJICAgIH0NCg== --0-1089154843-978875662=:17540-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 7:51:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 19B3C37B6DD for ; Sun, 7 Jan 2001 07:49:34 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f07FnTs60836; Sun, 7 Jan 2001 08:49:30 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101071549.f07FnTs60836@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Polstra Cc: hackers@FreeBSD.ORG Subject: Re: KVM switch vs. FreeBSD psm driver In-Reply-To: Your message of "Sat, 06 Jan 2001 14:12:24 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 07 Jan 2001 08:49:29 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I've got a Belkin OmniView Pro 8-Port KVM switch which thinks it's >much smarter than it really is. I've had so many problems with this product that I dumped it for an Apex Outlook. I couldn't be happier. Since I donated the Belkin to another group, I've heard that they were able to send it in to be fixed. There was some manufacturing defect on early boxes that accounted for part of my problem. Since the signal quality through the switch was so poor anyway, I don't regret going to the Apex. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 7:53:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id DF65B37B6B2 for ; Sun, 7 Jan 2001 07:52:58 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f07Fqf728078; Sun, 7 Jan 2001 10:52:42 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 7 Jan 2001 10:52:41 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kazutaka YOKOTA Cc: hackers@freebsd.org, John Polstra Subject: Re: KVM switch vs. FreeBSD psm driver (Solved!) In-Reply-To: <200101071136.UAA24356@zodiac.mech.utsunomiya-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 7 Jan 2001, Kazutaka YOKOTA wrote: > I guess your KVM switch won't let the kernel talk to the keyboard, if > the switch wasn't pointed to the FreeBSD box. > > Remove the flags 0x1 from atkbd in your kernel config file. This flag > makes atkbd fail, if it doesn't detect a keyboard. Without the flag, > atkbd will install regardless of the absence of the keyboard. > > In RELENG_2 and RELENG_3, this flag wasn't specified to atkbd by > default. In RELENG_4, the flag was added to GENERIC so that syscons will > use a USB keyboard, if any, when there is no AT keyboard. So, question: is there a reason why we can't enable both the USB keyboard and a native PS/2 keyboard with syscons? It seems that I frequently find myself in a position where I'd like to plug in a keyboard, or switch KVM choices to a machine, and discover myself with no access to the hardware console, and I know at least one person who uses FreeBSD in production and finds this to be a serious impediment (as it requires the system to be rebooted to regain console access, and when you have 8 machines per KVM, and you boot them all, switching back and forth to catch each probe is effectively impossible). Presumably our syscons is intended to select on source of I/O and use it, but it might be worth considering a change here. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 10:28:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by hub.freebsd.org (Postfix) with ESMTP id 8D1CE37B400 for ; Sun, 7 Jan 2001 10:28:28 -0800 (PST) Received: from [195.92.198.123] (helo=mail17.svr.pol.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14FKYN-0006Ww-00 for freebsd-hackers@freebsd.org; Sun, 07 Jan 2001 18:28:27 +0000 Received: from modem-36.curunir.dialup.pol.co.uk ([62.136.149.164] helo=henny.webweaving.org) by mail17.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14FKYL-0003Xg-00 for freebsd-hackers@FreeBSD.org; Sun, 07 Jan 2001 18:28:26 +0000 Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id SAA18200; Sun, 7 Jan 2001 18:12:14 GMT (envelope-from n_hibma@calcaphon.com) Date: Sun, 7 Jan 2001 18:12:14 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: Kaltashkin Eugene Cc: freebsd-hackers@FreeBSD.org Subject: Re: umodem and manual In-Reply-To: <200012081515.SAA16086@ns.klondike.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The change to MAKEDEV will be committed. Thanks! Nick > KE: I try testing 3com USB modem, but don't know, how connect to him ? > KE: Maybe i can get some help about it ? > > I found problem (MAKEDEV create umodem0 with rw------- permissions, change it to > 660) > When Zyxel Omni USB modems be supported in FreeBSD kernel ? > > -- > Best Regards > ZHECKA-RIPN > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 10:28:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171]) by hub.freebsd.org (Postfix) with ESMTP id 6868F37B402 for ; Sun, 7 Jan 2001 10:28:34 -0800 (PST) Received: from [195.92.198.123] (helo=mail17.svr.pol.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14FKYT-0003yV-00 for freebsd-hackers@freebsd.org; Sun, 07 Jan 2001 18:28:33 +0000 Received: from modem-36.curunir.dialup.pol.co.uk ([62.136.149.164] helo=henny.webweaving.org) by mail17.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14FKYR-0003Xg-00 for freebsd-hackers@FreeBSD.org; Sun, 07 Jan 2001 18:28:32 +0000 Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id SAA18198; Sun, 7 Jan 2001 18:11:55 GMT (envelope-from n_hibma@calcaphon.com) Date: Sun, 7 Jan 2001 18:11:55 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: Kaltashkin Eugene Cc: freebsd-hackers@FreeBSD.org Subject: Re: umodem and manual In-Reply-To: <200012081515.SAA16086@ns.klondike.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have no Zyxel modem, nor do I have any specs for what the device. So you might be better off asking on the usb-bsd mailing list: USB BSD list Nick On Fri, 8 Dec 2000, Kaltashkin Eugene wrote: > KE: I try testing 3com USB modem, but don't know, how connect to him ? > KE: Maybe i can get some help about it ? > > I found problem (MAKEDEV create umodem0 with rw------- permissions, change it to > 660) > When Zyxel Omni USB modems be supported in FreeBSD kernel ? > > -- > Best Regards > ZHECKA-RIPN > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 11:12:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by hub.freebsd.org (Postfix) with ESMTP id 1EBEC37B400 for ; Sun, 7 Jan 2001 11:12:19 -0800 (PST) Received: from cx443070b ([24.0.36.170]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010107191039.GAFK1118.femail3.sdc1.sfba.home.com@cx443070b>; Sun, 7 Jan 2001 11:10:39 -0800 Message-ID: <000f01c078de$14478c40$aa240018@cx443070b> From: "Jeremiah Gowdy" To: "Jonas Luster" , References: <200101070509.f0759uw74992@green.dyndns.org> <001801c0786c$e5d55b60$aa240018@cx443070b> <20010107001846.A42548@netwarriors.org> Subject: Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap Date: Sun, 7 Jan 2001 11:14:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Claiming that software isn't "free" because it's not valuable is redefining > > the word "free" to mean something that has no cost, yet has value. > > > > free (fr) adj. Costing nothing; gratuitous: > > Yeah, and 'gay' means 'joyful'. You're saying the most common definition of "free" isn't no cost ? > > software, and that's a pretty damned closed minded point of view. I've > > written hundreds of DOS and Windows applications, which are FREE, although I > > didn't include the source code with them. Your massive generalization that > > So they are 'free' to modify, 'free' to distribute, 'free' to look into? > Maybe I'm missing something here, but despite not being an English > major, I seem to recognize the word 'free' in 'freedom'. What does a > programmer gain from mislabeling his products? Freeware != free > software, not just because 'free' is more than just 'free beer'. Mislabeling products ? Who the hell are you to decide what the term free software means ? If someone says, free beer, free bread, free hats, or free software, they mean the item is *free*. You can't have beer that's "more free". There's already a word for the kind of "free" software you people are talking about. Open source. > > > you can't start redefining words like "free" to push your rabid open source > > agenda. The people of the past who contributed their software to the scene > > in the form of public domain, freeware, and shareware were writing code in > > the same spirit as those of us who write open source code today. So why > > No. While (with the exception of 'Shareware' to a certain point), > Freeware is a gift, 'free software' is more than that. It is a 'call to > participate', to 'evaluate', to learn. One cannot learn much from closed > source, no matter how much the author charges for its use. Oh, so now the word free means the following: 'no cost' 'has value' 'call to participate' 'call to evaluate' 'call to learn' 'open source'. That's quite alot of meaning you're putting in that word. Don't we already have a term to describe such software rather than such an ambigous term as "free software" ? Open source. > 'Free', for me and for a lot of people out there, means my freedom to > extend my horizon by looking inside the program. My freedom to enhance > and contribute, my freedom to borrow and my freedom to give. This is > freedom, this is what 'free software' is all about. So you're going to annex those words and demand that everyone accept your meaning of the words, rather than using the preexisting term, open source. > I guess this is a thread that should not be here and I apologize for > adding my $0.02 to it, even though I know it's wrong, but I am one of > these 'open source jihad bullshit assholes' and I don't like it if > someone belittles the efforts of my fellow coders out there. Who's belittling who ? You're saying my free software can't be called free software because it's not open source. I've been writing free software for 11 fucking years, so don't tell me my software is not free software, just because it's not open source software. Get your terms straight and take your open source jihad elsewhere. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 11:27:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from irev.net (cx858027-b.escnd1.sdca.home.com [24.5.180.185]) by hub.freebsd.org (Postfix) with ESMTP id D1E1837B400; Sun, 7 Jan 2001 11:27:23 -0800 (PST) Received: from cx443070b (cx443070-b.vista1.sdca.home.com [24.0.36.170]) by irev.net (8.11.1/8.11.1) with SMTP id f07JRKT73332; Sun, 7 Jan 2001 11:27:20 -0800 (PST) (envelope-from data@irev.net) Message-ID: <001701c078e0$2dd587f0$aa240018@cx443070b> From: "Jeremiah Gowdy" To: "Ken Stox" Cc: "Brian F. Feldman" , , References: Subject: Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap Date: Sun, 7 Jan 2001 11:29:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [ The dict command is your friend ] > > 1. Exempt from subjection to the will of others; not under > restraint, control, or compulsion; able to follow one's > own impulses, desires, or inclinations; determining one's > own course of action; not dependent; at liberty. > > 2. Not under an arbitrary or despotic government; subject > only to fixed laws regularly and fairly administered, and > defended by them from encroachments upon natural or > acquired rights; enjoying political liberty. What do you think the average person would interpret "free software" as ? Software that's not opressed, or software that has no cost ? Give me a break. > > > We already have a term for software that just costs no money: "freeware". > > > This is _NOT_ free software. Shareware is not free software. GPLed, > > BSDed, > > > X11ed, public domain, APSLed (ad infinitum) code is free software, the > > kind > > > that is not often written for Windows. > > I would agree with this statement fully in the case of BSD and X11. The > other cases do not fulfill the definition of "free." GPL is not free, > although it approaches it. GPL, APSL, etc. are subject to the will of the > authors. > > > You're idioticly redefining the term "free" to be software with source code > > and restrictions, rather than no source code and no restrictions. You can't > > define the language. Free doesn't have a damned thing to do with your value > > judgements on what's useful, what's "no-value", whether or not it includes > > source, and whether or not it travels under the restrictions of your "free" > > licence. You're saying that the only "free" software is open-source > > software, and that's a pretty damned closed minded point of view. I've > > I'm afraid you are the victim of a "pretty damned closed minded point of > view." "Free" binaries are under the restraint, control, and compulsion of > the author. the user is unable to determine the course of action. If I > cannot freely change the function of a program, it is not "free". If I > must perform other actions as a result of my modifications, it is not > "free." I am being compelled to perform. This is not "free." Oh, but other "free" (open source) software has no restraints, controls, or compulsions right ? Then what's the point of having the licence ? If I may repeat what you just said again: > If I must perform other actions as a result of my modifications, it is not > "free." I am being compelled to perform. This is not "free." a.. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. b.. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Those sure seem to be compulsions. They are small and simple, but they are compulsions. So even BSD licenced software is not truly "free software" by your foolish definitions. X11 and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation X11 has the same restrictions. Although including the licence in future copies is no big thing, it's still a restriction, and by your own words: "If I must perform other actions as a result of my modifications, it is not 'free'". Now lets hear you rephrase your words to try to become less ambigous about the definition of "free" and how it interacts with the restrictions of the BSD and/or X11 licences. Maybe you can tell us how they are "more free". That's always fun, to listen to people rant about levels of "freeness". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 11:59:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 0935F37B400 for ; Sun, 7 Jan 2001 11:58:53 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 7 Jan 2001 19:58:51 +0000 (GMT) X-Mmdf-To: iedowse Received: from salmon.maths.tcd.ie by maccullagh.maths.tcd.ie with SMTP id ; 7 Jan 2001 19:57:56 +0000 (GMT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 7 Jan 2001 19:57:56 +0000 (GMT) To: freebsd-fs@freebsd.org Cc: Jaye Mathisen , Kirk McKusick , iedowse@maths.tcd.ie Subject: Re: fsck problem on large vinum volume In-Reply-To: Your message of "Sun, 07 Jan 2001 15:07:54 GMT." <200101071507.aa79033@salmon.maths.tcd.ie> Date: Sun, 07 Jan 2001 19:57:55 +0000 From: Ian Dowse Message-ID: <200101071957.aa07352@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moved to -fs] In message <200101071507.aa79033@salmon.maths.tcd.ie>, Ian Dowse writes: > >Jaye sent me a ktrace.out for the fsck that was failing. It appears >that the kernel had overshot the end of the superblock fs_csp[] array >in ffs_mountfs(), since the list of pointers there extended through >fs_maxcluster, fs_cpc, and fs_opostbl. This caused the mismatch between >the master and alternate superblocks. > >The filesystem parameters were 8k/1k, and the total number of cylinder >groups was 29782. fs_cssize was 29782*sizeof(struct csum) = 477184 >bytes. Hence 477184/8192 = ~59 entries were being used in fs_csp, >but fs_csp[] is only 31 entries long (15 on alpha). Here is a patch which should avoid the possibility of overflowing the fs_csp[] array. The idea is that since all summary blocks are stored in one contiguous malloc'd region, there is no need to have a separate pointer to the start of each block within that region. This is achieved by simplifying the 'fs_cs' macro from fs_csp[(indx) >> (fs)->fs_csshift][(indx) & ~(fs)->fs_csmask] to fs_csp[0][indx] so that only the start of the malloc'd region is needed, and can always be placed in fs_csp[0] without the risk of overflow. I have only tested this to the extent that the kernel compiles and runs, and only on -stable. Any comments or suggestions? Ian Index: ffs/ffs_vfsops.c =================================================================== RCS file: /home/iedowse/CVS/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.134 diff -u -r1.134 ffs_vfsops.c --- ffs/ffs_vfsops.c 2000/12/13 10:03:52 1.134 +++ ffs/ffs_vfsops.c 2001/01/07 19:04:06 @@ -365,7 +365,7 @@ { register struct vnode *vp, *nvp, *devvp; struct inode *ip; - struct csum *space; + caddr_t space; struct buf *bp; struct fs *fs, *newfs; struct partinfo dpart; @@ -432,7 +432,7 @@ * Step 3: re-read summary information from disk. */ blks = howmany(fs->fs_cssize, fs->fs_fsize); - space = fs->fs_csp[0]; + space = (caddr_t)fs->fs_csp[0]; for (i = 0; i < blks; i += fs->fs_frag) { size = fs->fs_bsize; if (i + fs->fs_frag > blks) @@ -441,7 +441,8 @@ NOCRED, &bp); if (error) return (error); - bcopy(bp->b_data, fs->fs_csp[fragstoblks(fs, i)], (u_int)size); + bcopy(bp->b_data, space, (u_int)size); + space += size; brelse(bp); } /* @@ -513,7 +514,7 @@ register struct fs *fs; dev_t dev; struct partinfo dpart; - caddr_t base, space; + caddr_t space; int error, i, blks, size, ronly; int32_t *lp; struct ucred *cred; @@ -623,18 +624,18 @@ blks = howmany(size, fs->fs_fsize); if (fs->fs_contigsumsize > 0) size += fs->fs_ncg * sizeof(int32_t); - base = space = malloc((u_long)size, M_UFSMNT, M_WAITOK); + space = malloc((u_long)size, M_UFSMNT, M_WAITOK); + fs->fs_csp[0] = (struct csum *)space; for (i = 0; i < blks; i += fs->fs_frag) { size = fs->fs_bsize; if (i + fs->fs_frag > blks) size = (blks - i) * fs->fs_fsize; if ((error = bread(devvp, fsbtodb(fs, fs->fs_csaddr + i), size, cred, &bp)) != 0) { - free(base, M_UFSMNT); + free(fs->fs_csp[0], M_UFSMNT); goto out; } bcopy(bp->b_data, space, (u_int)size); - fs->fs_csp[fragstoblks(fs, i)] = (struct csum *)space; space += size; brelse(bp); bp = NULL; @@ -691,7 +692,7 @@ if (ronly == 0) { if ((fs->fs_flags & FS_DOSOFTDEP) && (error = softdep_mount(devvp, mp, fs, cred)) != 0) { - free(base, M_UFSMNT); + free(fs->fs_csp[0], M_UFSMNT); goto out; } if (fs->fs_snapinum[0] != 0) Index: ffs/fs.h =================================================================== RCS file: /home/iedowse/CVS/src/sys/ufs/ffs/fs.h,v retrieving revision 1.16 diff -u -r1.16 fs.h --- ffs/fs.h 2000/07/04 04:55:48 1.16 +++ ffs/fs.h 2001/01/07 18:55:44 @@ -108,10 +108,10 @@ /* * The limit on the amount of summary information per file system * is defined by MAXCSBUFS. It is currently parameterized for a - * size of 128 bytes (2 million cylinder groups on machines with - * 32-bit pointers, and 1 million on 64-bit machines). One pointer - * is taken away to point to an array of cluster sizes that is - * computed as cylinder groups are inspected. + * size of 128 bytes. One pointer is taken away to point to an array + * of cluster sizes that is computed as cylinder groups are inspected. + * + * Currently, the ffs code uses only the first entry. */ #define MAXCSBUFS ((128 / sizeof(void *)) - 1) @@ -167,9 +167,6 @@ * from first cylinder group data blocks. These blocks have to be * read in from fs_csaddr (size fs_cssize) in addition to the * super block. - * - * N.B. sizeof(struct csum) must be a power of two in order for - * the ``fs_cs'' macro to work (see below). */ struct csum { int32_t cs_ndir; /* number of directories */ @@ -213,8 +210,8 @@ int32_t fs_fragshift; /* block to frag shift */ int32_t fs_fsbtodb; /* fsbtodb and dbtofsb shift constant */ int32_t fs_sbsize; /* actual size of super block */ - int32_t fs_csmask; /* csum block offset */ - int32_t fs_csshift; /* csum block number */ + int32_t fs_csmask; /* csum block offset (now unused) */ + int32_t fs_csshift; /* csum block number (now unused) */ int32_t fs_nindir; /* value of NINDIR */ int32_t fs_inopb; /* value of INOPB */ int32_t fs_nspf; /* value of NSPF */ @@ -328,11 +325,8 @@ /* * Convert cylinder group to base address of its global summary info. - * - * N.B. This macro assumes that sizeof(struct csum) is a power of two. */ -#define fs_cs(fs, indx) \ - fs_csp[(indx) >> (fs)->fs_csshift][(indx) & ~(fs)->fs_csmask] +#define fs_cs(fs, indx) fs_csp[0][indx] /* * Cylinder group block for a file system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 12:38:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 8E47E37B402; Sun, 7 Jan 2001 12:38:06 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA55171; Sun, 7 Jan 2001 13:37:57 -0700 (MST) (envelope-from ken) Date: Sun, 7 Jan 2001 13:37:57 -0700 From: "Kenneth D. Merry" To: cristian nicolae Cc: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 Message-ID: <20010107133757.A55049@panzer.kdm.org> References: <3A5870B9.D4402452@chello.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A5870B9.D4402452@chello.at>; from cristian.nicolae@chello.at on Sun, Jan 07, 2001 at 02:35:53PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 07, 2001 at 14:35:53 +0100, cristian nicolae wrote: > Dear all, > I have a Compaq DL380 with an integrated Compaq Smart Array Controller. > I have succesfully managed to install the FreeBSD 4.2-20010104 > and everything is fine but the DAT drive which is not detected. > The DAT is connected to the same Controller as the RAID system. > > I have checked the archives and noticed that I am not the first one who > has this problem. But I could not find any resource which could lead me > to a > solution. > > If any of you could give me any hints on that, I would be very grateful. > I am at the point where I am considering switching to Linux because of > that. I don't think the ida driver in FreeBSD has SCSI passthrough capability. That is to say that it doesn't hook into the CAM subsystem so that generic tape, CDROM, changer, etc., devices will work. I don't know whether or not the hardware itself has passthrough capability; someone more familiar with those controllers will have to comment on that. If the hardware can't handle it, switching to Linux won't help you. If it does handle it, switching will only help if the Linux driver supports that functionality. > On the other hand does any of you have info whether Compaq will support > officially FreeBSD in the future? I don't know. They offer FreeBSD in their test drive program, though: http://www.testdrive.compaq.com Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 12:47:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by hub.freebsd.org (Postfix) with ESMTP id 8C32237B404; Sun, 7 Jan 2001 12:46:27 -0800 (PST) Received: from CldFsn@aol.com by imo-d06.mx.aol.com (mail_out_v28.35.) id u.f8.65bd20b (3979); Sun, 7 Jan 2001 15:45:40 -0500 (EST) From: CldFsn@aol.com Message-ID: Date: Sun, 7 Jan 2001 15:45:40 EST Subject: Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jiha... To: data@irev.net, stox@enteract.com Cc: green@freebsd.org, freebsd-hackers@freebsd.org, lan@irev.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part1_f8.65bd20b.278a2f74_boundary" X-Mailer: AOL 5.0 for Windows sub 128 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --part1_f8.65bd20b.278a2f74_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/7/2001 11:27:46 AM Pacific Standard Time, data@irev.net writes: > > [ The dict command is your friend ] > > > > 1. Exempt from subjection to the will of others; not under > > restraint, control, or compulsion; able to follow one's > > own impulses, desires, or inclinations; determining one's > > own course of action; not dependent; at liberty. > > > > 2. Not under an arbitrary or despotic government; subject > > only to fixed laws regularly and fairly administered, and > > defended by them from encroachments upon natural or > > acquired rights; enjoying political liberty. > > What do you think the average person would interpret "free software" as ? > Software that's not opressed, or software that has no cost ? Give me a > break. > > > > > We already have a term for software that just costs no money: > "freeware". > > > > This is _NOT_ free software. Shareware is not free software. GPLed, > > > BSDed, > > > > X11ed, public domain, APSLed (ad infinitum) code is free software, the > > > kind > > > > that is not often written for Windows. > > > > I would agree with this statement fully in the case of BSD and X11. The > > other cases do not fulfill the definition of "free." GPL is not free, > > although it approaches it. GPL, APSL, etc. are subject to the will of the > > authors. > > > > > You're idioticly redefining the term "free" to be software with source > code > > > and restrictions, rather than no source code and no restrictions. You > can't > > > define the language. Free doesn't have a damned thing to do with your > value > > > judgements on what's useful, what's "no-value", whether or not it > includes > > > source, and whether or not it travels under the restrictions of your > "free" > > > licence. You're saying that the only "free" software is open-source > > > software, and that's a pretty damned closed minded point of view. I've > > > > I'm afraid you are the victim of a "pretty damned closed minded point of > > view." "Free" binaries are under the restraint, control, and compulsion of > > the author. the user is unable to determine the course of action. If I > > cannot freely change the function of a program, it is not "free". If I > > must perform other actions as a result of my modifications, it is not > > "free." I am being compelled to perform. This is not "free." > > Oh, but other "free" (open source) software has no restraints, controls, or > compulsions right ? Then what's the point of having the licence ? > > If I may repeat what you just said again: > > > If I must perform other actions as a result of my modifications, it is not > > "free." I am being compelled to perform. This is not "free." > a.. Redistributions of source code must retain the above copyright notice, > this list of conditions and the following disclaimer. > > b.. Redistributions in binary form must reproduce the above copyright > notice, this list of conditions and the following disclaimer in the > documentation and/or other materials provided with the distribution. > > Those sure seem to be compulsions. They are small and simple, but they are > compulsions. So even BSD licenced software is not truly "free software" by > your foolish definitions. > > X11 > > and this permission notice appear in all copies of > the Software and that both the above copyright notice(s) and this > permission notice appear in supporting documentation > > X11 has the same restrictions. Although including the licence in future > copies is no big thing, it's still a restriction, and by your own words: "If > I must perform other actions as a result of my modifications, it is not > 'free'". > > Now lets hear you rephrase your words to try to become less ambigous about > the definition of "free" and how it interacts with the restrictions of the > BSD and/or X11 licences. Maybe you can tell us how they are "more free". > That's always fun, to listen to people rant about levels of "freeness". > I dunno who has it, but here's a cool little program called MultiRes... it's like QuickRes, but it's for Windows 2000, and supports refresh rates and shit. Oh, and Stox and Feldman need to, like, sit on a tack or something... --part1_f8.65bd20b.278a2f74_boundary Content-Type: application/octet-stream; name="multires.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multires.exe" TVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAALoQAA4ftAnNIbgBTM0hkJBUaGlzIHByb2dyYW0gbXVzdCBiZSBydW4gdW5k ZXIgV2luMzINCiQ3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQoAGV5CKgAA AAAAAAAA4ACOgQsBAhkACgEAAHQAAAAAAAAB4AEAABAAAAAgAQAAAEAAABAAAAACAAABAAAA AAAAAAQAAAAAAAAAACACAAAEAAAAAAAAAgAAAAAAEAAAQAAAAAAQAAAQAAAAAAAAEAAAAAAA AAAAAAAAvO8BAIQBAAAAkAEAAFAAAAAAAAAAAAAAAAAAAAAAAABU7gEACAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAzgAQAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABAAQ09ERQAAAAAAEAEAABAAAAB4AAAABAAAAAAAAAAAAAAAAAAA QAAAwERBVEEAAAAAABAAAAAgAQAAAgAAAHwAAAAAAAAAAAAAAAAAAEAAAMBCU1MAAAAAAAAQ AAAAMAEAAAAAAAB+AAAAAAAAAAAAAAAAAABAAADALmlkYXRhAAAAEAAAAEABAAAGAAAAfgAA AAAAAAAAAAAAAAAAQAAAwC50bHMAAAAAABAAAABQAQAAAAAAAIQAAAAAAAAAAAAAAAAAAEAA AMAucmRhdGEAAAAQAAAAYAEAAAIAAACEAAAAAAAAAAAAAAAAAABAAADALnJlbG9jAAAAIAAA AHABAAAAAAAAhgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAAFAAAACQAQAAGAAAAIYAAAAA AAAAAAAAAAAAAEAAAMAuZW50ZWNoAAAwAAAA4AEAACoAAACeAAAAAAAAAAAAAAAAAABAAADA LmRhdGEAAAAAEAAAABACAAAAAAAAyAAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBD uzKZEaqAK8e61r2SakmiTQEO8AiMOkIdJCApDRF1CdGHfUkOkIAiVIMOlA2T3QDWASOiVPTx lCq1tzi3dSq3opXcqW1gLVkmgnQFCSApBHoIPSR9FYgIaAia1qB6QbvKhb+HK3M3mV5zOfgP PykLd8yBecu9Qbd7gVrdRHawWu7qRGkB65AbTILa5IW1yRW3NAtcgXbckFrgDeXIG925Jbeb yA2uRrvfMBu+XLzfLzn///7fP778++e+eeffPvzz33Pf3+d/iYktAlrslo34L5WaeVL/LvXz M8H9De8op67KmaN59+PzMJNCJ9YGv2tmZpqEoZxKVG0WQTMorWG0b6zTcJWhKnrlnZkAM2rs wVCqmi5Ly9haGisb/aoRGIAq1h9ezTQKxH02AKi0IJwcAGLDFOtAkO3GUXLItWO0xX+cVD/g FY7J7CLS4bKs7Na7II0L9rtPr08K8Hya7ZGi1WETfWdQCwcIZlVWYRntNiW7FYkW0T5mEpKu XTPn6LAiE15VPr9kZrP2zTbVi05dZrHYTNnEYIqdis8UWaas4m1Zmtv2B5rq1RSOPf11KrFX 9dZWbfRG2FSV86jtf9CSx7+hlm9fmTcMR2g0RbWwgOEDKY6kOojzkdQHVhyo5QcmOGOEO/F8 qcHxo76Pih3sfoR8OPzg70Pgx2DvxLvxS49PHpo7v8Xlx3Ue+DuA/KDt4/wP52OtcrTaXA5r eAjNOZ11JCCsoT2ktBGFjq2OxlIWHDe66bu9LhjFICzLNyw8gciTg2rriGCfCzkVJqBrI2Iz igJICos3huuwqHC4ZuJ0DFgekTbyebHDvFgm4pgmCtBwIUBNRYc2SDKh18k3ENBjCKcPpEWB URofq2DqQHAT8CBItwyr8LlyHt3JMZQtNzKgA2iyWJBQlhgXChA8NN0XSSLRZyMzL6X7JAnh bJGb4DmgOiDpp65OBkNYcId7BpZaU1ZNXw89AyQKVENLPtrs4MASqUOz2Ss0UnmLbvaCGZ5p fkMzBCoika4AoEZXe/EMWAmAtYZLAAOEoVFsCZSFRoKDUJB4ggpRTVcgK0qaJs0VXcVjKAwc O+pQQxRuIDE9Q62IBXGWvxaPibc2B9a8mEEVCt6VyubUONbmdOwY19HmkDCtAdlIM4SlB1ak Exo+cFLNh0TdQYJvp8ed8A01Qu1SEoBIwgoEMxmpLwDVkGFjzT26LgemHZQ+7kz52rOkVTM/ 8HWw8r2roomiwXg/GfEe+3ufRaophiqCm6LqmTO/JWOmj8oamSdBUDKAnsS0apgaCZbJ22oA cyS4ULZ9W3dywkOLRD1BHz+9tBED337a1pV61iTHRInMQIgF134AOeNeSiamffAXYrKw8ilW zphJtnYFYRNQBVs8CfEFZwzV8K6masaOB3B0rX0QT6dOkoPa3I6nxpLEID1lY7raJBBNVvsR PWZYKZ4YtPBvaELgUJZIsNbCIOdLNKFbZC6CC2Stk+jpRU8q5KtscbM8L37EQ0Gbs15PUbco avhTTqyKVp1mFHUYyPKJ7/qBKWpgGJfXgjYwpAF9VYJW/sD02AFFTaCQM1LdRGuerixVFnCL +EH42XxF/61w1sxJ0L+8qRm5z4dUz9a3Q7vMWT0gThpeV+KYsFuAKXGjAwAMJIo6KvLJEmTR DAF/XHcEdbvGWpiP850y7fhlywfcjugOXhFfT29Ej1PU4cONhHWgwJKCThFPXWtcZfuEvCSx UizAyIH3U8KkdMQRILNBMz1X/PW4uVP9lw8ZE2x9wGEVWMpF3I06KB7iLCkasIRYz9KNsfL8 IjQCL39/8QHk8dQdG75Bc+JNwJ95ADnpEmlwFU9ssaPx0l2jMALMTLdUZp0dLpgIxrCQ//G0 JmqaitRIKAXjqPzP7tQrlkrvGGr4oeYZUalBkEeO2+21Z7E5SlqZJ9a+jzqW55oroMCDmlXB RJ2NJ+yc3x1HUdgryBNmGEn/2OEM+FtIyosYHBRU9mfE4UNVp3XcfFpydnSotDTn1kGKWHms s+AnRcKxHaVYhaAzqOhrhSITUtUpWg1EFM+heIPeeUyR6Ij84t2WZzif+UUXFibJcLUCRJKS 3ktZgTbPBYdhapwONLrRCSchnFN9eQXZJQWHNnPuaRNj5BYcGWuVyxClWfmYtnU6J4s8bfEn 2s9CG6Liu4Cv6oZjQxB3WJ9ywGlZqlPgTvLeLuV36grvp05KIcA/6jTz3VNPPYaOK2Ev9CFj 0fjdQuyx0jbiTjY3KKL4AOzJl8sV1SAvkmr4TZ+Tnfi8Pf9jj/FKMNXa/rloskM+nCS9ji0X M67LKMBNryEms7jRdjXiri+EfDURt9YueNGnsIgT3PNAQY38nAkab/p3YE2t2qvKgqRMs42t KJVIpBM3BNGvI6BGXvzj3HvdqLCO6BfjT4G2qJA1kSrSnuhJKhW1AeHtJyRQJFBBg2kohNrd iOfApMVNQU6kPyxF1O5rpQ4i+Ifjp245xITYLw5K3MwoxqHko0pxq/EZEhcJF6tKaF3bEyAg k5GlLJygJd4rPvoH9ryGbBPPkAb/zbXidMZVRZdViZ49yycjsdsUd4xxAgIpRKCgLWTVXMta ifbAkn4r3JpgRLngG/QK0B6WDoCXvQtMlNoMTwkcJPSCe8ImZqDGAc+5QC+T0ANbrkwOn50X Um/+0RPTTz1JEMF9kmlFebSm7qrxGa3EMBxVyaE1W+mjhS3zSTsKqxol7AucETCGT4SYSMxb V8PsWCjKbZ021J9WBzKrzUTzeT0RfXd0Pe0XtyaExtUIoDvI3sLNoauv7m4h5+c1SWL2PT58 VokheSczT2UFtRNryetQEV+acel8o+Au3bGo6sr83Frx4WuhizwanI9JcgeaykqsoY1G0VU8 80zL0RRvpTaDFOLuz9ws9zZ9WQ9ENGlqz650uBf5mUt5T7f1KPjKt3z2NOpEE2tUSYjd82+W J66dhDm3tI9EzShYgfW2nqfG8aB+kWSZScjJn7dAIme1bViAlFnpoTI9jl1RKIb0GgRLsOMJ CKZQs5tGxjCqUC7MyksTM09h3vWKerzmrSHn5qBAIR04sbXlCV/74L/Cp8G2rkXfgknZyERN BfIPdJl+aUyMgI2H62es0Q8u21oOQSb6lfVafeikXxxeyK1rOK2zfzqGCscDjWx5Mk/PovSg cvzAUB95aO//Ds+wZe+H9jYU/2Vy1w9P9ro1w4DWANdDz6uJwE4FqCDT8QMWfjb75YZMtYu3 lOR28a/q2d2NO07CUefEm/J6KZlC3GKmamrfHxSZIzsv+vBeOxIUzVpua83P84AGunDhXrvM aqRmeuNEdkByVXNH9yQywRLmuE2BDGmgMWWn5lIAjOkrWUcj7wLpGQr/5F9G09fWfkAJmaon zVL0+aZp2358SalMwljHVlnYN02QQ3Y9QoCho2lGsS/GskUt6RyZSNXteSjhyfdeF2tYtjhv 5I04EnE4R+/IITfwX4DiSN6emoBlnczO+3xlMf1g6K0+xxsqPGMbMdn45nsmeWtetrvJY0FK FMnAdflVAzYrIoAYif2sYv77Ogx6e+dM+onwXhpFp7IY7jUlT5d5qlMiUIfNKPJKT3KYLSdr jUqQOYZOChi/KXyr7pAdAIdjwmXr+sfo8Uw+OI0v9drfeHz/LTf8PcTPukPebUSX2aSgG1ln 6egSBtXPbpAUBjI/mCfY42RMp+jKl9zzgeOzLZl43sM1I2aokapJDhAReBJt8Bgnsi6Tx7kS k+F3gUzLSV9ciyFfp7IlKvNraj0SbKmqbAcLLUdKM0ZUnursavU16vzJwi4JGwQetcvJTvul GVxzkREUfyPjIh/jeSa/7uaJkBlQDoatwcj/bSR0mDSZTt8NNYwQlzf4TTBAc9eT3eGD7+FH VUCA99qIX/gKjTmlGujfjWTR9/Kv4Hs10wYLfKdF4ed9JOgHotk0/gTWg2EVealKnLeH0Zps pZSokZ1gsgkeYn9PbaoQC+iO2FUygMe+JPHKEkT8cSIy3+xipBFHVLSb5KNM8BzpLntEEl/B SSEfx/PuH7rpBW6bS1Prjb9sxYWhG0se06zvlZ077vmiE50NfPxKmfigb7uUKQs6LwVB1g8m vopmS6sVA2e8eZFr8/p86rG+nKUWWWM7r5aU4RoTiUrPXN6qLS0Go3hmaglBPDTTo2E5gQt5 zVpxKlqeqklAfGpH5hM3TKI1nL1hT2YHuMnZBEvTZfEm8zWLsGnWpZT+wSXmu2L9Bz+uU22u GcDQYBwOa04uSmj+kC19+G3fWN2BT8ycjyb3Ln381kLPtvIwulxpTQDqDCdxGPm8jB7Vyxbf 5kSwtBgPuUypMOzYNSkdmDCBuQDJ83Q3duyRPKGT5EcBNsdhKVJX6cmBXVCZQ/XNFk6F7cYU rn3/vG+tTRIVPO+lb8XpD0mujWHuIJkHF1xGSTKdeGC6NS1QoU7+myOSpBAag9gGOXpAV/5d 1dsJgXXmMBhnq/YXm+c53nufw/QRgRhiYdDhpvf0XGVki8FdwymmEY0IXXu1ejpmu+Y3qzp2 Qb3LDCUdYcLoj9ltguYam5rqmQp3YSITbclMnIp5hnDgiPOZesHlXPpG0/2LxApl229oSPbl novXandaAFFNKSmR7Vfq1WxXMXCCuqzj7jNRKS45AjbqLjONFcTXQEsZxlg3s22iJz82tKe/ aBzPq/pQ059fdIYn6GPT9BHT70MQXLoSRlgdPUrZ1TUWoBlNauAIQIkGjZEbo1jHDbrT4Pna 4MkXMOlr/9uQk6nLhCE/pwYf7bhJFcwYMAjtKAjRtKEh9e5HtWXaGesQYz5Gh6y7VjylKq9G hKzJWLd5xJFGKZnLM/QBq3v0UEkvjDeYQpCiHm2TyCxun4HqU5DWvP+KXRVDmTkBe1OqfM6R Fg6vHLWBNdtWCLgc8oNPtN+REdpd3fUOSu+E9sRolUxnxEyQDa+WMYZRU+IZIGb3n8B3B1bF dLnzArq44crY4EFeI7Ml4zj4Hjv/HWCUhaQPmEfowq7gr4bluX64pdJ8vtWSUhDnwQoFo4i9 mqqJUDymej+1KahlaDku20VZOW2hNobUQcCD1oihYZ6PJ8wIVRKaStcV8cLStOkvjB496uD7 XVTnhunyd9hoG5Xlo+Qn9yQnQIk2G1kkUVLR0tibA0zPJFtd2o2mRH3Zxw4f1u8yNx5vDYni MLRyqlteCBGNRfOEBauhV3a6Jy3rEjV2lfDJbyIogL6Aky1SfjJWpXSnk6VT0xq6TnzIdRM4 tcub1LT0XxRutmIEe0dXNghXQVyZOPAwPau4MMrWlRxnH1zVnxXewbNdC5lWBWncFsxUjlJU OvP0E89NmOMjQb7tECO9RDDdyhcTlQXhNPAs5Jn+RtZRCUItjpsTCvzjslAJ8iQOsL8bjBfB /eoqujUVAEsu8ViMQlUz6qSN8cGrfCg4DDyUnmSfySewmnQjY8X/MImVwFdxSNq6JFtkIOCo 6gr29P2mNpPAaorBm9XKsYJ3Y0vDCTixylGODQVMRS5ULZ2EySWkwtdO9BXQEzthfdafK7sr nbpOwWrnGzHCTaHneDTmRulWSabhc7pxDAVcz1PfD50acoZGG+CFdK8nJNKUUxqxPPmenqMM C+R9Md0LgVfDIpaN01iA9YWrRHOs+Ic8h7GaNnP3NKGTIWpPk/IkGpCoutEF6PqGoNScrOZI xpVXM4vRi55lGnmZz8Ge9Sjumf0llIO8TJiYWM6Yxqu8yrrFbECdizoWyE3RbDeJhUYq2UsQ qZXa4yyOzglHZX6jIslJGkncals0+j8hU6xHIxJqWgkdeQthWyhf8TPgcj0ychS/kD3Z4ISb mDDFWLKRhgwY+2M2yG0GIH3eAgM99aSUYY4rlDPR6rZDmdAWyDUsvghTNRjJRP5VwW1sYkac Ugg46lDKOzFdXh3YdHx4y1c2I17dVM2LtSecsym7t2emv2LcFlofYsbakBjy4e2GIntl4li/ puAhkAYnIGBQEpMvISdS7eymyc7yn3IEMZ15bHCDGs/KEHGvUpRCFcolMOZQ0wBkZHIlIusQ J4xxfMMtEsuxR9Ro8U1ilQnIQ7tKCbNtHW7XMYvFZsBaSYLAG6b0GZhqNG0jS5UUJ4nYX30a fc9DMzFu3y5bJvkg1byGyjl2/Z/j7JQk/BUkTqgHy9H/VbNlJxtSUhyIq8bRAO5nZC5X6ZnD pGyExnNBWYJG9p1uTKsCjclVqzv+QGI4akncErvKu7Db19RNWP8HLzPQ6rbVS0akD9qpONit eQjp0rS5dQGJI2qKlYgM0U26rwWzJTLWKzW60xyBtKmD+dprE+SBzyTSs6HuTRX+4D8TtMF+ 2LqBQ1vgfV+QuEmSAk/LxRp4EruEvZ2KUVrgJoLM/tYxFtJwv+7GUFiU6Me2MAJslfQT2sat xBtXeQVT0tpxsKFhE68ORSOdSnq7NQfqb4FZQsRWuERPcLjRhK8teyzfNhK3R0g+gVH4KQKr TAJVht8SP5Dp3eTT2Rte7CKwzEtcP2mTOF1H4X4lIQrNevqY1Oo/V540lDS0JQhqM3Oo1Fbn YahN3MDUBuwI0+hFO27CDTduwA00bnoZObubGTG7CjJLdfhiMDUE7ql2LWTM/Cr7kH5k8Rmz ePDkH8gy5ykj7fh7WW1vyxqAFyciT3zI9FE71wr15XsVzkhSI9eZIeTIL/B+40xGqA2/C6bb CofcPR4g3dpJCL2NsQEyNeik4+e36WgrOTFSLn6Sio3F81hlWXUyTAFDXClLNZA6ITWSBnqg TFmPIdUk9tBcnh6H9QVtvi7OqiflX1Vv00G34NH5+klZad1iSUdvTG/EbZROnSis5wspfb9e 2pblPpxhijHd+4MxGoojM94OLWk+tdJkrRHQJGg1ydjNEsQJtRtVQHwMiG+7Us/O6hYPNm04 RA+403/YTCyM8V2MAnToFrW+pHKi0zIWBDJNtqBzZ4E3spULzQJroYJQFjRsOrGcNszVDVus Mi3cZ2YYgVCWzPdJJAskHMB/HzeSbAxLRdwWmzNdJu3Vos/UuJNcO3fn6BKuCiYNOCXtRpgY myimH50LnNcouYZUKU63Z0bVBi4EU54R2QFdJIlJYrkK+6hMV6jSGfRb0ZUxC4i9RI9pD0no tjCUyofN87RZu6MVOTBJxTqkQEmeakRE08SESDTkGM91DrhXhlVHh87gNqFxhhFwiu4YvkDJ HHvDIQcWSwdlY35JHB+N9ZvMseyfcnOUq/69gN/fgVp+IZFZwEUiVrGUJd9BVkFmqCajHT0f RICQuQirRJrDEkuR8sVErxYmInRWZib+6Ru2Kj/MeidYIXAGALj8SX/JJukaBegVN++2EyPe lJMfzyyIFKHESO1c5Eo72Yt+fM6wLEz1gsxGEVVdwBVOGKyyuklt+qRnF93yFTmBd4lQFxcs 80f2IYDu7VMy+MrJF2osVLKsp5kbVPhjuH14l+kw1l3T7ldesj0LPFiWYC+/Arb8qO9tIkHJ il9hCUICcCfrOFMslSmMmVYPYpTOdTNOZM06E6kZxAyTBoZ4NlNYgkJQO06mnls9OKb1ZmnQ KVa8TsY+E19BmzRXQyDgNuvejGUYpubZsy6IyuiAo4vhVxGKwgInrB+aEpgzpyoI5aBPnoib CbzNLkdXXoyrrKUSgsYpvzI+Y9NNQMCO8gaBPNBATWuiu5tjiB0cDI/So20KpNM8Webt8/VM E2OzTOlnC3GZkNlsif6Shmau8jdELhRhs9dbW12SnJvzDaQW2qYWvolYFSfqs00VZwFvoTYd uFAVOpWcDcCKE1TIEMW2h07v/R/liflTI61F1TkWSX0XK/khgVd+raOBqVunl0SV9UeLgoI7 8qLf8/3jGe6hyEKRZmKZVdwGJyK+yinFR3/Xyr66SudiHsACURndTVuOEDM9NPZM05JZgXDz FVpsEySNSKSFtT85hqwQ1EFd/Lku5SKXkY1Os9S0kRep/FWeV3ZjulSIfHbRExMA0piSCXq9 NyENF1oQSMKq9x6eGzxoPK7zdEm6Vog1HEwSdZqUEVT0yEph5OEqjcR+N+jzDWQIRSrild6w ZgFv0DsZ/eUGNGyspO1FCRYxgytWReZQQlXqQRBVKRFZrFITNixKFn70tfGUPpmFxcsJOfD7 tzj7AlvnaV+4N6Vwk5sVJ1IOblplmH2uffXsMqBIexCNC2tmBE/0VcUMMdbzyQquf5eVksIN /ydvJPaEAcwsPPaJ/PWQJOkkUVyJx/6BW/cg8xxleix3BgJbbOIoX6ei1KqetAvdyvhPv9Ot aihVZ4F/VqFa0DsymEY75e6njH0VBtTltUGonx60x/2hp6azBn0vWa39OW6alSXZuT/SLK3F fmSu82MBXHuW5E7Mzs1kSdrmzXkQiGc5rY9ku0aq+R0rO+zb9dPG5VfrPYzVNQ9PDDFY2umw 4iE+ygxPRFq/TKyITpxNomcotxOYpKKwQQUPFDcOVOPGZ1L+xS/yyjNMIhuFRDferYj++nkt wT2ysHeu/xW6VqXbO4yEdjRJLHy0OC8+w4x47Vuq02oBoss2ywUtXDpQ9u2bCQTCsUlmpwVc JwI/Hig05+qOx/V8SNUA6Kvm9vCaKVt4ISkV7coVD0hKx7HYkIhnxvTCNIf2sprlD8ev20kw phHH+hcsUxooYqxgIgwtjLPUvdeD8ym0RHk0SioeWoxOuWM1kif0nP1TK+JNGO9jdsd74azl m2svsNwL/l7iiT6YcWj05/fdQL1sriOlFHmDmXTMp1FEhSxfW+hK9EwolHejUadALtf8HqHU oiOgI+7yNRM/s3DJb01iisVANTPC4e9Qt/bCRU/GiJPBCkpiDmvRnyJ5EGu929WiM2zd+33y mrHy5M67oQ7HilQdjpjy3F55OiRnhbouP1YBQqK9fKMTbArEdtRPLqB1WmI2RX9oFCw4blrx HowWwgQw2PNwnaw7I6Zh3JGbCxd0GMygZ6ufUEbHnZYn27CaoThYXsBkh3iq0B9RmK+U6+Vk p9R/fwyCJrAIpZmkPiSCjBN+22NeyMEXol2F0X1Fvi6xqHoEXvZB/0HGT883DKdteIPQSpp5 Z/UufhA1XBg3A2fIH0eU1QSw2WROW1fYJED4iV3o4dQgMfFSWu4B3nCS1ycWfO1YOy5ru0p5 KFi6FHY/R2vsLQRWHCTGhjQYbKe+7vwMHEa70bbw9Uy8HIT1cRlYEUwH4eZjoFUauUSdB52I SLjdRLbaquWkGCb9nTExyyvjUCMI1QMWvyMciDsuOGhx6qYAfqNhC2oy1b2cdxPH+OAKwtIm UqM8jhW4lxNwt1f5BPHFN9kjnL59AeQowzbc9OoKwKEfWJ+SzgUnqjI/N18rB85ocbSy6ieU syptpdg2NinnweBlKXuZMvcnYSZ/1AlZPmDL2wXOibmc1ryOn8MkzphRlzKpxtAtRjj2/ftm lLTNwu3w6lAWR0UkYu03pfo1ONZEjbZ1o7poDZ1jU4LIylJw3o3dapqPbEfe7FKFk4cWpK3q QvlSnjlsDqHqG1T+BcJacyabKtm45wu+uEIPEKLDz+E+Ou8Pxpaoncv/Jd4kvJqalmt6TPWK qx/UtTkrXOa1PS7xfJq2fV37TKPw0zL7kovEJ904S8bxBsMbi9hmemirK8SozNkcHSob2dQz XZnY2QCGUG8OlIBe89YwNW7Di6SE36obYxyjhQwf9TrMIlheIDuF+Zc9kuR+mKWhri0SuxTm kaENRjj3qeOBcC0VkwnTCmbJ6Tf6OGfdpXpVZXpSxS6Zu2701ZW6guLq8vzCEwo4BGGRvq6x U887qkf1mT3T7KBtWo8S3P6YeJHtQ6BzF3sM7Wpzsg7ICNlx2+xxqzyCvU3uQdDcre+RzbyV 7vL+3eollrtwetAKQC3KBK3epVFVMFCzxcZuQgVVvxhhBfsZxnka1iuMg3NkGApt8ELUcXMq DDsoBOqSEyMtc7xYnJI+TwM818t0VcwiTe6bG4jWQL3DdDT4XRavRfQxQ4fv/MldMzKG/mZU yrrvmyp0Hm1iWXp87SmNYw10narf7gmmGLcpH8JSdjuwX+u9l73btYOkfrWQZVo4X2nZ9Lrz LMBO3pZJgULnMzpcobPeIrQ2U9iPENmnihn2i3Y9/eBeGhtnFMTawne94DB3oh4DmWLmGCjZ z6wgyJp2l2Y4vkMe8VGDmVVeAObD3JVyUZnCWDe9RbLBs0sAi8tBKEk7G24ntbaT9tUOEw1G rLAtlwuednF7SBFPW5QhTslcKhlQ4RhtR5eUFx/N4967tVvqGk0bIP+HgN8g/uuW+Obw1H3j RIbwvTmwv6Go7cf6g3kfiiJcd1SMtkSY5fiSg5g2njqeNmmVauH9tN8qpcpys6ytEs3TqOVy BH2illC/JLl73XKFeNwb2k9N/IfovSXL2dF+O1Y1S6P4NHf+KV/e2DEqz+HyztPPZUt/vtI5 T3Pv93+MXtlOsybz1OPvYoe6ul03g/668X0a3e+jI2r2E45KhYR6XcvdrxaKVbvY8EwHvgVt M3mbs/vameu/TcvgJ45YKrF+KuSgXsLDXLkxF3XjZ1dr1xtp42sl6cnqWNod1v+AZC9yS+GO W5Z3lrrxfok29bthEq63ewF+fq2/B8w7Yt29cX4egNa8XabS/Mxf+X4NqVfee+vvt7IX5n3W BO1Gf25F0vxahxF9m/H3nqFpbw/BvjU7b1e+F94t8dOOjuKrd5v8KaVCzVmhrLbj7Vh2moKz tT8Sd4diunSVD2XPZD2+SGuHHMK5wdJstenT9Qnnk1y2Ynl8WqUm5NdCXXlMu2GCofGe4uy7 OOOOcgVxN9vmRXa5xLc+JXE3TF2JeweMx43QVL2HtMCveu9z7RK5x63hvWV909mne65Dip1i eLX5wUMtfsTNsdmCq9D7vhVktTG/kemY+ir61fa+WB/LwjL7p9u6k4VjjeD3ewgZQPVBr4uQ w2/HMZQ+W9y61/nWq0cR7VSuhFi3y+UEy+1zmbR66Z0zkL9wEpG3+b0J2u5bbqvccOR4vBwU sbIE/LVPK0Q9r/6Tet2Dy+e1GPuaQsQQRgWl5WmHyVjdEjnIg/XQXij8ncS0687UXuiRVIQt 1Gk9bmF+eII3RBPzQAclM2r/l9R2g2f+I3zP/TWIffB68OyD1gcwO9D4Md3H5cd1Hvg7gPyg 7eP8AduHvA/vB+MH4ofiR/bD8MPdh+DHuY9yHah2ke3DiD4od7H6EfD+AKoD/F4Ye5j3IdqH aR7cOIPah7OOzj2IffB68OyD1gcwPVB2AddHLj08emj0sdWHow9EHUx1IdRHnI6gOVHKDkxw xwh377jo58XG5RP5L/heXHEFU1ylE19xu0sIWuQgV8n2AofKn1A/OT6ifUj6mx7G4WWWPumB V2vuSkFdu4ZA9FGgkQv6KDPIyLUBbCsb0XC+VpihMU/i4t/+04MnaFCGwxP/xyxLXrdvrNah LJabQF8q12iZd+7rbnXjzT2AovVcyJV7HVWb19pte/tuZ+VfB6LiveG1Olk1eqNoiEL1rteZ 0lxKDBpXZiyWf0YI0t8i1Yf+8VmNJi8u2S2VDf2VmREu2Yvw0Bx9oJisNo35mgOmDzDinxKv bGa12Oz2m2+M6NOaj90N4tRqrYRGfUC5hjJEi7tWYpFjWyw2eyWKr2rMM9tAcfdDR0GNlIiM 2kuJ6gOPvRvug8w2c1LxXhVm0WLRj8ZoKpeM2En9aYtNktAjN99kridJU3W9auWFoEzDsPmH TJeXLTaI0Z5nfSU6n8hpVeW9933+E/daslps9h123qXHWep+Y9WMWuPp2dm35mzDLxpHCTl5 jEsO+2b71vSMM+wDkuOJCWu02dc8Zo5WqnjPpVqw2uyWH0PQRCVT0GqKaLy9bkYraLDZ/QJb dpbMr/yJBvkJ0v2ep9hq8+mHYemQYgbt0Qw9g/1XKY9t4ZL9VEKW8wSxPwrisvFsIivCy7Yz 3QlFum9ndye0TzX2Ft3J790uKBHT+Z+P1ClTckI9J/wjfX8IqO9dRY2+ev/oV3u6AfzfZlPb X5dAX/b4xYwJRjM79TP3Jzelh7uhMfUCCjf0F+y+RCXk1+h8KWFMYy/iI0DpdwqQ6frxtyey J24ZSLYxpSmppn51StmNg23pgL76W9pxVkH3c+ch4wCrf1sGC7i+PU/TNTbis6yhbmhtzzT+ K9rle36qxzfpF0LcERbRyvkyz+0GxZpuffsbF9/7CN8LOYsP1ve50LXtGVN3LoCw7N7Ud0/P EU+VzzcIffr4kwyuwYPuZ7lyKIzLIEvWcafv3Mk+nG92O7+peSNazjdvTnzSHYZP2dG/90m/ rXtZSVl3OZL7nFxy4A2zg1KIAaxJLM+3an/7uaBLbS+8FFR/u8j6oFcu4aprtp8pSYfKU7L4 TNb22J+opZ8ylS8xY48CBWWNo9vbp/TICu3dLC87S5gW2sGc3fvPiljDC184LVX7WKm0/Xoq vlvLM9zCJU2zDXArdF2fHaNSBCdGKCB0agGRphdKMIQZBUjk9LC4tq8cMAv9R28Q4fpD5l6y cBL7KwMH4ygfnjxcVpSw3/vw/b/r05+De8HPimUp3e66ittrGQvR3wQ/lc0xPN0Qf5KtMWeb 8nBao6i4T1m9uamKO35Zx+4D4VdwxtuJLnj96lIOnzsIurQM105I11BJCGhfcyjRtX1ph7+i tMUVSJhnJBbVL+Lj0VNLDC6N2Fym4aDru92D/QxX4lKeFV6l4C/lBVb1Kpx7x1dXubvF47cm MVw4XftGZEOY8BDx+522c7jWWQ5bkET+O++gtDLyIkv6ZeMzhgAYKB95782uOnoGFkTHJT+4 JHJz/Ti3wF/0JuYajnORh1I+ppMiiKTb7HiouhYdteiw+UTuzfZKgyXP1SaL3ms8/Hcf5hab 49hG38ASqpXcYoK8wLY51/GyTnTpjdiZeGo5QYM46YySKcVdzm9wq6Fn1i8o9tu95MWvvtzX uoQCjmUjrObvCLtqqASA04ymI5WEjreBufgyFDjLxDhTSD0JvgdrGZ6EUzh2Fig+9HmUCF1S /tBFXwzVb+oo6GVS/NAZB4V3nGcZwV/+dNyljOOzw7OGrfjZdu7FuCL/4QXLaItcAii+JPIw ZEHOUUSgZqrWunnlm27vZsMmNT2rJ/wnAgbiwiV4G6GY8NfNzvOcLLxO2zQ7A0p9bU0mw0FU TYkWRDTzl4NqfP3Nx9ZAlCCG6+eMP5ko20vngJKKEu+RT9v0TEXCozHmk9P3U/Qqwe5OCiZ9 70C+Rnlz9Az+/3H5j1swSaq4dUeI8pL2VyC6JM81rIk+PMhnEXorJ6ycJbhv6dj3rYpFcCbq Ot1a5pJvb11bTLqr+lXhqyNOtZKBkqFs33GwHSttVdVTqUWuh/hBfayBtUv1sTCDw3K2iqpG cibRbYzIu3ZdnVPbPYI8mYciQtieK5auVbY0uZxo0/V3btTrh8VzvCf8J1GmnYtgyiXjhOd3 ATxaq9DbdwWDAna/RsojUVZwhNide4VcXIKnU2CGIweKH3Re6Hcmq+G++JNYXAuSIDEeSCh5 vMaC3oTebyQgVeEpt5Inl8SaXkkeqwibmtVRAwGTPXkNvmh+MhWXK2UH9pE8/jM8T/hTbif9 qQwRQb2SPTAE5pbEhvT84MZhGSN4uLQrJMXf6vFMcW0y3m/VdbL339WEW1An8Pxr5kwgK8TM epYW9ycZQb2q3IvJI9or/Q6/qPmBVSfs+CeNm+89ZPJNd8D/hz6YNXz//EmcAAIh3dlNoiqg pJQqSqsipV4V1XhXp06apGlPC66MV1Cbm22Zbx2wOd62OuSjrQsW03zjMzNbc5jOWzm2NtmV IS1LqLdHg9bFwy02Mb0VFTma3e434Y8fW6vvf8D+jh2+Dqr13DemG23aR1gZpJuEGEmBmSZi s2EbgNuIGBbgejBzc4rHOB02W43Ow2523jz6/fz99/Pft79+/v358e+zv///8VG7RU669/n+ AeZtxVLT5tp+m5pdpHS9EUYDaABdnh9rwl5v+Si6/x+fgy0UXeJ65hWP9QGdxcNLehwvmd+6 aSbUzSw8uruAmlnczTPGxXjQrLMjJ8BxWLzNQRbxQSybWDFPFYc+grQBsoBvei6++M5XBqCT z1y1yXyatOlGEDvUc+ZuknDhrAQ8M0IOdCLnMVqBE1u4us0oo2pgKurVb/GzNt3GCzQuEeX7 yLnhzvSJAx2vJ8Fra8Lm2IJuoRkvSHrCS9aSjeYwS+L2s49KAbrKAIZzWDt4nwrx0a2kNr4r WwLFeUtV3c3+wfQ4XX7i/2FHEuGic79nJVqy8pqQCeOouT87MLaANYlezI2+5Qgis2OFk1fY EDPm7tqL9KgJb+pKwmYd2DZ8K0L/Wgve63cZxnFGLwraPB+fCBykiYD77f+CiF78MrJGCMhf FvgzZg/KWV3Jg2gL+J96RCu1ZLwmmBKOVH4XxKcWM5lTBtIXT3CllY+WLVIJTysgLFqnlN4W 3B5h10PjCtrBVnpM2UE4xgCwlnxh20NWxgsIUO0SPtxJtTLW8l3mxfqz8hnFBDuHtv+caSy+ Eg0sTkwOM68yD6WPI242BJRn+UdAT9yStyVFTqUelf7h6VIh5fdWNG+iSU+/RZSLYlyYWN/m JjecgHy6aI00+3jgEqM57a1/pURIjPPEO1b+IlFbTr5YLgK1eKrKOg0fDgjaLrvjSfAVYBVJ 2XFi1UL94Fr1Y1Q59CuVZoe/3zWyorGwaV7oD3HfSU22vU8p8hombyFMxnM7xDjQWbW6Lhzo CFCNaXoyZ8XM6vlMHaANXaUg1J+NFOnt2zPwOBC2/Nu6xlKSAbCxF4vDN68A60qSE5l110pv 4oByt0tBpfUmmdc63WkGnOdPKrvDdniHaSX915kNZe/p34xYt++jAm0P0mTK+ZOzzaCwqa1L xtmTD/MnvZie663I/TyH2qU6Q7Keb/wOtGf9pI6v5Hta6DVegnZCoiy7+4eke2x+K/ISfTAb mzeDUVad/1257dHtWug+ArJpQA/Q6sbak7nbg9yhLs2dtiHVtIPc7VC4ssvf/g0+nZVsht7I /8F6Qia6OGa6FBfy42k1q0l/LV5OqMga5s3ysbztMHxQmfBvZRT3nac8CIAfEUH04L9KY0gx DJb9Nju+k3oAysUluGYXNJlcLLQz3zCqlhWL0uk0eAH2PeRB28rVwjanFiceps3zrAJx1dG8 yy4vQsxGmZCuZPIBcLMxiPb9OK/IjPL/jxpvrgjt6Q3ywpMSaQFSYT3ROYOEob4/etkJ7k37 cV2gntdTOGKpjeonJQ6KHZQcUixQ8KHpSMFIyU2NiXsybTQZ6HGGPxyd7QhFawZClIaBWaC1 MnAOArFiG1jWq78tauA5THPs4ABFiKdks3FgJPzRWomqrVEQBhI75j4+GeADcxxzui0SOCoZ 6tojSxolxOV19TBo6aIcky+azxbVmx2W15phEagG9Y+F3xlB3os9324U4MbayjOMXXZRoF7U m8SZ4VMt8Aewacub4Aq0a7TZ+cveTFXiZDF829YWHJDB1jhcU9e8I142CrshyNzOogTxCvwM AzPdl+FZPGn5cPGHAseEA9A0X4gc2Zy07QZWNQaUCb6yL3QMqJFooy/xtFgF5gsG2Je0oEpW OEhMef7g7/nKuUtjcymqLNZdNYI5cY9pcGRG1fjehy8YS2UVEPdYYurHK+b+RlauUjQFt5KM vn24PTqx+bqZxoKx7sFsaQMFVm0+q99pHqtFYfSJ+u1ZCofAoXoIzXanE9tXSVuPuWnh+sXk 2EdY2hRY+rd7lZmaub1UY3IHxI5wRq8ZNJIek2TyN5lrxKa6kBJ/8FUFSi7CSONIVrEsK3Qj BL6SOomj2Sowwy6aNEmskrmh7RtqWuj+XRY6eV+jR4xNRWN3MOhUzQFjUbxaC6u1RJx7yTc3 h7UJs1RtrZ9a2NcZ8IqXyGAB2YZs67DyyCHUmYdYBVIe1JnSHfK5t3X2K+rmWBb2WrSGESr7 capm5j6miLk8tx9W0ho3moxeKFyWQnFzKlY6qcjvFpJnUXaBDhcr1R4hGFtby7xKJ3AH/PMT Q5keMJK5P2lv3pcOKjK7WSbJ12tRUgzrpI0pnLBk/uRkemOcgwTj8mtUEDEi4tcmNVOLvdly 1ofboTISMb0Sa6Z8PI5vLJ3DIDx3vAPPxbD3vIh7LiXR4Tb7ErwxawaHaIeGO+Td3UPC7+EV PhpSVWigm65aDfnV2l8Xz6TAyzkHo0SIQm072jyxBEO5ZuIkXqJOEYFh3vOIhAdnf99Q7ba9 Y1ZKIel9bwec6SA7tTuAYkHcUL+3cUF1oI/cb8D78x8v5AhSPBxBkbrduRvGMM5ddZcOtxL4 ucOF7+7Tvl05f97yHpercfBII+5SDL5aE3xCXrRWPJfy8jBD4U7PJgNEjos2G1y37UTjR9V5 gOPMDTu+s2HF8fNJ1GUeIxi7MyKayG1g8Hka9IuchRGkWx5f90sSsIvyheay/gli33S92MOJ srsN1GE2LFqJD76mLV472NoGdch9fEQxjsV0srk9reYxFNkx7Xa0tMrJNQhzjMvDaymY/Ruk 2Idz+0VKWbgIgyzbBB5qYP5YY3orbclw6v0NAePSfXzcoxLjPUpVXhLHmR28E7cjrZm1ZzUP Jq/JrIyIhnU7KUlIbOotZmW2ibfLJKJt0skgkilkiEk2LFKAbnLEQSVSwgJKTLREV7P8omhb wTskrsqsbi2neBbATZFpWaW4lXFtIaSdaY0RsNifLdrPk70gGcyN+VkJKmwlkNqlixXkn8Ax 1x7FzgAqI0yGuK5vpYbZ7/MStemjf2LJrBDt42ZKo3CBBhKNNGOHhZlEYZDhshMaZEzCkmqE Ly7PMONdKDpWSHEs19ZFDcAbaC7A6IG0gjoEEA8COUEm1RJxGIuTm4wn8jt+WN48qKNa5t6w 2yEQ7vmRkrXujRp3YS5FWN3M06PNZ5zWBvz0dcfc9weZNY0YZv5Ok5xTMS0rMwwTZ6Ke9WDP G6aMxK7k4w3IjMKiWuVojQrxonLlw4Q4BCeb1gYzq+51OS4ZbWMLuGRuJ7TUVhWbNY6+9ItN hsrn1UOLvdVhtNiR1+fBM3tbFl9WOgFM8ed0cAvfZbnOM23yxI8IwHGo9FHC2PboLuIf7s7p qCS+EVzo1QnCFJrIxoZxEFJ2/DVapJI9ag8msJ/D9LXGw/QtJymX3pC7Vo56HnmSjLQ22qRp 0Im2a0cXzqs28Wl3hEbRkuEi1pziwbjE2wl0K7RDhgih93Frkv2PoFxnYWkasNB8lnMlkqXy G8kie6MNRFVmw4VhypFHMFmVqx7nRTfK03RojuCxRZWcShT25jl7sjJtQ4x0rvYC+7oVyJ7U lsiGcbnjCE0Ct45X7jnfXHJRLoK8tLFnA5LrlwfWrZxSUc3YhTqKd0sp5YD6j1bDkeWRUO7x abwzLVpNfb7MceNxppbn3I2i7VW4KZLpHnYXx/CWmq8szxgjdZkc4EWQrDg8tpDXbE9q16KY bkx9dEO7TJ6ROshn3OHFnlfJbPWMjquS+MdzoS2lcryCfEtqmRK4k/drlcGyWo4Xwnh9cbum EuArIuzONnEhrjGdjJssS2SiXh+7rlw2omd50w2SkoZx3Kffbzoq1QrB4u0K3ScXarbaJHQX 4u0XNpOuRnL6Ld1hukIhzfMjJGyKLzZfL5QyVcOpUc5ZWJDkXAy8WmV82JvLyEG2SxEJRdF3 wv7MUnRxY+zKsbvrYO67ncQSOIjOn5u+Jkb2hnhZcNtktJm9qlvF2xnS6hFjGHWvm5Dedh2w xxif0nF+C6sVSziIHiXiasWRGqUilQ2LkT60xjLE8JgLT1HeCdw6zLkZWOjftb5+YuHWEyMo vB2SLnFj4TpGvO45TuGDxveLSxROJJbumOEPz01GRBAUR1nEwBuU20efiiJkT6hN51YHLCZ5 17zI4imQSU/VxRdLV7FGe3dPyiobkIQdP0OTXSp4UmykQUIn8A7TF8/ItTdtTdPxSSxlXnc4 e3wgkpXZhdKMr5UT8FOdfjpIOn4HUDzr6emaaREdPyjPYj+J4MKsyeUmKhfCkA5m+JVAhi1O wzOhxTwhr5o3021R6vKV7jjvHk3RiCmRe26/Pgd/Znwz2Oh7Fibnew0AkCLjBs6UuDQgiU8I cDDTjfsmj3j0TqXnquKcqWRKNgD2hFJYCvUMpSVR6Z+akTqRgUzg3tzlcVO/T1zOIUqbwl4k 9yJO9QSlWw/HoFKhgm6PsNsxGKz9fZW2vymTQZKFi68pPP45kUv/X7oyedoqZa/RqOiWkL/f lGSXk4sWo7wo+BtdPT9VLFt1opTgnUlUVzo6sUsKs32ZXKTtVDlrv0gUQonURzqVFe1UV0rU lVydVjoj0T278huWPDv7Mz1+vgaeV1u+p21p0HZeweNVR66jub+Kdsp3e+p3N8P2T2tKdjdx cNRjR86qkCMTf1uC/aohqpKndpKYu86RMWAzJooUvYqH8RKh1ALFl89ahkVMhnhRe8zpWl4P oi5iDAHd9dOWl2f3+6iAC2TS/yycAM/x/flIlBjUi70WKtDUU6FihG8abt6HbB5KrbNIWMVl rnPG97GrqBU/rEvqY304cTONLuTFi+isL58M9eKNqernFFBT+jHK52watn+xX2GgHFTnYQXj jnMegxYpWJMO4TVZsO1ftHF6eiH+vjNW032EF2t6m4Bedy123sRwqvFindV+s/z2UVHyBKzr BR2UWuVxn0kg697kRjj28d/LZI64gUc3bExabIu4cDkXtWd64+pjrhi1P0sZH5ltUXB9/EQg 4ltem8uYP1/TueR9s/drhsUSwt7W6RiZsdIancPOyw4b6QVME13psANXcJ+sJIrAyB4ROxiH jrPW9R1G8Ef3Eb8vDygmpwziO5bXvXntdIaXtgQrPzSBYsmzFjjcjzPTlX7BujKwBre5E6Qe W9V85r/Kja1tIbIclcmlvCk4C45sikjMGLSFtn4eTWBhyNFk1qXTIRbLgzurdOT0WI/FgRjO oArK9n37BuSoc1JWfJLrnnuP4AyGe9OutX6UER67Kcl/XfXC2l+w1MVYWP+XstEf5lwXvMky Pmbrjl20rJ8al+8MO/7EYSdS+zgRkRYf+IQVEG6+11VDbvKUfbkMb6zMI1kog4VCM4Uo8aUZ FVTbAFjfxfcMBbPhJbC+lr6ozBYuxsTP+pndy9eHb+MxGew7OevIS1Ld1uAh9RRkxChMh/h8 MqZD0yQVJGb6KysEfU8f5A1I3prS/xQuOwfpW5dTEbFPoNfL7smP4yq7XEs1dRuMD5LWhTcG NEvGJ932dm8DjK2YlKxbtBdZLeu8V/OakYu7jBsGSLjOmk6q+2w+3QPiyvc/YzImzqcFfuOo 3z+uGI77P5dCmr+ByTV1Fr8R4q6RcDT1l9nGV+t5d0gHa7q46f6O+/YPHusGYmsB5K3TgeK9 owav/HijZes2Wv62pRHzvzJVeMZfHmgi7ei3BztrxzLrepLXfJ3qtYY1BuZH2OF97EVyiHNP ftmkJYhHDwGWqyrahSWbnZAisiI16EZ8NOpeJlcYNOr6StMJucMzcYSakrZBOua9XV4WeX22 ftCIQcuIS43oVs14MeMwXkwFiz5iOLYxnEYQ74i6H2e2XJKWziFTDK0/ynyJDXSU0JBeYl9Y oRRdtQ5Nd/BBH9MwMvMs6HuwyKWTIu9Emda5tuf0LNyRVr1HOiPYlAY02Z/LO7ZTA4nczvsO K5cWgjHmf27EtazmLYF/ik9C0/dqqojO44ZgqDTvN39G2wHz4o30/o17zEtorJhmwW09o9Zo MNzlSHWoZ6ZbOo+rnoeO3IWpdganNuCRfrL6sbvz+iDoIUnUGGtjVugxNGn4nZzbw6Ntf01K yTaJJF3IF+JtUCtn2GWTnw3Z9Pv5AY6I4oWN6569A4W34yb59p8i+2Kl6vuUFi8OigsGOp46 hOGhWP3kOu+fFRNA/m+djamUvwx5+jYB7kYaE6nPX9sRR/VnI3ptDqCpZgmTG5uGQf0pbqEH bggo6oYfnsODN3vVJobh5AMy8Wx49TgdsxQ81Xsov75NqL/nqZQw9Y3g1WCsOgtnxX/xboIV WXzusEGg+uJVVA7WQpPFT15/H/zi6yWZCJ+7FYoqOPG4p5MsXCLiHN8nBLoheakLLqaDcRmP TwumRLErjBLDA7EXvQwlXX9VpSpB2+uEVA0hrq43VQr7v80IMhvFttQdZysOVqMZCLJo+vWU o/oqLKujohulD71O7o4Uj31oeUQRUU92D9ucDhWVfX9IynEbAeT1w+jkFsNjyh+wbC3/IdLe 9hWL1ULx2qhANQSe3i2Hw7tSNfWyriHsciNlOPdKyiG5OLr8Z/aZEIXkBB9sOAnjP42zaEe9 iS3ZjowSLmnyxiy6PZ2B9bi2wKQSg9i0KzHpfSLwcFO9o8fvR6wZEL8gKGVYr117pnleoUe3 z5JuvmFXRrUW4co3GZZBrSJAWOHo3FqdxxahxX7+v5+buj7TsZArRakN2LNRA60Os5lh4P73 aLghZ09/soqEUGsosXFji3HYocINeSNW9+GuI3+u5g5p8/gmTXeIwRNpX0tFk67Hvdc4T0EU DWaAxfpbCscrpE2JoAt5m19iUY+6hssK2xmwhuLdsMytYfbMbSVcB/QvD+0DspwpZIrmSgXX yTh67RUI9YspzSgh0vahv7IWPw/xAo3I0oloz3ia1JQzLK+yFs7TnGJ82f7312WGiRfjHhM/ cKq5aA9Zh09eP92Vd+bgtiGfvoNhifThmV39zdqHeCRuf13Np51miwb6Wa/nibN2GzKu4vP9 IoO0L2jO0S/+5YjuluitQ3ENIbDlatDh7ZpAk9Agioq7gLPC9JNkILxXnHCQ2c5cBZtA4ucv UJMxZhlk2EOXzqLci/mt6ag5Rrl6IZ8Y1uoQrJl9lDmpdq1ezvKVz15D3vBm8J4xbfXSueNl Fice35RXhrqrIV6YBRwUHFj9vhOMdfj17m0x2YNtrhAgbK+zloQGzLN/+M66JHS9TqbqyaTB 3e1mbqtofPHCtRcm4PFYw6AZ1/wn4d/VC7hbRrfZM6XNu1UhRWP7uDZWzCbJWBv6+8ZU0rRC 3fQhUIaXBPd4oZeSN4f/8CtlloUfVev4GoZTv30TseTSUiKRBKw4xrJu2gCElKIXKMm7lGxb og2kNytv62Sa9TEo8gLOtFlNu3QryY5uZOUmQ+2gi4XDUtoY3S1Urba6eG7eOTQxYVn2kSH2 sUSrHPLUsijTRMc4cJb4+hjk93qmHU3gtYM7CO7elq8jKLvAtlwC0t+8AMgKrd7KSRXKbd7K xmMizg/9tDtLNa/HG8KrOwMehOJ7I3EuY8ZbeWz6kpofdjvVuUghFTGSpmEPm6an+AFCIvSN xTN2UKFMIdHYT6lMLdvR+X/opDekGQtsZOUizVAkOGehReKeV8PDwGXPu7Qpm63aJxIOa9oo win5sYAxS3YPRDfbdchLOAi1qJMfoo+euhyhaTni8NNHmyCtS2RQKRd9TsE4frMloTPsrLfu ggc8fZ6dWjveNMv5hf8dqhvIva4eoIrHovIY/WaFWPrD16ws27Lnvo1B7q+RHQh06o0THvnl CexvCGhZz3aw17madsnZBcawQW7e+0NgauQmqeN5Xl3WBZC9gl3MXFa1SWjxUucWdHTJvVwi WmJtJnYpx+aE7Oi2+539ctMR6JW2XpD/K8tikpvsgvtp9DaD/cxf80ar9XwhO/OQzwsAXmu8 tWoyGjVz2Epiftuy8aMLPCRtDDt5Uxm++V4zVkh3vLTyjhRd5P1FdkVpsPD7heK0xkUGkcst GDmD07S710dTcCMPC2dykBaYFpSCWgJ8CkQ8CYvJOcJHnqL9uOTmJcG4clRQaHJEUi4c2ld0 OAfmEE9ie4TYiAdgbwpg9HmBUfXVR6zRNZwMgJseyGbFXrKqIMeD9KQc1ORZgUmBQwBiun94 EM/2JT8GlID84P+cG90Sb3e6b1U7jWfwksQda3ZRtmqkRiDCNBvQn4hTZaoe9bjGhwWz5fGv 901JQEHsv6weKxq2sbXCME7hWHD8/sYMPp3nGFCpfQcrcy6v7+j9U2h4Y+stNov2DDiSzpnk zDAYVIZCNvsEnf2DX9UqP2IcPuMKFZjQCtq2YZxuJg8M9TnDE3woix0+u1Dw8nvpOgdaXGS1 C+1OKapPBRohxEn/4ioH3EsOoV+t7YzkR6AZ7bCbO1gwuY1ek/scEwbwuJ1bsWvErWt2dzMu B//jj1bU+Y62MSXsB/hzX0zHw7bQc1fbf1NTguNsEiKpRb+rQYcZjk4NTxs9Qas0bHvZif6I 1NkiJBTk26SRKTk4YMQ0z0uffasSpySqI5AQTTT4RKHLvoIigST/tyXkKCm+jgq/5ZGu9OUY p3I+wytULJvl9e79VCgqgl57d05+O+ppgeMO9j/AGodN/Zu3apDa9E/Lz9ZdELZ9DE0TxcFn D96k0+jy50P0Ns0b1JtaRg/CLI96n4af/Mxt+sPYk8QACEhbbetdDCxwz90Ymx83+9a+dz3D 05W9v+etomtotPCjZoBuq7ehTAMzhW9U3b+Ga3bPz5AS1tweXrczNF792oXli+1slavu9+1j dZKSlLvLk6Nli86/ydfNDJbfjPa1Jmjef+89B6kt00bNUcNYWyt20wFRwPTBl1Dr4nrcT1oY Kxfi5iV+cggyAWS9AsYV/7JWk/fdimSZKPQ4PNn5S34/UI9VPZ8fFwy18Ra2UpDDmcJ638sr XaCuv9ufbxRSk+eDhY98Slms1Hx4XYxE0AuEXImoN0a1gd0/1N4VNU12cBfQrWHb6mubeNHP E3Fr7Cumj8EWm/3+f8MgluPefwWeFWBqvT83BtJ9tkFn/6JFliVzuFHRduN8RAkoy5H4I0BA Jxz1uOK+b/4A29HBXDJ6evTZrD1sNbEaVzJ6mbk0B2xoDgmeFDgA0nD+JnKV4krdBNzA96WP bRl0QYxop6beJ7Y+bbbRqmuaMT/uXW8bNo+dGzbdEGv2tY0w/R2aWpOMJnTvS0pnpONXUM/y 5d5zptq6LCR39dBf6qxod9vbeLfgp5WsSwHehxLv2UZ+rZhZi+/r4g2j2QkNiBVYZ6552i9N dJmjd5dL05dcNLMdl8yi2lfJuVRntGDSUa6tZ+xZNPBOUH21KTZ5I2PuNbPfIc1WJktGHwyg dj2cJ//ChzeqLClmYScpD9SidKTk0VRG8Ur9kdAxHb7k4PrOlKSVaVxuedtHZhI43UE/TKTm i8k1vz+uxBbVnzbMSTcCniKeIrvlb2IuGcfssfxG1TsHf5te0i9NiPV6SXUNAfsYDSjXwegH YEDUZH7j9Fvqay+3wYf2+tZv3RGszi1hVJ9752pfLqQzQuI4VWz1H4IWaWuXP1vnI2eni7vI NZJNrYr/Xug5OHlE2nAswxwfuin2rpsTWZvSLN5dMoc9axlEW4d+Lem+jlPTzT+U3/TCFb9L pAvMwBMcFIg0rEKQd3x0R+7EzlvMgG6ZblEGUlEh2+/5UNf1cGb+ABivkeDoX2lWZwtMrdvu /Qa5rpi8ewg5tANv0qT+ieBHWPC7u3m6MW4A+Tm4kzbyRImwrJ5q/DD+nN4Kd9obr7rLisSx BNhDp3Dclsv3ANHqFsBMmw00E/Jt6yqrtnZed2n/phO3v2VvlAG0A49qO9j0t+yEWRhtLyF2 bl9vmDYtl7VPs27DiEE7F2bYA5CvT2Jd29YEyzaqcHysphqSikmtcRPR49vKwrXkaSjmsv7o 0bnC6XKMLhiwl4n5M8FZO3lNzRSx+Uvw1D2d2wlzQhLRNJ4kOKqNnmbOMq4KGV4EqJtq2rai BrrUNzuNHoamst/O+su4sk5z33cmMMnJYkGcuHkWeHr9NlkjPeakm4rFjfLYuaZVvfaKzqHe qGVE37NNy975wTGG/NNoejWcZ1LbRTs7RteBqi/hihPb/soj3tFweyLRSdf/O7H8fOcG0vl6 mk0LQVjf5NU/cAR8A/QkFGf3ROTnIHEOC1u2MwMJHMI3uEzNefo3fChyM3bHg4KzP6GPr1Wc 66+1z6uqx7klKeP7iyycv0/RXExLyZSsXXMnkn+4SZTOqRZ0/eRim0zRJckTeTboM/yvrfm1 KgcH5jW/oIzVrrySi9tXfs9AQkw99/ofn77zTaT29e1SmGzKnXv9R2Deae4Dopu+ECOM1sNE VMm/u4G22Hp9wvP/r37dMP0ZpTilu8I6lkC8D4oKkBgAygs4GgF1AMw5awlZBd3PuPM4hcSc JLwk6CJwRYCUoJTglWCV4JawjViO6zyeGgrFCqs8yZb7Ss1Or8J9aP82LZNcJrG8UlJU0r7j RcCMXI9Kt/uBkgnU4d2FYSXM8KqZBKIJab7ghwo65VXcOtrnScQa3/tKt1iuU6vU1vOwf/g3 z5p6CxXMfdrjcyd4Z7le7DSMbkkQiJz2Mm59Tpeop6pS05QIZWubZOJgXTq3kE6AlgEAsgXg fFBUgMAGUFnA0FPoDvgBkcwQI+E3UJMwnBBKGE4YJTAlT622rQSxlunbFd6hdgysM1x5bBRf /RWjKSVLh6kpqKkokcFNOSCbr07JB0R72VKaekqsP8ybhZyzX1murPGLNecItBaqaPqxNksV bqHVY5gkyjPTNNG0q5uDZ9NscNP1NJT00hiEUunqiSEytL11yHfN/BcdvdUnBvAEYHAATgKo KSD4AKcCqAYQOTQ7Lo2zBAPeKDB4SThJiEnYROCUUIvBKcEXwlhDne2tzlI9gZuOtvKJ5bqt Z7PX+QqlgLRdv4NOIEvcHY3M8b58oksGCOInIqSpz0xP35dhScoqab4D5zXkXBeKs3csO+82 YMnxqu9t6C63O2lou+PxjH/y7AbSek+SSH9AZB1AuKB8IF8OLi4uSMUcXFxcXFxcXFxcXFxc XFxcfmu66MuHSfDCOhuoSZhOCCKQRYCUoJTwlaCWMOd6u3SUGgMtgpnNzPC3TZvC+n0303xC zAPgnumczos44KJz/Ny+k5vnvnN/jzosE86J8knOD3BuQb7vAI/h8W47i6t1AigwC+qm4J78 5SArg4YELZHd8RtmCA0hB1LDEEIhBJ2EooTii3fzj8Fdl1Q6TjraPj+5ygfx1xpy/IBgP9NY rAxXiv8heubrNmqIVsgJioz8h4F/CJPfcLF5B15Rsqm924/zq0prU9Wp/IOtWZLEw2EfXmKr 8nhAYLox8k5n+I9rnogM3LfhsgA6yJKcIo42U6fjrOo0JUfONdZnl5WlJjgE9A+I49I7w4Gy XwXTo0EG6fOQgTUE7BmmZ2XR0vBAXwjMEawh/8UMkQSZhEwtleaUpDaUh/iUhrKQ3MA6UlJU +Xw9ykN5SG0pD+vgQCeVfGcbA7zM6uh6pfVNbkblj8G0uUiKQVJGdl0adggUkJTwjKEaAgym Bg8IhFnR8mSrFwK7pJw7/J6GwcqUwedN5ykqYWYR0mxgm6mSId3Ewf8CplH+Y+Sq9u7+sYJz 6zYjXQNi6s/0cq62kj1Oxsxje9eBYc41heSkGV7tKEAvjVNceMd6purmOqX1VhcrT1WaXeu7 qG360GfU0Ml+CBwQRYCUwJWgjMEbAkc4zK0tSbdA1ec6fswjpXB90u9E6Vec6Wee6XwgulzB OfldcNeOMiXTevn/G5N7Jtu8/S+s5NATVsGo8EHFSBWRBD4rNCu6hI4VlBWXhB5XaCqMEGlT n8CddhAXGRNfEvYxJtCKL5o39QnO71r0o+yo14OigEjooRw6PqflB+k3mnZkC40HGgdVhBac d45XcA2nfPdQ8EkBLAZbmpwYpYICwEXglMCVYIyhGYI0hGwIO+OGRwJHy3lEtVWpFi3KfJLe oS0nEtJG6ho1ESKQU0/qLpiPPkxOTSFsekcxwENMTSSUQ8mGcQq4murPLLNvxuKq3O8pbS3a aMrSXP8GmRnuDVebq2hSGUU8LC35JT+DUE2gXo5KpyiRIeVQWt5yHe38dDxd8cDq+GCng5YF eBZAM4LmBtBF3ro44wV6WOy6NGwQEoJRwlPCMoRqCDuPDJKEm4RSCcUErRb5x4Dmef+Pa69z tQsEk/tGfa1is1g5iwNdjszhsnfRoKwmz8goEYEQpKTtdcOELZgI0QExTTbeJbyI9K3BJS0t NenMdhFwjbKCXKCriRviOliFO2NHnxGICM4+gppElr+G6qq6cO+KTilRnLFU797x1htlqsFs Yqe/obaAcq1cuwMjFV6xDo5WrLWmAe8Is/4VHcbikpJSiD9go9R9ABJ8To2DnLbc7fdLrbWc e0NN06In0Dd+KraCz4gkE51PYi7n5IhjfFJHuLGlCcVBNSR9CVKXfgR9RfvCP43Gl/a+05jN fzkMMRehg6U1zgYdgp7jtjqkoN3BMwb8BMBQQUcHEApgOSBWgOTO7Lo2vBAHVAMj4RGCKQRe CUwJUwlhCNIQdUX8A6b6Q4HI8hVlSqiVSg6iJ+s7MxNPNWiu2Bvc5xr+SSaQJULWj4pamQ94 SvcBTg8IkVTt+A0+IQLQeppKX1G5z5MTfRyVT3q4N1U5wzmDeeSSzCGAcST3EuBCGFRIuK8q pI9Jn8/TVHX9B8SNRhkal2vL3weOhmuqnWeX5ny5/Z/7JNDSceKQnxJSxa7dz6j4623yme6X W53VnH3Pnrlc7aT6C5NLdou++7REJPk27KDn15I6qqT3g1Gl9CPUUrLOFbyzfqI8rfCEAYIp mQ9E1Fqfb5Ag5JyDj/Y71KdXGAqYOYBYQWmCRuV3ANeqjTkPBoHY5AMnWCAnBOGCVMJYwlxC DKkGIASShEYInBKSW1DLFy83rNE4+7cf0XIsocZauy2JfbV+vWfldG4OTaAqps/NMl7Hz0hQ SBG935hshWv/OJabnoCPToQQQjnMZl2Ejo23VeUHIliivY2hz0TdYoxAokj09RSk2FphB/xb ibEuzpZalxPpSL4+WKsWiqXQey8kw82+emTQKZk5JKSVC3JJF/QUR25outt6BqaGm6to9pt1 x6C5Gmk63j4n0dixB0+SU+epqj+L4/AjKIhpdU0r4w9VT/ZAi+wpdx9iMruuCMH0xVSA/+95 HSQs7zW6je/R+5bSCRAlQJiCcASgKYFgGmps7Lo2bBAPeSDFIIzBJjyYZUwjaEl9TDKYEuIS Z8o+FnPwmLcf02qqzyoUKnUJfn+Waqah1CycdVcBKpzPHTrlFWosHIqFPl/LWumzEx3ZNn8V X2nlqfZOc5jkctFU3jea6Oy2PASr3lgsVe6Tla9ZKiyXautXG1v6U61ZWjSt7jnURz+yTfcc t77p3g2NCUVNKd1KVIRZQraHl/QsvoJUkHzlNThB5KEL6qQMVBvlSUlQUMthS0YWnYJma3FJ JiPbNOvBo+OfIeR9kU34IFbyP4WQktzQG+mnGmkKqyOguyRM6n2tQ3zJQ7LoY1KS8/HjM94T fxnZpV7o8leiJcJWSZqTPb20ZpZE7ql9jNLu8oR6xHe0JWdrTseJ8epa3zz8bQ9NT9SRITzB 24aMXBRH95Md4vXWJCT7w5q/rt44W95EAg+3l0+ICCaWMchw/YeJmJLe6aQv1GEvc7xDSs1H 33QLPILPI5vWqqzcFm1rPKrPL8JvCzyl+rcs2HBp4leWehWSbtaktnMrNXWahwkx71NLdGHs wsg+tVWuU6HP9hvNWtzLeB8IGbnzFzrlV5dhq1iq1okg9g5Op9DqTQr6/XKuyWLl7AX/KXOW 9mpHBNoEtQCRESCpfqJVLUYHLnCClKODChbck69U5oeRSRDHJZDST3EXaMaQgEBGGRyxXpd8 xname49BdWq86JTx/PXkm0+MfbyZfZbpdTCNNtZ+luo/q07V0H/LupSGSd51n7nKcARyA80Y eKm35rt99HsxWOw54LreGnuL0mfEH65QK5Bf9DizANv2jq2w9VywzVVTMOs+VYca4WCPVmX4 saGqvNoEF0pbyH5mhaTeFBUvqPEVDU/nJZ+EyRo2+xH+FTuQUoObuVD/YNzG5kAk5OVDSuaU lRRJd0JDk/maUQznqJrX7JMgL4/fS2yqFOldU4AlAUwLAPegpYKiBfAxgswLaBqBnrFVQxCq vTmCBVgjaEmNWDKUErwQZyoZLwnDBLMEQeWdDbAcha6hcGBSpsu5WZ1Hg6c0VaoVVRp7JC4a sf9YW7ciy01DMN2HMFr5Tj2Rf42pc3/0q9Ps/H2bkvk22x1CFv1erMJbi85Wm8b1/SzOWJVh q2TgySgoANDwg9RhTf1eJO14yVewviVMzUmSUlJ5ZjEqBjw1aoobgaWer7yIROEU2epxB8Sp djks43EeG4knB3fHnpzyH4syl7i4vMExy7aIqiFCBaGSa3vOLaGvBlApjyYWGkHZL78hELGX 9NbeDxmNDJ3fI+DM+GbIRifIWaYstMI7Kws3Qp/qW5grFh5hlZLFU7NyvKj4bdq1kfXLvW2w wLsD+YsH6Gj+F0ryc7N9N8qJGRD8iJDbs1Q59Rfukognj37Z+1x2kK2L341KsA+6XPoWfQbn 0pk7Qz3K5XnoB/RQ2y6uRf//4mrA8xDvMO5NEJ35jqHYHZAbDSyCiBsNNpKBuzDq3Gw2zV2s 2Y3ONty4UNlNtLjbc14cxyxutuBsgs7dtG26G0Y03DexgBfTXXM97EUL4TDeJvG4566b9XN6 //v9LdfnX54/GfE6pfPOidQmuAc+VW4aMNCYMoS7BTg22wwAaozUYpFNQiinyls8aOzUlIFU kXxe/Pr569PXvz69vz+//zs7bu2fPr5/vr6/x9/fn78u8xWbqut+y/MP7LKaKzMDB1ZRyg11 7V8cCc9WOtoG2GzWTImN/Shf2oKA7oNThgGARoIR4qyTmZm4OiT1VNVP552c4nzkuGND3/gn bayhq4GqDZzRID/ZyrcyP4GeUJvmIJLdATN2Kq0RF80bKD/hBzrzvTQRxseIFFRUJG/8Skq4 xvmNTtX0bfVG3OdAug6cDECzgQnAtkaI+DdAJAIYh1TC/n3SCwhiStBfGBjKGTSqOMxpjEGJ BILpoYvhiLzYR5lFy/B8jzHNVOtdfV+wp9a/c+lU1bl69UP3YBOKA/e5WG/Qo/LL/PdkZ/7Z L8pf5H6fKrYp9O8t2fl15dJ1Re5uz8xx/SNZzq4x81yzoO5jnluw1ytGfUlv8pv5+zrvJf8+ ABNcNdUciJnQHOJ2rf5tyG9roKpmb0gSaVR1yShOB0Jm5LUY3xnrZ5NTDlXEwXl3UxBL58Nz 59Y02lVssCzV8s4JZJ+2oyL8vNXAm7CYbkaqGo73I5yqdzty3s8sNk6DJzDH0nwBuRihrh/4 dkUaoec7Xfd8yYNx3CEp/bPeT1Weqxqcmt/BFMgb1CXWp2XwSric/AFjoFuZ8VUMYy3WZFZP 0sHqzgI1Vnhl8FbTgs8n3jx4/K9FasktufgF4slvPp0iWUqy/Lmt51v/FS/5lU4apEVshMeL 5WAcFrltZJW+4+kbuNwEW8Aq1aqxLnrA/MTmOvG1HpqzVvCYtfRbS38bWbBUqxnzMavYhtV6 /nPoDebsdb6WBcXlq5WMjERtS6DIvDANbyCbUGdWXDYuCKzuHohgi1GeP3gnjZd/7Kk3DqYS 7KYzffjVANVBNre7TAHOr7E/NyzdR11mYGFisw37HVlOrsa/1RTrbHl4j7RFG9h9k0loycdg 2eZhvU2ZkgW2G/vMJPrZHlkmlGcvW6HsmNojxxlhIw9/gniqJOhL26WgTR+mgdcGN4OGujVO sGzx+5tANmyL5ckHzpSoM/nhnvpaqI3icT0dRDRNA5R9GqfKJb7QR70S86qKykPHOaZc5XK3 eLFR5wIgL9hIsJmPhSON5UXeDw4bU/R7JRz1wZo6in47bQIpOUZFnc2FsV0gZQxDqoXtIIid +hhNcnQml1yp81T7o1DAMaXDAJth4CZT0UdV5U1ZM6j9tUyZ0ID5yqhDeCVhbRqE1CBpk0kh Jn1vNu9g3Vruv0H7Y6RWlrIk3Lmfpm3uWjXpmgoUfiqrHR0tN7ClJiIze4m0Uvf+vzoOPXKr pajXTuPVtuBqFT2pT7Uo3jxiqMhYPU2r1YIeBp9gWVJpjxi+S+sCdrpuDrNP85+prGynsIUt qeTdKQtbSbMTi7mTR/ekpZlSlK7ChHzy/T+4lXRLMmgKCHTvjgxvz1WEKXL4PX/qjo170OTy m4B8WT+dN/+BnIgMIGYCqkum1u80d/SM80JwUoZMbTjrwQz9lzzJr6a1BazXIvUZ7VFfa/WI Zk+sIhZ/B2+A8G8bFe7LdMDk5BjNL0KM3xkPbRqw5O5575c/w45XYdiVo7rgfzXjPoxvCErm jNntvaB55zIubasySbxbzkke+vFfeTb+5g+rd9KVMlFP4q5qvu1XZO05/wX20tS/aAaxHysM DYtQviJTJrSkIjq2YenelgOme31qpae/J9aKp7r8L/ytBXDro4mYykIRuncpKJZ/gtSbn8Mk vCcBRfW37pLCKc13VLcJFDo5pkSRJGvj9IwjwmmknbPUIpZKSS7n8/63KxYxY/b0/fDTYyFS KNIWKsGNI7wRYXkR0LdabWQHsUUs3RZcRq121L2uk2DgtoI+Jln/5ZbtppKdcPxIuWMjeNcc qHRuakCaHcgmjPZKOVkId80sK98ywhOLOhhwDRn26lBmr6bZwPjl8dhQiYy+NSvXdZ3Sjxlw TWPmSUmx4Pzf+BGhq7CiDKSoHrXbkKaByGlmR856/O1es5nGfc7WjPxiLJ9EL1sbVTJHBJVN Q8ub3wq48DUQ+sWEK+6pzv0Lo4/yIpndhSRXcJJQeiD3F/AlQN6SGycRp2JceOexWkeiuSm9 4UgW0oj1z/bzt4mkX7pXObEJUw0N5x77XFimURxFlfPF70DGFpYYZU3CzkBa6UA5WJaD6l4v g4n5VXgSvjoSb9lxsiiHKg/SDYWENaSQ1zCw3iNz16Plseb1TaXOeOpujFjsFEx1EvANy/CD QUd8nGEqr0ZEuuJA/njMVSx8wv32c2vRGhpamKOfazyTPLI5u4zuXnkmfwGlLa8Ukr4MsCfp 4Rp6G9g0oL6RDqmiSVWeQGIpKirTq1xkGk0TGt3NBo51cscUNzqb97Asx1itDdyGlvnuKJFG xLlFZ1SN3OR7pJ4xFpbQVSiG98CpDjK+N8ZH3LdJL/AaVKoE0gLLGzScZitpGaeWT6fDSytA swbFwSioXUfdS+GF7QFEdKRrfRypKZJJKF/BI1Ez3Px39fQshTUpW5T8yJ9KfRspIcc0+6hG kTcINPu6e3ACY9EKArKKhBQiqPJtB1ePGSKj08nGZ5G2jLhXRf1F8QE1NCPHKVBNFwbk2Y2Y c1k5Hvcn0rwKTXTzMaznUgqZUCFR0o5cn50Phxh93spvJSAGDqrkk/e8z0jkZnz86hjv0Pm+ 2h51HO/FQ0qyqs+kyo36tmNEmhNsnXNsynFxVwQPlhdyggx1jBEujlShPYrg9CIpofne3eGw XnL0wshNr3YqTaru3mUCY6uyDRnD8LA1jwq0+dkKEjpremu/79fgAtB7721Mf+9qnyJ3f65w u024gtkiNGzA20Gja4+UVl3bdKK7qJ0tLKownJcQVkQlC4krtokyphXZtQSJx0Y2Fbqio6s1 tru84rel4ouvoKhs5VFQHoGF8hm1OE4ipNi1CgWuxIFCNWn1vqpiR/reRIfWe+e4VwwRp39J kPWlI3Dmjf6k3BSSHAW9qBZe8OtoUBEwt8gtYS9yFaJH+tydrSOuAWO7F/YR0smhyGl8LBQ8 H32mYOl/otcd58PCP8+HpIHPh94sG5XGaZNy9eWfAu1CeWux9kXbFugMOzVAGiq8ppjXHyVK psHGgyk7Y69x5ttofRAWoTi2ON+3lNCir3uOOzIXVOLBVfU0MKrvhqTT90wp/+12AcNNvK07 QwhJOJDXflvKeJlT48qtMuSvB9pcHKnffYoCZfH2GEE7x0spjnhGWGCk/H88Xu8xvV27j+3L syyEcPc8wgJpuFCPAbmtZsLmoy84OrERxCG4t0adH0Bux+JjN2mt/xFs/H9rEw+HWS8f2O9c OmsunX1ZqnGqZ0RjjqY9K9HrrmmPBCKv++x/7iwCNrHKAy64VSn9FkzBz5DWNUPRHk9fDo0a 8ncuLJLTg3gcsHKAXn4HfLb6a/DtnTKa6KEYip4GOrG6rYhoPuTVecLxIX4Sl1xQMw9eUrC2 pvtfc7ab19381qmUtMHJpFNXyTC5kZuZHQySkmr1xsvqkjhggMvRGEQ2BxHxcqTGaYb9dG9Q vkc7GLHyj4VANGUFFbODC/Vlz8WmCMQq9myrOODIYX8ieh4VQPJHeQG54W+U/gPv2k3woIzV +r/ySt8tdrBc/fw/FAdMxXSxBqvzm6muVRuvQc6xRVO8QUEwIu7gweatvrVNV68U5qSRa95W 6MwM/Sjyd9kQP+NYOcwU4Nk8PWoYbUkPW+aEDBKeYJy905eqobV0IjDcV8v5E6k8mDFqj1l2 hoNjsN0RlK9wSF5xcsosaTQO2kVmHlCOHKWX2gOuKZWUsUfSnuKJ8o+/brJAsUFE4mmNTkdu bgx3z+SZ05XTHlrdfOENfpaaxupH8oe0brpXyghlpNYP8QJaJFRZCcrJ4aOSmGnEc6bfjq1x n+vQjwyOiLv6qiIl8gk4zYvwjGy1bP235XhX3PiCJPROmnaaEfKEjBWankmvAvBRUdFDwh5f 9nzsQNN4DcAuP6PwqxDJjlgZPmYToul8ysC/mmtrF/NxG71FvWzCEgAT02ZJKVM4TcohsJCu uMBFLxfLFlb36sRx7oO4kdxHSgvGAkb3fq0Inuk8lkp0WlI8nRTJRfi7p92josoR3Et8WTyg 6GDkaTfbcXLiKlEnRngPXh7ykHlW5yXdEYF6a9uacZeCGmSgF7acnsCB6DjTQvYFnjbg6wAW xFWPLU8rg6+YxiNkanTK+/v6sQLpLAC5CZP4sUVtplPnRldO7MrOsCQdGYcmmgO9/xgH8Dr/ yMaqOaLd6Y8DTXH3WXylap9fLjpbfdyKvmLr+85dzkzoxy4sh7L+/bubFHN6McCrs3DpSK+D AqyZ95uzoy8Jx3r+akuawL0UPrhr2wViVfKdysfNxl1goPjdKEav9gsMcogtytDqQymZGLad eQ5j5slZYPFtuqgruEjDNWVqndcyOTkT5Yjt8G/mhGaQZ83PT49FnGnYz3Y30OGlJzuP5/LZ Xnu/ODIHOC5u+z/OYl+9lps8acMpYg1TSNOmgJyFx6PX6y0vhI08E9PeV7w092qL1tJsVPz8 HGnGzLLX8oam3lQupqJ8B6+smxDOH4f1P9z3pCpO3OLBxoOSBy4ObBzwOhB0wOqA6kWlF1KT mNwJ2IkicCJKRFISSiTwTbxFMTaRJ6JGRJ8IhCT8HjNeiHJFvNZik9iOKnqBF2vrdPhYqGSz apELEjpfRjTO0F9X2etRHIu7VB4k+XOdgfXW9rZCz8OUNeb82mDeyZaeoe+jVJI16GtcJlqb VFFEEC3gseiaY9m6FuWA1UFGGpdH1o6O5pnMpdNN8lm9pSemzydKtBVqDOxyfqiZhyyESVPx /umhUKoeiZC81mPi+QEriUze3mInVbeb2PUKQszZ9I9I8o70gqDqAp75qC1ru/bTstOTrrd9 a+uNrXbcrvdBzQCA64Fk5SpoXdU+PFVJfvmlLhXq+4sT4R7qbZ0xi/ibFenQtOxjf+D48Qil myfj8foUUt2mIA8q7aRK52w3n7igE+4F98a3LwxaXYjCl82xag4RsAtu5ixoz5ALtp/JbriV aH73SgEqlqkP2chM59KqdK20DxjWqhVIEPnBxcKKCZyBwYcg0iWwsDImC8tNasCXOIQFQqkB KIKV/k0ORUeddvpDgNDiRv4IwhWs2Cls2in2IR5ftjzI0xuV4PtLg2zhKIKJ6JVQ55XIUQcV kloavaZFR0HxR3lSQP33WT4rO1qm20sy2PkJnIFmnMjnM7/1Wr5wL23KevMMpnEZhcZo5FUf IWWsWNHM8ZJQ0tvc5SBaqfDpST4E4xiw+mVGjthOSf/LXt+bImPj16B7MbtXBUrM2LGJN1/u CZ1mPlXapiPk5HCMX5B/RNbcXkOGy5aznoStzR7x/dYsCTaX6ba2AWBuil7XJFShVCd5PpmB tdr8nbxfGFbi6ppUrF+4KdY7gelfHOkBHFfpCOJDaeO4iD0S92hhW4bHBCkr1ZLfHuRDOJz4 Npobh4tv8vvffCGXxz/DCoaZmS1H6uNeN3+uYeK9XdauAwEf9z654hs3hKEZ8wS3Fn8VJOfa hhEK3l8WPTEYsV4X5NcXmPOuHLwCiq0D+scWTmbyIDkN+LCtJj90XB+VLcKLxH+WpsnTh/ZD 8bjY692/8aHs8RDo/9R0sz0x4aEIt/r2IR6LxFMgpmlpSYmaPFqIkis1G+944i08e6qlVrWL zGAJ4zrDGczwsfEBmATqPWCVs7gQooXKCN+DGMuxwZVrbqZw2IDGKiWYYJLyTC39s6r5YnNV rIob8SJrrscUEzWq54SR1JDrH1fLYUOHQy9hVjwL3bhA3SHFBprQi8rkz6io8tq59AkePYHV WuMBb0/+W31VSblENnsVtz6KHaC7/QasQ2e22amjrBIpfzLfa6DG6SG9h07MzYX4FqAGyHf5 mNpFkPhWqm6ZyViNRpu//We9/8at3f/UXQUbMPZrSfvGcR+u57ppzBzS9BARTaqQ6RzT/ZAV VTUuLRNApn0NYpF7zs+TLwtGX3wc3NvzYdQDcC3UgjxbqgRoGfLRlfeVD3Ddg4T1GsPYqq0n NHr/Cj5W34M+QFDQ3VAh3k+lhnBLhbG+o+ao07DijLxkSgRRz3AL0wsUDr884/zEEDi47a/v gzifjtqxIUKw+bM5E82bjcuy5kwI8eiGb1Vq3ZwTerffXtzamArPwVUEX6srvwOTB1wMmYKA SPscIr64bIkTAf2PkeaiFUtK6jVheNWY+QqXNV8hZ6RY2b0pl9CMqdG6eVNQR458YYdynOL6 FSOp+/zs952drKV0/h6PO62CG2A+WMpK3I3eXR/C8JbYxyoPzr8XWkyd2ac3HWDzYBTq84cc rfDMqjPfOHIhzClc2A+mQ/nb3E9LV8PJXw02ppJ8WXQ8i6Gm1NJPy1dDyV0NNqaSgFq4Hkrg abU0lBLLYeRbDTavtE5hWPhEdKyc5HVkNVZEl28jFhVzxJOtIgLKhZi1scwP+LE4j+QyomWo hokYA5dOXOkKqa0Ce5+8bSizpPS5ZvaTma7SUqbS+WpSbLE5PaprplmlWyfoSo29aItSg6p5 erjRsTQB58CNTZxQNEaAqp8V/yOgSLSffaI0WfxAi8l6aWdQraUd5UaI4hkmXzNOTJZvroWl svdrJUxiBLaQp0xTjCADwDp9zR0GvWtCOGSf/Yx/qBgU+UDqHu+FY6T5aPVVVo/S3xTNRHJ9 tKuC3Vk/WbQO9Nqb/XtuZk0pEUz65NhzUySdEqyZd4Pz8hFY7JjV9A+zr0dH3j4slXWH1EsX DaCmU0/ed9yalJv5vTY4J09TomqYRUGH1BaH3v8T1uIW5jsCO8eJ5WV7KeUUfu9qY627aPND dBsB+8oQ7XJapf+2+Jcq5yi66gKQuis/wERteMzVqhh3FstGPyHOpZM9IzAWaGjdR3ckOmkS 9wka3nBWzThmUgefAmeOwz6Wj+udcrI6lMrMaZXN6PmZNYx/zr/N/sFmQzpEOjZZELXYxGWe P34zZjBKQNjdr+gz0CFGMXvSNJSizCVKAgJOjugCFYBNvsoTGwJzUoglLTShw0w4i7GB/ZGb fc5G85k2AR1ZPIQZ/sZYhfBV4yILRmZ22rmS84MI8hgAIAs4AsF4GhtqwNfDs/4ZF8h2uOvh 3PPDt/aCZqx/6GvX4XjIh0XY5tbLGVkl8J8BA6PjEE4nlvBPZ2zNrUnmKK7Ntm0lXdqX+pY/ tbfeSUnhbp+9fDW5kGF1HsmqvkerHPmKQzVxsRhHeMMJ8bRFF4hnSA8z+vKxcFYbkSSL4Pwb X/z8Z8hYiHQYiyCnCXq8aXYCrvxIgSh/jv+IJg0FTrs3DDhHcHftSknHeN3fprx+Xq1BtgmP XfQX6sbjjSe5vW3CdTm7WapCaqfJ94mMT6bLny+IOGKtd04MQpNkQLF9fyZMrDrtAfye4ccb 4X9JZsoV9QMyxuWzd9dDOsvrHsZ3DXS9nbmaRQ+sbaTCwtNjaqjaTq+Ofl5hp78pCNSTs3QD a2QxEshX7SB3equcniRp3eoub9MVNqzgV86hX+cioa6avVo/lJkM4iU5kszLtUlAb3Lo/TYQ cpH5tMzu6H+vwfLapRtZOMmmhdPXSa9x6TMB7R1K+FrrYUijz7hDzGfXE1jt9UsQsTmAEJcp K7IicJswykzltyuwoQ74ltoJkLWvbUfldS22O9n1N3zVjzy7nxsjYJ9koORwkYlKGTFs7coc d9RvDqhYhch59McDfWxDFjlXXmJS0l1Mcn3xD+0pCHHO7NoxS4fl3jxHigRGSxQPbKB81iCO CFiMQe2xB81hCPrChGEPba/j7G0+UwFx+7wpknjttMGFDbOQHH0A3/G6EqlykPnTWyAtPh83 KopZUHpqvR4kWG8Er7GDpKk6u157TqWXUO+htW4xNaXiJUMKIwjCKW47jpK7lzIvPZGKb503 mnSDtv+fFAwoGMQYxBjCGMIYwBjAJCzs9WDbDj9IRv5SpODLUn3Nd+WEOrf2bIqd3VF6H5gc iSo6yuhPbmbUJgNFpC93PP5p/Z6J9L3je6DtUYYc5UjA4KB7iIHDEHuR0OGEPcGhwwB5fKHz Liw5Vs/ht9M3nzdD68xeE99CmsoEI+BTo7voaAmWU4IF9JM8sx7vc64NK6A7kp6kBec85Jlf dbshVFkN9PEa+Ruw9xL5h+9G271Y30cLIGMjPTDGQmSQKaSVRY6+jyTRsaPZz0EGvUtHkp6Y YeSukOlfb0z0dgYcIwsVpQMC4sI2dAOPNeZED3DphjJvfyXCSz1cOSSF4Tn6pPo5PuR0JPnj JnQQjk0osDYM/O4X6Ydpkpa0x/K/JyZ00xahPWm0HCW3sgl9BEWMKgBvYC52hmrS+0+77W5Q cZKDa/eJSvu2T22CvXdi+58aWMqfR/A7lSS5SHSJh0VxKaYU/vESbZ4dSTvkD9WyRNT536lr Y8TRVJaq5vRI+s74i/U474SGyx3mddXLIbemjZUf8DJIoILE/TF+yZ1LNa+6rNi/ZapKzVaW Mgj0GFIlr2xV7pa7/znXBJZFNZXkJXsqgdULRsqc3lkyDRrWb/oxLd+d4Od/0Op9qOPKufzx eN7U6MGVnJTR3IdM0xA0MvY6Xhpt5Vj2xm06/zR5I1Gh6cjpPZHOlSfIqLJtL0EIs1kCye2v 31JM829yav6q1HTsphSYmU6xAG0Wsge5cQiEF4CwzDOJGHmwZKfX1rWT00OQDJMGux7C7MOt W1jKp4TcHP5WaFdso5O05E5C6aGxliDVWvHpJkHcKVHBJlZbYegXCxCOaBSuaLhWNW8aFyoo IDIV7O0inU20FY26gqtvly3F0H1gMALMBkAeOBIbQ6kOhStcCFwIXAhcCFwIXAhcCFwT0UzH x//7L74xW7ULUkLskj3xCHDCs9jUXWUnpKqTS3FMSjYIQJlNXrF+Q2KNvtftuOjmbDXnYtA9 OyJX1Vo+32gUWZkplmQxYZOyypeWT19HX1bKIUDR+iqz/qot+kuLwrhWyS5o2sulq72wjAtS 8QHxshRkTVsLMToclFpYX0ETk7lUemzyd2buVZX4sp9nFDKnomzaPwkcGUkZhvKWOkKW1m9l bv9y2O+bMrmAH/KMvrebRYZw3M3oK2f4088N3Wy+1kQbdI6YDPc1+1g34TZM/sf7otMZlLST xmiZ7oX6beFJI07BJd3SDHSviP+p98y/sbsCuiEbsSS3FthFL3UObNDrfDzCcyz/LdfuvOdt zNUi+tcUJeeTqfw4lYoRWmg9lCInVRfc7JMdu5K36A/Pj7rMtLU9QZG9Jcta3LobrpaUGLg4 HHtK6Hje+HcTDKx2AgnRQAfReWM/hVrrxcuuh3RglGD1VI5pBdL4d9bDsoYkzp2nuTf7PzZH iVImC+yT/xVzF62fc8kPPeSg01QlmN88kto1AEJs0sDgiYBBA2KcBRfyiaPIgvaTf2md8mLr J99XXx024uL0aGu/6P8OmBwIlZuDJHuAwCio4B+yd0ekAyaLwMkLfbYipBHuGr2Y8GcRHm0y 7TjKFmPJj7//1If4l3WV3dOZ009MqwfxB4OGBxQOMByYOaBWgLoMXz5Xab7cfgREwupCbsXn gm6F1MT4heeiR0vPhIuXn4Ms84ixfFtPqrSV0NjqXctdxctjXbr+RG7IO5FveQ6B/LYXW/12 UrZED9az3tsA+GWDsw7ZbfwBRuQC/RY5kEt3h8wyPuPUvINz756lJcPdg5Sbha8pqtxPzBCP d9W0C6Ls89rUXIo1/fmymeFt5dmzfRdrlDurIWoOw27U5H4MiHS6zdLQWF49INItJ67+DkJq kAA/aTP6VHe1tBk+YIaUGptm+Wdw4+EQyosAxY5fDUvZFKX3liNSsrECUFg7YXownd8DgI7/ eqR77K25U5E5X8sEKnForaPAkKf/tQq6tAW9yIosfoDlnxrcSgb0DfwTwA8FIARB+wDcgYgo Can3Kv1Wc8E3tnPRJcznwkpZz8SRs6AJtrOgibIzoQkWZ9i+Ghx6eA/tfgWhyd0WI1o9QEzu NAApjIVkmjxu1IGFeU4tMwN2YJn6+M0msGacs8R9O+BiGUuFDykxOMBYPQLXLvlMIhFQ/Lq0 +L5wpP6hB2j0TJE47XRR6vEz093+wxOCZiPrUq39go8eg9Jjd+JLz0TQpXzyu1H3rTqdkGWF /Cqv5pPPfsUPWZy7O2s15J37dt0LBZMf8sUwcfiWh7fhk+DtHv7JvJDo8HVLsmezb2CK9Ad9 FHRcTRxYqr2g8GLEsFnAnNOm/QitYr/5SekCogmE9J7f7189d+ne4ryqaJ/btxvX63pwDr8O gjwjzDu1eJWpBG1ZNgxpXKvGBSaMc0KRZxwMi93TOCFaS5VDnbH7NgdCMtUEtOU0J37wGpPZ e6jFBEtZk2vjFhJwxp7Y4OZ7HhZMwsh39ppzlUO68fumv3EV8fHO/hM1OQHA0mlXQdCCZK6Z INCY0ECgh8wX7M9R2RV/BwNBcGF2/bjCneEDipPr6va9R43fFFbyN8Fs+gr3m2uKjU5+Pad/ RvDo/+8nq+Vi2UTSMWkwFgERFHr2dcl/q7CUn1UNJHwJHL5jLxR3Q9ZCAmaZ8KPzx6B1nlTL TmolYPJv255rOGvzyNEUEu/67tENd2lkt1xhqXwf5piSGUISWURueMwNer27JLC+WcW6VGFb CcxGU4/hrNVvQCs006CBU7X2R64fzC67OgqSIr1baQH1HQbuxZccAaCLUUEvZ5gWGVdhdwKx wsCU3I/QJxirsV0R84mIzVZ4pL4BZlXrOekqjhWyCi29IcAd1uSaMM5PuVbZ/LdT+DfxGNtX ZNCA0dN/60hAMcU0daPBzzjChTt2ofDhl0ZFj9iXD+aYIMmp/yZ4TnDOek5uznxOZM5+TlzO gE91Z0EmjM6ETkTPsRPbWeLE9mZ4uTRGdDJoLO+T3KZ64aQexPNWzJ0LrFQjucJYs2paKbJ9 +XXD4oXpJxSkytr85MNZO+QhgSKadlVzyEER3nt/iOPyiZuFosozIq4Eh+50Kv4UDm6/Ad9V 2S3axUMyH6pjLB3Mp4sxco3FTvIazrk17NHFDImWtEacObfVBor/9OKkFwzKaJwoRWyvzbSF wpdv07rNazxqBQfSichrZ+nYuaNficH116qn0JsP/hO8PobIpYm1/jvhbX+Qod2yX2sItqiE hdC5tzMnFchStZ1Xt5mE1QULve8hsuj6hqKDfapATDh7blgC9Df/jlUlG9lOiuijIJwGo/yX qllYVe2eoKg5WoaYHbm6e00UwPfDOBwsW/V57ecVgwUxIBV4RT9O3VJydbhl2pleyl4fkgyW F9SVS28i4XpMHEs1jQxs92FrgMe0uXkz+yy0GzWEH5llqTWtFWS2XShrrB+3aaF4Cs/pOu9g B27HLDCwl4mNJKTg9/z9EjTbmmXJd2faeAmqUPZYhoAzxMLbzdUwPx0kN1oQ1DT8dMDeoAex P1AqaB+PjA3rINVWCMMzpT0XdjiNbF4y8I+x7x+E+PJ0fb7e+0UL472wnH3GqJWYJU/zKfaC sSTZPe0a5GTHmZ4s1TTv5FjB6RrCX5mJgy3r9O6NHOl6ogyAUnGmVoKPQ0+YBfOeMhT4NECk J2Q4w+VPYvakNH2IgZGIv7jmF2BkONxrpKuNwSo/cccXmQ7+NG0Xyf26gJGFerd7HPJipZ4V mb7356hmNGutkPBn3V+Q8GZaMh4MK0QpX6ic7qlsJsBXL1iKOfUza+DzZehY8ZJq9ixT04ho kFrN0Umd+8WKJ7FD/zEeHI9+buv8XuMWNq7HRwbcNsJa7h9eH4IKPAAL3jmbJ4lRsUc90+BL +TisCv3lzP2NecRWD3zB5bJggHeXNQM2MxpZ9CKPIxFralI2EnxatotPZzOFX3RTtQ1RjtSR N7lU3Zz8RKm8vmmaQ1SlpUkLoQm9pUzmkyts6/tkx2cO3J0RTfuVb6XPQbunJ1+Hkvg/+hRd V1Y1Xs69qzoZfYUCA2Bh6TW6ezcFTHg4ChA3bhsrqbNHTHoFfCyE2aWfw8iTXv2OgzJzb2fh kdnGTnFoEZqxQiZtKYjKKegFES56O7NBoztzlJ5sHOSgHxzVUkKk0f/JLR43YE6Oxi3HW+AA hlVa0NSflv9zsEPK/v7TC74MYqk8sdfULPsBv+39wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsqgqEYAAAA MSev4JJKoECzxIMEZLoITZALVEEVGJJDEFlCyZMrxAQhmU/ygUuKoJtpog0IIxF0YaDPdR5H k3FWWSwsG4aAJBAgZYMF1dYb/3/sio4vjOTjOz6TvISnDI0/cJwDY4JuV4xij9s1aXMUKoqr 2Kl+pKxUvsnNtxCt25He9EzTtCGNj44EcI4tNSy65dHGGA6HcJQphQVB1CqOmN/XuIkRDVha FcNCxuIprIuotD2HeH37Wwyi6IPObwHWGRkHiMIvBLoN5HvnwH8z+h/ULDCbOp9D8vdOjqnq 7go+SFY2G8wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEEKyqhmQAAA6RF0OxKXQ6ERHQ6EoiQV0QR0TJ7MyXJckmVmW REQTsz3czPXPZ7vjvvelnqIlEdDoR0TQjouh0TQiIlIOql0IjqhR1OiiIiTVR0OqjouimfOm XB/Fcqum6ZtjrkQoRhdGT8ezJKRuSxlZkqUvbR/GWrFIEWmUohLKkMtYpjkkwkVsGiEF//// //wzzn3Pu879zvdXd3ec59/c59OWVVtB0055c/Zt0vMZw5Osout6IT1i2bSA4wt5BVsXXUMD 1LF+uG2sXs6KBr8VSymuvZX/CsA24dUdA68O1CfCkA8Chrg8UPKDzQ2gbUNuGlkmdby5IU+D cO5DVhrQ8EPECtCugYzm9tqG4haSTN10Gdgez3FrHwqsPCDXh5AbENm04nWttoWla4okHsAn QZhTg7Aod+FYHjBsArwsGsKFpKGTtB7YG4VIVQeAFYFaG82VrefC9MPVY3T6fHbQtME8FEFO CId8HhhWhsArw9IPWDcB1LaB1gaYJ4GYd0CQd6FYHjhsg84PQCwDbh1Eqt1cHsQ7cKIO7BIN cFYHkhsQ3m03s+GVIaPadn2R6KMxutsaozioKoOhI0w3XukSvY3GKqjYcFolHIu6hslcWGIa 3iw+nQKqtD5qUY4pTJFEjrhxvaN9t9RqKhA80noiuSUayJnUC6uAzlFQ3Vae/xZhUNib3jli mckqzkKxRCFXZcdPrBDN+q+9WH6jIfeUenEkfaF/IqzVCzUgn8YJuJRVobpoYhxH7/Dtugl8 q0P39ZUY5Lju/CK3HBEObHzl2NDGpXe/czwqjqktYhDtvDEfGEEgoNpVuhp5FX7aUyp+N+Ym B+mlB0Upyun7EfyCrgpDCUUhHFN9jKst2iQ2fSta2CzSMo8MxPB0BKu/wiMdllYx1OIqG5Vx 5iTz7FSCxqRE12xrsJZxh8zRdSmVh2O9uNJidDlFPiPqhJoYiZAp5lcuQZkwam2yrxY3I27J qBr+5Spmi4fBfdxrHCj2472miSz/CRc4+io5p/c9oYOkVFSuk/2rBxZ6oXxJHcLmJzcAlRD8 3RuuX5Dg08sEw4TgsvIcKUjm9FWW8lz73s0Z/KEKXDVJRZjpnh+PSksqklRbnwOUHT44ixvM SUFkLfsxuxZxM3lVGzONwHcCTE1keeWWSMGTyC0PBhn/8fPisHRUOXpZOGx8a1NrR0h//MNN xyZ1WneTlBaa/Dw/MbeioNV9S1OrzsTEczHVISFHCTU0RLmZ057dvMtBnTkpsURvb/SGxjbc ETWTh+ks0q+hWek1lRnd60MrDfbkdWqyujnqPzZmiCSKPCynZ+Dl8maLxtKS/O+6Ly4m4bYn CX5Hl7mdJKYvuXzISs8v0X8VdwCZN3Q4JDmpWQV4Ve/EWCBjfRJosgzKn6C4ibP/mmoQRR/L Nspi7UCyqpEjno3T4Z825Q1/GM6zXn3Tu1k7VZUaH1SjuUZf+5Jv1sjx9IKng+iY6aGChmyY 9/GsLBrkq6Q3s0FE0RLyg5WSlzkTTH2/7BCPPjsBBKunuSh19+ONcCKJ+ymKX9keRf8R0Sfu S3Sd3x/DlNLi7/P3ohMX3ErIbskQ93/ml5U4ZJpyyTh+uX/0V1VwFj67d3HKGRHRL3U1yu8p CGE7XbOjZfusv/skAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBBAAhQQQDQM0EA EGBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAXEQoKQAAAAAAAAUAAwAAADgAAIAFAAAAsAAAgAYAAADIAACA DgAAAHABAIAQAAAA4AEAgAAAAABcRCgpAAAAAAAADQABAAAA+AEAgAIAAAAYAgCAAwAAADAC AIAEAAAASAIAgAUAAABgAgCABgAAAHgCAIAHAAAAkAIAgAgAAACoAgCACQAAAMACAIAKAAAA 2AIAgAsAAADwAgCADAAAAAgDAIANAAAAIAMAgAAAAABcRCgpAAAAAAEAAABYCQCAOAMAgAAA AABcRCgpAAAAAAAAEwABDwAAUAMAgAIPAABoAwCAAw8AAIADAIAEDwAAmAMAgAUPAACwAwCA Bg8AAMgDAIAHDwAA4AMAgAgPAAD4AwCACQ8AABAEAIAKDwAAKAQAgAsPAABABACADA8AAFgE AIANDwAAcAQAgPkPAACIBACA+g8AAKAEAID7DwAAuAQAgP0PAADQBACA/g8AAOgEAID/DwAA AAUAgAAAAABcRCgpAAAAAAwAAABkCQCAGAUAgHYJAIAwBQCAfAkAgEgFAICCCQCAYAUAgIgJ AIB4BQCAjgkAgJAFAICUCQCAqAUAgJoJAIDABQCAoAkAgNgFAICmCQCA8AUAgKwJAIAIBgCA sgkAgCAGAIAAAAAAXEQoKQAAAAAAAAEAAQAAADgGAIAAAAAAXEQoKQAAAAAAAAIACQQAAGgG AAAJBAAAeAYAAAAAAABcRCgpAAAAAAAAAQAJBAAAiAYAAAAAAABcRCgpAAAAAAAAAQAJBAAA mAYAAAAAAABcRCgpAAAAAAAAAQAJBAAAqAYAAAAAAABcRCgpAAAAAAAAAQAJBAAAuAYAAAAA AABcRCgpAAAAAAAAAQAJBAAAyAYAAAAAAABcRCgpAAAAAAAAAQAJBAAA2AYAAAAAAABcRCgp AAAAAAAAAQAJBAAA6AYAAAAAAABcRCgpAAAAAAAAAQAJBAAA+AYAAAAAAABcRCgpAAAAAAAA AQAJBAAACAcAAAAAAABcRCgpAAAAAAAAAQAJBAAAGAcAAAAAAABcRCgpAAAAAAAAAQAJBAAA KAcAAAAAAABcRCgpAAAAAAAAAQAJBAAAOAcAAAAAAABcRCgpAAAAAAAAAQAAAAAASAcAAAAA AABcRCgpAAAAAAAAAQAAAAAAWAcAAAAAAABcRCgpAAAAAAAAAQAAAAAAaAcAAAAAAABcRCgp AAAAAAAAAQAAAAAAeAcAAAAAAABcRCgpAAAAAAAAAQAAAAAAiAcAAAAAAABcRCgpAAAAAAAA AQAAAAAAmAcAAAAAAABcRCgpAAAAAAAAAQAAAAAAqAcAAAAAAABcRCgpAAAAAAAAAQAAAAAA uAcAAAAAAABcRCgpAAAAAAAAAQAAAAAAyAcAAAAAAABcRCgpAAAAAAAAAQAAAAAA2AcAAAAA AABcRCgpAAAAAAAAAQAAAAAA6AcAAAAAAABcRCgpAAAAAAAAAQAAAAAA+AcAAAAAAABcRCgp AAAAAAAAAQAAAAAACAgAAAAAAABcRCgpAAAAAAAAAQAAAAAAGAgAAAAAAABcRCgpAAAAAAAA AQAAAAAAKAgAAAAAAABcRCgpAAAAAAAAAQAAAAAAOAgAAAAAAABcRCgpAAAAAAAAAQAAAAAA SAgAAAAAAABcRCgpAAAAAAAAAQAAAAAAWAgAAAAAAABcRCgpAAAAAAAAAQAAAAAAaAgAAAAA AABcRCgpAAAAAAAAAQAAAAAAeAgAAAAAAABcRCgpAAAAAAAAAQAJBAAAiAgAAAAAAABcRCgp AAAAAAAAAQAJBAAAmAgAAAAAAABcRCgpAAAAAAAAAQAJBAAAqAgAAAAAAABcRCgpAAAAAAAA AQAJBAAAuAgAAAAAAABcRCgpAAAAAAAAAQAJBAAAyAgAAAAAAABcRCgpAAAAAAAAAQAJBAAA 2AgAAAAAAABcRCgpAAAAAAAAAQAJBAAA6AgAAAAAAABcRCgpAAAAAAAAAQAJBAAA+AgAAAAA AABcRCgpAAAAAAAAAQAJBAAACAkAAAAAAABcRCgpAAAAAAAAAQAJBAAAGAkAAAAAAABcRCgp AAAAAAAAAQAJBAAAKAkAAAAAAABcRCgpAAAAAAAAAQAJBAAAOAkAAAAAAABcRCgpAAAAAAAA AQAAAAAASAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAHAgAoAQAAAAAAAAAAAAAYBgIA KAEAAAAAAAAAAAAAMAMCAOgCAAAAAAAAAAAAAAgCAgAoAQAAAAAAAAAAAADgAAIAKAEAAAAA AAAAAAAAuP8BACgBAAAAAAAAAAAAAJD+AQAoAQAAAAAAAAAAAABo/QEAKAEAAAAAAAAAAAAA QPwBACgBAAAAAAAAAAAAABj7AQAoAQAAAAAAAAAAAADw+QEAKAEAAAAAAAAAAAAAyPgBACgB AAAAAAAAAAAAAKD3AQAoAQAAAAAAAAAAAAC49AEA6AIAAAAAAAAAAAAAaK0BAAoBAAAAAAAA AAAAAHSuAQCoAwAAAAAAAAAAAAAcsgEASAMAAAAAAAAAAAAAZLUBAKwDAAAAAAAAAAAAABC5 AQDiAwAAAAAAAAAAAAD0vAEANAIAAAAAAAAAAAAAKL8BANoCAAAAAAAAAAAAAATCAQD6AgAA AAAAAAAAAAAAxQEAAgIAAAAAAAAAAAAABMcBAMgAAAAAAAAAAAAAAMzHAQDsAQAAAAAAAAAA AAC4yQEAegIAAAAAAAAAAAAANMwBAKoDAAAAAAAAAAAAAODPAQB+AAAAAAAAAAAAAABg0AEA 8gIAAAAAAAAAAAAAVNMBAAwDAAAAAAAAAAAAAGDWAQDOAgAAAAAAAAAAAAAw2QEAaAAAAAAA AAAAAAAAmNkBALQAAAAAAAAAAAAAAEzaAQCuAAAAAAAAAAAAAACU9AEAIgAAAAAAAAAAAAAA gPQBABQAAAAAAAAAAAAAAGz0AQAUAAAAAAAAAAAAAABY9AEAFAAAAAAAAAAAAAAARPQBABQA AAAAAAAAAAAAADD0AQAUAAAAAAAAAAAAAAAc9AEAFAAAAAAAAAAAAAAACPQBABQAAAAAAAAA AAAAAPTzAQAUAAAAAAAAAAAAAADg8wEAFAAAAAAAAAAAAAAAzPMBABQAAAAAAAAAAAAAALjz AQAUAAAAAAAAAAAAAABA8QEAeAIAAAAAAAAAAAAABQBBAEIATwBVAFQACABNAEEASQBOAEkA QwBPAE4AAgBaADAAAgBaADEAAgBaADIAAgBaADMAAgBaADQAAgBaADUAAgBaADYAAgBaADcA AgBaADgAAgBaADkAAgBaAEwAGDsrsZGhgAAqN/sIQJJkySEhGTrgTvDIoSZl6rKqlbJCTJMy dVCdFbVdD6AN2MbaG2GEV0Yr8Buyq3bbvvwm6LqvyXJLlxehasUDMyzJotkwuqzXXJbVCSxI 6UJAKpIMQOQLMY4EntjOjT6Qaw7JsYNQZIIbAaGAxQGxrDo2lAH6szDBpSQfqqso9FVp9/+x 05znnOec5/6+8aNnPy/LxfvAcfPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LP 8fb8jr+X1eTOYHaLfmB+OVNcAcAqAyAwB6BtoonGBIG6A/gLywdY6fuhuQGgKRu5hJ6DlmgJ 0HL3u5BL3KnqzYB4PW9b7gPrg2oONkJc6QGUB+EHAAQ9fdni9TtLxvme394H3wawGXjSI9UG 4B6fsOUbvZ/AhF5XU0udgh4UQkJIUQSFv+PEUcoFF97eY971r90H4p3D/fsz04M0IsVpPoyL xRI8BSPOQ01JiTivPVdzsQf2uf47GDQ9IzE+WTGzQTmgtEFDkrmU1YxPLSF5wQ4KfWLFeQdj kKFrQx/DgmqTNGaFoCKgpOgpXQ02iNFqoAsjgQjaqaOkF0Cz5tOdqI2QP1YglXmrVGE5wpGL q10YD+XBxj4DfB/ztxYQvtGoeosliTR3EJ8oXpzsDAIoyERnp9rmFIQ+CKsvnZDonXWd6auH dhDNJ7uU7Q1Qk/JKNUsTcSCrc0tt1UukPlui93gSNHeRJIrfqg6lfUfHgG1mwYmOIVrk1q8Z DqKunywCWViUeSVaOSpBRVGUKotmAXRhMSFWAWYsTSBQ/P3S0XrqorSVQVQ2ELxabA9EtL8M Bu4yHVNhWk76i9VSkFOMi0uRS+Kd34gouoes4sNY9El3IaWwwag3eTIgJY49LUCIO0vKRbvK pfwO0gVxMpVPoFVb0YzHGWWESi+Kujk/5UlnFstpacBghlXEMGHO530CyqMR7kO56RlpCVIy 7nZmUzKo2PdsbtmmTdqNXefOUfSkTP9wda+D7v7y7E1ZmuNKGdBr7k9tdpZEnmCfNXuRXgcM TJD0Vx36Lv8M6/3KSw+DnTZdKEzNf1cNVNtE0YnNHdzJobq3gRC9INSWSctAO8NG/nShZXFp WMXKmaOwX+c/3VWuyTU1fz2DQTri9ruLMgQD6VJa1wjegw7KKMMaOonihq19SXNCMc20NN2q XF2Xo4uX2FsjLstOrvOKWWTft3bH0pREMcay0+bOJJB80pKWNo2JUWprq1Mge13NB7JmUpwg XWYIMT+3U8TaJfXpqWuUZO0dFGB+qj67xNLcJAEY3l8GrvEFHE2oRnm2TIxZHzzeX0Own3e4 Tbn1Umgathm2kj5dunAWJ2fS3DmSY53O2rqrhlVjV6rGWHB3VC9XwzmYPt7QkrEv0Bvq6soG RlJsmRy65Z4GNWg1CQcFoUsOIxNVyv1bZNO2hq2GC6yOGyt2r2y6C29Sx8SnZ3BofunT/U1Z G2dDujnqWjlv0iYlTzIN6IIKsHntEPUGRYcnAaTNwhA0mVAHhPKduMMucKKMiQODu5zQUF6E hDRRnwHGfgG1dvlMsn7qy2ZFhp2/9mPUYIG6ETDEHQdi8XVlVPE0V7PNQGg0BRZZg7NFhbot 1ms/mb7JSW7cKyWBYXsWzyB4U/TWhOmJ3KUA9Q+acn11rq18ZubfVB6KJl6XbRKoB60QRzCr JO30Gtx4bTNYpxW2017KX5xqJRQaN59wX1ab+nDR3MKKUn0fl8szeERFBF51hGwTH7cX57bp J3ZV85crPIJmsTaaS3ULeBJ+EfvMpIieLj1xgb4NbARtakuh2rVX7PCAVAwlEZAKOPcnzDbZ V3VBwint5uDqzKJ0fX6izVsmUBh92SmUVWQ8QRslTgHzbZEGnB9ZYdcuWVV5zNWzlYtLbT3q +Kz4ukVtPCBNd6bF5cI5obqXFJ2D4M7muumx2r4sIXz2p9cTPg3K5Q2F8Z9JmyjoDC9xBatx 4vS4yw+1ESLPjBmWGuQzPvfUHw0bWLZz+E2LCN3CaG0atNQ5o8DUvXBEfiYUSo0QEpLOT7Ft jD4EQ0tgV01ohewazorQZGrr/7NCMHs2rUsHzmECsjiJ+kEDrQ2283F4GY0LNwolSMTZ4Rdy QQQbRiUW6oAUrmaIKnkzIfDla/lHo8LX8LSWJCvo+K1tTEbdl1Yc1UD9agi3CybYi6IdkJij FNHqBxykc8QyRk6NmHkVoLmJuRFs0pVl1vqgKzsLMMhJ6RUjCsfCDUKfJOIJrnL4UvxLijKM DT6PfOTWxPqdcEDhIhli2QV4BNOw4HuGqQIVQsg/IDs7lmgfSeJ5Ogdpc1azH++2a18n2bu2 aLWZcVjKOaHb0qw4PcRYEThnKyl0ii6M2KH1xcKHigLRgQFKYrz5u7hgW8LmbCkO6/ldscfs Se1m5azMLUEfCOTMlrzoKagqivMCNF1wh1odRkvZxc0G49uJZFoMN9E59V8usreXjIxqh7Ef PWB3YYVbfDqYtaOFPRV9NiqnhLnocUzRbiYRd3Cx2aCUCNjfRBILswy66JHzCbCnjhejC+Z3 4Ib4VGVRQVTMalAWXWK626nn/2XQG+WBSllbObRT9lUXwqjhR4dHDiaJMdhNCaAQEXM4T6I+ 420B2R98e0IhGEcqCExCIV0Ya+wDPx4XLx2WNWxVl1LRr6HM23gk03tyedvI15w+9OTSVgyJ HgBUvNr4DB4GCbx426VdEcBKvuKoDkngqin2lJkr1wJTd1XVWwpQk+XRKLMqZMGpFhYnvqWO tvhWR7+KZt6vBXBufxPjcSrEoxuHq2ASJ9MTjym4GUrhvkZTBESw8V65N8FX+qAMF1dGE24D zcELf3pleXL7aTqNL/bOUSg7Q4c64ZzwtzSkYjv4Sh8Le4GhZRMGytJjDU614HavGcix+nEk /mp+IfPn71ge+3zhymLnfFmn2J0zc20JghWe9bRleCYX2RaumFATqiN2geeDdt7evrJn9qf4 ld05WoF8dufMD3rO2xEu+p/mhH5jVNa6GdzHPpPVysKJEw51lm0/Bw5T4vDZaOTphLpJMNr+ qpGuVnMkzTro6bW/6D+4u9J8JCzEVr418GxwNBs+5u9IHp98vbY8G4/1dd4WsAF+NATIHCym tYV9vRIgzZ9ZABz2NsrSB4u2QYYdlYUSomGTIbBgnsNSVKdceHjC07o2wuhdFhQZj5ZN0G4c RWRax00XYLkBh3W1+uDitvFGfKPC4n19cox/DE1MWxnvBHDKgqNn2hk8TiaDdrtlf0j/iHRk /o1SOMmJ2ZqwDCBrICp3awIXj0LSuhrrMI9BVXsY62NxZsbmgj6803tgl2uGPaZLWIsTrfS/ GPHioa21riSG7r1yNo+ICscZs9NcWkZ4usb1bUWu/1waXX2piBFcUp9h3jTW2DrHOuF4cfvo qDGno4cca41IdgoBdocMHq62nvBizwFYWGx241/JVNr5ptaif6FwdkRNTdlsfkWzyj3azpls wJwnN5bNDNtHmzAnAPNQ+zQpGrHJ4zcvaJcWuh7cA2H5L/oGWixfKHXRmK1ej/yqod2dyd5X Hk38hGV1c29b82SEAvurGM6fhek4E00dsyhUxtMN/rrrb9S0ydW4gWKsQWAxq9NtcWgIs0ge U0Y7zYhU9ijA+wpTs8HepsSY6GztS8vfLOUqasENQx4I2ZqQ+Qxjv4muWse/2MBMRgJzLlBD xZZM9pjyvnJv/ItObLy/EjI3u5lJKyziJc1ca+SPfCZnkPMjUTsQ67lsU6TLZexmRNDGG4lR mshTscJMFplUw3YzGDEyfno6dmozlPz/9dBrnFSzCjQPOxqQNlo6EKRxxl9xGlNM4ebrxBZT YvI+XSos1T+clInkWqPVXI2eGzLNNsXO+74WznaP48rMptSytQcXE6T7Isv5qc8dXzntS+1j EazBuZqJIopL51oDegD6DdQyLCtVT3ZwMUKYkFJ9aDH6gEUlGPD8/8SCpJrQzRQ6DouCHu2P Ybi7rg1PcUT+3ODcVIR1xnIHpH7GrZS0HRG2P+h1waHkWGN0+v8ombMRA8J+PhEbhPpDrL0J 4zIjtxnShUzi1U60ExlJZzoPKnHNIC6FKMbI+w//0PkEOSSE+VBZNIaqDN9YdO20rIrqkiba SyS7hr+2kdT623UXKt3Ew8RvldyQSMbk7yK00VhDJdakIdFKdCSHTsEXkXJ9hinPWdZ7Vdns lQGmTQKbb9fHz4WfCz4WfCwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACQYOhyBQAA6zOH25AAUEEACFBBANAzQQAQYEEAAAAAAAAAAAAA4AEAAABAAABAAQAAAAAA AAAAAABwAQC7MDlEAAPdK51UOUQAg72MR0QAAImdjEdEAA+FgQQAAI2FlEdEAFD/laBIRACJ hZBHRACL+I2doUdEAFNQ/5WcSEQAiYXpOUQAjZ2uR0QAU1f/lZxIRACJhe05RACNhf46RAD/ 4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1BcBAAAAAAAA AAAAAAAAAAAAEAAAAAoBAAAgAQAAAgAAAEABAAAMAAC4mQEASEYAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACLnWA5RAAL23QKiwOHhWQ5RACJA421 DjpEAIM+AA+EHwEAAI21DjpEAGoEaAAQAABoABgAAGoA/5XpOUQAiYXlOUQAi0YEBQ4BAABq BGgAEAAAUGoA/5XpOUQAiYXhOUQAVoseA52MR0QA/7XlOUQA/3YEUFPoOwMAAIC9BTpEAAB1 Xv6FBTpEAIs+A72MR0QA/zfGB8P/148HUFFWU4vIg+kGi7XhOUQAM9sLyXQueCysPOh0CusA POl0BENJ6+uLBusAgD4GdfMkAMHAGCvDiQaDwwWDxgSD6QXrzlteWViLyIs+A72MR0QAi7Xh OUQAwfkC86WLyIPhA/OkXmgAgAAAagD/teE5RAD/le05RACDxgiDPgAPhSb///9oAIAAAGoA /7XlOUQA/5XtOUQAi51gOUQAC9t0CIsDh4VkOUQAi5WMR0QAi4VYOUQAK9B0eYvCwegQM9uL tWg5RAADtYxHRACDPgB0YYtOBIPpCNHpiz4DvYxHRACDxghmix7B6wyD+wF0DIP7AnQWg/sD dCDrLGaLHoHj/w8AAGYBBB/rHWaLHoHj/w8AAGYBFB/rDmaLHoHj/w8AAAEUH+sAZoMO/4PG AuK065qLlYxHRACLtdU5RAAL9nQRA/KtC8B0CgPCi/hmrWar6/GLtVw5RACLlYxHRAAD8otG DIXAD4QKAQAAA8KL2FD/laBIRACFwHUHU/+VpEhEAImF2TlEAMeF3TlEAAAAAACLlYxHRACL BoXAdQOLRhADwgOF3TlEAIsYi34QA/oDvd05RACF2w+EogAAAPfDAAAAgHUEA9pDQ1OB4/// /39T/7XZOUQA/5WcSEQAhcBbdW/3wwAAAIB1GVeLRgwDhYxHRABQU42FB0hEAFBX6ZkAAACB 4////3+LhZBHRAA5hdk5RAB1JFeL00rB4gKLndk5RACLezyLfDt4A1w7HIsEEwOF2TlEAF/r FleLRgwDhYxHRABQU42FWEhEAFBX60uJB4OF3TlEAATpMv///4kGiUYMiUYQg8YUi5WMR0QA 6ev+//+Lhf05RABQA4WMR0QAWQvJiYUvPkQAYXUIuAEAAADCDABoAAAAAMOLhZBHRACNjclH RABRUP+VnEhEAImF9TlEAI2F2UdEAFD/laRIRACJhdVHRACNjeRHRABRUP+VnEhEAImF+TlE AIuF1UdEAI2N8EdEAFFQ/5WcSEQA/9CDxBBfajCNnfpHRABTV2oA/5X5OUQAav//lfU5RACL LCSB7Tc5RADDi0QkEIHsVAMAAI1MJARQ6KgDAACLjCRcAwAAi5QkWAMAAFFSjUwkDOgNBAAA hMB1CoPI/4HEVAMAAMOLjCRgAwAAjQQkUFGNTCQM6OgFAACEwHUKg8j/gcRUAwAAw4sEJIHE VAMAAMIQAAABAgMEBQYHCAoMDhAUGBwgKDA4QFBgcICgwOAAAAAAAAAAAAEBAQECAgICAwMD AwQEBAQFBQUFAAAAAAEBAgIDAwQEBQUGBgcHCAgJCQoKCwsMDA0NDg4PDxAQERERERERERER ERERERESEhISEhISElGL0Va5CAAAAFc5SgRyNVO++P///4sCihhAiFwkDIkCi0IIi3wkDMHg CIHn/wAAAAvHi3oEA/6JQgiLx4l6BDvBc9Jbi3IEi0IIi3wkECvO0+i5GAAAACvPJf///wDT 6AP3X4lyBF5ZwgQAi0QkBItUJAiJgYQAAACJkYgAAACNBIKJgYwAAAAFAAEAAMIIAIHsmAAA AFNVVovRV7kPAAAAi6qEAAAAM8CNfCQsM/bzq4u8JKwAAAA77olUJCB2FTPJigw4i1yMKI1M jChDQDvFiRly67kXAAAAiXQkKIlyBIlyRIl0JGgz/4l0JBzHRCQQAQAAAIlMJBiNagiJdCQU i0Q0LNPgA/iB/wAAAAGJfCQkD4eOAAAAi0Q0KIl9AItdPAPDg/kQiUVAiUQ0bHxNi3UAi0Qk EItcJByLuowAAADB7hCLziX/AAAAK8sD+4rYi9GK+4l0JByLw4t0JBTB4BBmi8PB6QLzq4vK i1QkIIPhA/Oqi3wkJItMJBiLRCQQg8YEQEmDxQSD+QmJRCQQiUwkGIl0JBQPjWL///+B/wAA AAF0D19eXTLAW4HEmAAAAMIEAIuChAAAADPJhcB2O4u0JKwAAACKBDGEwHQii7qIAAAAJf8A AACLRIRoiQyHM8CKBDGLfIRojUSEaEeJOIuChAAAAEE7yHLMX15dsAFbgcSYAAAAwgQAUVNW i/FXiwaDeAQIcjCLCIoRQYhUJAyJCItICItUJAzB4QiB4v8AAAALyotQBIPC+IlICIvKiVAE g/kIc9CLUASLQAi5CAAAACvK0+iLTiQlAP7/ADvBcxSLlowAAACLyMHpEDPbihwRi9PrOztG LHMKO0YoG9KDwgrrLDtGMHMHugsAAADrIDtGNHMHugwAAADrFDtGOHMHug0AAADrCDtGPBvS g8IPiw6LeQQD+ol5BIsclrkYAAAAK8Mryl/T6ItMlkQDwYuOiAAAAF5biwSBWcNTVleL+TPS M8CNt2gCAACJFlboVwIAAIqMMFU/RABeuwEAAACDxgTT4wPTQIP4OnLei0QkEI1PEFBo0QIA AOhI/f//UGocjY+gAAAA6Dr9//9QagiNjzABAADoLP3//1BqE42PwAEAAOge/f//iYdgAgAA X14F9QIAAFvCBACLRCQIi9GLTCQEV4kCjUIEiQjHQAQgAAAAiUIQiYKgAAAAiYIwAQAAiYLA AQAAM8C5vQAAAImCUAIAAImCVAIAAImCWAIAAIu6YAIAAImCXAIAAPOri8qq6AQAAABfwggA gewMAwAAU4vZVVaNawRXagGLzegp/P//hcB1Dou7YAIAALm9AAAA86uqM/ZqBIvN6Az8//+I RDQQRoP+E3LtjbvAAQAAjUQkEFCLz+iA/P//hMB1C19eXVuBxAwDAADDM/aLz+jk/f//g/gQ cxWLi2ACAACKFDEC0IDiD4hUNCRG62B1KGoCi83os/v//4PAA4XAfk6B/vUCAAB9UopMNCNI iEw0JEaFwH/q6zaD+BF1DmoDi83ohvv//4PAA+sMageLzeh4+///g8ALhcB+E4H+9QIAAH0X xkQ0JABGSIXAf+2B/vUCAAAPjHP///+NVCQkjUsQUujV+///hMB1C19eXVuBxAwDAADDjYQk 9QIAAI2LoAAAAFDos/v//4TAdQtfXl1bgcQMAwAAw42MJBEDAABRjYswAQAA6JH7//+EwHUL X15dW4HEDAMAAMPGg2QCAAAAM8CAvAQRAwAAA3UIQIP4CHLw6wfGg2QCAAABi7tgAgAAjXQk JLn1AgAA86RfXl2wAVuBxAwDAADD6AEAAACQXoHu4kREAMOD7BSLRCQcU1VWxwAAAAAAi0Qk JFcz/4XAi/GJfCQQD4ZbAgAAjU4Q6IP8//89AAEAAHMTiw6IAYsOQUeJDol8JBDpKQIAAD3Q AgAAD4MTAgAABQD///+L6IPgB8HtA41QAoP4B4lUJBQPhZQAAACNjqAAAADoNvz//4tOCDPb Vuht////ipwwOT9EAF6D+QhyMotOBIoRQYhUJBiJTgSLTgyLVCQYweEIgeL/AAAAC8qLVgiD wviJTgyLyolWCIP5CHPOi34Ii1YMuQgAAAArzwP70+q5GAAAAIl+CCvLgeL///8A0+ozyVbo A////4qMMB0/RABei0QkFAPKA8GJRCQUioZkAgAAi5yuaAIAADPSVuja/v//ipQ1VT9EAF6E wIv6dHaD/wNycYtGCI1v/YP4CHIxi0YEi1YMweIIighAiEwkHItOCIlGBItEJBwl/wAAAIPB +AvQi8GD+AiJVgyJTghzz4tGCIt+DLkIAAAAK8gDxdPvuRgAAACJRggrzYHn////ANPvjY4w AQAA6Bv7//8Dw40c+Otbg34ICHIxi0YEi1YMweIIighAiEwkIItOCIlGBItEJCAl/wAAAIPB +AvQi8GD+AiJVgyJTghzz4tWCItGDLkIAAAAK8oD19PouRgAAACJVggrzyX///8A0+gD2IP7 A3Mai4yeUAIAAIXbdDCLllACAACJlJ5QAgAA6xuLhlQCAACLllACAACNS/2JhlgCAACJllQC AACJjlACAACLBot8JBRBjRQ4O8KJFnMQi9Ar0UCKEohQ/4sWO8Jy8ItEJBADx4lEJBCL+OsL i87o9/v//4TAdBw7fCQoD4Kr/f//i0QkLIk4X15dsAFbg8QUwggAX15dMsBbg8QUwggAkAAA AAAIAAAAAAAAAAAAAABrZXJuZWwzMi5kbGwAVmlydHVhbEFsbG9jAFZpcnR1YWxGcmVlAFZp cnR1YWxQcm90ZWN0AEV4aXRQcm9jZXNzAAAAAAB1c2VyMzIuZGxsAE1lc3NhZ2VCb3hBAHdz cHJpbnRmQQBMT0FERVIgRVJST1IAVGhlIHByb2NlZHVyZSBlbnRyeSBwb2ludCAlcyBjb3Vs ZCBub3QgYmUgbG9jYXRlZCBpbiB0aGUgZHluYW1pYyBsaW5rIGxpYnJhcnkgJXMAVGhlIG9y ZGluYWwgJXUgY291bGQgbm90IGJlIGxvY2F0ZWQgaW4gdGhlIGR5bmFtaWMgbGluayBsaWJy YXJ5ICVzAJCJ7wEAmu8BAK3vAQAAAAAAa2VybmVsMzIuZGxsAAAAR2V0UHJvY0FkZHJlc3MA AABHZXRNb2R1bGVIYW5kbGVBAAAATG9hZExpYnJhcnlBAAAAAAAAAAAAAAAAAHzvAQBs7wEA AAAAAAAAAAAAAAAAXPABAKLwAQAAAAAAAAAAAAAAAABn8AEAqvABAAAAAAAAAAAAAAAAAHTw AQCy8AEAAAAAAAAAAAAAAAAAgfABALrwAQAAAAAAAAAAAAAAAACL8AEAwvABAAAAAAAAAAAA AAAAAJbwAQDK8AEAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c2VyMzIuZGxsAG9sZWF1dDMyLmRs bABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAHVzZXIzMi5kbGwAc2hlbGwzMi5kbGwA0vABAAAA AADg8AEAAAAAAPbwAQAAAAAAB/EBAAAAAAAY8QEAAAAAACvxAQAAAAAAAABNZXNzYWdlQm94 QQAAAFZhcmlhbnRDaGFuZ2VUeXBlRXgAAABSZWdTZXRWYWx1ZUV4QQAAAEdldFN0b2NrT2Jq ZWN0AAAAVHJhbnNsYXRlTWVzc2FnZQAAAFNoZWxsX05vdGlmeUljb25BAAB4AjQAAABWAFMA XwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQALAAQAGAABABgAAQAAAAAA AAAAAAAAAAAEAAQAAQAAAAAAAAAAAAAAAAAAANYBAAAAAFMAdAByAGkAbgBnAEYAaQBsAGUA SQBuAGYAbwAAALIBAAAAADAANAAwADkAMAA0AEUANAAAAD4ADwABAEMAbwBtAHAAYQBuAHkA TgBhAG0AZQAAAAAARQBuAFQAZQBjAGgAIABUAGEAaQB3AGEAbgAAAAAAAAA6AAkAAQBGAGkA bABlAEQAZQBzAGMAcgBpAHAAdABpAG8AbgAAAAAATQB1AGwAdABpAFIAZQBzAAAAAAA4AAwA AQBGAGkAbABlAFYAZQByAHMAaQBvAG4AAAAAADQALgAxADEALgAwADEALgAyADYAAAAAADIA CQABAEkAbgB0AGUAcgBuAGEAbABOAGEAbQBlAAAATQB1AGwAdABpAFIAZQBzAAAAAABuACUA AQBMAGUAZwBhAGwAQwBvAHAAeQByAGkAZwBoAHQAAABDAG8AcAB5AHIAaQBnAGgAdAAgAKkA IABFAG4AVABlAGMAaAAgAFQAYQBpAHcAYQBuACAAMQA5ADkANQAtADIAMAAwADAAAAAAAAAA QgANAAEATwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0AZQAAAG0AdQBsAHQAaQByAGUA cwAuAGUAeABlAAAAAABEAAAAAABWAGEAcgBGAGkAbABlAEkAbgBmAG8AAAAAACQABAAAAFQA cgBhAG4AcwBsAGEAdABpAG8AbgAAAAAACQTkBAAAAQABACAgEAABAAQA6AIAAA0AAAABAAEA EBAQAAEABAAoAQAAAwAAAAEAAQAQEBAAAQAEACgBAAAEAAAAAQABABAQEAABAAQAKAEAAAUA AAABAAEAEBAQAAEABAAoAQAABgAAAAEAAQAQEBAAAQAEACgBAAAHAAAAAQABABAQEAABAAQA KAEAAAgAAAABAAEAEBAQAAEABAAoAQAACQAAAAEAAQAQEBAAAQAEACgBAAAKAAAAAQABABAQ EAABAAQAKAEAAAsAAAABAAEAEBAQAAEABAAoAQAADAAAAAEAAgAQEBAAAQAEACgBAAABACAg EAABAAQA6AIAAAIAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAH//////93iAAAAAAAAACP/3d3h3d3dwAI AAAAAAAAj///eDB3d3GZkAAAAAAAAAiHd4uzB3dx+ZAAAAAAAAAACIO7sDB3gfmQAAAAAAAA AAAAOzuzCAH5kAAAAAAAAAAAAAO7sDAB+ZAAAAAACIiIiIiIO7uzAfmQiIAAAAj3d3d3d3O7 sDD5kHeIAAAI9///////OzuzCZD3iIAACPdEREREREO7sDCQ94iAAAj3BmZmZmZmO7uzAPeI gAAI9wZmZmZmZmO7sDD3iIAACPcGZmZmZmZmOzuzB4iAAAj3BmZmZmZmZmO7sDCIgAAI9wZm ZmZmZmZhO7uzCIAACPcGZmZmZmZmYfO7sDCAAAj3Bp5mZmZmZmH3OzuzAAAI9wbpZmZmZmZh 95O7sDAACPcGZmZmZmZmYXeQOzuzAAj3BmZmZmZmZmEREPO7sDAI9wbaZmZmZmZh9VD3OzMA CPcGrWZmZmZmZgAE94MwAAj3BmZmZmZmZmM4MPeIMAAI9wAAAAAAAAAKs4D3iIAACPeIiIiI iIiIiqgw94iAAAj3d3d3d3d3d3qrB3eIgAAAj///////////qg//iIAAAAh3d3d3d3d3d3p3 d/iAAAAAh3d3d3d3d3d6d3d/gAAAAAiIiIiIiIiIiIiIiIAA/gAD//gAAP/wAAB/8AAAf/gA AP/+AAD//8AA/8AAAB+AAAAPgAAAB4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA4AAAAOAAAAD gAAAA4AAAAOAAAABgAAAAIAAAAGAAAADgAAAA4AAAAOAAAADgAAAA8AAAAPgAAAD8AAAA/gA AAcoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAA AICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAA AAAAAAAACP93d3gYAAAAiPcIeZEAAAAAg7CJcQAAAAAAOwlxAACHd3dzsHF4AI9EREQ7AXgA jwZmZmOwiACPBmZmaTsIAI8GZmZpc7AAjwamZmmaCwCPBmZmZgB4sI8AAAACuHgAj/////q/ eAAId3d3d6f4AACIiIiIiIgAwA8AAIAHAADABwAA8AcAAIATAAAAAQAAAAEAAAABAAAAAQAA AAEAAAABAAAAAQAAAAEAAAABAACAAQAAwAMAACgAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8A AP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAI/3d3eBgAAACI9wh5kQAAAACDsIlx AAAAAAA7CXEAAId3d3OwcXgAj0RERDsBeACPBv//Y7CIAI8Gb/ZpOwgAjwZv9mlzsACPBv/2 aZoLAI8Gb/ZmAHiwjwAAAAK4eACP////+r94AAh3d3d3p/gAAIiIiIiIiADADwAAgAcAAMAH AADwBwAAgBMAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAIABAADAAwAA KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACA gACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAA AAAAAAj/d3d4GAAAAIj3CHmRAAAAAIOwiXEAAAAAADsJcQAAh3d3c7BxeACPREREOwF4AI8E //9jsIgAjwT/b2k7CACPBE/2aXOwAI8ERP9pmgsAjwT/9mYAeLCPAAAAArh4AI/////6v3gA CHd3d3en+AAAiIiIiIiIAMAPAACABwAAwAcAAPAHAACAEwAAAAEAAAABAAAAAQAAAAEAAAAB AAAAAQAAAAEAAAABAAAAAQAAgAEAAMADAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/ AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAACP93d3gYAAAAiPcIeZEAAAAAg7CJcQAA AAAAOwlxAACHd3dzsHF4AI9VVVU7AXgAjwX//1OwiACPBVVfWTsIAI8FX/9Zc7AAjwVVX1ma CwCPBf//VQB4sI8AAAACuHgAj/////q/eAAId3d3d6f4AACIiIiIiIgAwA8AAIAHAADABwAA 8AcAAIATAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAACAAQAAwAMAACgA AAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAA AAAI/3d3eBgAAACI9wh5kQAAAACDsIlxAAAAAAA7CXEAAId3d3OwcXgAjwERETsBeACPARHx E7CIAI8B//8ZOwgAjwHx8RlzsACPAR/xGZoLAI8BEfERAHiwjwAAAAK4eACP////+r94AAh3 d3d3p/gAAIiIiIiIiADADwAAgAcAAMAHAADwBwAAgBMAAAABAAAAAQAAAAEAAAABAAAAAQAA AAEAAAABAAAAAQAAAAEAAIABAADAAwAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAj/d3d4GAAAAIj3CHmRAAAAAIOwiXEAAAAA ADsJcQAAh3d3c7BxeACPAiIiOwF4AI8C//8jsIgAjwIiLyk7CACPAv//KXOwAI8C8iIpmgsA jwL//yIAeLCPAAAAArh4AI/////6v3gACHd3d3en+AAAiIiIiIiIAMAPAACABwAAwAcAAPAH AACAEwAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAgAEAAMADAAAoAAAA EAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAA AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAA CP93d3gYAAAAiPcIeZEAAAAAg7CJcQAAAAAAOwlxAACHd3dzsHF4AI8GZmY7AXgAjwb//2Ow iACPBvZvaTsIAI8G//9pc7AAjwb2ZmmaCwCPBv//ZgB4sI8AAAAGuHgAj/////q/eAAId3d3 d6f4AACIiIiIiIgAwA8AAIAHAADABwAA8AcAAIATAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB AAAAAQAAAAEAAAABAACAAQAAwAMAACgAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD/ /wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAI/3d3eBgAAACI9wh5kQAAAACDsIlxAAAAAAA7 CXEAAId3d3OwcXgAjwERETsBeACPAR/xE7CIAI8BEfEZOwgAjwER/xlzsACPAfEfGZoLAI8B //8RAHiwjwAAAAG4eACP////+r94AAh3d3d3p/gAAIiIiIiIiADADwAAgAcAAMAHAADwBwAA gBMAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAIABAADAAwAAKAAAABAA AAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAA gACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAj/ d3d4GAAAAIj3CHmRAAAAAIOwiXEAAAAAADsJcQAAh3d3c7BxeACPAREROwF4AI8B//8TsIgA jwHxHxk7CACPAf//GXOwAI8B8R8ZmgsAjwH//xEAeLCPAAAAAbh4AI/////6v3gACHd3d3en +AAAiIiIiIiIAMAPAACABwAAwAcAAPAHAACAEwAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAA AAEAAAABAAAAAQAAgAEAAMADAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAACP93d3gYAAAAiPcIeZEAAAAAg7CJcQAAAAAAOwlx AACHd3dzsHF4AI8EREQ7AXgAjwT//0OwiACPBERPSTsIAI8E//9Jc7AAjwT0T0maCwCPBP// RAB4sI8AAAAEuHgAj/////q/eAAId3d3d6f4AACIiIiIiIgAwA8AAIAHAADABwAA8AcAAIAT AAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAACAAQAAwAMAACgAAAAgAAAA QAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAA gACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAA AAAAAAAAAAf//////3eIAAAAAAAAAI//d3eHd3d3AAgAAAAAAACP//94MHd3cZmQAAAAAAAA CId3i7MHd3H5kAAAAAAAAAAIg7uwMHeB+ZAAAAAAAAAAAAA7O7MIAfmQAAAAAAAAAAAAA7uw MAH5kAAAAAAIiIiIiIg7u7MB+ZCIgAAACPd3d3d3c7uwMPmQd4gAAAj3//////87O7MJkPeI gAAI90REREREQ7uwMJD3iIAACPcGZmZmZmY7u7MA94iAAAj3BmZmZmZmY7uwMPeIgAAI9wZm ZmZmZmY7O7MHiIAACPcGZmZmZmZmY7uwMIiAAAj3BmZmZmZmZmE7u7MIgAAI9wZmZmZmZmZh 87uwMIAACPcGnmZmZmZmYfc7O7MAAAj3BulmZmZmZmH3k7uwMAAI9wZmZmZmZmZhd5A7O7MA CPcGZmZmZmZmYREQ87uwMAj3BtpmZmZmZmH1UPc7MwAI9watZmZmZmZmAAT3gzAACPcGZmZm ZmZmYzgw94gwAAj3AAAAAAAAAAqzgPeIgAAI94iIiIiIiIiKqDD3iIAACPd3d3d3d3d3eqsH d4iAAACP//////////+qD/+IgAAACHd3d3d3d3d3end3+IAAAACHd3d3d3d3d3p3d3+AAAAA CIiIiIiIiIiIiIiIgAD+AAP/+AAA//AAAH/wAAB/+AAA//4AAP//wAD/wAAAH4AAAA+AAAAH gAAAA4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA4AAAAGAAAAAgAAAAYAA AAOAAAADgAAAA4AAAAOAAAADwAAAA+AAAAPwAAAD+AAABygAAAAQAAAAIAAAAAEABAAAAAAA wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICA gAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAI/3d3eBgAAACI9wh5kQAA AACDsIlxAAAAAAA7CXEAAId3d3OwcXgAj0RERDsBeACPBmZmY7CIAI8GZmZpOwgAjwZmZmlz sACPBqZmaZoLAI8GZmZmAHiwjwAAAAK4eACP////+r94AAh3d3d3p/gAAIiIiIiIiADADwAA gAcAAMAHAADwBwAAgBMAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAIAB AADAAwAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP// /wAAAAAAAAAAAAj/d3d4GAAAAIj3CHmRAAAAAIOwiXEAAAAAADsJcQAAh3d3c7BxeACPRERE OwF4AI8GZmZjsIgAjwZmZmk7CACPBmZmaXOwAI8GpmZpmgsAjwZmZmYAeLCPAAAAArh4AI// ///6v3gACHd3d3en+AAAiIiIiIiIAMAPAACABwAAwAcAAPAHAACAEwAAAAEAAAABAAAAAQAA AAEAAAABAAAAAQAAAAEAAAABAAAAAQAAgAEAAMADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA= --part1_f8.65bd20b.278a2f74_boundary-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 13:23:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 6AE6A37B402 for ; Sun, 7 Jan 2001 13:23:02 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14FNNM-00009p-00; Sun, 07 Jan 2001 14:29:16 -0700 Message-ID: <3A58DFAC.15021C06@softweyr.com> Date: Sun, 07 Jan 2001 14:29:16 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: opentrax@email.com Cc: freebsd-hackers@freebsd.org Subject: Re: [Question] CVS and CVS@freebsd References: <200101070416.UAA04408@spammie.svbug.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG opentrax@email.com wrote: > > [Note: I've BCC'd to arch to get advanced implemention suggestions] > > Hey everyone OpenCountry.org has asked me to setup > a CVS repository for them. Their business plan includes > packageing, wrapping and selling LINUX open source software. > > They want to build an infrastructure to support multiple unrelated > independent developers. It will include the usual web, mailing list > stuff, but they also want CVS, bug reporting and integrationg > with the message board (Twiki). > > I'm considering using Perl, Mysql, Cvsweb and Mason or PHP. > > Can anyone give me suggestion on implementing this? > Specifically I'd like to know about tools available, > concepts that would aid developers and any suggestions > out-of-scope that would aid developers. Bugzilla. The only thing not to like about it is the insanse insistence on MySQL; it would be ever so much better with PostgreSQL (says Wes the Berkeley license bigot). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 13:46:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15C6037B6B5 for ; Sun, 7 Jan 2001 13:46:10 -0800 (PST) Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 800B36E2777 for ; Sun, 7 Jan 2001 13:42:58 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14FNbc-0000A5-00; Sun, 07 Jan 2001 14:44:00 -0700 Message-ID: <3A58E31F.19F8F194@softweyr.com> Date: Sun, 07 Jan 2001 14:43:59 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeremiah Gowdy Cc: Jonas Luster , freebsd-hackers@FreeBSD.ORG Subject: Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap References: <200101070509.f0759uw74992@green.dyndns.org> <001801c0786c$e5d55b60$aa240018@cx443070b> <20010107001846.A42548@netwarriors.org> <000f01c078de$14478c40$aa240018@cx443070b> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeremiah Gowdy wrote: > > > > Claiming that software isn't "free" because it's not valuable is > redefining > > > the word "free" to mean something that has no cost, yet has value. > > > > > > free (fr) adj. Costing nothing; gratuitous: > > > > Yeah, and 'gay' means 'joyful'. > > You're saying the most common definition of "free" isn't no cost ? That would depend on whether you're talking to Libertarians or KMart Shoppers. Can we please take this off the hackers list? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 14: 0:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id C72DE37B402 for ; Sun, 7 Jan 2001 14:00:36 -0800 (PST) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.11.2/8.11.2) with ESMTP id f07M0I816620; Sun, 7 Jan 2001 20:00:18 -0200 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Sun, 7 Jan 2001 20:00:18 -0200 (BRDT) From: Rik van Riel X-Sender: riel@duckman.distro.conectiva To: Jeremiah Gowdy Cc: Jonas Luster , freebsd-hackers@FreeBSD.ORG Subject: Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap In-Reply-To: <000f01c078de$14478c40$aa240018@cx443070b> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 7 Jan 2001, Jeremiah Gowdy wrote: > You're saying the most common definition of "free" isn't no cost ? I'm a free man, not a commercial sample! Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 14:37:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by hub.freebsd.org (Postfix) with ESMTP id E1CE537B402 for ; Sun, 7 Jan 2001 14:37:36 -0800 (PST) Received: from UNIX8.ANDREW.CMU.EDU (UNIX8.ANDREW.CMU.EDU [128.2.11.208]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id RAA06430 for ; Sun, 7 Jan 2001 17:37:35 -0500 (EST) Date: Sun, 7 Jan 2001 17:37:35 -0500 (EST) From: Mohan Khurana To: freebsd-hackers@freebsd.org Subject: Xbox Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, this is going to seem like a rather strange question. I understand that Xbox is simply IA-32, however I have heard that the Xbox has a special ROM that boots Windows CE, to ensure that people do not purchase the Xbox for the sole reason of running FreeBSD or any other operating system on it. Does anyone know enough about Xbox internals to verify that FreeBSD will or will not be able to run on Xbox without any type of hardware modification? thanks, mohan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 15:36:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bilver.wjv.com (dhcp-1-62.n01.orldfl01.us.ra.verio.net [157.238.210.62]) by hub.freebsd.org (Postfix) with ESMTP id E188137B400 for ; Sun, 7 Jan 2001 15:36:29 -0800 (PST) Received: (from bill@localhost) by bilver.wjv.com (8.9.3/8.9.3) id SAA04434 for hackers@FreeBSD.ORG; Sun, 7 Jan 2001 18:36:29 -0500 (EST) (envelope-from bill) Date: Sun, 7 Jan 2001 18:36:29 -0500 From: Bill Vermillion To: hackers@FreeBSD.ORG Subject: Re: freebsd-hackers-digest V5 #1 Message-ID: <20010107183629.A4125@wjv.com> Reply-To: bv@bilver.wjv.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from owner-freebsd-hackers-digest@FreeBSD.ORG on Sun, Jan 07, 2001 at 12:47:32PM -0800 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Date: Sun, 7 Jan 2001 05:07:06 -0800 (PST) > From: Gordon Tetlow > Subject: Re: OT: silence as an answer? (was: how to test out cron.c changes?) > Hello there! > On Fri, 5 Jan 2001, Doug Barton wrote: > > Gerhard Sittig wrote: > [snip] > > Consider the following. We are in the spring and DST is > > "springing forward" at 2am. We have a job scheduled at 2:15 > > that takes one hour to run. There is another job scheduled at > > 3:20 that ABSOLUTELY POSITIVELY cannot run unless the first > > job finishes. Aside from the fact that this is bad design, how > > should cron handle this situation? .... > I think this is a really horrible example. It is impossible for > FreeBSD to expect to catch bad design on a local administrator's > part. The admin should implement some sort of semaphore (a file in > /tmp) or just append the dependent job to the first job. We can't > insulate stupidity, at least we shouldn't, otherwise FreeBSD is > going to start looking more like Windows. I agree on that. Cron can't know the just how a program runs. Taking the above example and shifting the first program back to prior to 2AM - and that it take over an hour to run - what happens when a the clock springs forward and the hour is missing. The job wasn't scheduled in the 2AM black hole area. Programmers do have to consider DST. That's what we get paid for, right. Just like getting things like Y2K straight :-0 And the last Y2K bugs occured this past week. In Norway [as I recall] on train schedules, because 12/31/2000 hadn't been tested and this week in the US when all the 7/11 stores POS system though 01/01/01 was 1901, and that all the credit cards were invalid. > I think that cron is broken because it doesn't handle DST shift > properly. Just my opinion though, and we seem to get plenty of > those around here =) ISTR that at least in the last couple of years some of the OSes handle the DST shift properly. eg - not running a job twice for example. I've not had a problem on BSD - but then I don't have anything scheduled in those hours except things that run every hour. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 15:45:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.attica.net.nz (mail.attica.net.nz [202.180.64.33]) by hub.freebsd.org (Postfix) with SMTP id 0E49037B400 for ; Sun, 7 Jan 2001 15:45:19 -0800 (PST) Received: (qmail 32345 invoked from network); 7 Jan 2001 23:45:16 -0000 Received: from 202-180-83-18.iff2.attica.net.nz (HELO davep200.afterswish.com) (202.180.83.18) by mail.attica.net.nz with SMTP; 7 Jan 2001 23:45:16 -0000 Message-Id: <5.0.0.25.1.20010108122629.01b325a0@pop3.i4free.co.nz> X-Sender: dmpreece@pop3.i4free.co.nz (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 08 Jan 2001 12:27:46 +1300 To: Mohan Khurana From: David Preece Subject: Re: Xbox Cc: freebsd-hackers@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 17:37 7/01/01 -0500, you wrote: >Does anyone know enough about Xbox internals to verify that >FreeBSD will or will not be able to run on Xbox without any type of >hardware modification? No, but if you'd like to be into that kind of thing I understand the NetBSD/Dreamcast port is coming along quite nicely. >mohan Dave To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 15:51:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 5CEAB37B400; Sun, 7 Jan 2001 15:51:36 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 5E76C6A913; Mon, 8 Jan 2001 10:21:34 +1030 (CST) Date: Mon, 8 Jan 2001 10:21:34 +1030 From: Greg Lehey To: Kathy Quinlan , Robert Swindells , Devin Butterfield Cc: "Michael C . Wu" , freebsd-small@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: StrongARM support? (was also: Group for porting to other proccessor families) Message-ID: <20010108102134.E83353@wantadilla.lemis.com> References: <00c701c078c6$005804c0$fe00a8c0@kat.lan> <3A58E5D6.4A301727@wireless.net> <00c701c078c6$005804c0$fe00a8c0@kat.lan> <200101071635.QAA00761@fdy2.demon.co.uk> <00c701c078c6$005804c0$fe00a8c0@kat.lan> <92527.978877226@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <92527.978877226@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Sun, Jan 07, 2001 at 06:20:26AM -0800 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 8 January 2001 at 0:22:01 +0800, Kathy Quinlan wrote: > Hi all > > Is their a group of FreeBSD Enthusiasts that are working on porting > free to embedded controllers that are not x86 I am in the process of > developing a security / access / building management system, and am > looking at using free on all my outlying units. I am not interested > in using pc104 etc but using processors like the atmel thumb > processor, this is a risc based uC capable of handling 64Mb of flash > ram for program and working ram. why do I want an OS for an > industrial app, simple some units may be standalone and need > dialling into, building units will probably be TCP/IP. If I understand correctly, this is an ARM architecture. Almost the same time you wrote that, this message was sent to -hackers: On Sunday, 7 January 2001 at 6:20:26 -0800, Jordan Hubbard wrote: > [missing attribution to Michael C. Wu] >> I'm definitely interested in both StrongARM and PPC. (and so are very >> many people) My understanding is that FreeBSD *wants* a FreeBSD/ARM, >> but lack the resources/man-power to do so. I'd prefer to see an >> official decision on the above by someone (hint hint -core :)) though. > > I don't think any "official decision" would say anything we in core > haven't already said individually and many times over the years. > Sure, FreeBSD wants ARM and PPC ports but currently lacks, at least to > our knowledge, the man-power to lead and support such a project. You > said it yourself. If some motivated individuals out there would > like to change that situation, you have our full support! Porting to ARM isn't going to be trivial, but the obvious first step is to get interested people together. Note that we've had a SPARC porting effort languishing out there for years now. If ARM is to do better, it will need significant support. Jordan's response above was made without his -core hat on. If people want a response from -core (which I suspect will probably be very similar), they should send mail to -core asking for it. 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-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 16:49:38 2001 Delivered-To: freebsd-hackers@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 56C6137B400; Sun, 7 Jan 2001 16:49:20 -0800 (PST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:8Rv1Y89YKUQ+pTXplWtPrwxkzJAJJRsM@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.11.0/3.7Wpl2) with ESMTP id f080nFH27744; Mon, 8 Jan 2001 09:49:15 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:Il1yWWiJ8rxS7XuksnBjyeKPn35/zOAg@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 JAA27262; Mon, 8 Jan 2001 09:56:56 +0900 (JST) Message-Id: <200101080056.JAA27262@zodiac.mech.utsunomiya-u.ac.jp> To: Robert Watson Cc: hackers@freebsd.org, John Polstra , yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: KVM switch vs. FreeBSD psm driver (Solved!) In-reply-to: Your message of "Sun, 07 Jan 2001 10:52:41 EST." References: Date: Mon, 08 Jan 2001 09:56:55 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >So, question: is there a reason why we can't enable both the USB keyboard >and a native PS/2 keyboard with syscons? It seems that I frequently find >myself in a position where I'd like to plug in a keyboard, or switch KVM >choices to a machine, and discover myself with no access to the hardware >console, and I know at least one person who uses FreeBSD in production and >finds this to be a serious impediment (as it requires the system to be >rebooted to regain console access, and when you have 8 machines per KVM, >and you boot them all, switching back and forth to catch each probe is >effectively impossible). Presumably our syscons is intended to select on >source of I/O and use it, but it might be worth considering a change here. This IS already possible in RELENG_4 and -CURRENT. Add the flags 0x100 to syscons (this is default in both RELENG_4 and CURRENT). Then syscons will look for a keyboard if it started without one at boot time. I don't know if this mechanism works well with KVMs. I never tested with KVMs, because I don't use one. But, it works wonderfully with the USB keyboard. As for unplugging/plugging the AT keyboard... Well, I don't recommend that. That will likely fly your keyboard controller... But, still syscons should be able to use the AT keyboard which is plugged after boot, so long as atkbd is forced to install at boot time. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 19: 7:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 0F7C037B400 for ; Sun, 7 Jan 2001 19:07:34 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id VAA01996 for freebsd-hackers@FreeBSD.ORG; Sun, 7 Jan 2001 21:11:59 -0600 (CST) Date: Sun, 7 Jan 2001 21:11:59 -0600 From: Robert Lipe To: freebsd-hackers@FreeBSD.ORG Subject: kthread_exit & zombification Message-ID: <20010107211159.C1400@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Gang. In 4.1.1, I have a pretty simple need for a kernel thread or two, but I'm having problems with kthread_exit(). The problem is that the thread goes zombie after I kthread_exit in it, but it never gets reaped. Since I'm doing this during a MOD_UNLOAD phase, if I happen to do a `ps -ax' after the module has been unmapped, a panic results becuase it's trying to get the lwp name and wchan string from what is now unmapped memory. But that's a secondary problem; the primary one is that I am missing whatever it takes to get a ticket for the resulting kernel thread to go to Byte Heaven. After a couple of load/unload cycles, I see: $ ps -alx | grep mem 0 357 0 2 0 0 0 0 - ZL ?? 0:00.00 (udi_memd) 0 360 0 2 0 0 0 0 - ZL ?? 0:00.00 (udi_memd) 0 920 0 2 0 0 0 0 - ZL ?? 0:00.00 (udi_memd) 0 954 0 0 0 0 0 0 udi_os SL ?? 0:00.00 (udi_memd) The creation is pretty simple: if (kthread_create(my_daemon, NULL, &my_thread, "mydaemon")) { printf("kthread_create failed!\n"); } Once the interesting part is stripped away, the daemon itself is texbook: _udi_alloc_daemon(void *arg) { while (!kill_daemon_req) { /* do work */ } wakeup(&_udi_kill_daemon); kthread_exit(0); } And the code that does the teardown looks like: case MOD_UNLOAD: kill_daemon_req = TRUE; /* poke the daemon to awaken it's 'work' loop */ ... tsleep(&_udi_kill_daemon, PZERO, "udiallocdeath", 0); I can see the interlocks happening with the tsleep/wakeup, so I know we're not unloading prematurely. There aren't many users of the kthread facilities in the kernel and since they don't seem to be in modules, the teardown case might have been skipped. What am I missing? Thanx, RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 19:10:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from spammie.svbug.com (unknown [198.79.110.2]) by hub.freebsd.org (Postfix) with ESMTP id C046D37B402 for ; Sun, 7 Jan 2001 19:10:00 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id TAA05893; Sun, 7 Jan 2001 19:09:36 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200101080309.TAA05893@spammie.svbug.com> Date: Sun, 7 Jan 2001 19:09:35 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: [Question] CVS and CVS@freebsd To: wes@softweyr.com Cc: freebsd-hackers@freebsd.org In-Reply-To: <3A58DFAC.15021C06@softweyr.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 7 Jan, Wes Peters wrote: > opentrax@email.com wrote: >> >> ....[Trimmed]........ >> Can anyone give me suggestion on implementing this? >> Specifically I'd like to know about tools available, >> concepts that would aid developers and any suggestions >> out-of-scope that would aid developers. > > Bugzilla. The only thing not to like about it is the insanse insistence > on MySQL; it would be ever so much better with PostgreSQL (says Wes the > Berkeley license bigot). > After some thought I remembered that durning the Mozilla Developer Conference, many of the Mozilla people agree. They also thought that support for other DB system would be appropriate. However, it is also not on the top of their TODO list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 20:50: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B1E6E37B400 for ; Sun, 7 Jan 2001 20:49:44 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f084nes41261; Sun, 7 Jan 2001 21:49:40 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101080449.f084nes41261@harmony.village.org> To: Mohan Khurana Subject: Re: Xbox Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 07 Jan 2001 17:37:35 EST." References: Date: Sun, 07 Jan 2001 21:49:40 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Mohan Khurana writes: : Well, this is going to seem like a rather strange question. I understand : that Xbox is simply IA-32, however I have heard that the Xbox has a : special ROM that boots Windows CE, to ensure that people do not purchase : the Xbox for the sole reason of running FreeBSD or any other operating : system on it. Does anyone know enough about Xbox internals to verify that : FreeBSD will or will not be able to run on Xbox without any type of : hardware modification? I know that NetBSD/hpcmips uses Windows CE as a boot loader. It will be harder on the Xbox, since Windows CE 3.0 breaks many of the interfaces that pbsdboot.exe used. Don't know if that was on purpose, or if it was accidental to cleaning up the horrible protection mechanisms that were in place before. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 7 22:27:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id C1B9A37B6F7; Sun, 7 Jan 2001 22:19:38 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f086HHY22434; Mon, 8 Jan 2001 08:17:19 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200101080617.f086HHY22434@gratis.grondar.za> To: CldFsn@aol.com Cc: data@irev.net, stox@enteract.com, green@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, lan@irev.net Subject: Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jiha... References: In-Reply-To: ; from CldFsn@aol.com "Sun, 07 Jan 2001 15:45:40 EST." Date: Mon, 08 Jan 2001 08:17:44 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Could you people please take this flamewar off our lists? Thanks! M > > --part1_f8.65bd20b.278a2f74_boundary > Content-Type: text/plain; charset="US-ASCII" > Content-Transfer-Encoding: 7bit > > In a message dated 1/7/2001 11:27:46 AM Pacific Standard Time, data@irev.net > writes: > > > > [ The dict command is your friend ] > > > > > > 1. Exempt from subjection to the will of others; not under > > > restraint, control, or compulsion; able to follow one's > > > own impulses, desires, or inclinations; determining one's > > > own course of action; not dependent; at liberty. > > > > > > 2. Not under an arbitrary or despotic government; subject > > > only to fixed laws regularly and fairly administered, and > > > defended by them from encroachments upon natural or > > > acquired rights; enjoying political liberty. > > > > What do you think the average person would interpret "free software" as ? > > Software that's not opressed, or software that has no cost ? Give me a > > break. > > > > > > > We already have a term for software that just costs no money: > > "freeware". > > > > > This is _NOT_ free software. Shareware is not free software. GPLed , > > > > BSDed, > > > > > X11ed, public domain, APSLed (ad infinitum) code is free software, > the > > > > kind > > > > > that is not often written for Windows. > > > > > > I would agree with this statement fully in the case of BSD and X11. The > > > other cases do not fulfill the definition of "free." GPL is not free, > > > although it approaches it. GPL, APSL, etc. are subject to the will of th e > > > authors. > > > > > > > You're idioticly redefining the term "free" to be software with source > > code > > > > and restrictions, rather than no source code and no restrictions. You > > can't > > > > define the language. Free doesn't have a damned thing to do with your > > value > > > > judgements on what's useful, what's "no-value", whether or not it > > includes > > > > source, and whether or not it travels under the restrictions of your > > "free" > > > > licence. You're saying that the only "free" software is open-source > > > > software, and that's a pretty damned closed minded point of view. I'v e > > > > > > I'm afraid you are the victim of a "pretty damned closed minded point of > > > view." "Free" binaries are under the restraint, control, and compulsion > of > > > the author. the user is unable to determine the course of action. If I > > > cannot freely change the function of a program, it is not "free". If I > > > must perform other actions as a result of my modifications, it is not > > > "free." I am being compelled to perform. This is not "free." > > > > Oh, but other "free" (open source) software has no restraints, controls, o r > > compulsions right ? Then what's the point of having the licence ? > > > > If I may repeat what you just said again: > > > > > If I must perform other actions as a result of my modifications, it is > not > > > "free." I am being compelled to perform. This is not "free." > > a.. Redistributions of source code must retain the above copyright > notice, > > this list of conditions and the following disclaimer. > > > b.. Redistributions in binary form must reproduce the above copyright > > notice, this list of conditions and the following disclaimer in the > > documentation and/or other materials provided with the distribution. > > > > Those sure seem to be compulsions. They are small and simple, but they ar e > > compulsions. So even BSD licenced software is not truly "free software" b y > > your foolish definitions. > > > > X11 > > > > and this permission notice appear in all copies of > > the Software and that both the above copyright notice(s) and this > > permission notice appear in supporting documentation > > > > X11 has the same restrictions. Although including the licence in future > > copies is no big thing, it's still a restriction, and by your own words: > "If > > I must perform other actions as a result of my modifications, it is not > > 'free'". > > > > Now lets hear you rephrase your words to try to become less ambigous about > > the definition of "free" and how it interacts with the restrictions of the > > BSD and/or X11 licences. Maybe you can tell us how they are "more free". > > That's always fun, to listen to people rant about levels of "freeness". > > > > > I dunno who has it, but here's a cool little program called MultiRes... > it's like QuickRes, but it's for Windows 2000, and supports refresh rates and > shit. Oh, and Stox and Feldman need to, like, sit on a tack or something... > > --part1_f8.65bd20b.278a2f74_boundary > Content-Type: application/octet-stream; name="multires.exe" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="multires.exe" > > TVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAEAALoQAA4ftAnNIbgBTM0hkJBUaGlzIHByb2dyYW0gbXVzdCBiZSBydW4gdW5k > ZXIgV2luMzINCiQ3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQoAGV5CKgAA > AAAAAAAA4ACOgQsBAhkACgEAAHQAAAAAAAAB4AEAABAAAAAgAQAAAEAAABAAAAACAAABAAAA > AAAAAAQAAAAAAAAAACACAAAEAAAAAAAAAgAAAAAAEAAAQAAAAAAQAAAQAAAAAAAAEAAAAAAA > AAAAAAAAvO8BAIQBAAAAkAEAAFAAAAAAAAAAAAAAAAAAAAAAAABU7gEACAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAzgAQAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAABAAQ09ERQAAAAAAEAEAABAAAAB4AAAABAAAAAAAAAAAAAAAAAAA > QAAAwERBVEEAAAAAABAAAAAgAQAAAgAAAHwAAAAAAAAAAAAAAAAAAEAAAMBCU1MAAAAAAAAQ > AAAAMAEAAAAAAAB+AAAAAAAAAAAAAAAAAABAAADALmlkYXRhAAAAEAAAAEABAAAGAAAAfgAA > AAAAAAAAAAAAAAAAQAAAwC50bHMAAAAAABAAAABQAQAAAAAAAIQAAAAAAAAAAAAAAAAAAEAA > AMAucmRhdGEAAAAQAAAAYAEAAAIAAACEAAAAAAAAAAAAAAAAAABAAADALnJlbG9jAAAAIAAA > AHABAAAAAAAAhgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAAFAAAACQAQAAGAAAAIYAAAAA > AAAAAAAAAAAAAEAAAMAuZW50ZWNoAAAwAAAA4AEAACoAAACeAAAAAAAAAAAAAAAAAABAAADA > LmRhdGEAAAAAEAAAABACAAAAAAAAyAAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBD > uzKZEaqAK8e61r2SakmiTQEO8AiMOkIdJCApDRF1CdGHfUkOkIAiVIMOlA2T3QDWASOiVPTx > lCq1tzi3dSq3opXcqW1gLVkmgnQFCSApBHoIPSR9FYgIaAia1qB6QbvKhb+HK3M3mV5zOfgP > PykLd8yBecu9Qbd7gVrdRHawWu7qRGkB65AbTILa5IW1yRW3NAtcgXbckFrgDeXIG925Jbeb > yA2uRrvfMBu+XLzfLzn///7fP778++e+eeffPvzz33Pf3+d/iYktAlrslo34L5WaeVL/LvXz > M8H9De8op67KmaN59+PzMJNCJ9YGv2tmZpqEoZxKVG0WQTMorWG0b6zTcJWhKnrlnZkAM2rs > wVCqmi5Ly9haGisb/aoRGIAq1h9ezTQKxH02AKi0IJwcAGLDFOtAkO3GUXLItWO0xX+cVD/g > FY7J7CLS4bKs7Na7II0L9rtPr08K8Hya7ZGi1WETfWdQCwcIZlVWYRntNiW7FYkW0T5mEpKu > XTPn6LAiE15VPr9kZrP2zTbVi05dZrHYTNnEYIqdis8UWaas4m1Zmtv2B5rq1RSOPf11KrFX > 9dZWbfRG2FSV86jtf9CSx7+hlm9fmTcMR2g0RbWwgOEDKY6kOojzkdQHVhyo5QcmOGOEO/F8 > qcHxo76Pih3sfoR8OPzg70Pgx2DvxLvxS49PHpo7v8Xlx3Ue+DuA/KDt4/wP52OtcrTaXA5r > eAjNOZ11JCCsoT2ktBGFjq2OxlIWHDe66bu9LhjFICzLNyw8gciTg2rriGCfCzkVJqBrI2Iz > igJICos3huuwqHC4ZuJ0DFgekTbyebHDvFgm4pgmCtBwIUBNRYc2SDKh18k3ENBjCKcPpEWB > URofq2DqQHAT8CBItwyr8LlyHt3JMZQtNzKgA2iyWJBQlhgXChA8NN0XSSLRZyMzL6X7JAnh > bJGb4DmgOiDpp65OBkNYcId7BpZaU1ZNXw89AyQKVENLPtrs4MASqUOz2Ss0UnmLbvaCGZ5p > fkMzBCoika4AoEZXe/EMWAmAtYZLAAOEoVFsCZSFRoKDUJB4ggpRTVcgK0qaJs0VXcVjKAwc > O+pQQxRuIDE9Q62IBXGWvxaPibc2B9a8mEEVCt6VyubUONbmdOwY19HmkDCtAdlIM4SlB1ak > Exo+cFLNh0TdQYJvp8ed8A01Qu1SEoBIwgoEMxmpLwDVkGFjzT26LgemHZQ+7kz52rOkVTM/ > 8HWw8r2roomiwXg/GfEe+3ufRaophiqCm6LqmTO/JWOmj8oamSdBUDKAnsS0apgaCZbJ22oA > cyS4ULZ9W3dywkOLRD1BHz+9tBED337a1pV61iTHRInMQIgF134AOeNeSiamffAXYrKw8ilW > zphJtnYFYRNQBVs8CfEFZwzV8K6masaOB3B0rX0QT6dOkoPa3I6nxpLEID1lY7raJBBNVvsR > PWZYKZ4YtPBvaELgUJZIsNbCIOdLNKFbZC6CC2Stk+jpRU8q5KtscbM8L37EQ0Gbs15PUbco > avhTTqyKVp1mFHUYyPKJ7/qBKWpgGJfXgjYwpAF9VYJW/sD02AFFTaCQM1LdRGuerixVFnCL > +EH42XxF/61w1sxJ0L+8qRm5z4dUz9a3Q7vMWT0gThpeV+KYsFuAKXGjAwAMJIo6KvLJEmTR > DAF/XHcEdbvGWpiP850y7fhlywfcjugOXhFfT29Ej1PU4cONhHWgwJKCThFPXWtcZfuEvCSx > UizAyIH3U8KkdMQRILNBMz1X/PW4uVP9lw8ZE2x9wGEVWMpF3I06KB7iLCkasIRYz9KNsfL8 > IjQCL39/8QHk8dQdG75Bc+JNwJ95ADnpEmlwFU9ssaPx0l2jMALMTLdUZp0dLpgIxrCQ//G0 > JmqaitRIKAXjqPzP7tQrlkrvGGr4oeYZUalBkEeO2+21Z7E5SlqZJ9a+jzqW55oroMCDmlXB > RJ2NJ+yc3x1HUdgryBNmGEn/2OEM+FtIyosYHBRU9mfE4UNVp3XcfFpydnSotDTn1kGKWHms > s+AnRcKxHaVYhaAzqOhrhSITUtUpWg1EFM+heIPeeUyR6Ij84t2WZzif+UUXFibJcLUCRJKS > 3ktZgTbPBYdhapwONLrRCSchnFN9eQXZJQWHNnPuaRNj5BYcGWuVyxClWfmYtnU6J4s8bfEn > 2s9CG6Liu4Cv6oZjQxB3WJ9ywGlZqlPgTvLeLuV36grvp05KIcA/6jTz3VNPPYaOK2Ev9CFj > 0fjdQuyx0jbiTjY3KKL4AOzJl8sV1SAvkmr4TZ+Tnfi8Pf9jj/FKMNXa/rloskM+nCS9ji0X > M67LKMBNryEms7jRdjXiri+EfDURt9YueNGnsIgT3PNAQY38nAkab/p3YE2t2qvKgqRMs42t > KJVIpBM3BNGvI6BGXvzj3HvdqLCO6BfjT4G2qJA1kSrSnuhJKhW1AeHtJyRQJFBBg2kohNrd > iOfApMVNQU6kPyxF1O5rpQ4i+Ifjp245xITYLw5K3MwoxqHko0pxq/EZEhcJF6tKaF3bEyAg > k5GlLJygJd4rPvoH9ryGbBPPkAb/zbXidMZVRZdViZ49yycjsdsUd4xxAgIpRKCgLWTVXMta > ifbAkn4r3JpgRLngG/QK0B6WDoCXvQtMlNoMTwkcJPSCe8ImZqDGAc+5QC+T0ANbrkwOn50X > Um/+0RPTTz1JEMF9kmlFebSm7qrxGa3EMBxVyaE1W+mjhS3zSTsKqxol7AucETCGT4SYSMxb > V8PsWCjKbZ021J9WBzKrzUTzeT0RfXd0Pe0XtyaExtUIoDvI3sLNoauv7m4h5+c1SWL2PT58 > VokheSczT2UFtRNryetQEV+acel8o+Au3bGo6sr83Frx4WuhizwanI9JcgeaykqsoY1G0VU8 > 80zL0RRvpTaDFOLuz9ws9zZ9WQ9ENGlqz650uBf5mUt5T7f1KPjKt3z2NOpEE2tUSYjd82+W > J66dhDm3tI9EzShYgfW2nqfG8aB+kWSZScjJn7dAIme1bViAlFnpoTI9jl1RKIb0GgRLsOMJ > CKZQs5tGxjCqUC7MyksTM09h3vWKerzmrSHn5qBAIR04sbXlCV/74L/Cp8G2rkXfgknZyERN > BfIPdJl+aUyMgI2H62es0Q8u21oOQSb6lfVafeikXxxeyK1rOK2zfzqGCscDjWx5Mk/PovSg > cvzAUB95aO//Ds+wZe+H9jYU/2Vy1w9P9ro1w4DWANdDz6uJwE4FqCDT8QMWfjb75YZMtYu3 > lOR28a/q2d2NO07CUefEm/J6KZlC3GKmamrfHxSZIzsv+vBeOxIUzVpua83P84AGunDhXrvM > aqRmeuNEdkByVXNH9yQywRLmuE2BDGmgMWWn5lIAjOkrWUcj7wLpGQr/5F9G09fWfkAJmaon > zVL0+aZp2358SalMwljHVlnYN02QQ3Y9QoCho2lGsS/GskUt6RyZSNXteSjhyfdeF2tYtjhv > 5I04EnE4R+/IITfwX4DiSN6emoBlnczO+3xlMf1g6K0+xxsqPGMbMdn45nsmeWtetrvJY0FK > FMnAdflVAzYrIoAYif2sYv77Ogx6e+dM+onwXhpFp7IY7jUlT5d5qlMiUIfNKPJKT3KYLSdr > jUqQOYZOChi/KXyr7pAdAIdjwmXr+sfo8Uw+OI0v9drfeHz/LTf8PcTPukPebUSX2aSgG1ln > 6egSBtXPbpAUBjI/mCfY42RMp+jKl9zzgeOzLZl43sM1I2aokapJDhAReBJt8Bgnsi6Tx7kS > k+F3gUzLSV9ciyFfp7IlKvNraj0SbKmqbAcLLUdKM0ZUnursavU16vzJwi4JGwQetcvJTvul > GVxzkREUfyPjIh/jeSa/7uaJkBlQDoatwcj/bSR0mDSZTt8NNYwQlzf4TTBAc9eT3eGD7+FH > VUCA99qIX/gKjTmlGujfjWTR9/Kv4Hs10wYLfKdF4ed9JOgHotk0/gTWg2EVealKnLeH0Zps > pZSokZ1gsgkeYn9PbaoQC+iO2FUygMe+JPHKEkT8cSIy3+xipBFHVLSb5KNM8BzpLntEEl/B > SSEfx/PuH7rpBW6bS1Prjb9sxYWhG0se06zvlZ077vmiE50NfPxKmfigb7uUKQs6LwVB1g8m > vopmS6sVA2e8eZFr8/p86rG+nKUWWWM7r5aU4RoTiUrPXN6qLS0Go3hmaglBPDTTo2E5gQt5 > zVpxKlqeqklAfGpH5hM3TKI1nL1hT2YHuMnZBEvTZfEm8zWLsGnWpZT+wSXmu2L9Bz+uU22u > GcDQYBwOa04uSmj+kC19+G3fWN2BT8ycjyb3Ln381kLPtvIwulxpTQDqDCdxGPm8jB7Vyxbf > 5kSwtBgPuUypMOzYNSkdmDCBuQDJ83Q3duyRPKGT5EcBNsdhKVJX6cmBXVCZQ/XNFk6F7cYU > rn3/vG+tTRIVPO+lb8XpD0mujWHuIJkHF1xGSTKdeGC6NS1QoU7+myOSpBAag9gGOXpAV/5d > 1dsJgXXmMBhnq/YXm+c53nufw/QRgRhiYdDhpvf0XGVki8FdwymmEY0IXXu1ejpmu+Y3qzp2 > Qb3LDCUdYcLoj9ltguYam5rqmQp3YSITbclMnIp5hnDgiPOZesHlXPpG0/2LxApl229oSPbl > novXandaAFFNKSmR7Vfq1WxXMXCCuqzj7jNRKS45AjbqLjONFcTXQEsZxlg3s22iJz82tKe/ > aBzPq/pQ059fdIYn6GPT9BHT70MQXLoSRlgdPUrZ1TUWoBlNauAIQIkGjZEbo1jHDbrT4Pna > 4MkXMOlr/9uQk6nLhCE/pwYf7bhJFcwYMAjtKAjRtKEh9e5HtWXaGesQYz5Gh6y7VjylKq9G > hKzJWLd5xJFGKZnLM/QBq3v0UEkvjDeYQpCiHm2TyCxun4HqU5DWvP+KXRVDmTkBe1OqfM6R > Fg6vHLWBNdtWCLgc8oNPtN+REdpd3fUOSu+E9sRolUxnxEyQDa+WMYZRU+IZIGb3n8B3B1bF > dLnzArq44crY4EFeI7Ml4zj4Hjv/HWCUhaQPmEfowq7gr4bluX64pdJ8vtWSUhDnwQoFo4i9 > mqqJUDymej+1KahlaDku20VZOW2hNobUQcCD1oihYZ6PJ8wIVRKaStcV8cLStOkvjB496uD7 > XVTnhunyd9hoG5Xlo+Qn9yQnQIk2G1kkUVLR0tibA0zPJFtd2o2mRH3Zxw4f1u8yNx5vDYni > MLRyqlteCBGNRfOEBauhV3a6Jy3rEjV2lfDJbyIogL6Aky1SfjJWpXSnk6VT0xq6TnzIdRM4 > tcub1LT0XxRutmIEe0dXNghXQVyZOPAwPau4MMrWlRxnH1zVnxXewbNdC5lWBWncFsxUjlJU > OvP0E89NmOMjQb7tECO9RDDdyhcTlQXhNPAs5Jn+RtZRCUItjpsTCvzjslAJ8iQOsL8bjBfB > /eoqujUVAEsu8ViMQlUz6qSN8cGrfCg4DDyUnmSfySewmnQjY8X/MImVwFdxSNq6JFtkIOCo > 6gr29P2mNpPAaorBm9XKsYJ3Y0vDCTixylGODQVMRS5ULZ2EySWkwtdO9BXQEzthfdafK7sr > nbpOwWrnGzHCTaHneDTmRulWSabhc7pxDAVcz1PfD50acoZGG+CFdK8nJNKUUxqxPPmenqMM > C+R9Md0LgVfDIpaN01iA9YWrRHOs+Ic8h7GaNnP3NKGTIWpPk/IkGpCoutEF6PqGoNScrOZI > xpVXM4vRi55lGnmZz8Ge9Sjumf0llIO8TJiYWM6Yxqu8yrrFbECdizoWyE3RbDeJhUYq2UsQ > qZXa4yyOzglHZX6jIslJGkncals0+j8hU6xHIxJqWgkdeQthWyhf8TPgcj0ychS/kD3Z4ISb > mDDFWLKRhgwY+2M2yG0GIH3eAgM99aSUYY4rlDPR6rZDmdAWyDUsvghTNRjJRP5VwW1sYkac > Ugg46lDKOzFdXh3YdHx4y1c2I17dVM2LtSecsym7t2emv2LcFlofYsbakBjy4e2GIntl4li/ > puAhkAYnIGBQEpMvISdS7eymyc7yn3IEMZ15bHCDGs/KEHGvUpRCFcolMOZQ0wBkZHIlIusQ > J4xxfMMtEsuxR9Ro8U1ilQnIQ7tKCbNtHW7XMYvFZsBaSYLAG6b0GZhqNG0jS5UUJ4nYX30a > fc9DMzFu3y5bJvkg1byGyjl2/Z/j7JQk/BUkTqgHy9H/VbNlJxtSUhyIq8bRAO5nZC5X6ZnD > pGyExnNBWYJG9p1uTKsCjclVqzv+QGI4akncErvKu7Db19RNWP8HLzPQ6rbVS0akD9qpONit > eQjp0rS5dQGJI2qKlYgM0U26rwWzJTLWKzW60xyBtKmD+dprE+SBzyTSs6HuTRX+4D8TtMF+ > 2LqBQ1vgfV+QuEmSAk/LxRp4EruEvZ2KUVrgJoLM/tYxFtJwv+7GUFiU6Me2MAJslfQT2sat > xBtXeQVT0tpxsKFhE68ORSOdSnq7NQfqb4FZQsRWuERPcLjRhK8teyzfNhK3R0g+gVH4KQKr > TAJVht8SP5Dp3eTT2Rte7CKwzEtcP2mTOF1H4X4lIQrNevqY1Oo/V540lDS0JQhqM3Oo1Fbn > YahN3MDUBuwI0+hFO27CDTduwA00bnoZObubGTG7CjJLdfhiMDUE7ql2LWTM/Cr7kH5k8Rmz > ePDkH8gy5ykj7fh7WW1vyxqAFyciT3zI9FE71wr15XsVzkhSI9eZIeTIL/B+40xGqA2/C6bb > CofcPR4g3dpJCL2NsQEyNeik4+e36WgrOTFSLn6Sio3F81hlWXUyTAFDXClLNZA6ITWSBnqg > TFmPIdUk9tBcnh6H9QVtvi7OqiflX1Vv00G34NH5+klZad1iSUdvTG/EbZROnSis5wspfb9e > 2pblPpxhijHd+4MxGoojM94OLWk+tdJkrRHQJGg1ydjNEsQJtRtVQHwMiG+7Us/O6hYPNm04 > RA+403/YTCyM8V2MAnToFrW+pHKi0zIWBDJNtqBzZ4E3spULzQJroYJQFjRsOrGcNszVDVus > Mi3cZ2YYgVCWzPdJJAskHMB/HzeSbAxLRdwWmzNdJu3Vos/UuJNcO3fn6BKuCiYNOCXtRpgY > myimH50LnNcouYZUKU63Z0bVBi4EU54R2QFdJIlJYrkK+6hMV6jSGfRb0ZUxC4i9RI9pD0no > tjCUyofN87RZu6MVOTBJxTqkQEmeakRE08SESDTkGM91DrhXhlVHh87gNqFxhhFwiu4YvkDJ > HHvDIQcWSwdlY35JHB+N9ZvMseyfcnOUq/69gN/fgVp+IZFZwEUiVrGUJd9BVkFmqCajHT0f > RICQuQirRJrDEkuR8sVErxYmInRWZib+6Ru2Kj/MeidYIXAGALj8SX/JJukaBegVN++2EyPe > lJMfzyyIFKHESO1c5Eo72Yt+fM6wLEz1gsxGEVVdwBVOGKyyuklt+qRnF93yFTmBd4lQFxcs > 80f2IYDu7VMy+MrJF2osVLKsp5kbVPhjuH14l+kw1l3T7ldesj0LPFiWYC+/Arb8qO9tIkHJ > il9hCUICcCfrOFMslSmMmVYPYpTOdTNOZM06E6kZxAyTBoZ4NlNYgkJQO06mnls9OKb1ZmnQ > KVa8TsY+E19BmzRXQyDgNuvejGUYpubZsy6IyuiAo4vhVxGKwgInrB+aEpgzpyoI5aBPnoib > CbzNLkdXXoyrrKUSgsYpvzI+Y9NNQMCO8gaBPNBATWuiu5tjiB0cDI/So20KpNM8Webt8/VM > E2OzTOlnC3GZkNlsif6Shmau8jdELhRhs9dbW12SnJvzDaQW2qYWvolYFSfqs00VZwFvoTYd > uFAVOpWcDcCKE1TIEMW2h07v/R/liflTI61F1TkWSX0XK/khgVd+raOBqVunl0SV9UeLgoI7 > 8qLf8/3jGe6hyEKRZmKZVdwGJyK+yinFR3/Xyr66SudiHsACURndTVuOEDM9NPZM05JZgXDz > FVpsEySNSKSFtT85hqwQ1EFd/Lku5SKXkY1Os9S0kRep/FWeV3ZjulSIfHbRExMA0piSCXq9 > NyENF1oQSMKq9x6eGzxoPK7zdEm6Vog1HEwSdZqUEVT0yEph5OEqjcR+N+jzDWQIRSrild6w > ZgFv0DsZ/eUGNGyspO1FCRYxgytWReZQQlXqQRBVKRFZrFITNixKFn70tfGUPpmFxcsJOfD7 > tzj7AlvnaV+4N6Vwk5sVJ1IOblplmH2uffXsMqBIexCNC2tmBE/0VcUMMdbzyQquf5eVksIN > /ydvJPaEAcwsPPaJ/PWQJOkkUVyJx/6BW/cg8xxleix3BgJbbOIoX6ei1KqetAvdyvhPv9Ot > aihVZ4F/VqFa0DsymEY75e6njH0VBtTltUGonx60x/2hp6azBn0vWa39OW6alSXZuT/SLK3F > fmSu82MBXHuW5E7Mzs1kSdrmzXkQiGc5rY9ku0aq+R0rO+zb9dPG5VfrPYzVNQ9PDDFY2umw > 4iE+ygxPRFq/TKyITpxNomcotxOYpKKwQQUPFDcOVOPGZ1L+xS/yyjNMIhuFRDferYj++nkt > wT2ysHeu/xW6VqXbO4yEdjRJLHy0OC8+w4x47Vuq02oBoss2ywUtXDpQ9u2bCQTCsUlmpwVc > JwI/Hig05+qOx/V8SNUA6Kvm9vCaKVt4ISkV7coVD0hKx7HYkIhnxvTCNIf2sprlD8ev20kw > phHH+hcsUxooYqxgIgwtjLPUvdeD8ym0RHk0SioeWoxOuWM1kif0nP1TK+JNGO9jdsd74azl > m2svsNwL/l7iiT6YcWj05/fdQL1sriOlFHmDmXTMp1FEhSxfW+hK9EwolHejUadALtf8HqHU > oiOgI+7yNRM/s3DJb01iisVANTPC4e9Qt/bCRU/GiJPBCkpiDmvRnyJ5EGu929WiM2zd+33y > mrHy5M67oQ7HilQdjpjy3F55OiRnhbouP1YBQqK9fKMTbArEdtRPLqB1WmI2RX9oFCw4blrx > HowWwgQw2PNwnaw7I6Zh3JGbCxd0GMygZ6ufUEbHnZYn27CaoThYXsBkh3iq0B9RmK+U6+Vk > p9R/fwyCJrAIpZmkPiSCjBN+22NeyMEXol2F0X1Fvi6xqHoEXvZB/0HGT883DKdteIPQSpp5 > Z/UufhA1XBg3A2fIH0eU1QSw2WROW1fYJED4iV3o4dQgMfFSWu4B3nCS1ycWfO1YOy5ru0p5 > KFi6FHY/R2vsLQRWHCTGhjQYbKe+7vwMHEa70bbw9Uy8HIT1cRlYEUwH4eZjoFUauUSdB52I > SLjdRLbaquWkGCb9nTExyyvjUCMI1QMWvyMciDsuOGhx6qYAfqNhC2oy1b2cdxPH+OAKwtIm > UqM8jhW4lxNwt1f5BPHFN9kjnL59AeQowzbc9OoKwKEfWJ+SzgUnqjI/N18rB85ocbSy6ieU > syptpdg2NinnweBlKXuZMvcnYSZ/1AlZPmDL2wXOibmc1ryOn8MkzphRlzKpxtAtRjj2/ftm > lLTNwu3w6lAWR0UkYu03pfo1ONZEjbZ1o7poDZ1jU4LIylJw3o3dapqPbEfe7FKFk4cWpK3q > QvlSnjlsDqHqG1T+BcJacyabKtm45wu+uEIPEKLDz+E+Ou8Pxpaoncv/Jd4kvJqalmt6TPWK > qx/UtTkrXOa1PS7xfJq2fV37TKPw0zL7kovEJ904S8bxBsMbi9hmemirK8SozNkcHSob2dQz > XZnY2QCGUG8OlIBe89YwNW7Di6SE36obYxyjhQwf9TrMIlheIDuF+Zc9kuR+mKWhri0SuxTm > kaENRjj3qeOBcC0VkwnTCmbJ6Tf6OGfdpXpVZXpSxS6Zu2701ZW6guLq8vzCEwo4BGGRvq6x > U887qkf1mT3T7KBtWo8S3P6YeJHtQ6BzF3sM7Wpzsg7ICNlx2+xxqzyCvU3uQdDcre+RzbyV > 7vL+3eollrtwetAKQC3KBK3epVFVMFCzxcZuQgVVvxhhBfsZxnka1iuMg3NkGApt8ELUcXMq > DDsoBOqSEyMtc7xYnJI+TwM818t0VcwiTe6bG4jWQL3DdDT4XRavRfQxQ4fv/MldMzKG/mZU > yrrvmyp0Hm1iWXp87SmNYw10narf7gmmGLcpH8JSdjuwX+u9l73btYOkfrWQZVo4X2nZ9Lrz > LMBO3pZJgULnMzpcobPeIrQ2U9iPENmnihn2i3Y9/eBeGhtnFMTawne94DB3oh4DmWLmGCjZ > z6wgyJp2l2Y4vkMe8VGDmVVeAObD3JVyUZnCWDe9RbLBs0sAi8tBKEk7G24ntbaT9tUOEw1G > rLAtlwuednF7SBFPW5QhTslcKhlQ4RhtR5eUFx/N4967tVvqGk0bIP+HgN8g/uuW+Obw1H3j > RIbwvTmwv6Go7cf6g3kfiiJcd1SMtkSY5fiSg5g2njqeNmmVauH9tN8qpcpys6ytEs3TqOVy > BH2illC/JLl73XKFeNwb2k9N/IfovSXL2dF+O1Y1S6P4NHf+KV/e2DEqz+HyztPPZUt/vtI5 > T3Pv93+MXtlOsybz1OPvYoe6ul03g/668X0a3e+jI2r2E45KhYR6XcvdrxaKVbvY8EwHvgVt > M3mbs/vameu/TcvgJ45YKrF+KuSgXsLDXLkxF3XjZ1dr1xtp42sl6cnqWNod1v+AZC9yS+GO > W5Z3lrrxfok29bthEq63ewF+fq2/B8w7Yt29cX4egNa8XabS/Mxf+X4NqVfee+vvt7IX5n3W > BO1Gf25F0vxahxF9m/H3nqFpbw/BvjU7b1e+F94t8dOOjuKrd5v8KaVCzVmhrLbj7Vh2moKz > tT8Sd4diunSVD2XPZD2+SGuHHMK5wdJstenT9Qnnk1y2Ynl8WqUm5NdCXXlMu2GCofGe4uy7 > OOOOcgVxN9vmRXa5xLc+JXE3TF2JeweMx43QVL2HtMCveu9z7RK5x63hvWV909mne65Dip1i > eLX5wUMtfsTNsdmCq9D7vhVktTG/kemY+ir61fa+WB/LwjL7p9u6k4VjjeD3ewgZQPVBr4uQ > w2/HMZQ+W9y61/nWq0cR7VSuhFi3y+UEy+1zmbR66Z0zkL9wEpG3+b0J2u5bbqvccOR4vBwU > sbIE/LVPK0Q9r/6Tet2Dy+e1GPuaQsQQRgWl5WmHyVjdEjnIg/XQXij8ncS0687UXuiRVIQt > 1Gk9bmF+eII3RBPzQAclM2r/l9R2g2f+I3zP/TWIffB68OyD1gcwO9D4Md3H5cd1Hvg7gPyg > 7eP8AduHvA/vB+MH4ofiR/bD8MPdh+DHuY9yHah2ke3DiD4od7H6EfD+AKoD/F4Ye5j3IdqH > aR7cOIPah7OOzj2IffB68OyD1gcwPVB2AddHLj08emj0sdWHow9EHUx1IdRHnI6gOVHKDkxw > xwh377jo58XG5RP5L/heXHEFU1ylE19xu0sIWuQgV8n2AofKn1A/OT6ifUj6mx7G4WWWPumB > V2vuSkFdu4ZA9FGgkQv6KDPIyLUBbCsb0XC+VpihMU/i4t/+04MnaFCGwxP/xyxLXrdvrNah > LJabQF8q12iZd+7rbnXjzT2AovVcyJV7HVWb19pte/tuZ+VfB6LiveG1Olk1eqNoiEL1rteZ > 0lxKDBpXZiyWf0YI0t8i1Yf+8VmNJi8u2S2VDf2VmREu2Yvw0Bx9oJisNo35mgOmDzDinxKv > bGa12Oz2m2+M6NOaj90N4tRqrYRGfUC5hjJEi7tWYpFjWyw2eyWKr2rMM9tAcfdDR0GNlIiM > 2kuJ6gOPvRvug8w2c1LxXhVm0WLRj8ZoKpeM2En9aYtNktAjN99kridJU3W9auWFoEzDsPmH > TJeXLTaI0Z5nfSU6n8hpVeW9933+E/daslps9h123qXHWep+Y9WMWuPp2dm35mzDLxpHCTl5 > jEsO+2b71vSMM+wDkuOJCWu02dc8Zo5WqnjPpVqw2uyWH0PQRCVT0GqKaLy9bkYraLDZ/QJb > dpbMr/yJBvkJ0v2ep9hq8+mHYemQYgbt0Qw9g/1XKY9t4ZL9VEKW8wSxPwrisvFsIivCy7Yz > 3QlFum9ndye0TzX2Ft3J790uKBHT+Z+P1ClTckI9J/wjfX8IqO9dRY2+ev/oV3u6AfzfZlPb > X5dAX/b4xYwJRjM79TP3Jzelh7uhMfUCCjf0F+y+RCXk1+h8KWFMYy/iI0DpdwqQ6frxtyey > J24ZSLYxpSmppn51StmNg23pgL76W9pxVkH3c+ch4wCrf1sGC7i+PU/TNTbis6yhbmhtzzT+ > K9rle36qxzfpF0LcERbRyvkyz+0GxZpuffsbF9/7CN8LOYsP1ve50LXtGVN3LoCw7N7Ud0/P > EU+VzzcIffr4kwyuwYPuZ7lyKIzLIEvWcafv3Mk+nG92O7+peSNazjdvTnzSHYZP2dG/90m/ > rXtZSVl3OZL7nFxy4A2zg1KIAaxJLM+3an/7uaBLbS+8FFR/u8j6oFcu4aprtp8pSYfKU7L4 > TNb22J+opZ8ylS8xY48CBWWNo9vbp/TICu3dLC87S5gW2sGc3fvPiljDC184LVX7WKm0/Xoq > vlvLM9zCJU2zDXArdF2fHaNSBCdGKCB0agGRphdKMIQZBUjk9LC4tq8cMAv9R28Q4fpD5l6y > cBL7KwMH4ygfnjxcVpSw3/vw/b/r05+De8HPimUp3e66ittrGQvR3wQ/lc0xPN0Qf5KtMWeb > 8nBao6i4T1m9uamKO35Zx+4D4VdwxtuJLnj96lIOnzsIurQM105I11BJCGhfcyjRtX1ph7+i > tMUVSJhnJBbVL+Lj0VNLDC6N2Fym4aDru92D/QxX4lKeFV6l4C/lBVb1Kpx7x1dXubvF47cm > MVw4XftGZEOY8BDx+522c7jWWQ5bkET+O++gtDLyIkv6ZeMzhgAYKB95782uOnoGFkTHJT+4 > JHJz/Ti3wF/0JuYajnORh1I+ppMiiKTb7HiouhYdteiw+UTuzfZKgyXP1SaL3ms8/Hcf5hab > 49hG38ASqpXcYoK8wLY51/GyTnTpjdiZeGo5QYM46YySKcVdzm9wq6Fn1i8o9tu95MWvvtzX > uoQCjmUjrObvCLtqqASA04ymI5WEjreBufgyFDjLxDhTSD0JvgdrGZ6EUzh2Fig+9HmUCF1S > /tBFXwzVb+oo6GVS/NAZB4V3nGcZwV/+dNyljOOzw7OGrfjZdu7FuCL/4QXLaItcAii+JPIw > ZEHOUUSgZqrWunnlm27vZsMmNT2rJ/wnAgbiwiV4G6GY8NfNzvOcLLxO2zQ7A0p9bU0mw0FU > TYkWRDTzl4NqfP3Nx9ZAlCCG6+eMP5ko20vngJKKEu+RT9v0TEXCozHmk9P3U/Qqwe5OCiZ9 > 70C+Rnlz9Az+/3H5j1swSaq4dUeI8pL2VyC6JM81rIk+PMhnEXorJ6ycJbhv6dj3rYpFcCbq > Ot1a5pJvb11bTLqr+lXhqyNOtZKBkqFs33GwHSttVdVTqUWuh/hBfayBtUv1sTCDw3K2iqpG > cibRbYzIu3ZdnVPbPYI8mYciQtieK5auVbY0uZxo0/V3btTrh8VzvCf8J1GmnYtgyiXjhOd3 > ATxaq9DbdwWDAna/RsojUVZwhNide4VcXIKnU2CGIweKH3Re6Hcmq+G++JNYXAuSIDEeSCh5 > vMaC3oTebyQgVeEpt5Inl8SaXkkeqwibmtVRAwGTPXkNvmh+MhWXK2UH9pE8/jM8T/hTbif9 > qQwRQb2SPTAE5pbEhvT84MZhGSN4uLQrJMXf6vFMcW0y3m/VdbL339WEW1An8Pxr5kwgK8TM > epYW9ycZQb2q3IvJI9or/Q6/qPmBVSfs+CeNm+89ZPJNd8D/hz6YNXz//EmcAAIh3dlNoiqg > pJQqSqsipV4V1XhXp06apGlPC66MV1Cbm22Zbx2wOd62OuSjrQsW03zjMzNbc5jOWzm2NtmV > IS1LqLdHg9bFwy02Mb0VFTma3e434Y8fW6vvf8D+jh2+Dqr13DemG23aR1gZpJuEGEmBmSZi > s2EbgNuIGBbgejBzc4rHOB02W43Ow2523jz6/fz99/Pft79+/v358e+zv///8VG7RU669/n+ > AeZtxVLT5tp+m5pdpHS9EUYDaABdnh9rwl5v+Si6/x+fgy0UXeJ65hWP9QGdxcNLehwvmd+6 > aSbUzSw8uruAmlnczTPGxXjQrLMjJ8BxWLzNQRbxQSybWDFPFYc+grQBsoBvei6++M5XBqCT > z1y1yXyatOlGEDvUc+ZuknDhrAQ8M0IOdCLnMVqBE1u4us0oo2pgKurVb/GzNt3GCzQuEeX7 > yLnhzvSJAx2vJ8Fra8Lm2IJuoRkvSHrCS9aSjeYwS+L2s49KAbrKAIZzWDt4nwrx0a2kNr4r > WwLFeUtV3c3+wfQ4XX7i/2FHEuGic79nJVqy8pqQCeOouT87MLaANYlezI2+5Qgis2OFk1fY > EDPm7tqL9KgJb+pKwmYd2DZ8K0L/Wgve63cZxnFGLwraPB+fCBykiYD77f+CiF78MrJGCMhf > FvgzZg/KWV3Jg2gL+J96RCu1ZLwmmBKOVH4XxKcWM5lTBtIXT3CllY+WLVIJTysgLFqnlN4W > 3B5h10PjCtrBVnpM2UE4xgCwlnxh20NWxgsIUO0SPtxJtTLW8l3mxfqz8hnFBDuHtv+caSy+ > Eg0sTkwOM68yD6WPI242BJRn+UdAT9yStyVFTqUelf7h6VIh5fdWNG+iSU+/RZSLYlyYWN/m > JjecgHy6aI00+3jgEqM57a1/pURIjPPEO1b+IlFbTr5YLgK1eKrKOg0fDgjaLrvjSfAVYBVJ > 2XFi1UL94Fr1Y1Q59CuVZoe/3zWyorGwaV7oD3HfSU22vU8p8hombyFMxnM7xDjQWbW6Lhzo > CFCNaXoyZ8XM6vlMHaANXaUg1J+NFOnt2zPwOBC2/Nu6xlKSAbCxF4vDN68A60qSE5l110pv > 4oByt0tBpfUmmdc63WkGnOdPKrvDdniHaSX915kNZe/p34xYt++jAm0P0mTK+ZOzzaCwqa1L > xtmTD/MnvZie663I/TyH2qU6Q7Keb/wOtGf9pI6v5Hta6DVegnZCoiy7+4eke2x+K/ISfTAb > mzeDUVad/1257dHtWug+ArJpQA/Q6sbak7nbg9yhLs2dtiHVtIPc7VC4ssvf/g0+nZVsht7I > /8F6Qia6OGa6FBfy42k1q0l/LV5OqMga5s3ysbztMHxQmfBvZRT3nac8CIAfEUH04L9KY0gx > DJb9Nju+k3oAysUluGYXNJlcLLQz3zCqlhWL0uk0eAH2PeRB28rVwjanFiceps3zrAJx1dG8 > yy4vQsxGmZCuZPIBcLMxiPb9OK/IjPL/jxpvrgjt6Q3ywpMSaQFSYT3ROYOEob4/etkJ7k37 > cV2gntdTOGKpjeonJQ6KHZQcUixQ8KHpSMFIyU2NiXsybTQZ6HGGPxyd7QhFawZClIaBWaC1 > MnAOArFiG1jWq78tauA5THPs4ABFiKdks3FgJPzRWomqrVEQBhI75j4+GeADcxxzui0SOCoZ > 6tojSxolxOV19TBo6aIcky+azxbVmx2W15phEagG9Y+F3xlB3os9324U4MbayjOMXXZRoF7U > m8SZ4VMt8Aewacub4Aq0a7TZ+cveTFXiZDF829YWHJDB1jhcU9e8I142CrshyNzOogTxCvwM > AzPdl+FZPGn5cPGHAseEA9A0X4gc2Zy07QZWNQaUCb6yL3QMqJFooy/xtFgF5gsG2Je0oEpW > OEhMef7g7/nKuUtjcymqLNZdNYI5cY9pcGRG1fjehy8YS2UVEPdYYurHK+b+RlauUjQFt5KM > vn24PTqx+bqZxoKx7sFsaQMFVm0+q99pHqtFYfSJ+u1ZCofAoXoIzXanE9tXSVuPuWnh+sXk > 2EdY2hRY+rd7lZmaub1UY3IHxI5wRq8ZNJIek2TyN5lrxKa6kBJ/8FUFSi7CSONIVrEsK3Qj > BL6SOomj2Sowwy6aNEmskrmh7RtqWuj+XRY6eV+jR4xNRWN3MOhUzQFjUbxaC6u1RJx7yTc3 > h7UJs1RtrZ9a2NcZ8IqXyGAB2YZs67DyyCHUmYdYBVIe1JnSHfK5t3X2K+rmWBb2WrSGESr7 > capm5j6miLk8tx9W0ho3moxeKFyWQnFzKlY6qcjvFpJnUXaBDhcr1R4hGFtby7xKJ3AH/PMT > Q5keMJK5P2lv3pcOKjK7WSbJ12tRUgzrpI0pnLBk/uRkemOcgwTj8mtUEDEi4tcmNVOLvdly > 1ofboTISMb0Sa6Z8PI5vLJ3DIDx3vAPPxbD3vIh7LiXR4Tb7ErwxawaHaIeGO+Td3UPC7+EV > PhpSVWigm65aDfnV2l8Xz6TAyzkHo0SIQm072jyxBEO5ZuIkXqJOEYFh3vOIhAdnf99Q7ba9 > Y1ZKIel9bwec6SA7tTuAYkHcUL+3cUF1oI/cb8D78x8v5AhSPBxBkbrduRvGMM5ddZcOtxL4 > ucOF7+7Tvl05f97yHpercfBII+5SDL5aE3xCXrRWPJfy8jBD4U7PJgNEjos2G1y37UTjR9V5 > gOPMDTu+s2HF8fNJ1GUeIxi7MyKayG1g8Hka9IuchRGkWx5f90sSsIvyheay/gli33S92MOJ > srsN1GE2LFqJD76mLV472NoGdch9fEQxjsV0srk9reYxFNkx7Xa0tMrJNQhzjMvDaymY/Ruk > 2Idz+0VKWbgIgyzbBB5qYP5YY3orbclw6v0NAePSfXzcoxLjPUpVXhLHmR28E7cjrZm1ZzUP > Jq/JrIyIhnU7KUlIbOotZmW2ibfLJKJt0skgkilkiEk2LFKAbnLEQSVSwgJKTLREV7P8omhb > wTskrsqsbi2neBbATZFpWaW4lXFtIaSdaY0RsNifLdrPk70gGcyN+VkJKmwlkNqlixXkn8Ax > 1x7FzgAqI0yGuK5vpYbZ7/MStemjf2LJrBDt42ZKo3CBBhKNNGOHhZlEYZDhshMaZEzCkmqE > Ly7PMONdKDpWSHEs19ZFDcAbaC7A6IG0gjoEEA8COUEm1RJxGIuTm4wn8jt+WN48qKNa5t6w > 2yEQ7vmRkrXujRp3YS5FWN3M06PNZ5zWBvz0dcfc9weZNY0YZv5Ok5xTMS0rMwwTZ6Ke9WDP > G6aMxK7k4w3IjMKiWuVojQrxonLlw4Q4BCeb1gYzq+51OS4ZbWMLuGRuJ7TUVhWbNY6+9ItN > hsrn1UOLvdVhtNiR1+fBM3tbFl9WOgFM8ed0cAvfZbnOM23yxI8IwHGo9FHC2PboLuIf7s7p > qCS+EVzo1QnCFJrIxoZxEFJ2/DVapJI9ag8msJ/D9LXGw/QtJymX3pC7Vo56HnmSjLQ22qRp > 0Im2a0cXzqs28Wl3hEbRkuEi1pziwbjE2wl0K7RDhgih93Frkv2PoFxnYWkasNB8lnMlkqXy > G8kie6MNRFVmw4VhypFHMFmVqx7nRTfK03RojuCxRZWcShT25jl7sjJtQ4x0rvYC+7oVyJ7U > lsiGcbnjCE0Ct45X7jnfXHJRLoK8tLFnA5LrlwfWrZxSUc3YhTqKd0sp5YD6j1bDkeWRUO7x > abwzLVpNfb7MceNxppbn3I2i7VW4KZLpHnYXx/CWmq8szxgjdZkc4EWQrDg8tpDXbE9q16KY > bkx9dEO7TJ6ROshn3OHFnlfJbPWMjquS+MdzoS2lcryCfEtqmRK4k/drlcGyWo4Xwnh9cbum > EuArIuzONnEhrjGdjJssS2SiXh+7rlw2omd50w2SkoZx3Kffbzoq1QrB4u0K3ScXarbaJHQX > 4u0XNpOuRnL6Ld1hukIhzfMjJGyKLzZfL5QyVcOpUc5ZWJDkXAy8WmV82JvLyEG2SxEJRdF3 > wv7MUnRxY+zKsbvrYO67ncQSOIjOn5u+Jkb2hnhZcNtktJm9qlvF2xnS6hFjGHWvm5Dedh2w > xxif0nF+C6sVSziIHiXiasWRGqUilQ2LkT60xjLE8JgLT1HeCdw6zLkZWOjftb5+YuHWEyMo > vB2SLnFj4TpGvO45TuGDxveLSxROJJbumOEPz01GRBAUR1nEwBuU20efiiJkT6hN51YHLCZ5 > 17zI4imQSU/VxRdLV7FGe3dPyiobkIQdP0OTXSp4UmykQUIn8A7TF8/ItTdtTdPxSSxlXnc4 > e3wgkpXZhdKMr5UT8FOdfjpIOn4HUDzr6emaaREdPyjPYj+J4MKsyeUmKhfCkA5m+JVAhi1O > wzOhxTwhr5o3021R6vKV7jjvHk3RiCmRe26/Pgd/Znwz2Oh7Fibnew0AkCLjBs6UuDQgiU8I > cDDTjfsmj3j0TqXnquKcqWRKNgD2hFJYCvUMpSVR6Z+akTqRgUzg3tzlcVO/T1zOIUqbwl4k > 9yJO9QSlWw/HoFKhgm6PsNsxGKz9fZW2vymTQZKFi68pPP45kUv/X7oyedoqZa/RqOiWkL/f > lGSXk4sWo7wo+BtdPT9VLFt1opTgnUlUVzo6sUsKs32ZXKTtVDlrv0gUQonURzqVFe1UV0rU > lVydVjoj0T278huWPDv7Mz1+vgaeV1u+p21p0HZeweNVR66jub+Kdsp3e+p3N8P2T2tKdjdx > cNRjR86qkCMTf1uC/aohqpKndpKYu86RMWAzJooUvYqH8RKh1ALFl89ahkVMhnhRe8zpWl4P > oi5iDAHd9dOWl2f3+6iAC2TS/yycAM/x/flIlBjUi70WKtDUU6FihG8abt6HbB5KrbNIWMVl > rnPG97GrqBU/rEvqY304cTONLuTFi+isL58M9eKNqernFFBT+jHK52watn+xX2GgHFTnYQXj > jnMegxYpWJMO4TVZsO1ftHF6eiH+vjNW032EF2t6m4Bedy123sRwqvFindV+s/z2UVHyBKzr > BR2UWuVxn0kg697kRjj28d/LZI64gUc3bExabIu4cDkXtWd64+pjrhi1P0sZH5ltUXB9/EQg > 4ltem8uYP1/TueR9s/drhsUSwt7W6RiZsdIancPOyw4b6QVME13psANXcJ+sJIrAyB4ROxiH > jrPW9R1G8Ef3Eb8vDygmpwziO5bXvXntdIaXtgQrPzSBYsmzFjjcjzPTlX7BujKwBre5E6Qe > W9V85r/Kja1tIbIclcmlvCk4C45sikjMGLSFtn4eTWBhyNFk1qXTIRbLgzurdOT0WI/FgRjO > oArK9n37BuSoc1JWfJLrnnuP4AyGe9OutX6UER67Kcl/XfXC2l+w1MVYWP+XstEf5lwXvMky > Pmbrjl20rJ8al+8MO/7EYSdS+zgRkRYf+IQVEG6+11VDbvKUfbkMb6zMI1kog4VCM4Uo8aUZ > FVTbAFjfxfcMBbPhJbC+lr6ozBYuxsTP+pndy9eHb+MxGew7OevIS1Ld1uAh9RRkxChMh/h8 > MqZD0yQVJGb6KysEfU8f5A1I3prS/xQuOwfpW5dTEbFPoNfL7smP4yq7XEs1dRuMD5LWhTcG > NEvGJ932dm8DjK2YlKxbtBdZLeu8V/OakYu7jBsGSLjOmk6q+2w+3QPiyvc/YzImzqcFfuOo > 3z+uGI77P5dCmr+ByTV1Fr8R4q6RcDT1l9nGV+t5d0gHa7q46f6O+/YPHusGYmsB5K3TgeK9 > owav/HijZes2Wv62pRHzvzJVeMZfHmgi7ei3BztrxzLrepLXfJ3qtYY1BuZH2OF97EVyiHNP > ftmkJYhHDwGWqyrahSWbnZAisiI16EZ8NOpeJlcYNOr6StMJucMzcYSakrZBOua9XV4WeX22 > ftCIQcuIS43oVs14MeMwXkwFiz5iOLYxnEYQ74i6H2e2XJKWziFTDK0/ynyJDXSU0JBeYl9Y > oRRdtQ5Nd/BBH9MwMvMs6HuwyKWTIu9Emda5tuf0LNyRVr1HOiPYlAY02Z/LO7ZTA4nczvsO > K5cWgjHmf27EtazmLYF/ik9C0/dqqojO44ZgqDTvN39G2wHz4o30/o17zEtorJhmwW09o9Zo > MNzlSHWoZ6ZbOo+rnoeO3IWpdganNuCRfrL6sbvz+iDoIUnUGGtjVugxNGn4nZzbw6Ntf01K > yTaJJF3IF+JtUCtn2GWTnw3Z9Pv5AY6I4oWN6569A4W34yb59p8i+2Kl6vuUFi8OigsGOp46 > hOGhWP3kOu+fFRNA/m+djamUvwx5+jYB7kYaE6nPX9sRR/VnI3ptDqCpZgmTG5uGQf0pbqEH > bggo6oYfnsODN3vVJobh5AMy8Wx49TgdsxQ81Xsov75NqL/nqZQw9Y3g1WCsOgtnxX/xboIV > WXzusEGg+uJVVA7WQpPFT15/H/zi6yWZCJ+7FYoqOPG4p5MsXCLiHN8nBLoheakLLqaDcRmP > TwumRLErjBLDA7EXvQwlXX9VpSpB2+uEVA0hrq43VQr7v80IMhvFttQdZysOVqMZCLJo+vWU > o/oqLKujohulD71O7o4Uj31oeUQRUU92D9ucDhWVfX9IynEbAeT1w+jkFsNjyh+wbC3/IdLe > 9hWL1ULx2qhANQSe3i2Hw7tSNfWyriHsciNlOPdKyiG5OLr8Z/aZEIXkBB9sOAnjP42zaEe9 > iS3ZjowSLmnyxiy6PZ2B9bi2wKQSg9i0KzHpfSLwcFO9o8fvR6wZEL8gKGVYr117pnleoUe3 > z5JuvmFXRrUW4co3GZZBrSJAWOHo3FqdxxahxX7+v5+buj7TsZArRakN2LNRA60Os5lh4P73 > aLghZ09/soqEUGsosXFji3HYocINeSNW9+GuI3+u5g5p8/gmTXeIwRNpX0tFk67Hvdc4T0EU > DWaAxfpbCscrpE2JoAt5m19iUY+6hssK2xmwhuLdsMytYfbMbSVcB/QvD+0DspwpZIrmSgXX > yTh67RUI9YspzSgh0vahv7IWPw/xAo3I0oloz3ia1JQzLK+yFs7TnGJ82f7312WGiRfjHhM/ > cKq5aA9Zh09eP92Vd+bgtiGfvoNhifThmV39zdqHeCRuf13Np51miwb6Wa/nibN2GzKu4vP9 > IoO0L2jO0S/+5YjuluitQ3ENIbDlatDh7ZpAk9Agioq7gLPC9JNkILxXnHCQ2c5cBZtA4ucv > UJMxZhlk2EOXzqLci/mt6ag5Rrl6IZ8Y1uoQrJl9lDmpdq1ezvKVz15D3vBm8J4xbfXSueNl > Fice35RXhrqrIV6YBRwUHFj9vhOMdfj17m0x2YNtrhAgbK+zloQGzLN/+M66JHS9TqbqyaTB > 3e1mbqtofPHCtRcm4PFYw6AZ1/wn4d/VC7hbRrfZM6XNu1UhRWP7uDZWzCbJWBv6+8ZU0rRC > 3fQhUIaXBPd4oZeSN4f/8CtlloUfVev4GoZTv30TseTSUiKRBKw4xrJu2gCElKIXKMm7lGxb > og2kNytv62Sa9TEo8gLOtFlNu3QryY5uZOUmQ+2gi4XDUtoY3S1Urba6eG7eOTQxYVn2kSH2 > sUSrHPLUsijTRMc4cJb4+hjk93qmHU3gtYM7CO7elq8jKLvAtlwC0t+8AMgKrd7KSRXKbd7K > xmMizg/9tDtLNa/HG8KrOwMehOJ7I3EuY8ZbeWz6kpofdjvVuUghFTGSpmEPm6an+AFCIvSN > xTN2UKFMIdHYT6lMLdvR+X/opDekGQtsZOUizVAkOGehReKeV8PDwGXPu7Qpm63aJxIOa9oo > win5sYAxS3YPRDfbdchLOAi1qJMfoo+euhyhaTni8NNHmyCtS2RQKRd9TsE4frMloTPsrLfu > ggc8fZ6dWjveNMv5hf8dqhvIva4eoIrHovIY/WaFWPrD16ws27Lnvo1B7q+RHQh06o0THvnl > CexvCGhZz3aw17madsnZBcawQW7e+0NgauQmqeN5Xl3WBZC9gl3MXFa1SWjxUucWdHTJvVwi > WmJtJnYpx+aE7Oi2+539ctMR6JW2XpD/K8tikpvsgvtp9DaD/cxf80ar9XwhO/OQzwsAXmu8 > tWoyGjVz2Epiftuy8aMLPCRtDDt5Uxm++V4zVkh3vLTyjhRd5P1FdkVpsPD7heK0xkUGkcst > GDmD07S710dTcCMPC2dykBaYFpSCWgJ8CkQ8CYvJOcJHnqL9uOTmJcG4clRQaHJEUi4c2ld0 > OAfmEE9ie4TYiAdgbwpg9HmBUfXVR6zRNZwMgJseyGbFXrKqIMeD9KQc1ORZgUmBQwBiun94 > EM/2JT8GlID84P+cG90Sb3e6b1U7jWfwksQda3ZRtmqkRiDCNBvQn4hTZaoe9bjGhwWz5fGv > 901JQEHsv6weKxq2sbXCME7hWHD8/sYMPp3nGFCpfQcrcy6v7+j9U2h4Y+stNov2DDiSzpnk > zDAYVIZCNvsEnf2DX9UqP2IcPuMKFZjQCtq2YZxuJg8M9TnDE3woix0+u1Dw8nvpOgdaXGS1 > C+1OKapPBRohxEn/4ioH3EsOoV+t7YzkR6AZ7bCbO1gwuY1ek/scEwbwuJ1bsWvErWt2dzMu > B//jj1bU+Y62MSXsB/hzX0zHw7bQc1fbf1NTguNsEiKpRb+rQYcZjk4NTxs9Qas0bHvZif6I > 1NkiJBTk26SRKTk4YMQ0z0uffasSpySqI5AQTTT4RKHLvoIigST/tyXkKCm+jgq/5ZGu9OUY > p3I+wytULJvl9e79VCgqgl57d05+O+ppgeMO9j/AGodN/Zu3apDa9E/Lz9ZdELZ9DE0TxcFn > D96k0+jy50P0Ns0b1JtaRg/CLI96n4af/Mxt+sPYk8QACEhbbetdDCxwz90Ymx83+9a+dz3D > 05W9v+etomtotPCjZoBuq7ehTAMzhW9U3b+Ga3bPz5AS1tweXrczNF792oXli+1slavu9+1j > dZKSlLvLk6Nli86/ydfNDJbfjPa1Jmjef+89B6kt00bNUcNYWyt20wFRwPTBl1Dr4nrcT1oY > Kxfi5iV+cggyAWS9AsYV/7JWk/fdimSZKPQ4PNn5S34/UI9VPZ8fFwy18Ra2UpDDmcJ638sr > XaCuv9ufbxRSk+eDhY98Slms1Hx4XYxE0AuEXImoN0a1gd0/1N4VNU12cBfQrWHb6mubeNHP > E3Fr7Cumj8EWm/3+f8MgluPefwWeFWBqvT83BtJ9tkFn/6JFliVzuFHRduN8RAkoy5H4I0BA > Jxz1uOK+b/4A29HBXDJ6evTZrD1sNbEaVzJ6mbk0B2xoDgmeFDgA0nD+JnKV4krdBNzA96WP > bRl0QYxop6beJ7Y+bbbRqmuaMT/uXW8bNo+dGzbdEGv2tY0w/R2aWpOMJnTvS0pnpONXUM/y > 5d5zptq6LCR39dBf6qxod9vbeLfgp5WsSwHehxLv2UZ+rZhZi+/r4g2j2QkNiBVYZ6552i9N > dJmjd5dL05dcNLMdl8yi2lfJuVRntGDSUa6tZ+xZNPBOUH21KTZ5I2PuNbPfIc1WJktGHwyg > dj2cJ//ChzeqLClmYScpD9SidKTk0VRG8Ur9kdAxHb7k4PrOlKSVaVxuedtHZhI43UE/TKTm > i8k1vz+uxBbVnzbMSTcCniKeIrvlb2IuGcfssfxG1TsHf5te0i9NiPV6SXUNAfsYDSjXwegH > YEDUZH7j9Fvqay+3wYf2+tZv3RGszi1hVJ9752pfLqQzQuI4VWz1H4IWaWuXP1vnI2eni7vI > NZJNrYr/Xug5OHlE2nAswxwfuin2rpsTWZvSLN5dMoc9axlEW4d+Lem+jlPTzT+U3/TCFb9L > pAvMwBMcFIg0rEKQd3x0R+7EzlvMgG6ZblEGUlEh2+/5UNf1cGb+ABivkeDoX2lWZwtMrdvu > /Qa5rpi8ewg5tANv0qT+ieBHWPC7u3m6MW4A+Tm4kzbyRImwrJ5q/DD+nN4Kd9obr7rLisSx > BNhDp3Dclsv3ANHqFsBMmw00E/Jt6yqrtnZed2n/phO3v2VvlAG0A49qO9j0t+yEWRhtLyF2 > bl9vmDYtl7VPs27DiEE7F2bYA5CvT2Jd29YEyzaqcHysphqSikmtcRPR49vKwrXkaSjmsv7o > 0bnC6XKMLhiwl4n5M8FZO3lNzRSx+Uvw1D2d2wlzQhLRNJ4kOKqNnmbOMq4KGV4EqJtq2rai > BrrUNzuNHoamst/O+su4sk5z33cmMMnJYkGcuHkWeHr9NlkjPeakm4rFjfLYuaZVvfaKzqHe > qGVE37NNy975wTGG/NNoejWcZ1LbRTs7RteBqi/hihPb/soj3tFweyLRSdf/O7H8fOcG0vl6 > mk0LQVjf5NU/cAR8A/QkFGf3ROTnIHEOC1u2MwMJHMI3uEzNefo3fChyM3bHg4KzP6GPr1Wc > 66+1z6uqx7klKeP7iyycv0/RXExLyZSsXXMnkn+4SZTOqRZ0/eRim0zRJckTeTboM/yvrfm1 > KgcH5jW/oIzVrrySi9tXfs9AQkw99/ofn77zTaT29e1SmGzKnXv9R2Deae4Dopu+ECOM1sNE > VMm/u4G22Hp9wvP/r37dMP0ZpTilu8I6lkC8D4oKkBgAygs4GgF1AMw5awlZBd3PuPM4hcSc > JLwk6CJwRYCUoJTglWCV4JawjViO6zyeGgrFCqs8yZb7Ss1Or8J9aP82LZNcJrG8UlJU0r7j > RcCMXI9Kt/uBkgnU4d2FYSXM8KqZBKIJab7ghwo65VXcOtrnScQa3/tKt1iuU6vU1vOwf/g3 > z5p6CxXMfdrjcyd4Z7le7DSMbkkQiJz2Mm59Tpeop6pS05QIZWubZOJgXTq3kE6AlgEAsgXg > fFBUgMAGUFnA0FPoDvgBkcwQI+E3UJMwnBBKGE4YJTAlT622rQSxlunbFd6hdgysM1x5bBRf > /RWjKSVLh6kpqKkokcFNOSCbr07JB0R72VKaekqsP8ybhZyzX1murPGLNecItBaqaPqxNksV > bqHVY5gkyjPTNNG0q5uDZ9NscNP1NJT00hiEUunqiSEytL11yHfN/BcdvdUnBvAEYHAATgKo > KSD4AKcCqAYQOTQ7Lo2zBAPeKDB4SThJiEnYROCUUIvBKcEXwlhDne2tzlI9gZuOtvKJ5bqt > Z7PX+QqlgLRdv4NOIEvcHY3M8b58oksGCOInIqSpz0xP35dhScoqab4D5zXkXBeKs3csO+82 > YMnxqu9t6C63O2lou+PxjH/y7AbSek+SSH9AZB1AuKB8IF8OLi4uSMUcXFxcXFxcXFxcXFxc > XFxcfmu66MuHSfDCOhuoSZhOCCKQRYCUoJTwlaCWMOd6u3SUGgMtgpnNzPC3TZvC+n0303xC > zAPgnumczos44KJz/Ny+k5vnvnN/jzosE86J8knOD3BuQb7vAI/h8W47i6t1AigwC+qm4J78 > 5SArg4YELZHd8RtmCA0hB1LDEEIhBJ2EooTii3fzj8Fdl1Q6TjraPj+5ygfx1xpy/IBgP9NY > rAxXiv8heubrNmqIVsgJioz8h4F/CJPfcLF5B15Rsqm924/zq0prU9Wp/IOtWZLEw2EfXmKr > 8nhAYLox8k5n+I9rnogM3LfhsgA6yJKcIo42U6fjrOo0JUfONdZnl5WlJjgE9A+I49I7w4Gy > XwXTo0EG6fOQgTUE7BmmZ2XR0vBAXwjMEawh/8UMkQSZhEwtleaUpDaUh/iUhrKQ3MA6UlJU > +Xw9ykN5SG0pD+vgQCeVfGcbA7zM6uh6pfVNbkblj8G0uUiKQVJGdl0adggUkJTwjKEaAgym > Bg8IhFnR8mSrFwK7pJw7/J6GwcqUwedN5ykqYWYR0mxgm6mSId3Ewf8CplH+Y+Sq9u7+sYJz > 6zYjXQNi6s/0cq62kj1Oxsxje9eBYc41heSkGV7tKEAvjVNceMd6purmOqX1VhcrT1WaXeu7 > qG360GfU0Ml+CBwQRYCUwJWgjMEbAkc4zK0tSbdA1ec6fswjpXB90u9E6Vec6Wee6XwgulzB > OfldcNeOMiXTevn/G5N7Jtu8/S+s5NATVsGo8EHFSBWRBD4rNCu6hI4VlBWXhB5XaCqMEGlT > n8CddhAXGRNfEvYxJtCKL5o39QnO71r0o+yo14OigEjooRw6PqflB+k3mnZkC40HGgdVhBac > d45XcA2nfPdQ8EkBLAZbmpwYpYICwEXglMCVYIyhGYI0hGwIO+OGRwJHy3lEtVWpFi3KfJLe > oS0nEtJG6ho1ESKQU0/qLpiPPkxOTSFsekcxwENMTSSUQ8mGcQq4murPLLNvxuKq3O8pbS3a > aMrSXP8GmRnuDVebq2hSGUU8LC35JT+DUE2gXo5KpyiRIeVQWt5yHe38dDxd8cDq+GCng5YF > eBZAM4LmBtBF3ro44wV6WOy6NGwQEoJRwlPCMoRqCDuPDJKEm4RSCcUErRb5x4Dmef+Pa69z > tQsEk/tGfa1is1g5iwNdjszhsnfRoKwmz8goEYEQpKTtdcOELZgI0QExTTbeJbyI9K3BJS0t > NenMdhFwjbKCXKCriRviOliFO2NHnxGICM4+gppElr+G6qq6cO+KTilRnLFU797x1htlqsFs > Yqe/obaAcq1cuwMjFV6xDo5WrLWmAe8Is/4VHcbikpJSiD9go9R9ABJ8To2DnLbc7fdLrbWc > e0NN06In0Dd+KraCz4gkE51PYi7n5IhjfFJHuLGlCcVBNSR9CVKXfgR9RfvCP43Gl/a+05jN > fzkMMRehg6U1zgYdgp7jtjqkoN3BMwb8BMBQQUcHEApgOSBWgOTO7Lo2vBAHVAMj4RGCKQRe > CUwJUwlhCNIQdUX8A6b6Q4HI8hVlSqiVSg6iJ+s7MxNPNWiu2Bvc5xr+SSaQJULWj4pamQ94 > SvcBTg8IkVTt+A0+IQLQeppKX1G5z5MTfRyVT3q4N1U5wzmDeeSSzCGAcST3EuBCGFRIuK8q > pI9Jn8/TVHX9B8SNRhkal2vL3weOhmuqnWeX5ny5/Z/7JNDSceKQnxJSxa7dz6j4623yme6X > W53VnH3Pnrlc7aT6C5NLdou++7REJPk27KDn15I6qqT3g1Gl9CPUUrLOFbyzfqI8rfCEAYIp > mQ9E1Fqfb5Ag5JyDj/Y71KdXGAqYOYBYQWmCRuV3ANeqjTkPBoHY5AMnWCAnBOGCVMJYwlxC > DKkGIASShEYInBKSW1DLFy83rNE4+7cf0XIsocZauy2JfbV+vWfldG4OTaAqps/NMl7Hz0hQ > SBG935hshWv/OJabnoCPToQQQjnMZl2Ejo23VeUHIliivY2hz0TdYoxAokj09RSk2FphB/xb > ibEuzpZalxPpSL4+WKsWiqXQey8kw82+emTQKZk5JKSVC3JJF/QUR25outt6BqaGm6to9pt1 > x6C5Gmk63j4n0dixB0+SU+epqj+L4/AjKIhpdU0r4w9VT/ZAi+wpdx9iMruuCMH0xVSA/+95 > HSQs7zW6je/R+5bSCRAlQJiCcASgKYFgGmps7Lo2bBAPeSDFIIzBJjyYZUwjaEl9TDKYEuIS > Z8o+FnPwmLcf02qqzyoUKnUJfn+Waqah1CycdVcBKpzPHTrlFWosHIqFPl/LWumzEx3ZNn8V > X2nlqfZOc5jkctFU3jea6Oy2PASr3lgsVe6Tla9ZKiyXautXG1v6U61ZWjSt7jnURz+yTfcc > t77p3g2NCUVNKd1KVIRZQraHl/QsvoJUkHzlNThB5KEL6qQMVBvlSUlQUMthS0YWnYJma3FJ > JiPbNOvBo+OfIeR9kU34IFbyP4WQktzQG+mnGmkKqyOguyRM6n2tQ3zJQ7LoY1KS8/HjM94T > fxnZpV7o8leiJcJWSZqTPb20ZpZE7ql9jNLu8oR6xHe0JWdrTseJ8epa3zz8bQ9NT9SRITzB > 24aMXBRH95Md4vXWJCT7w5q/rt44W95EAg+3l0+ICCaWMchw/YeJmJLe6aQv1GEvc7xDSs1H > 33QLPILPI5vWqqzcFm1rPKrPL8JvCzyl+rcs2HBp4leWehWSbtaktnMrNXWahwkx71NLdGHs > wsg+tVWuU6HP9hvNWtzLeB8IGbnzFzrlV5dhq1iq1okg9g5Op9DqTQr6/XKuyWLl7AX/KXOW > 9mpHBNoEtQCRESCpfqJVLUYHLnCClKODChbck69U5oeRSRDHJZDST3EXaMaQgEBGGRyxXpd8 > xname49BdWq86JTx/PXkm0+MfbyZfZbpdTCNNtZ+luo/q07V0H/LupSGSd51n7nKcARyA80Y > eKm35rt99HsxWOw54LreGnuL0mfEH65QK5Bf9DizANv2jq2w9VywzVVTMOs+VYca4WCPVmX4 > saGqvNoEF0pbyH5mhaTeFBUvqPEVDU/nJZ+EyRo2+xH+FTuQUoObuVD/YNzG5kAk5OVDSuaU > lRRJd0JDk/maUQznqJrX7JMgL4/fS2yqFOldU4AlAUwLAPegpYKiBfAxgswLaBqBnrFVQxCq > vTmCBVgjaEmNWDKUErwQZyoZLwnDBLMEQeWdDbAcha6hcGBSpsu5WZ1Hg6c0VaoVVRp7JC4a > sf9YW7ciy01DMN2HMFr5Tj2Rf42pc3/0q9Ps/H2bkvk22x1CFv1erMJbi85Wm8b1/SzOWJVh > q2TgySgoANDwg9RhTf1eJO14yVewviVMzUmSUlJ5ZjEqBjw1aoobgaWer7yIROEU2epxB8Sp > djks43EeG4knB3fHnpzyH4syl7i4vMExy7aIqiFCBaGSa3vOLaGvBlApjyYWGkHZL78hELGX > 9NbeDxmNDJ3fI+DM+GbIRifIWaYstMI7Kws3Qp/qW5grFh5hlZLFU7NyvKj4bdq1kfXLvW2w > wLsD+YsH6Gj+F0ryc7N9N8qJGRD8iJDbs1Q59Rfukognj37Z+1x2kK2L341KsA+6XPoWfQbn > 0pk7Qz3K5XnoB/RQ2y6uRf//4mrA8xDvMO5NEJ35jqHYHZAbDSyCiBsNNpKBuzDq3Gw2zV2s > 2Y3ONty4UNlNtLjbc14cxyxutuBsgs7dtG26G0Y03DexgBfTXXM97EUL4TDeJvG4566b9XN6 > //v9LdfnX54/GfE6pfPOidQmuAc+VW4aMNCYMoS7BTg22wwAaozUYpFNQiinyls8aOzUlIFU > kXxe/Pr569PXvz69vz+//zs7bu2fPr5/vr6/x9/fn78u8xWbqut+y/MP7LKaKzMDB1ZRyg11 > 7V8cCc9WOtoG2GzWTImN/Shf2oKA7oNThgGARoIR4qyTmZm4OiT1VNVP552c4nzkuGND3/gn > bayhq4GqDZzRID/ZyrcyP4GeUJvmIJLdATN2Kq0RF80bKD/hBzrzvTQRxseIFFRUJG/8Skq4 > xvmNTtX0bfVG3OdAug6cDECzgQnAtkaI+DdAJAIYh1TC/n3SCwhiStBfGBjKGTSqOMxpjEGJ > BILpoYvhiLzYR5lFy/B8jzHNVOtdfV+wp9a/c+lU1bl69UP3YBOKA/e5WG/Qo/LL/PdkZ/7Z > L8pf5H6fKrYp9O8t2fl15dJ1Re5uz8xx/SNZzq4x81yzoO5jnluw1ytGfUlv8pv5+zrvJf8+ > ABNcNdUciJnQHOJ2rf5tyG9roKpmb0gSaVR1yShOB0Jm5LUY3xnrZ5NTDlXEwXl3UxBL58Nz > 59Y02lVssCzV8s4JZJ+2oyL8vNXAm7CYbkaqGo73I5yqdzty3s8sNk6DJzDH0nwBuRihrh/4 > dkUaoec7Xfd8yYNx3CEp/bPeT1Weqxqcmt/BFMgb1CXWp2XwSric/AFjoFuZ8VUMYy3WZFZP > 0sHqzgI1Vnhl8FbTgs8n3jx4/K9FasktufgF4slvPp0iWUqy/Lmt51v/FS/5lU4apEVshMeL > 5WAcFrltZJW+4+kbuNwEW8Aq1aqxLnrA/MTmOvG1HpqzVvCYtfRbS38bWbBUqxnzMavYhtV6 > /nPoDebsdb6WBcXlq5WMjERtS6DIvDANbyCbUGdWXDYuCKzuHohgi1GeP3gnjZd/7Kk3DqYS > 7KYzffjVANVBNre7TAHOr7E/NyzdR11mYGFisw37HVlOrsa/1RTrbHl4j7RFG9h9k0loycdg > 2eZhvU2ZkgW2G/vMJPrZHlkmlGcvW6HsmNojxxlhIw9/gniqJOhL26WgTR+mgdcGN4OGujVO > sGzx+5tANmyL5ckHzpSoM/nhnvpaqI3icT0dRDRNA5R9GqfKJb7QR70S86qKykPHOaZc5XK3 > eLFR5wIgL9hIsJmPhSON5UXeDw4bU/R7JRz1wZo6in47bQIpOUZFnc2FsV0gZQxDqoXtIIid > +hhNcnQml1yp81T7o1DAMaXDAJth4CZT0UdV5U1ZM6j9tUyZ0ID5yqhDeCVhbRqE1CBpk0kh > Jn1vNu9g3Vruv0H7Y6RWlrIk3Lmfpm3uWjXpmgoUfiqrHR0tN7ClJiIze4m0Uvf+vzoOPXKr > pajXTuPVtuBqFT2pT7Uo3jxiqMhYPU2r1YIeBp9gWVJpjxi+S+sCdrpuDrNP85+prGynsIUt > qeTdKQtbSbMTi7mTR/ekpZlSlK7ChHzy/T+4lXRLMmgKCHTvjgxvz1WEKXL4PX/qjo170OTy > m4B8WT+dN/+BnIgMIGYCqkum1u80d/SM80JwUoZMbTjrwQz9lzzJr6a1BazXIvUZ7VFfa/WI > Zk+sIhZ/B2+A8G8bFe7LdMDk5BjNL0KM3xkPbRqw5O5575c/w45XYdiVo7rgfzXjPoxvCErm > jNntvaB55zIubasySbxbzkke+vFfeTb+5g+rd9KVMlFP4q5qvu1XZO05/wX20tS/aAaxHysM > DYtQviJTJrSkIjq2YenelgOme31qpae/J9aKp7r8L/ytBXDro4mYykIRuncpKJZ/gtSbn8Mk > vCcBRfW37pLCKc13VLcJFDo5pkSRJGvj9IwjwmmknbPUIpZKSS7n8/63KxYxY/b0/fDTYyFS > KNIWKsGNI7wRYXkR0LdabWQHsUUs3RZcRq121L2uk2DgtoI+Jln/5ZbtppKdcPxIuWMjeNcc > qHRuakCaHcgmjPZKOVkId80sK98ywhOLOhhwDRn26lBmr6bZwPjl8dhQiYy+NSvXdZ3Sjxlw > TWPmSUmx4Pzf+BGhq7CiDKSoHrXbkKaByGlmR856/O1es5nGfc7WjPxiLJ9EL1sbVTJHBJVN > Q8ub3wq48DUQ+sWEK+6pzv0Lo4/yIpndhSRXcJJQeiD3F/AlQN6SGycRp2JceOexWkeiuSm9 > 4UgW0oj1z/bzt4mkX7pXObEJUw0N5x77XFimURxFlfPF70DGFpYYZU3CzkBa6UA5WJaD6l4v > g4n5VXgSvjoSb9lxsiiHKg/SDYWENaSQ1zCw3iNz16Plseb1TaXOeOpujFjsFEx1EvANy/CD > QUd8nGEqr0ZEuuJA/njMVSx8wv32c2vRGhpamKOfazyTPLI5u4zuXnkmfwGlLa8Ukr4MsCfp > 4Rp6G9g0oL6RDqmiSVWeQGIpKirTq1xkGk0TGt3NBo51cscUNzqb97Asx1itDdyGlvnuKJFG > xLlFZ1SN3OR7pJ4xFpbQVSiG98CpDjK+N8ZH3LdJL/AaVKoE0gLLGzScZitpGaeWT6fDSytA > swbFwSioXUfdS+GF7QFEdKRrfRypKZJJKF/BI1Ez3Px39fQshTUpW5T8yJ9KfRspIcc0+6hG > kTcINPu6e3ACY9EKArKKhBQiqPJtB1ePGSKj08nGZ5G2jLhXRf1F8QE1NCPHKVBNFwbk2Y2Y > c1k5Hvcn0rwKTXTzMaznUgqZUCFR0o5cn50Phxh93spvJSAGDqrkk/e8z0jkZnz86hjv0Pm+ > 2h51HO/FQ0qyqs+kyo36tmNEmhNsnXNsynFxVwQPlhdyggx1jBEujlShPYrg9CIpofne3eGw > XnL0wshNr3YqTaru3mUCY6uyDRnD8LA1jwq0+dkKEjpremu/79fgAtB7721Mf+9qnyJ3f65w > u024gtkiNGzA20Gja4+UVl3bdKK7qJ0tLKownJcQVkQlC4krtokyphXZtQSJx0Y2Fbqio6s1 > tru84rel4ouvoKhs5VFQHoGF8hm1OE4ipNi1CgWuxIFCNWn1vqpiR/reRIfWe+e4VwwRp39J > kPWlI3Dmjf6k3BSSHAW9qBZe8OtoUBEwt8gtYS9yFaJH+tydrSOuAWO7F/YR0smhyGl8LBQ8 > H32mYOl/otcd58PCP8+HpIHPh94sG5XGaZNy9eWfAu1CeWux9kXbFugMOzVAGiq8ppjXHyVK > psHGgyk7Y69x5ttofRAWoTi2ON+3lNCir3uOOzIXVOLBVfU0MKrvhqTT90wp/+12AcNNvK07 > QwhJOJDXflvKeJlT48qtMuSvB9pcHKnffYoCZfH2GEE7x0spjnhGWGCk/H88Xu8xvV27j+3L > syyEcPc8wgJpuFCPAbmtZsLmoy84OrERxCG4t0adH0Bux+JjN2mt/xFs/H9rEw+HWS8f2O9c > OmsunX1ZqnGqZ0RjjqY9K9HrrmmPBCKv++x/7iwCNrHKAy64VSn9FkzBz5DWNUPRHk9fDo0a > 8ncuLJLTg3gcsHKAXn4HfLb6a/DtnTKa6KEYip4GOrG6rYhoPuTVecLxIX4Sl1xQMw9eUrC2 > pvtfc7ab19381qmUtMHJpFNXyTC5kZuZHQySkmr1xsvqkjhggMvRGEQ2BxHxcqTGaYb9dG9Q > vkc7GLHyj4VANGUFFbODC/Vlz8WmCMQq9myrOODIYX8ieh4VQPJHeQG54W+U/gPv2k3woIzV > +r/ySt8tdrBc/fw/FAdMxXSxBqvzm6muVRuvQc6xRVO8QUEwIu7gweatvrVNV68U5qSRa95W > 6MwM/Sjyd9kQP+NYOcwU4Nk8PWoYbUkPW+aEDBKeYJy905eqobV0IjDcV8v5E6k8mDFqj1l2 > hoNjsN0RlK9wSF5xcsosaTQO2kVmHlCOHKWX2gOuKZWUsUfSnuKJ8o+/brJAsUFE4mmNTkdu > bgx3z+SZ05XTHlrdfOENfpaaxupH8oe0brpXyghlpNYP8QJaJFRZCcrJ4aOSmGnEc6bfjq1x > n+vQjwyOiLv6qiIl8gk4zYvwjGy1bP235XhX3PiCJPROmnaaEfKEjBWankmvAvBRUdFDwh5f > 9nzsQNN4DcAuP6PwqxDJjlgZPmYToul8ysC/mmtrF/NxG71FvWzCEgAT02ZJKVM4TcohsJCu > uMBFLxfLFlb36sRx7oO4kdxHSgvGAkb3fq0Inuk8lkp0WlI8nRTJRfi7p92josoR3Et8WTyg > 6GDkaTfbcXLiKlEnRngPXh7ykHlW5yXdEYF6a9uacZeCGmSgF7acnsCB6DjTQvYFnjbg6wAW > xFWPLU8rg6+YxiNkanTK+/v6sQLpLAC5CZP4sUVtplPnRldO7MrOsCQdGYcmmgO9/xgH8Dr/ > yMaqOaLd6Y8DTXH3WXylap9fLjpbfdyKvmLr+85dzkzoxy4sh7L+/bubFHN6McCrs3DpSK+D > AqyZ95uzoy8Jx3r+akuawL0UPrhr2wViVfKdysfNxl1goPjdKEav9gsMcogtytDqQymZGLad > eQ5j5slZYPFtuqgruEjDNWVqndcyOTkT5Yjt8G/mhGaQZ83PT49FnGnYz3Y30OGlJzuP5/LZ > Xnu/ODIHOC5u+z/OYl+9lps8acMpYg1TSNOmgJyFx6PX6y0vhI08E9PeV7w092qL1tJsVPz8 > HGnGzLLX8oam3lQupqJ8B6+smxDOH4f1P9z3pCpO3OLBxoOSBy4ObBzwOhB0wOqA6kWlF1KT > mNwJ2IkicCJKRFISSiTwTbxFMTaRJ6JGRJ8IhCT8HjNeiHJFvNZik9iOKnqBF2vrdPhYqGSz > apELEjpfRjTO0F9X2etRHIu7VB4k+XOdgfXW9rZCz8OUNeb82mDeyZaeoe+jVJI16GtcJlqb > VFFEEC3gseiaY9m6FuWA1UFGGpdH1o6O5pnMpdNN8lm9pSemzydKtBVqDOxyfqiZhyyESVPx > /umhUKoeiZC81mPi+QEriUze3mInVbeb2PUKQszZ9I9I8o70gqDqAp75qC1ru/bTstOTrrd9 > a+uNrXbcrvdBzQCA64Fk5SpoXdU+PFVJfvmlLhXq+4sT4R7qbZ0xi/ibFenQtOxjf+D48Qil > myfj8foUUt2mIA8q7aRK52w3n7igE+4F98a3LwxaXYjCl82xag4RsAtu5ixoz5ALtp/JbriV > aH73SgEqlqkP2chM59KqdK20DxjWqhVIEPnBxcKKCZyBwYcg0iWwsDImC8tNasCXOIQFQqkB > KIKV/k0ORUeddvpDgNDiRv4IwhWs2Cls2in2IR5ftjzI0xuV4PtLg2zhKIKJ6JVQ55XIUQcV > kloavaZFR0HxR3lSQP33WT4rO1qm20sy2PkJnIFmnMjnM7/1Wr5wL23KevMMpnEZhcZo5FUf > IWWsWNHM8ZJQ0tvc5SBaqfDpST4E4xiw+mVGjthOSf/LXt+bImPj16B7MbtXBUrM2LGJN1/u > CZ1mPlXapiPk5HCMX5B/RNbcXkOGy5aznoStzR7x/dYsCTaX6ba2AWBuil7XJFShVCd5PpmB > tdr8nbxfGFbi6ppUrF+4KdY7gelfHOkBHFfpCOJDaeO4iD0S92hhW4bHBCkr1ZLfHuRDOJz4 > Npobh4tv8vvffCGXxz/DCoaZmS1H6uNeN3+uYeK9XdauAwEf9z654hs3hKEZ8wS3Fn8VJOfa > hhEK3l8WPTEYsV4X5NcXmPOuHLwCiq0D+scWTmbyIDkN+LCtJj90XB+VLcKLxH+WpsnTh/ZD > 8bjY692/8aHs8RDo/9R0sz0x4aEIt/r2IR6LxFMgpmlpSYmaPFqIkis1G+944i08e6qlVrWL > zGAJ4zrDGczwsfEBmATqPWCVs7gQooXKCN+DGMuxwZVrbqZw2IDGKiWYYJLyTC39s6r5YnNV > rIob8SJrrscUEzWq54SR1JDrH1fLYUOHQy9hVjwL3bhA3SHFBprQi8rkz6io8tq59AkePYHV > WuMBb0/+W31VSblENnsVtz6KHaC7/QasQ2e22amjrBIpfzLfa6DG6SG9h07MzYX4FqAGyHf5 > mNpFkPhWqm6ZyViNRpu//We9/8at3f/UXQUbMPZrSfvGcR+u57ppzBzS9BARTaqQ6RzT/ZAV > VTUuLRNApn0NYpF7zs+TLwtGX3wc3NvzYdQDcC3UgjxbqgRoGfLRlfeVD3Ddg4T1GsPYqq0n > NHr/Cj5W34M+QFDQ3VAh3k+lhnBLhbG+o+ao07DijLxkSgRRz3AL0wsUDr884/zEEDi47a/v > gzifjtqxIUKw+bM5E82bjcuy5kwI8eiGb1Vq3ZwTerffXtzamArPwVUEX6srvwOTB1wMmYKA > SPscIr64bIkTAf2PkeaiFUtK6jVheNWY+QqXNV8hZ6RY2b0pl9CMqdG6eVNQR458YYdynOL6 > FSOp+/zs952drKV0/h6PO62CG2A+WMpK3I3eXR/C8JbYxyoPzr8XWkyd2ac3HWDzYBTq84cc > rfDMqjPfOHIhzClc2A+mQ/nb3E9LV8PJXw02ppJ8WXQ8i6Gm1NJPy1dDyV0NNqaSgFq4Hkrg > abU0lBLLYeRbDTavtE5hWPhEdKyc5HVkNVZEl28jFhVzxJOtIgLKhZi1scwP+LE4j+QyomWo > hokYA5dOXOkKqa0Ce5+8bSizpPS5ZvaTma7SUqbS+WpSbLE5PaprplmlWyfoSo29aItSg6p5 > erjRsTQB58CNTZxQNEaAqp8V/yOgSLSffaI0WfxAi8l6aWdQraUd5UaI4hkmXzNOTJZvroWl > svdrJUxiBLaQp0xTjCADwDp9zR0GvWtCOGSf/Yx/qBgU+UDqHu+FY6T5aPVVVo/S3xTNRHJ9 > tKuC3Vk/WbQO9Nqb/XtuZk0pEUz65NhzUySdEqyZd4Pz8hFY7JjV9A+zr0dH3j4slXWH1EsX > DaCmU0/ed9yalJv5vTY4J09TomqYRUGH1BaH3v8T1uIW5jsCO8eJ5WV7KeUUfu9qY627aPND > dBsB+8oQ7XJapf+2+Jcq5yi66gKQuis/wERteMzVqhh3FstGPyHOpZM9IzAWaGjdR3ckOmkS > 9wka3nBWzThmUgefAmeOwz6Wj+udcrI6lMrMaZXN6PmZNYx/zr/N/sFmQzpEOjZZELXYxGWe > P34zZjBKQNjdr+gz0CFGMXvSNJSizCVKAgJOjugCFYBNvsoTGwJzUoglLTShw0w4i7GB/ZGb > fc5G85k2AR1ZPIQZ/sZYhfBV4yILRmZ22rmS84MI8hgAIAs4AsF4GhtqwNfDs/4ZF8h2uOvh > 3PPDt/aCZqx/6GvX4XjIh0XY5tbLGVkl8J8BA6PjEE4nlvBPZ2zNrUnmKK7Ntm0lXdqX+pY/ > tbfeSUnhbp+9fDW5kGF1HsmqvkerHPmKQzVxsRhHeMMJ8bRFF4hnSA8z+vKxcFYbkSSL4Pwb > X/z8Z8hYiHQYiyCnCXq8aXYCrvxIgSh/jv+IJg0FTrs3DDhHcHftSknHeN3fprx+Xq1BtgmP > XfQX6sbjjSe5vW3CdTm7WapCaqfJ94mMT6bLny+IOGKtd04MQpNkQLF9fyZMrDrtAfye4ccb > 4X9JZsoV9QMyxuWzd9dDOsvrHsZ3DXS9nbmaRQ+sbaTCwtNjaqjaTq+Ofl5hp78pCNSTs3QD > a2QxEshX7SB3equcniRp3eoub9MVNqzgV86hX+cioa6avVo/lJkM4iU5kszLtUlAb3Lo/TYQ > cpH5tMzu6H+vwfLapRtZOMmmhdPXSa9x6TMB7R1K+FrrYUijz7hDzGfXE1jt9UsQsTmAEJcp > K7IicJswykzltyuwoQ74ltoJkLWvbUfldS22O9n1N3zVjzy7nxsjYJ9koORwkYlKGTFs7coc > d9RvDqhYhch59McDfWxDFjlXXmJS0l1Mcn3xD+0pCHHO7NoxS4fl3jxHigRGSxQPbKB81iCO > CFiMQe2xB81hCPrChGEPba/j7G0+UwFx+7wpknjttMGFDbOQHH0A3/G6EqlykPnTWyAtPh83 > KopZUHpqvR4kWG8Er7GDpKk6u157TqWXUO+htW4xNaXiJUMKIwjCKW47jpK7lzIvPZGKb503 > mnSDtv+fFAwoGMQYxBjCGMIYwBjAJCzs9WDbDj9IRv5SpODLUn3Nd+WEOrf2bIqd3VF6H5gc > iSo6yuhPbmbUJgNFpC93PP5p/Z6J9L3je6DtUYYc5UjA4KB7iIHDEHuR0OGEPcGhwwB5fKHz > Liw5Vs/ht9M3nzdD68xeE99CmsoEI+BTo7voaAmWU4IF9JM8sx7vc64NK6A7kp6kBec85Jlf > dbshVFkN9PEa+Ruw9xL5h+9G271Y30cLIGMjPTDGQmSQKaSVRY6+jyTRsaPZz0EGvUtHkp6Y > YeSukOlfb0z0dgYcIwsVpQMC4sI2dAOPNeZED3DphjJvfyXCSz1cOSSF4Tn6pPo5PuR0JPnj > JnQQjk0osDYM/O4X6Ydpkpa0x/K/JyZ00xahPWm0HCW3sgl9BEWMKgBvYC52hmrS+0+77W5Q > cZKDa/eJSvu2T22CvXdi+58aWMqfR/A7lSS5SHSJh0VxKaYU/vESbZ4dSTvkD9WyRNT536lr > Y8TRVJaq5vRI+s74i/U474SGyx3mddXLIbemjZUf8DJIoILE/TF+yZ1LNa+6rNi/ZapKzVaW > Mgj0GFIlr2xV7pa7/znXBJZFNZXkJXsqgdULRsqc3lkyDRrWb/oxLd+d4Od/0Op9qOPKufzx > eN7U6MGVnJTR3IdM0xA0MvY6Xhpt5Vj2xm06/zR5I1Gh6cjpPZHOlSfIqLJtL0EIs1kCye2v > 31JM829yav6q1HTsphSYmU6xAG0Wsge5cQiEF4CwzDOJGHmwZKfX1rWT00OQDJMGux7C7MOt > W1jKp4TcHP5WaFdso5O05E5C6aGxliDVWvHpJkHcKVHBJlZbYegXCxCOaBSuaLhWNW8aFyoo > IDIV7O0inU20FY26gqtvly3F0H1gMALMBkAeOBIbQ6kOhStcCFwIXAhcCFwIXAhcCFwT0UzH > x//7L74xW7ULUkLskj3xCHDCs9jUXWUnpKqTS3FMSjYIQJlNXrF+Q2KNvtftuOjmbDXnYtA9 > OyJX1Vo+32gUWZkplmQxYZOyypeWT19HX1bKIUDR+iqz/qot+kuLwrhWyS5o2sulq72wjAtS > 8QHxshRkTVsLMToclFpYX0ETk7lUemzyd2buVZX4sp9nFDKnomzaPwkcGUkZhvKWOkKW1m9l > bv9y2O+bMrmAH/KMvrebRYZw3M3oK2f4088N3Wy+1kQbdI6YDPc1+1g34TZM/sf7otMZlLST > xmiZ7oX6beFJI07BJd3SDHSviP+p98y/sbsCuiEbsSS3FthFL3UObNDrfDzCcyz/LdfuvOdt > zNUi+tcUJeeTqfw4lYoRWmg9lCInVRfc7JMdu5K36A/Pj7rMtLU9QZG9Jcta3LobrpaUGLg4 > HHtK6Hje+HcTDKx2AgnRQAfReWM/hVrrxcuuh3RglGD1VI5pBdL4d9bDsoYkzp2nuTf7PzZH > iVImC+yT/xVzF62fc8kPPeSg01QlmN88kto1AEJs0sDgiYBBA2KcBRfyiaPIgvaTf2md8mLr > J99XXx024uL0aGu/6P8OmBwIlZuDJHuAwCio4B+yd0ekAyaLwMkLfbYipBHuGr2Y8GcRHm0y > 7TjKFmPJj7//1If4l3WV3dOZ009MqwfxB4OGBxQOMByYOaBWgLoMXz5Xab7cfgREwupCbsXn > gm6F1MT4heeiR0vPhIuXn4Ms84ixfFtPqrSV0NjqXctdxctjXbr+RG7IO5FveQ6B/LYXW/12 > UrZED9az3tsA+GWDsw7ZbfwBRuQC/RY5kEt3h8wyPuPUvINz756lJcPdg5Sbha8pqtxPzBCP > d9W0C6Ls89rUXIo1/fmymeFt5dmzfRdrlDurIWoOw27U5H4MiHS6zdLQWF49INItJ67+DkJq > kAA/aTP6VHe1tBk+YIaUGptm+Wdw4+EQyosAxY5fDUvZFKX3liNSsrECUFg7YXownd8DgI7/ > eqR77K25U5E5X8sEKnForaPAkKf/tQq6tAW9yIosfoDlnxrcSgb0DfwTwA8FIARB+wDcgYgo > Can3Kv1Wc8E3tnPRJcznwkpZz8SRs6AJtrOgibIzoQkWZ9i+Ghx6eA/tfgWhyd0WI1o9QEzu > NAApjIVkmjxu1IGFeU4tMwN2YJn6+M0msGacs8R9O+BiGUuFDykxOMBYPQLXLvlMIhFQ/Lq0 > +L5wpP6hB2j0TJE47XRR6vEz093+wxOCZiPrUq39go8eg9Jjd+JLz0TQpXzyu1H3rTqdkGWF > /Cqv5pPPfsUPWZy7O2s15J37dt0LBZMf8sUwcfiWh7fhk+DtHv7JvJDo8HVLsmezb2CK9Ad9 > FHRcTRxYqr2g8GLEsFnAnNOm/QitYr/5SekCogmE9J7f7189d+ne4ryqaJ/btxvX63pwDr8O > gjwjzDu1eJWpBG1ZNgxpXKvGBSaMc0KRZxwMi93TOCFaS5VDnbH7NgdCMtUEtOU0J37wGpPZ > e6jFBEtZk2vjFhJwxp7Y4OZ7HhZMwsh39ppzlUO68fumv3EV8fHO/hM1OQHA0mlXQdCCZK6Z > INCY0ECgh8wX7M9R2RV/BwNBcGF2/bjCneEDipPr6va9R43fFFbyN8Fs+gr3m2uKjU5+Pad/ > RvDo/+8nq+Vi2UTSMWkwFgERFHr2dcl/q7CUn1UNJHwJHL5jLxR3Q9ZCAmaZ8KPzx6B1nlTL > TmolYPJv255rOGvzyNEUEu/67tENd2lkt1xhqXwf5piSGUISWURueMwNer27JLC+WcW6VGFb > CcxGU4/hrNVvQCs006CBU7X2R64fzC67OgqSIr1baQH1HQbuxZccAaCLUUEvZ5gWGVdhdwKx > wsCU3I/QJxirsV0R84mIzVZ4pL4BZlXrOekqjhWyCi29IcAd1uSaMM5PuVbZ/LdT+DfxGNtX > ZNCA0dN/60hAMcU0daPBzzjChTt2ofDhl0ZFj9iXD+aYIMmp/yZ4TnDOek5uznxOZM5+TlzO > gE91Z0EmjM6ETkTPsRPbWeLE9mZ4uTRGdDJoLO+T3KZ64aQexPNWzJ0LrFQjucJYs2paKbJ9 > +XXD4oXpJxSkytr85MNZO+QhgSKadlVzyEER3nt/iOPyiZuFosozIq4Eh+50Kv4UDm6/Ad9V > 2S3axUMyH6pjLB3Mp4sxco3FTvIazrk17NHFDImWtEacObfVBor/9OKkFwzKaJwoRWyvzbSF > wpdv07rNazxqBQfSichrZ+nYuaNficH116qn0JsP/hO8PobIpYm1/jvhbX+Qod2yX2sItqiE > hdC5tzMnFchStZ1Xt5mE1QULve8hsuj6hqKDfapATDh7blgC9Df/jlUlG9lOiuijIJwGo/yX > qllYVe2eoKg5WoaYHbm6e00UwPfDOBwsW/V57ecVgwUxIBV4RT9O3VJydbhl2pleyl4fkgyW > F9SVS28i4XpMHEs1jQxs92FrgMe0uXkz+yy0GzWEH5llqTWtFWS2XShrrB+3aaF4Cs/pOu9g > B27HLDCwl4mNJKTg9/z9EjTbmmXJd2faeAmqUPZYhoAzxMLbzdUwPx0kN1oQ1DT8dMDeoAex > P1AqaB+PjA3rINVWCMMzpT0XdjiNbF4y8I+x7x+E+PJ0fb7e+0UL472wnH3GqJWYJU/zKfaC > sSTZPe0a5GTHmZ4s1TTv5FjB6RrCX5mJgy3r9O6NHOl6ogyAUnGmVoKPQ0+YBfOeMhT4NECk > J2Q4w+VPYvakNH2IgZGIv7jmF2BkONxrpKuNwSo/cccXmQ7+NG0Xyf26gJGFerd7HPJipZ4V > mb7356hmNGutkPBn3V+Q8GZaMh4MK0QpX6ic7qlsJsBXL1iKOfUza+DzZehY8ZJq9ixT04ho > kFrN0Umd+8WKJ7FD/zEeHI9+buv8XuMWNq7HRwbcNsJa7h9eH4IKPAAL3jmbJ4lRsUc90+BL > +TisCv3lzP2NecRWD3zB5bJggHeXNQM2MxpZ9CKPIxFralI2EnxatotPZzOFX3RTtQ1RjtSR > N7lU3Zz8RKm8vmmaQ1SlpUkLoQm9pUzmkyts6/tkx2cO3J0RTfuVb6XPQbunJ1+Hkvg/+hRd > V1Y1Xs69qzoZfYUCA2Bh6TW6ezcFTHg4ChA3bhsrqbNHTHoFfCyE2aWfw8iTXv2OgzJzb2fh > kdnGTnFoEZqxQiZtKYjKKegFES56O7NBoztzlJ5sHOSgHxzVUkKk0f/JLR43YE6Oxi3HW+AA > hlVa0NSflv9zsEPK/v7TC74MYqk8sdfULPsBv+39wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsqgqEYAAAA > MSev4JJKoECzxIMEZLoITZALVEEVGJJDEFlCyZMrxAQhmU/ygUuKoJtpog0IIxF0YaDPdR5H > k3FWWSwsG4aAJBAgZYMF1dYb/3/sio4vjOTjOz6TvISnDI0/cJwDY4JuV4xij9s1aXMUKoqr > 2Kl+pKxUvsnNtxCt25He9EzTtCGNj44EcI4tNSy65dHGGA6HcJQphQVB1CqOmN/XuIkRDVha > FcNCxuIprIuotD2HeH37Wwyi6IPObwHWGRkHiMIvBLoN5HvnwH8z+h/ULDCbOp9D8vdOjqnq > 7go+SFY2G8wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAEEKyqhmQAAA6RF0OxKXQ6ERHQ6EoiQV0QR0TJ7MyXJckmVmW > REQTsz3czPXPZ7vjvvelnqIlEdDoR0TQjouh0TQiIlIOql0IjqhR1OiiIiTVR0OqjouimfOm > XB/Fcqum6ZtjrkQoRhdGT8ezJKRuSxlZkqUvbR/GWrFIEWmUohLKkMtYpjkkwkVsGiEF//// > //wzzn3Pu879zvdXd3ec59/c59OWVVtB0055c/Zt0vMZw5Osout6IT1i2bSA4wt5BVsXXUMD > 1LF+uG2sXs6KBr8VSymuvZX/CsA24dUdA68O1CfCkA8Chrg8UPKDzQ2gbUNuGlkmdby5IU+D > cO5DVhrQ8EPECtCugYzm9tqG4haSTN10Gdgez3FrHwqsPCDXh5AbENm04nWttoWla4okHsAn > QZhTg7Aod+FYHjBsArwsGsKFpKGTtB7YG4VIVQeAFYFaG82VrefC9MPVY3T6fHbQtME8FEFO > CId8HhhWhsArw9IPWDcB1LaB1gaYJ4GYd0CQd6FYHjhsg84PQCwDbh1Eqt1cHsQ7cKIO7BIN > cFYHkhsQ3m03s+GVIaPadn2R6KMxutsaozioKoOhI0w3XukSvY3GKqjYcFolHIu6hslcWGIa > 3iw+nQKqtD5qUY4pTJFEjrhxvaN9t9RqKhA80noiuSUayJnUC6uAzlFQ3Vae/xZhUNib3jli > mckqzkKxRCFXZcdPrBDN+q+9WH6jIfeUenEkfaF/IqzVCzUgn8YJuJRVobpoYhxH7/Dtugl8 > q0P39ZUY5Lju/CK3HBEObHzl2NDGpXe/czwqjqktYhDtvDEfGEEgoNpVuhp5FX7aUyp+N+Ym > B+mlB0Upyun7EfyCrgpDCUUhHFN9jKst2iQ2fSta2CzSMo8MxPB0BKu/wiMdllYx1OIqG5Vx > 5iTz7FSCxqRE12xrsJZxh8zRdSmVh2O9uNJidDlFPiPqhJoYiZAp5lcuQZkwam2yrxY3I27J > qBr+5Spmi4fBfdxrHCj2472miSz/CRc4+io5p/c9oYOkVFSuk/2rBxZ6oXxJHcLmJzcAlRD8 > 3RuuX5Dg08sEw4TgsvIcKUjm9FWW8lz73s0Z/KEKXDVJRZjpnh+PSksqklRbnwOUHT44ixvM > SUFkLfsxuxZxM3lVGzONwHcCTE1keeWWSMGTyC0PBhn/8fPisHRUOXpZOGx8a1NrR0h//MNN > xyZ1WneTlBaa/Dw/MbeioNV9S1OrzsTEczHVISFHCTU0RLmZ057dvMtBnTkpsURvb/SGxjbc > ETWTh+ks0q+hWek1lRnd60MrDfbkdWqyujnqPzZmiCSKPCynZ+Dl8maLxtKS/O+6Ly4m4bYn > CX5Hl7mdJKYvuXzISs8v0X8VdwCZN3Q4JDmpWQV4Ve/EWCBjfRJosgzKn6C4ibP/mmoQRR/L > Nspi7UCyqpEjno3T4Z825Q1/GM6zXn3Tu1k7VZUaH1SjuUZf+5Jv1sjx9IKng+iY6aGChmyY > 9/GsLBrkq6Q3s0FE0RLyg5WSlzkTTH2/7BCPPjsBBKunuSh19+ONcCKJ+ymKX9keRf8R0Sfu > S3Sd3x/DlNLi7/P3ohMX3ErIbskQ93/ml5U4ZJpyyTh+uX/0V1VwFj67d3HKGRHRL3U1yu8p > CGE7XbOjZfusv/skAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBBAAhQQQDQM0EA > EGBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAXEQoKQAAAAAAAAUAAwAAADgAAIAFAAAAsAAAgAYAAADIAACA > DgAAAHABAIAQAAAA4AEAgAAAAABcRCgpAAAAAAAADQABAAAA+AEAgAIAAAAYAgCAAwAAADAC > AIAEAAAASAIAgAUAAABgAgCABgAAAHgCAIAHAAAAkAIAgAgAAACoAgCACQAAAMACAIAKAAAA > 2AIAgAsAAADwAgCADAAAAAgDAIANAAAAIAMAgAAAAABcRCgpAAAAAAEAAABYCQCAOAMAgAAA > AABcRCgpAAAAAAAAEwABDwAAUAMAgAIPAABoAwCAAw8AAIADAIAEDwAAmAMAgAUPAACwAwCA > Bg8AAMgDAIAHDwAA4AMAgAgPAAD4AwCACQ8AABAEAIAKDwAAKAQAgAsPAABABACADA8AAFgE > AIANDwAAcAQAgPkPAACIBACA+g8AAKAEAID7DwAAuAQAgP0PAADQBACA/g8AAOgEAID/DwAA > AAUAgAAAAABcRCgpAAAAAAwAAABkCQCAGAUAgHYJAIAwBQCAfAkAgEgFAICCCQCAYAUAgIgJ > AIB4BQCAjgkAgJAFAICUCQCAqAUAgJoJAIDABQCAoAkAgNgFAICmCQCA8AUAgKwJAIAIBgCA > sgkAgCAGAIAAAAAAXEQoKQAAAAAAAAEAAQAAADgGAIAAAAAAXEQoKQAAAAAAAAIACQQAAGgG > AAAJBAAAeAYAAAAAAABcRCgpAAAAAAAAAQAJBAAAiAYAAAAAAABcRCgpAAAAAAAAAQAJBAAA > mAYAAAAAAABcRCgpAAAAAAAAAQAJBAAAqAYAAAAAAABcRCgpAAAAAAAAAQAJBAAAuAYAAAAA > AABcRCgpAAAAAAAAAQAJBAAAyAYAAAAAAABcRCgpAAAAAAAAAQAJBAAA2AYAAAAAAABcRCgp > AAAAAAAAAQAJBAAA6AYAAAAAAABcRCgpAAAAAAAAAQAJBAAA+AYAAAAAAABcRCgpAAAAAAAA > AQAJBAAACAcAAAAAAABcRCgpAAAAAAAAAQAJBAAAGAcAAAAAAABcRCgpAAAAAAAAAQAJBAAA > KAcAAAAAAABcRCgpAAAAAAAAAQAJBAAAOAcAAAAAAABcRCgpAAAAAAAAAQAAAAAASAcAAAAA > AABcRCgpAAAAAAAAAQAAAAAAWAcAAAAAAABcRCgpAAAAAAAAAQAAAAAAaAcAAAAAAABcRCgp > AAAAAAAAAQAAAAAAeAcAAAAAAABcRCgpAAAAAAAAAQAAAAAAiAcAAAAAAABcRCgpAAAAAAAA > AQAAAAAAmAcAAAAAAABcRCgpAAAAAAAAAQAAAAAAqAcAAAAAAABcRCgpAAAAAAAAAQAAAAAA > uAcAAAAAAABcRCgpAAAAAAAAAQAAAAAAyAcAAAAAAABcRCgpAAAAAAAAAQAAAAAA2AcAAAAA > AABcRCgpAAAAAAAAAQAAAAAA6AcAAAAAAABcRCgpAAAAAAAAAQAAAAAA+AcAAAAAAABcRCgp > AAAAAAAAAQAAAAAACAgAAAAAAABcRCgpAAAAAAAAAQAAAAAAGAgAAAAAAABcRCgpAAAAAAAA > AQAAAAAAKAgAAAAAAABcRCgpAAAAAAAAAQAAAAAAOAgAAAAAAABcRCgpAAAAAAAAAQAAAAAA > SAgAAAAAAABcRCgpAAAAAAAAAQAAAAAAWAgAAAAAAABcRCgpAAAAAAAAAQAAAAAAaAgAAAAA > AABcRCgpAAAAAAAAAQAAAAAAeAgAAAAAAABcRCgpAAAAAAAAAQAJBAAAiAgAAAAAAABcRCgp > AAAAAAAAAQAJBAAAmAgAAAAAAABcRCgpAAAAAAAAAQAJBAAAqAgAAAAAAABcRCgpAAAAAAAA > AQAJBAAAuAgAAAAAAABcRCgpAAAAAAAAAQAJBAAAyAgAAAAAAABcRCgpAAAAAAAAAQAJBAAA > 2AgAAAAAAABcRCgpAAAAAAAAAQAJBAAA6AgAAAAAAABcRCgpAAAAAAAAAQAJBAAA+AgAAAAA > AABcRCgpAAAAAAAAAQAJBAAACAkAAAAAAABcRCgpAAAAAAAAAQAJBAAAGAkAAAAAAABcRCgp > AAAAAAAAAQAJBAAAKAkAAAAAAABcRCgpAAAAAAAAAQAJBAAAOAkAAAAAAABcRCgpAAAAAAAA > AQAAAAAASAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAHAgAoAQAAAAAAAAAAAAAYBgIA > KAEAAAAAAAAAAAAAMAMCAOgCAAAAAAAAAAAAAAgCAgAoAQAAAAAAAAAAAADgAAIAKAEAAAAA > AAAAAAAAuP8BACgBAAAAAAAAAAAAAJD+AQAoAQAAAAAAAAAAAABo/QEAKAEAAAAAAAAAAAAA > QPwBACgBAAAAAAAAAAAAABj7AQAoAQAAAAAAAAAAAADw+QEAKAEAAAAAAAAAAAAAyPgBACgB AAAAAAAAAAAAAKD3AQAoAQAAAAAAAAAAAAC49AEA6AIAAAAAAAAAAAAAaK0BAAoBAAAAAAAA > AAAAAHSuAQCoAwAAAAAAAAAAAAAcsgEASAMAAAAAAAAAAAAAZLUBAKwDAAAAAAAAAAAAABC5 > AQDiAwAAAAAAAAAAAAD0vAEANAIAAAAAAAAAAAAAKL8BANoCAAAAAAAAAAAAAATCAQD6AgAA > AAAAAAAAAAAAxQEAAgIAAAAAAAAAAAAABMcBAMgAAAAAAAAAAAAAAMzHAQDsAQAAAAAAAAAA > AAC4yQEAegIAAAAAAAAAAAAANMwBAKoDAAAAAAAAAAAAAODPAQB+AAAAAAAAAAAAAABg0AEA > 8gIAAAAAAAAAAAAAVNMBAAwDAAAAAAAAAAAAAGDWAQDOAgAAAAAAAAAAAAAw2QEAaAAAAAAA > AAAAAAAAmNkBALQAAAAAAAAAAAAAAEzaAQCuAAAAAAAAAAAAAACU9AEAIgAAAAAAAAAAAAAA > gPQBABQAAAAAAAAAAAAAAGz0AQAUAAAAAAAAAAAAAABY9AEAFAAAAAAAAAAAAAAARPQBABQA > AAAAAAAAAAAAADD0AQAUAAAAAAAAAAAAAAAc9AEAFAAAAAAAAAAAAAAACPQBABQAAAAAAAAA > AAAAAPTzAQAUAAAAAAAAAAAAAADg8wEAFAAAAAAAAAAAAAAAzPMBABQAAAAAAAAAAAAAALjz > AQAUAAAAAAAAAAAAAABA8QEAeAIAAAAAAAAAAAAABQBBAEIATwBVAFQACABNAEEASQBOAEkA > QwBPAE4AAgBaADAAAgBaADEAAgBaADIAAgBaADMAAgBaADQAAgBaADUAAgBaADYAAgBaADcA > AgBaADgAAgBaADkAAgBaAEwAGDsrsZGhgAAqN/sIQJJkySEhGTrgTvDIoSZl6rKqlbJCTJMy > dVCdFbVdD6AN2MbaG2GEV0Yr8Buyq3bbvvwm6LqvyXJLlxehasUDMyzJotkwuqzXXJbVCSxI > 6UJAKpIMQOQLMY4EntjOjT6Qaw7JsYNQZIIbAaGAxQGxrDo2lAH6szDBpSQfqqso9FVp9/+x > 05znnOec5/6+8aNnPy/LxfvAcfPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LPhZ8LP > 8fb8jr+X1eTOYHaLfmB+OVNcAcAqAyAwB6BtoonGBIG6A/gLywdY6fuhuQGgKRu5hJ6DlmgJ > 0HL3u5BL3KnqzYB4PW9b7gPrg2oONkJc6QGUB+EHAAQ9fdni9TtLxvme394H3wawGXjSI9UG > 4B6fsOUbvZ/AhF5XU0udgh4UQkJIUQSFv+PEUcoFF97eY971r90H4p3D/fsz04M0IsVpPoyL > xRI8BSPOQ01JiTivPVdzsQf2uf47GDQ9IzE+WTGzQTmgtEFDkrmU1YxPLSF5wQ4KfWLFeQdj > kKFrQx/DgmqTNGaFoCKgpOgpXQ02iNFqoAsjgQjaqaOkF0Cz5tOdqI2QP1YglXmrVGE5wpGL > q10YD+XBxj4DfB/ztxYQvtGoeosliTR3EJ8oXpzsDAIoyERnp9rmFIQ+CKsvnZDonXWd6auH > dhDNJ7uU7Q1Qk/JKNUsTcSCrc0tt1UukPlui93gSNHeRJIrfqg6lfUfHgG1mwYmOIVrk1q8Z > DqKunywCWViUeSVaOSpBRVGUKotmAXRhMSFWAWYsTSBQ/P3S0XrqorSVQVQ2ELxabA9EtL8M > Bu4yHVNhWk76i9VSkFOMi0uRS+Kd34gouoes4sNY9El3IaWwwag3eTIgJY49LUCIO0vKRbvK > pfwO0gVxMpVPoFVb0YzHGWWESi+Kujk/5UlnFstpacBghlXEMGHO530CyqMR7kO56RlpCVIy > 7nZmUzKo2PdsbtmmTdqNXefOUfSkTP9wda+D7v7y7E1ZmuNKGdBr7k9tdpZEnmCfNXuRXgcM > TJD0Vx36Lv8M6/3KSw+DnTZdKEzNf1cNVNtE0YnNHdzJobq3gRC9INSWSctAO8NG/nShZXFp > WMXKmaOwX+c/3VWuyTU1fz2DQTri9ruLMgQD6VJa1wjegw7KKMMaOonihq19SXNCMc20NN2q > XF2Xo4uX2FsjLstOrvOKWWTft3bH0pREMcay0+bOJJB80pKWNo2JUWprq1Mge13NB7JmUpwg > XWYIMT+3U8TaJfXpqWuUZO0dFGB+qj67xNLcJAEY3l8GrvEFHE2oRnm2TIxZHzzeX0Own3e4 > Tbn1Umgathm2kj5dunAWJ2fS3DmSY53O2rqrhlVjV6rGWHB3VC9XwzmYPt7QkrEv0Bvq6soG > RlJsmRy65Z4GNWg1CQcFoUsOIxNVyv1bZNO2hq2GC6yOGyt2r2y6C29Sx8SnZ3BofunT/U1Z > G2dDujnqWjlv0iYlTzIN6IIKsHntEPUGRYcnAaTNwhA0mVAHhPKduMMucKKMiQODu5zQUF6E > hDRRnwHGfgG1dvlMsn7qy2ZFhp2/9mPUYIG6ETDEHQdi8XVlVPE0V7PNQGg0BRZZg7NFhbot > 1ms/mb7JSW7cKyWBYXsWzyB4U/TWhOmJ3KUA9Q+acn11rq18ZubfVB6KJl6XbRKoB60QRzCr > JO30Gtx4bTNYpxW2017KX5xqJRQaN59wX1ab+nDR3MKKUn0fl8szeERFBF51hGwTH7cX57bp > J3ZV85crPIJmsTaaS3ULeBJ+EfvMpIieLj1xgb4NbARtakuh2rVX7PCAVAwlEZAKOPcnzDbZ > V3VBwint5uDqzKJ0fX6izVsmUBh92SmUVWQ8QRslTgHzbZEGnB9ZYdcuWVV5zNWzlYtLbT3q > +Kz4ukVtPCBNd6bF5cI5obqXFJ2D4M7muumx2r4sIXz2p9cTPg3K5Q2F8Z9JmyjoDC9xBatx > 4vS4yw+1ESLPjBmWGuQzPvfUHw0bWLZz+E2LCN3CaG0atNQ5o8DUvXBEfiYUSo0QEpLOT7Ft > jD4EQ0tgV01ohewazorQZGrr/7NCMHs2rUsHzmECsjiJ+kEDrQ2283F4GY0LNwolSMTZ4Rdy > QQQbRiUW6oAUrmaIKnkzIfDla/lHo8LX8LSWJCvo+K1tTEbdl1Yc1UD9agi3CybYi6IdkJij > FNHqBxykc8QyRk6NmHkVoLmJuRFs0pVl1vqgKzsLMMhJ6RUjCsfCDUKfJOIJrnL4UvxLijKM > DT6PfOTWxPqdcEDhIhli2QV4BNOw4HuGqQIVQsg/IDs7lmgfSeJ5Ogdpc1azH++2a18n2bu2 > aLWZcVjKOaHb0qw4PcRYEThnKyl0ii6M2KH1xcKHigLRgQFKYrz5u7hgW8LmbCkO6/ldscfs > Se1m5azMLUEfCOTMlrzoKagqivMCNF1wh1odRkvZxc0G49uJZFoMN9E59V8usreXjIxqh7Ef > PWB3YYVbfDqYtaOFPRV9NiqnhLnocUzRbiYRd3Cx2aCUCNjfRBILswy66JHzCbCnjhejC+Z3 > 4Ib4VGVRQVTMalAWXWK626nn/2XQG+WBSllbObRT9lUXwqjhR4dHDiaJMdhNCaAQEXM4T6I+ > 420B2R98e0IhGEcqCExCIV0Ya+wDPx4XLx2WNWxVl1LRr6HM23gk03tyedvI15w+9OTSVgyJ > HgBUvNr4DB4GCbx426VdEcBKvuKoDkngqin2lJkr1wJTd1XVWwpQk+XRKLMqZMGpFhYnvqWO > tvhWR7+KZt6vBXBufxPjcSrEoxuHq2ASJ9MTjym4GUrhvkZTBESw8V65N8FX+qAMF1dGE24D > zcELf3pleXL7aTqNL/bOUSg7Q4c64ZzwtzSkYjv4Sh8Le4GhZRMGytJjDU614HavGcix+nEk > /mp+IfPn71ge+3zhymLnfFmn2J0zc20JghWe9bRleCYX2RaumFATqiN2geeDdt7evrJn9qf4 > ld05WoF8dufMD3rO2xEu+p/mhH5jVNa6GdzHPpPVysKJEw51lm0/Bw5T4vDZaOTphLpJMNr+ > qpGuVnMkzTro6bW/6D+4u9J8JCzEVr418GxwNBs+5u9IHp98vbY8G4/1dd4WsAF+NATIHCym > tYV9vRIgzZ9ZABz2NsrSB4u2QYYdlYUSomGTIbBgnsNSVKdceHjC07o2wuhdFhQZj5ZN0G4c > RWRax00XYLkBh3W1+uDitvFGfKPC4n19cox/DE1MWxnvBHDKgqNn2hk8TiaDdrtlf0j/iHRk > /o1SOMmJ2ZqwDCBrICp3awIXj0LSuhrrMI9BVXsY62NxZsbmgj6803tgl2uGPaZLWIsTrfS/ > GPHioa21riSG7r1yNo+ICscZs9NcWkZ4usb1bUWu/1waXX2piBFcUp9h3jTW2DrHOuF4cfvo > qDGno4cca41IdgoBdocMHq62nvBizwFYWGx241/JVNr5ptaif6FwdkRNTdlsfkWzyj3azpls > wJwnN5bNDNtHmzAnAPNQ+zQpGrHJ4zcvaJcWuh7cA2H5L/oGWixfKHXRmK1ej/yqod2dyd5X > Hk38hGV1c29b82SEAvurGM6fhek4E00dsyhUxtMN/rrrb9S0ydW4gWKsQWAxq9NtcWgIs0ge > U0Y7zYhU9ijA+wpTs8HepsSY6GztS8vfLOUqasENQx4I2ZqQ+Qxjv4muWse/2MBMRgJzLlBD > xZZM9pjyvnJv/ItObLy/EjI3u5lJKyziJc1ca+SPfCZnkPMjUTsQ67lsU6TLZexmRNDGG4lR > mshTscJMFplUw3YzGDEyfno6dmozlPz/9dBrnFSzCjQPOxqQNlo6EKRxxl9xGlNM4ebrxBZT > YvI+XSos1T+clInkWqPVXI2eGzLNNsXO+74WznaP48rMptSytQcXE6T7Isv5qc8dXzntS+1j > EazBuZqJIopL51oDegD6DdQyLCtVT3ZwMUKYkFJ9aDH6gEUlGPD8/8SCpJrQzRQ6DouCHu2P > Ybi7rg1PcUT+3ODcVIR1xnIHpH7GrZS0HRG2P+h1waHkWGN0+v8ombMRA8J+PhEbhPpDrL0J > 4zIjtxnShUzi1U60ExlJZzoPKnHNIC6FKMbI+w//0PkEOSSE+VBZNIaqDN9YdO20rIrqkiba > SyS7hr+2kdT623UXKt3Ew8RvldyQSMbk7yK00VhDJdakIdFKdCSHTsEXkXJ9hinPWdZ7Vdns > lQGmTQKbb9fHz4WfCz4WfCwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AACQYOhyBQAA6zOH25AAUEEACFBBANAzQQAQYEEAAAAAAAAAAAAA4AEAAABAAABAAQAAAAAA > AAAAAABwAQC7MDlEAAPdK51UOUQAg72MR0QAAImdjEdEAA+FgQQAAI2FlEdEAFD/laBIRACJ > hZBHRACL+I2doUdEAFNQ/5WcSEQAiYXpOUQAjZ2uR0QAU1f/lZxIRACJhe05RACNhf46RAD/ > 4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1BcBAAAAAAAA > AAAAAAAAAAAAEAAAAAoBAAAgAQAAAgAAAEABAAAMAAC4mQEASEYAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACLnWA5RAAL23QKiwOHhWQ5RACJA421 > DjpEAIM+AA+EHwEAAI21DjpEAGoEaAAQAABoABgAAGoA/5XpOUQAiYXlOUQAi0YEBQ4BAABq > BGgAEAAAUGoA/5XpOUQAiYXhOUQAVoseA52MR0QA/7XlOUQA/3YEUFPoOwMAAIC9BTpEAAB1 > Xv6FBTpEAIs+A72MR0QA/zfGB8P/148HUFFWU4vIg+kGi7XhOUQAM9sLyXQueCysPOh0CusA > POl0BENJ6+uLBusAgD4GdfMkAMHAGCvDiQaDwwWDxgSD6QXrzlteWViLyIs+A72MR0QAi7Xh > OUQAwfkC86WLyIPhA/OkXmgAgAAAagD/teE5RAD/le05RACDxgiDPgAPhSb///9oAIAAAGoA > /7XlOUQA/5XtOUQAi51gOUQAC9t0CIsDh4VkOUQAi5WMR0QAi4VYOUQAK9B0eYvCwegQM9uL > tWg5RAADtYxHRACDPgB0YYtOBIPpCNHpiz4DvYxHRACDxghmix7B6wyD+wF0DIP7AnQWg/sD > dCDrLGaLHoHj/w8AAGYBBB/rHWaLHoHj/w8AAGYBFB/rDmaLHoHj/w8AAAEUH+sAZoMO/4PG > AuK065qLlYxHRACLtdU5RAAL9nQRA/KtC8B0CgPCi/hmrWar6/GLtVw5RACLlYxHRAAD8otG > DIXAD4QKAQAAA8KL2FD/laBIRACFwHUHU/+VpEhEAImF2TlEAMeF3TlEAAAAAACLlYxHRACL > BoXAdQOLRhADwgOF3TlEAIsYi34QA/oDvd05RACF2w+EogAAAPfDAAAAgHUEA9pDQ1OB4/// > /39T/7XZOUQA/5WcSEQAhcBbdW/3wwAAAIB1GVeLRgwDhYxHRABQU42FB0hEAFBX6ZkAAACB > 4////3+LhZBHRAA5hdk5RAB1JFeL00rB4gKLndk5RACLezyLfDt4A1w7HIsEEwOF2TlEAF/r > FleLRgwDhYxHRABQU42FWEhEAFBX60uJB4OF3TlEAATpMv///4kGiUYMiUYQg8YUi5WMR0QA > 6ev+//+Lhf05RABQA4WMR0QAWQvJiYUvPkQAYXUIuAEAAADCDABoAAAAAMOLhZBHRACNjclH > RABRUP+VnEhEAImF9TlEAI2F2UdEAFD/laRIRACJhdVHRACNjeRHRABRUP+VnEhEAImF+TlE > AIuF1UdEAI2N8EdEAFFQ/5WcSEQA/9CDxBBfajCNnfpHRABTV2oA/5X5OUQAav//lfU5RACL > LCSB7Tc5RADDi0QkEIHsVAMAAI1MJARQ6KgDAACLjCRcAwAAi5QkWAMAAFFSjUwkDOgNBAAA > hMB1CoPI/4HEVAMAAMOLjCRgAwAAjQQkUFGNTCQM6OgFAACEwHUKg8j/gcRUAwAAw4sEJIHE > VAMAAMIQAAABAgMEBQYHCAoMDhAUGBwgKDA4QFBgcICgwOAAAAAAAAAAAAEBAQECAgICAwMD > AwQEBAQFBQUFAAAAAAEBAgIDAwQEBQUGBgcHCAgJCQoKCwsMDA0NDg4PDxAQERERERERERER > ERERERESEhISEhISElGL0Va5CAAAAFc5SgRyNVO++P///4sCihhAiFwkDIkCi0IIi3wkDMHg > CIHn/wAAAAvHi3oEA/6JQgiLx4l6BDvBc9Jbi3IEi0IIi3wkECvO0+i5GAAAACvPJf///wDT > 6AP3X4lyBF5ZwgQAi0QkBItUJAiJgYQAAACJkYgAAACNBIKJgYwAAAAFAAEAAMIIAIHsmAAA > AFNVVovRV7kPAAAAi6qEAAAAM8CNfCQsM/bzq4u8JKwAAAA77olUJCB2FTPJigw4i1yMKI1M > jChDQDvFiRly67kXAAAAiXQkKIlyBIlyRIl0JGgz/4l0JBzHRCQQAQAAAIlMJBiNagiJdCQU > i0Q0LNPgA/iB/wAAAAGJfCQkD4eOAAAAi0Q0KIl9AItdPAPDg/kQiUVAiUQ0bHxNi3UAi0Qk > EItcJByLuowAAADB7hCLziX/AAAAK8sD+4rYi9GK+4l0JByLw4t0JBTB4BBmi8PB6QLzq4vK > i1QkIIPhA/Oqi3wkJItMJBiLRCQQg8YEQEmDxQSD+QmJRCQQiUwkGIl0JBQPjWL///+B/wAA > AAF0D19eXTLAW4HEmAAAAMIEAIuChAAAADPJhcB2O4u0JKwAAACKBDGEwHQii7qIAAAAJf8A > AACLRIRoiQyHM8CKBDGLfIRojUSEaEeJOIuChAAAAEE7yHLMX15dsAFbgcSYAAAAwgQAUVNW > i/FXiwaDeAQIcjCLCIoRQYhUJAyJCItICItUJAzB4QiB4v8AAAALyotQBIPC+IlICIvKiVAE > g/kIc9CLUASLQAi5CAAAACvK0+iLTiQlAP7/ADvBcxSLlowAAACLyMHpEDPbihwRi9PrOztG > LHMKO0YoG9KDwgrrLDtGMHMHugsAAADrIDtGNHMHugwAAADrFDtGOHMHug0AAADrCDtGPBvS > g8IPiw6LeQQD+ol5BIsclrkYAAAAK8Mryl/T6ItMlkQDwYuOiAAAAF5biwSBWcNTVleL+TPS > M8CNt2gCAACJFlboVwIAAIqMMFU/RABeuwEAAACDxgTT4wPTQIP4OnLei0QkEI1PEFBo0QIA > AOhI/f//UGocjY+gAAAA6Dr9//9QagiNjzABAADoLP3//1BqE42PwAEAAOge/f//iYdgAgAA > X14F9QIAAFvCBACLRCQIi9GLTCQEV4kCjUIEiQjHQAQgAAAAiUIQiYKgAAAAiYIwAQAAiYLA > AQAAM8C5vQAAAImCUAIAAImCVAIAAImCWAIAAIu6YAIAAImCXAIAAPOri8qq6AQAAABfwggA > gewMAwAAU4vZVVaNawRXagGLzegp/P//hcB1Dou7YAIAALm9AAAA86uqM/ZqBIvN6Az8//+I > RDQQRoP+E3LtjbvAAQAAjUQkEFCLz+iA/P//hMB1C19eXVuBxAwDAADDM/aLz+jk/f//g/gQ > cxWLi2ACAACKFDEC0IDiD4hUNCRG62B1KGoCi83os/v//4PAA4XAfk6B/vUCAAB9UopMNCNI > iEw0JEaFwH/q6zaD+BF1DmoDi83ohvv//4PAA+sMageLzeh4+///g8ALhcB+E4H+9QIAAH0X > xkQ0JABGSIXAf+2B/vUCAAAPjHP///+NVCQkjUsQUujV+///hMB1C19eXVuBxAwDAADDjYQk > 9QIAAI2LoAAAAFDos/v//4TAdQtfXl1bgcQMAwAAw42MJBEDAABRjYswAQAA6JH7//+EwHUL > X15dW4HEDAMAAMPGg2QCAAAAM8CAvAQRAwAAA3UIQIP4CHLw6wfGg2QCAAABi7tgAgAAjXQk > JLn1AgAA86RfXl2wAVuBxAwDAADD6AEAAACQXoHu4kREAMOD7BSLRCQcU1VWxwAAAAAAi0Qk > JFcz/4XAi/GJfCQQD4ZbAgAAjU4Q6IP8//89AAEAAHMTiw6IAYsOQUeJDol8JBDpKQIAAD3Q > AgAAD4MTAgAABQD///+L6IPgB8HtA41QAoP4B4lUJBQPhZQAAACNjqAAAADoNvz//4tOCDPb > Vuht////ipwwOT9EAF6D+QhyMotOBIoRQYhUJBiJTgSLTgyLVCQYweEIgeL/AAAAC8qLVgiD > wviJTgyLyolWCIP5CHPOi34Ii1YMuQgAAAArzwP70+q5GAAAAIl+CCvLgeL///8A0+ozyVbo > A////4qMMB0/RABei0QkFAPKA8GJRCQUioZkAgAAi5yuaAIAADPSVuja/v//ipQ1VT9EAF6E > wIv6dHaD/wNycYtGCI1v/YP4CHIxi0YEi1YMweIIighAiEwkHItOCIlGBItEJBwl/wAAAIPB > +AvQi8GD+AiJVgyJTghzz4tGCIt+DLkIAAAAK8gDxdPvuRgAAACJRggrzYHn////ANPvjY4w > AQAA6Bv7//8Dw40c+Otbg34ICHIxi0YEi1YMweIIighAiEwkIItOCIlGBItEJCAl/wAAAIPB > +AvQi8GD+AiJVgyJTghzz4tWCItGDLkIAAAAK8oD19PouRgAAACJVggrzyX///8A0+gD2IP7 > A3Mai4yeUAIAAIXbdDCLllACAACJlJ5QAgAA6xuLhlQCAACLllACAACNS/2JhlgCAACJllQC > AACJjlACAACLBot8JBRBjRQ4O8KJFnMQi9Ar0UCKEohQ/4sWO8Jy8ItEJBADx4lEJBCL+OsL > i87o9/v//4TAdBw7fCQoD4Kr/f//i0QkLIk4X15dsAFbg8QUwggAX15dMsBbg8QUwggAkAAA > AAAIAAAAAAAAAAAAAABrZXJuZWwzMi5kbGwAVmlydHVhbEFsbG9jAFZpcnR1YWxGcmVlAFZp > cnR1YWxQcm90ZWN0AEV4aXRQcm9jZXNzAAAAAAB1c2VyMzIuZGxsAE1lc3NhZ2VCb3hBAHdz > cHJpbnRmQQBMT0FERVIgRVJST1IAVGhlIHByb2NlZHVyZSBlbnRyeSBwb2ludCAlcyBjb3Vs > ZCBub3QgYmUgbG9jYXRlZCBpbiB0aGUgZHluYW1pYyBsaW5rIGxpYnJhcnkgJXMAVGhlIG9y > ZGluYWwgJXUgY291bGQgbm90IGJlIGxvY2F0ZWQgaW4gdGhlIGR5bmFtaWMgbGluayBsaWJy > YXJ5ICVzAJCJ7wEAmu8BAK3vAQAAAAAAa2VybmVsMzIuZGxsAAAAR2V0UHJvY0FkZHJlc3MA > AABHZXRNb2R1bGVIYW5kbGVBAAAATG9hZExpYnJhcnlBAAAAAAAAAAAAAAAAAHzvAQBs7wEA > AAAAAAAAAAAAAAAAXPABAKLwAQAAAAAAAAAAAAAAAABn8AEAqvABAAAAAAAAAAAAAAAAAHTw > AQCy8AEAAAAAAAAAAAAAAAAAgfABALrwAQAAAAAAAAAAAAAAAACL8AEAwvABAAAAAAAAAAAA > AAAAAJbwAQDK8AEAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c2VyMzIuZGxsAG9sZWF1dDMyLmRs > bABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAHVzZXIzMi5kbGwAc2hlbGwzMi5kbGwA0vABAAAA > AADg8AEAAAAAAPbwAQAAAAAAB/EBAAAAAAAY8QEAAAAAACvxAQAAAAAAAABNZXNzYWdlQm94 > QQAAAFZhcmlhbnRDaGFuZ2VUeXBlRXgAAABSZWdTZXRWYWx1ZUV4QQAAAEdldFN0b2NrT2Jq > ZWN0AAAAVHJhbnNsYXRlTWVzc2FnZQAAAFNoZWxsX05vdGlmeUljb25BAAB4AjQAAABWAFMA > XwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQALAAQAGAABABgAAQAAAAAA > AAAAAAAAAAAEAAQAAQAAAAAAAAAAAAAAAAAAANYBAAAAAFMAdAByAGkAbgBnAEYAaQBsAGUA > SQBuAGYAbwAAALIBAAAAADAANAAwADkAMAA0AEUANAAAAD4ADwABAEMAbwBtAHAAYQBuAHkA > TgBhAG0AZQAAAAAARQBuAFQAZQBjAGgAIABUAGEAaQB3AGEAbgAAAAAAAAA6AAkAAQBGAGkA > bABlAEQAZQBzAGMAcgBpAHAAdABpAG8AbgAAAAAATQB1AGwAdABpAFIAZQBzAAAAAAA4AAwA > AQBGAGkAbABlAFYAZQByAHMAaQBvAG4AAAAAADQALgAxADEALgAwADEALgAyADYAAAAAADIA > CQABAEkAbgB0AGUAcgBuAGEAbABOAGEAbQBlAAAATQB1AGwAdABpAFIAZQBzAAAAAABuACUA > AQBMAGUAZwBhAGwAQwBvAHAAeQByAGkAZwBoAHQAAABDAG8AcAB5AHIAaQBnAGgAdAAgAKkA > IABFAG4AVABlAGMAaAAgAFQAYQBpAHcAYQBuACAAMQA5ADkANQAtADIAMAAwADAAAAAAAAAA > QgANAAEATwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0AZQAAAG0AdQBsAHQAaQByAGUA > cwAuAGUAeABlAAAAAABEAAAAAABWAGEAcgBGAGkAbABlAEkAbgBmAG8AAAAAACQABAAAAFQA > cgBhAG4AcwBsAGEAdABpAG8AbgAAAAAACQTkBAAAAQABACAgEAABAAQA6AIAAA0AAAABAAEA > EBAQAAEABAAoAQAAAwAAAAEAAQAQEBAAAQAEACgBAAAEAAAAAQABABAQEAABAAQAKAEAAAUA > AAABAAEAEBAQAAEABAAoAQAABgAAAAEAAQAQEBAAAQAEACgBAAAHAAAAAQABABAQEAABAAQA > KAEAAAgAAAABAAEAEBAQAAEABAAoAQAACQAAAAEAAQAQEBAAAQAEACgBAAAKAAAAAQABABAQ > EAABAAQAKAEAAAsAAAABAAEAEBAQAAEABAAoAQAADAAAAAEAAgAQEBAAAQAEACgBAAABACAg > EAABAAQA6AIAAAIAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A > /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAH//////93iAAAAAAAAACP/3d3h3d3dwAI > AAAAAAAAj///eDB3d3GZkAAAAAAAAAiHd4uzB3dx+ZAAAAAAAAAACIO7sDB3gfmQAAAAAAAA > AAAAOzuzCAH5kAAAAAAAAAAAAAO7sDAB+ZAAAAAACIiIiIiIO7uzAfmQiIAAAAj3d3d3d3O7 > sDD5kHeIAAAI9///////OzuzCZD3iIAACPdEREREREO7sDCQ94iAAAj3BmZmZmZmO7uzAPeI > gAAI9wZmZmZmZmO7sDD3iIAACPcGZmZmZmZmOzuzB4iAAAj3BmZmZmZmZmO7sDCIgAAI9wZm > ZmZmZmZhO7uzCIAACPcGZmZmZmZmYfO7sDCAAAj3Bp5mZmZmZmH3OzuzAAAI9wbpZmZmZmZh > 95O7sDAACPcGZmZmZmZmYXeQOzuzAAj3BmZmZmZmZmEREPO7sDAI9wbaZmZmZmZh9VD3OzMA > CPcGrWZmZmZmZgAE94MwAAj3BmZmZmZmZmM4MPeIMAAI9wAAAAAAAAAKs4D3iIAACPeIiIiI > iIiIiqgw94iAAAj3d3d3d3d3d3qrB3eIgAAAj///////////qg//iIAAAAh3d3d3d3d3d3p3 > d/iAAAAAh3d3d3d3d3d6d3d/gAAAAAiIiIiIiIiIiIiIiIAA/gAD//gAAP/wAAB/8AAAf/gA > AP/+AAD//8AA/8AAAB+AAAAPgAAAB4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA4AAAAOAAAAD > gAAAA4AAAAOAAAABgAAAAIAAAAGAAAADgAAAA4AAAAOAAAADgAAAA8AAAAPgAAAD8AAAA/gA > AAcoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAA > AICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAA > AAAAAAAACP93d3gYAAAAiPcIeZEAAAAAg7CJcQAAAAAAOwlxAACHd3dzsHF4AI9EREQ7AXgA > jwZmZmOwiACPBmZmaTsIAI8GZmZpc7AAjwamZmmaCwCPBmZmZgB4sI8AAAACuHgAj/////q/ > eAAId3d3d6f4AACIiIiIiIgAwA8AAIAHAADABwAA8AcAAIATAAAAAQAAAAEAAAABAAAAAQAA > AAEAAAABAAAAAQAAAAEAAAABAACAAQAAwAMAACgAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8A > AP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAI/3d3eBgAAACI9wh5kQAAAACDsIlx > AAAAAAA7CXEAAId3d3OwcXgAj0RERDsBeACPBv//Y7CIAI8Gb/ZpOwgAjwZv9mlzsACPBv/2 > aZoLAI8Gb/ZmAHiwjwAAAAK4eACP////+r94AAh3d3d3p/gAAIiIiIiIiADADwAAgAcAAMAH > AADwBwAAgBMAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAIABAADAAwAA > KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACA > gACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAA > AAAAAAj/d3d4GAAAAIj3CHmRAAAAAIOwiXEAAAAAADsJcQAAh3d3c7BxeACPREREOwF4AI8E > //9jsIgAjwT/b2k7CACPBE/2aXOwAI8ERP9pmgsAjwT/9mYAeLCPAAAAArh4AI/////6v3gA > CHd3d3en+AAAiIiIiIiIAMAPAACABwAAwAcAAPAHAACAEwAAAAEAAAABAAAAAQAAAAEAAAAB > AAAAAQAAAAEAAAABAAAAAQAAgAEAAMADAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/ > AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAACP93d3gYAAAAiPcIeZEAAAAAg7CJcQAA > AAAAOwlxAACHd3dzsHF4AI9VVVU7AXgAjwX//1OwiACPBVVfWTsIAI8FX/9Zc7AAjwVVX1ma > CwCPBf//VQB4sI8AAAACuHgAj/////q/eAAId3d3d6f4AACIiIiIiIgAwA8AAIAHAADABwAA > 8AcAAIATAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAACAAQAAwAMAACgA > AAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA > gAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAA > AAAI/3d3eBgAAACI9wh5kQAAAACDsIlxAAAAAAA7CXEAAId3d3OwcXgAjwERETsBeACPARHx > E7CIAI8B//8ZOwgAjwHx8RlzsACPAR/xGZoLAI8BEfERAHiwjwAAAAK4eACP////+r94AAh3 > d3d3p/gAAIiIiIiIiADADwAAgAcAAMAHAADwBwAAgBMAAAABAAAAAQAAAAEAAAABAAAAAQAA > AAEAAAABAAAAAQAAAAEAAIABAADAAwAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA > AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAj/d3d4GAAAAIj3CHmRAAAAAIOwiXEAAAAA > ADsJcQAAh3d3c7BxeACPAiIiOwF4AI8C//8jsIgAjwIiLyk7CACPAv//KXOwAI8C8iIpmgsA > jwL//yIAeLCPAAAAArh4AI/////6v3gACHd3d3en+AAAiIiIiIiIAMAPAACABwAAwAcAAPAH > AACAEwAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAgAEAAMADAAAoAAAA > EAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAA > AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAA > CP93d3gYAAAAiPcIeZEAAAAAg7CJcQAAAAAAOwlxAACHd3dzsHF4AI8GZmY7AXgAjwb//2Ow > iACPBvZvaTsIAI8G//9pc7AAjwb2ZmmaCwCPBv//ZgB4sI8AAAAGuHgAj/////q/eAAId3d3 > d6f4AACIiIiIiIgAwA8AAIAHAADABwAA8AcAAIATAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB > AAAAAQAAAAEAAAABAACAAQAAwAMAACgAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD/ > /wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAI/3d3eBgAAACI9wh5kQAAAACDsIlxAAAAAAA7 > CXEAAId3d3OwcXgAjwERETsBeACPAR/xE7CIAI8BEfEZOwgAjwER/xlzsACPAfEfGZoLAI8B > //8RAHiwjwAAAAG4eACP////+r94AAh3d3d3p/gAAIiIiIiIiADADwAAgAcAAMAHAADwBwAA > gBMAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAIABAADAAwAAKAAAABAA > AAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAA > gACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAj/ > d3d4GAAAAIj3CHmRAAAAAIOwiXEAAAAAADsJcQAAh3d3c7BxeACPAREROwF4AI8B//8TsIgA > jwHxHxk7CACPAf//GXOwAI8B8R8ZmgsAjwH//xEAeLCPAAAAAbh4AI/////6v3gACHd3d3en > +AAAiIiIiIiIAMAPAACABwAAwAcAAPAHAACAEwAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAA > AAEAAAABAAAAAQAAgAEAAMADAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A > /wAAAP8A/wD//wAA////AAAAAAAAAAAACP93d3gYAAAAiPcIeZEAAAAAg7CJcQAAAAAAOwlx > AACHd3dzsHF4AI8EREQ7AXgAjwT//0OwiACPBERPSTsIAI8E//9Jc7AAjwT0T0maCwCPBP// > RAB4sI8AAAAEuHgAj/////q/eAAId3d3d6f4AACIiIiIiIgAwA8AAIAHAADABwAA8AcAAIAT > AAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAACAAQAAwAMAACgAAAAgAAAA > QAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAA > gACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAA > AAAAAAAAAAf//////3eIAAAAAAAAAI//d3eHd3d3AAgAAAAAAACP//94MHd3cZmQAAAAAAAA > CId3i7MHd3H5kAAAAAAAAAAIg7uwMHeB+ZAAAAAAAAAAAAA7O7MIAfmQAAAAAAAAAAAAA7uw > MAH5kAAAAAAIiIiIiIg7u7MB+ZCIgAAACPd3d3d3c7uwMPmQd4gAAAj3//////87O7MJkPeI > gAAI90REREREQ7uwMJD3iIAACPcGZmZmZmY7u7MA94iAAAj3BmZmZmZmY7uwMPeIgAAI9wZm > ZmZmZmY7O7MHiIAACPcGZmZmZmZmY7uwMIiAAAj3BmZmZmZmZmE7u7MIgAAI9wZmZmZmZmZh > 87uwMIAACPcGnmZmZmZmYfc7O7MAAAj3BulmZmZmZmH3k7uwMAAI9wZmZmZmZmZhd5A7O7MA > CPcGZmZmZmZmYREQ87uwMAj3BtpmZmZmZmH1UPc7MwAI9watZmZmZmZmAAT3gzAACPcGZmZm > ZmZmYzgw94gwAAj3AAAAAAAAAAqzgPeIgAAI94iIiIiIiIiKqDD3iIAACPd3d3d3d3d3eqsH > d4iAAACP//////////+qD/+IgAAACHd3d3d3d3d3end3+IAAAACHd3d3d3d3d3p3d3+AAAAA > CIiIiIiIiIiIiIiIgAD+AAP/+AAA//AAAH/wAAB/+AAA//4AAP//wAD/wAAAH4AAAA+AAAAH > gAAAA4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA4AAAAGAAAAAgAAAAYAA > AAOAAAADgAAAA4AAAAOAAAADwAAAA+AAAAPwAAAD+AAABygAAAAQAAAAIAAAAAEABAAAAAAA > wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICA > gAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAI/3d3eBgAAACI9wh5kQAA > AACDsIlxAAAAAAA7CXEAAId3d3OwcXgAj0RERDsBeACPBmZmY7CIAI8GZmZpOwgAjwZmZmlz > sACPBqZmaZoLAI8GZmZmAHiwjwAAAAK4eACP////+r94AAh3d3d3p/gAAIiIiIiIiADADwAA > gAcAAMAHAADwBwAAgBMAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAIAB > AADAAwAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA > AIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP// > /wAAAAAAAAAAAAj/d3d4GAAAAIj3CHmRAAAAAIOwiXEAAAAAADsJcQAAh3d3c7BxeACPRERE > OwF4AI8GZmZjsIgAjwZmZmk7CACPBmZmaXOwAI8GpmZpmgsAjwZmZmYAeLCPAAAAArh4AI// > ///6v3gACHd3d3en+AAAiIiIiIiIAMAPAACABwAAwAcAAPAHAACAEwAAAAEAAAABAAAAAQAA > AAEAAAABAAAAAQAAAAEAAAABAAAAAQAAgAEAAMADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAA= > > --part1_f8.65bd20b.278a2f74_boundary-- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 0: 5: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 8E41937B402 for ; Mon, 8 Jan 2001 00:04:43 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 14FXIL-0008Op-00 for hackers@freebsd.org; Mon, 08 Jan 2001 10:04:45 +0200 Date: Mon, 8 Jan 2001 10:04:44 +0200 (IST) From: Roman Shterenzon To: Subject: Re: Ideas? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] ---------- Forwarded message ---------- Date: Sun, 7 Jan 2001 18:36:05 -0800 Subject: Re: Ideas? * Roman Shterenzon [010107 10:24] wrote: > Hi, > > Could you please take a look at : > http://www.freebsd.org/cgi/query-pr.cgi?pr=24019 > It's my friend's PR. Can you give me some hints on how can I debug this > issue. I'm completely puzzled here. > It panics on "goto out" with page fault. What I understand from it is that > the block at the address it tries to jmp to isn't present. But it's kernel > code which is never swapped out. Does it mean that the address was > rewritten? If it's so, what can rewrite this address? Ideas? > > Thank you in advance, > > P.S. Can it be due to faulty hardware? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 0:27:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id A74E237B400 for ; Mon, 8 Jan 2001 00:27:12 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id D1BF76A90D; Mon, 8 Jan 2001 18:57:09 +1030 (CST) Date: Mon, 8 Jan 2001 18:57:09 +1030 From: Greg Lehey To: Roman Shterenzon Cc: hackers@freebsd.org Subject: Dump analysis (was: Ideas? (fwd)) Message-ID: <20010108185709.D83353@wantadilla.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from roman@xpert.com on Mon, Jan 08, 2001 at 10:04:44AM +0200 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 8 January 2001 at 10:04:44 +0200, Roman Shterenzon wrote: > * Roman Shterenzon [010107 10:24] wrote: >> Hi, >> >> Could you please take a look at : >> http://www.freebsd.org/cgi/query-pr.cgi?pr=24019 >> It's my friend's PR. Can you give me some hints on how can I debug this >> issue. I'm completely puzzled here. >> It panics on "goto out" with page fault. What I understand from it is that >> the block at the address it tries to jmp to isn't present. But it's kernel >> code which is never swapped out. Does it mean that the address was >> rewritten? If it's so, what can rewrite this address? Ideas? My first suspicion here is that the sources are out of sync with the kernel you're debugging. It's very important to ensure that they are absolutely in sync. Here are a couple of incantations to throw at this dump (you may recognize the second one from an earlier mail exchange): (kgdb) x/10i epread (kgdb) x/10i 0xc012a038 The first one should show the beginning of the function; if it's in sync it will look like (modulo addresses): (kgdb) x/10i epread 0xc0165f8c : push %ebp 0xc0165f8d : mov %esp,%ebp 0xc0165f8f : sub $0x1c,%esp 0xc0165f92 : push %edi 0xc0165f93 : push %esi 0xc0165f94 : push %ebx 0xc0165f95 : mov 0x8(%ebp),%eax 0xc0165f98 : mov %eax,0xfffffff4(%ebp) 0xc0165f9b : mov 0x118(%eax),%edx 0xc0165fa1 : add $0x8,%edx In particular, those first two instructions are at the beginning of just about every function, so if you don't find them, you should check whether your code is in sync. >> P.S. Can it be due to faulty hardware? Or faulty Italian cuisine? In each case, not if it's repeatable. 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-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 0:37:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 7230F37B402 for ; Mon, 8 Jan 2001 00:36:53 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 14FXnC-0008RR-00; Mon, 08 Jan 2001 10:36:38 +0200 Date: Mon, 8 Jan 2001 10:36:38 +0200 (IST) From: Roman Shterenzon To: Greg Lehey , Yonatan Bokovza Cc: Subject: Re: Dump analysis (was: Ideas? (fwd)) In-Reply-To: <20010108185709.D83353@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 8 Jan 2001, Greg Lehey wrote: > On Monday, 8 January 2001 at 10:04:44 +0200, Roman Shterenzon wrote: > > * Roman Shterenzon [010107 10:24] wrote: > >> Hi, > >> > >> Could you please take a look at : > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=24019 > >> It's my friend's PR. Can you give me some hints on how can I debug this > >> issue. I'm completely puzzled here. > >> It panics on "goto out" with page fault. What I understand from it is that > >> the block at the address it tries to jmp to isn't present. But it's kernel > >> code which is never swapped out. Does it mean that the address was > >> rewritten? If it's so, what can rewrite this address? Ideas? > > My first suspicion here is that the sources are out of sync with the > kernel you're debugging. It's very important to ensure that they are This is not the case. The guy built it from the sam sources, he even used "buildkernel/installkernel" for that purpose. > absolutely in sync. Here are a couple of incantations to throw at > this dump (you may recognize the second one from an earlier mail > exchange): > > (kgdb) x/10i epread > (kgdb) x/10i 0xc012a038 > > The first one should show the beginning of the function; if it's in > sync it will look like (modulo addresses): > > (kgdb) x/10i epread > 0xc0165f8c : push %ebp > 0xc0165f8d : mov %esp,%ebp > 0xc0165f8f : sub $0x1c,%esp > 0xc0165f92 : push %edi > 0xc0165f93 : push %esi > 0xc0165f94 : push %ebx > 0xc0165f95 : mov 0x8(%ebp),%eax > 0xc0165f98 : mov %eax,0xfffffff4(%ebp) > 0xc0165f9b : mov 0x118(%eax),%edx > 0xc0165fa1 : add $0x8,%edx > > In particular, those first two instructions are at the beginning of > just about every function, so if you don't find them, you should check > whether your code is in sync. Yonatan, please provide the requested information. > > >> P.S. Can it be due to faulty hardware? > > Or faulty Italian cuisine? In each case, not if it's repeatable. It's repeatable, but not predictable. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 1:36:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1FC3E37B404 for ; Mon, 8 Jan 2001 01:36:01 -0800 (PST) Received: from newsguy.com (p10-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.139]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id SAA26301; Mon, 8 Jan 2001 18:35:02 +0900 (JST) Message-ID: <3A59893C.5D4FD5D3@newsguy.com> Date: Mon, 08 Jan 2001 18:32:44 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Mohan Khurana Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Xbox References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mohan Khurana wrote: > > Well, this is going to seem like a rather strange question. I understand > that Xbox is simply IA-32, however I have heard that the Xbox has a > special ROM that boots Windows CE, to ensure that people do not purchase > the Xbox for the sole reason of running FreeBSD or any other operating > system on it. Does anyone know enough about Xbox internals to verify that > FreeBSD will or will not be able to run on Xbox without any type of > hardware modification? I heard that too, and I heard that it will use DVD protection to ensure non-certified applications won't run. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 3:34:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id E5F1637B404 for ; Mon, 8 Jan 2001 03:33:45 -0800 (PST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id NAA08124; Mon, 8 Jan 2001 13:32:58 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 7886; Mon Jan 8 13:31:37 2001 Message-ID: <3A598CD5.CC26D681@cequrux.com> Date: Mon, 08 Jan 2001 11:48:05 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: Just how standard is APM? References: <3A556040.6B9163BB@cequrux.com> <3A545615.3597BCF3@cequrux.com> <200101042234.f04MYM147333@harmony.village.org> <200101051755.f05Htpb55318@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <3A556040.6B9163BB@cequrux.com> Graham Wheeler writes: > : Nope - as I said, I added log messages to apm.c to log the BIOS probe > : and they log a failure (I have "device apm0" in my config file). > > What's the failure mode? Is it enabled in the BIOS (I assume it is, > otherwise it wouldn't work in 'Doz). I suspect Mike is right when he says that the machine supports ACPI only, not APM. That would certainly explain what I observe. g. -- Dr Graham Wheeler E-mail: gram@cequrux.com Director, Research and Development WWW: http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN Specialists Fax: +27(21)424-3656 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 4:13:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id F123837B400 for ; Mon, 8 Jan 2001 04:12:59 -0800 (PST) Received: from calcaphon.demon.co.uk ([193.237.19.5]) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 14FbAY-000Hxw-0U; Mon, 8 Jan 2001 12:12:58 +0000 Received: from doug02.qubesoft.com (doug02.qubesoft.com [192.168.1.4]) by calcaphon.demon.co.uk (8.11.1/8.9.1) with ESMTP id f08CCp180475; Mon, 8 Jan 2001 12:12:51 GMT (envelope-from dfr@qubesoft.com) Date: Mon, 8 Jan 2001 12:12:51 +0000 (GMT) From: Doug Rabson To: Nick Hibma Cc: Jon Simola , FreeBSD Hackers Mailing List Subject: Re: Broken-by-design USB device? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 7 Jan 2001, Nick Hibma wrote: > > There is, I think, at least a bug in subr_bus.c that might cause this, > although, this is just a hunch. I've not been able to explain what's > happening yet. > > What is happening is that device_probe_child sets the device class, and > in case of an error unsets it. But in this case attach (instead of > probe) returns an error and hence the devclass _should_ be unset for > that device (it didn't have a devclass to start with) to force it back > to its virgin state, but isn't. > > If you could review his patch dfr, that would be appreciated. > > This is an issue in current as well. The patch looks good to me. -- Doug Rabson Mail: dfr@qubesoft.com Technical Director, Qube Software Ltd. Phone: +44 20 7431 9995 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 5:50:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from procsys.com (ppp33.bangalore-188.pacific.net.in [203.123.188.33]) by hub.freebsd.org (Postfix) with SMTP id 9A9B537B400 for ; Mon, 8 Jan 2001 05:50:29 -0800 (PST) Received: from procsys.com ([192.168.1.70]) by procsys.com with SMTP; Mon, 08 Jan 2001 19:13:31 -0530 Message-ID: <3A59C5BB.729B76BA@procsys.com> Date: Mon, 08 Jan 2001 19:20:51 +0530 From: nandan X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: unsubscribe freebsd-hackers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG unsubscribe freebsd-hackers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 10:32:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 246EF37B727 for ; Mon, 8 Jan 2001 10:10:15 -0800 (PST) Received: from FreeBSD.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA51902; Mon, 8 Jan 2001 10:10:10 -0800 (PST) (envelope-from DougB@FreeBSD.org) Message-ID: <3A5A0282.10EDAF5F@FreeBSD.org> Date: Mon, 08 Jan 2001 10:10:10 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Tetlow Cc: Gerhard Sittig , freebsd-hackers@FreeBSD.org Subject: Re: OT: silence as an answer? (was: how to test out cron.c changes?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gordon Tetlow wrote: > > Hello there! > > On Fri, 5 Jan 2001, Doug Barton wrote: > > Gerhard Sittig wrote: > [snip] > > > > Consider the following. We are in the spring and DST is "springing > > forward" at 2am. We have a job scheduled at 2:15 that takes one hour to > > run. There is another job scheduled at 3:20 that ABSOLUTELY POSITIVELY > > cannot run unless the first job finishes. Aside from the fact that this > > is bad design, how should cron handle this situation? You can (and > > probably should) respond that this is not cron's responsibility, and > > come up with all kinds of ways to ameliorate this situation. My response > > will then be that if you can "fix" this situation without "fixing" cron, > > then cron doesn't really need to be "fixed." > > I think this is a really horrible example. It is impossible for FreeBSD to > expect to catch bad design on a local administrator's part. The admin > should implement some sort of semaphore (a file in /tmp) or just append > the dependent job to the first job. We can't insulate stupidity, at least > we shouldn't, otherwise FreeBSD is going to start looking more like > Windows. Thank you. You just made my point. Did you actually read the last two sentences of my paragraph? > I think that cron is broken because it doesn't handle DST shift properly. And I think your definition of "properly" is broken. Cron doesn't "handle DST" changes at all. It simply follows the system clock, which is 100% understandable and reproducable behavior. I don't want to have to guess what cron is going to do with any kind of time shift. > OpenBSD seems to get by with these changes just fine. I have a lot of > respect for them and I think if they come up with a good solution to the > DST problem, we should seriously consider it. I agree with your premise, however I do not agree that this is a "good solution." That is the point of contention here. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 12:34:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id 4190A37B83F for ; Mon, 8 Jan 2001 12:00:25 -0800 (PST) Received: (qmail 12570 invoked by uid 1020); 8 Jan 2001 19:59:58 -0000 Date: Mon, 8 Jan 2001 11:59:58 -0800 (PST) From: Jon Simola X-Sender: jon@newmail.netbistro.com To: Nick Hibma Cc: Doug Rabson , FreeBSD Hackers Mailing List Subject: Re: Broken-by-design USB device? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 7 Jan 2001, Nick Hibma wrote: > Jon, could you try the attached patch and tell me whether that works for > you? Unfortunately, no. The probe messages differ, but it still panics. This is 4.2-RELEASE, I can try something more recent if it'll get you any better details. uhci0: port 0xd400-0xd41f irq 9 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhid0: vendor 0x6666 product 0x0667, rev 1.00/2.88, addr 2, iclass 3/0 uhid0: no report descriptor device_probe_and_attach: uhid0 attach returned 6 ugen0: vendor 0x6666 product 0x0667, rev 1.00/2.88, addr 2 ugen0: setting configuration index 0 failed device_probe_and_attach: ugen0 attach returned 6 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc011d58a stack pointer = 0x10:0xc030b920 frame pointer = 0x10:0xc030b920 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 = 0 (swapper) interrupt mask = net tty bio cam kernel: type 12 trap, code=0 Stopped at DEVICE_PROBE+0xe: cmpl 0(%edx),%eax db> trace DEVICE_PROBE(c0d32400,c0d32400,c0d32800,0,0) at DEVICE_PROBE+0xe device_probe_child(c0d32800,c0d32400,c0d32500,0,c0d32530) at device_probe_child+0xc1 device_probe_and_attach(c0d32400) at device_probe_and_attach+0x3d usbd_probe_and_attach(c0d32800,c0d32500,2,3,c0d32500) at usbd_probe_and_attach+0xef usbd_new_device(c0d32800,c0d33000,1,200,2,c0d327c0) at usbd_new_device+0x1dd uhub_explore(c0d32980,c0d32a00,c0d31580,0,c030be50) at uhub_explore+0x1d4 usb_attach(c0d32a00,c030be6c,c0154967,c0d32a00,c0d33000) at usb_attach+0xf1 DEVICE_ATTACH(c0d32a00,c0d33000,c0d31580,0,1) at DEVICE_ATTACH+0x2e device_probe_and_attach(c0d32a00) at device_probe_and_attach+0x63 uhci_pci_attach(c0d31580,c030beb8,c0154967,c0d31580,c0d31580) at uhci_pci_attach+0x33f DEVICE_ATTACH(c0d31580,c0d31580,c0d31b00,0,0) at DEVICE_ATTACH+0x2e device_probe_and_attach(c0d31580) at device_probe_and_attach+0x63 bus_generic_attach(c0d31a80,c030bef0,c0154967,c0d31a80,c0d31a80) at bus_generic_attach+0x16 DEVICE_ATTACH(c0d31a80,c0d31a80,c0d31c80,0,1) at DEVICE_ATTACH+0x2e device_probe_and_attach(c0d31a80) at device_probe_and_attach+0x63 bus_generic_attach(c0d31b00,c030bf28,c0154967,c0d31b00,c0d31b00) at bus_generic_attach+0x16 DEVICE_ATTACH(c0d31b00,c0d31b00,c0a25800,0,1) at DEVICE_ATTACH+0x2e device_probe_and_attach(c0d31b00) at device_probe_and_attach+0x63 bus_generic_attach(c0d31c80,c0d31c80,c030bf54,c011d60e,c0d31c80) at bus_generic_attach+0x16 nexus_attach(c0d31c80,c030bf70,c0154967,c0d31c80,c0d31c80) at nexus_attach+0xd DEVICE_ATTACH(c0d31c80,c0d31c80,c02791f0,310000,1) at DEVICE_ATTACH+0x2e device_probe_and_attach(c0d31c80) at device_probe_and_attach+0x63 root_bus_configure(c0a25800,c0258f8c,0) at root_bus_configure+0x16 configure(0,309c00,310000,0,c011d014) at configure+0x33 mi_startup(c030bfb4,b0206,ffe,310000,c0159069) at mi_startup+0x70 begin() at begin+0x4b db> --- Jon Simola | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 14:30:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id AA77F37B401; Mon, 8 Jan 2001 14:29:57 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id 6E0D9189A; Mon, 8 Jan 2001 17:29:56 -0500 (EST) Date: Mon, 8 Jan 2001 17:29:56 -0500 From: Will Andrews To: Peter Brezny Cc: Mike Smith , hackers@FreeBSD.org Subject: Re: 3ware 3dmd control/reporting utility for 3ware ide raid card Message-ID: <20010108172956.R649@puck.firepipe.net> Reply-To: hackers@FreeBSD.org, Mike Smith References: <003c01c079d2$415d4ae0$46010a0a@sysadmininc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003c01c079d2$415d4ae0$46010a0a@sysadmininc.com>; from peter@sysadmin-inc.com on Mon, Jan 08, 2001 at 04:22:30PM -0800 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.. redirected to hackers@ and msmith@, quotes kept for context ..] On Mon, Jan 08, 2001 at 04:22:30PM -0800, Peter Brezny wrote: > I've been trying to find the port for this utility. > > Mike Smith mentioned that it was in the testing phase, close to being > released, but I'm not sure what category to look under in the ports > collection for it. > > If anyone knows... > > I've included the message from mike for clarification. > > TIA > > Peter Brezny > SysAdmin Services Inc. > > > You did; please refer your 3ware contact to Janet LaFleur, however note > that we are currently resolving some minor issues with the 3dmd port. > It's running well on several beta sites, however, so it should be > available shortly. > > I want to apologise for the slow pace this has taken; I've been extremely > distracted for some time now, and by far the slowest link in the chain > related to getting this released. 3ware have been very responsive to > issues we've raised with their beta binaries, and my testers have been > all over the application like a rash, and very quick to pick up on things > I'd never have thought about. > > Regards, > Mike > > > There is reference to the beta version of 3ware's 3dm too for their raid > > cards being in a beta version, however, 3ware just told me they have no > > plans for FreeBSD. > > > > I wrote back encouraging them to do so. Did I just get a hold of a > clueless > > rep at 3ware, or are we going to have to do this on our own? They provide > > the sourcecode for redhat and suse... > > > > Peter Brezny > > SysAdmin Services Inc. > > > > > > -----Original Message----- > > From: Angie Nanjappa [] > > Sent: Thursday, January 04, 2001 11:35 AM > > To: 'peter@sysadmin-inc.com' > > Subject: RE: 3ware Service and Support Submission Form > > > > > > > > Hi Peter, > > > > We don't have any plans to compile the controller software for use with > > FreeBSD. > > > > If we can be of further assistance please let us know. > > > > Kind Regards, > > Angie > > > > > > -----Original Message----- > > From: peter@sysadmin-inc.com [] > > Sent: Thursday, January 04, 2001 10:41 AM > > To: peter@sysadmin-inc.com > > Cc: support@3ware.com > > Subject: 3ware Service and Support Submission Form > > > > > > On Thursday, January 04, 2001 this information has been submitted to > > 3ware. > > > > First Name Peter > > Last Name Brezny > > Company SysAdmin Systems Inc > > Phone 828-254-3577 > > Email Address peter@sysadmin-inc.com > > Product 5200 > > Product Information considering product purchase > > Serial Number > > Operating System Linux Other > > Computer Manufacturer pc > > Computer Model piii > > Disk Drive Manufacturer > > Disk Drive Model Number > > Video Card Manufacturer > > Video Card Model Number > > Drive Configuration RAID 1 > > Combination Description > > Reason For Call Compatibility question: > > Brief Description Do you plan to compile the controller software > > for use with FreeBSD? > > Is The Problem Repeatable My Question is not regarding a problem > > Symptoms And Error Messages > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hardware" in the body of the message > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hardware" in the body of the message > > > > > www@FreeBSD.org <../mailto.html> > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ports" in the body of the message -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 15: 1:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0865737B6A1 for ; Mon, 8 Jan 2001 15:01:05 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f08Mx8G49662; Mon, 8 Jan 2001 14:59:08 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010107211159.C1400@rjlhome.sco.com> Date: Mon, 08 Jan 2001 15:01:09 -0800 (PST) From: John Baldwin To: Robert Lipe Subject: RE: kthread_exit & zombification Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 08-Jan-01 Robert Lipe wrote: > Hi, Gang. > > In 4.1.1, I have a pretty simple need for a kernel thread or two, but > I'm having problems with kthread_exit(). The problem is that the thread > goes zombie after I kthread_exit in it, but it never gets reaped. Since > I'm doing this during a MOD_UNLOAD phase, if I happen to do a `ps -ax' > after the module has been unmapped, a panic results becuase it's trying > to get the lwp name and wchan string from what is now unmapped memory. > But that's a secondary problem; the primary one is that I am missing > whatever it takes to get a ticket for the resulting kernel thread to go > to Byte Heaven. > > After a couple of load/unload cycles, I see: kthreads are children of the swapper (pid 0), which doesn't harvest zombies. Hmm, a fix was committed to kthread_exit() in -current in rev 1.8 of sys/kern/kern_kthread.c. Actually, if you could test out both rev 1.8 and 1.9 that would be good, as both need to be backported to -stable. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 15:14:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail12.svr.pol.co.uk (mail12.svr.pol.co.uk [195.92.193.215]) by hub.freebsd.org (Postfix) with ESMTP id 227B337B6A8 for ; Mon, 8 Jan 2001 15:13:54 -0800 (PST) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by mail12.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14FlU9-000759-00 for hackers@freebsd.org; Mon, 08 Jan 2001 23:13:53 +0000 Received: from modem-253.humu-humu-trigger.dialup.pol.co.uk ([62.137.31.253] helo=henny.webweaving.org) by mail18.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14FlU4-0001oO-00 for hackers@FreeBSD.ORG; Mon, 08 Jan 2001 23:13:48 +0000 Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id XAA21599; Mon, 8 Jan 2001 23:12:46 GMT (envelope-from n_hibma@calcaphon.com) Date: Mon, 8 Jan 2001 23:12:46 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: Jon Simola Cc: FreeBSD Hackers Mailing List Subject: Re: Broken-by-design USB device? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > uhid0: vendor 0x6666 product 0x0667, rev 1.00/2.88, addr 2, iclass 3/0 > uhid0: no report descriptor > device_probe_and_attach: uhid0 attach returned 6 > ugen0: vendor 0x6666 product 0x0667, rev 1.00/2.88, addr 2 > ugen0: setting configuration index 0 failed > device_probe_and_attach: ugen0 attach returned 6 Just as a note on the side, the fact that the attach of the generic driver fails (while setting config 0, which is a sort of a soft reset) could indicate that there is something fishy going on with respect to fetching the report descriptor. I seems to freeze. And now back to your scheduled 'panic' demolition: It still bombs in the middle of DEVOPMETH in: device_probe_t *m = (device_probe_t *) DEVOPMETH(dev, device_probe); which is #define DEVOPMETH(DEV, OP) \ ((DEVOPDESC(OP)->offset >= DEVOPS(DEV)->maxoffset) \ ? DEVOPDESC(OP)->deflt \ : DEVOPS(DEV)->methods[DEVOPDESC(OP)->offset]) while executing 56: 3b 02 cmp (%edx),%eax with edx == dev->ops and eax == device_probe_ops->offset (don't you hate i386 assembler syntax?) and edx apparently being 0. Which as far as I can see is impossible in the subr_bus.c code. So that leaves 'memory spamming' as the only option :-( Apart from that, I have no clue which driver tries to attach after the ugen driver is finished. Because that is the last driver that makes an attempt. Could you do the following: Boot the machine and when it panics type the following commands: show registers x/x $ecx,0x20 x/c *($ecx+0x24),0x10 which will print three things: the contents of all registers (show registers), then the 32 longs at address $ecx (x/x $ecx,20), basically the contents of the struct device in DEVICE_PROBE, in which the 6th element (at +0x14) should be zero. And then the string that is pointed to by the nameunit element in the struct device. This last one should give us a hint at which device is failing. Never mind if the last one gives you a page fault. nameunit might be zero. I really am at a loss what this could be :( Nick > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc011d58a > stack pointer = 0x10:0xc030b920 > frame pointer = 0x10:0xc030b920 > 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 = 0 (swapper) > interrupt mask = net tty bio cam > kernel: type 12 trap, code=0 > Stopped at DEVICE_PROBE+0xe: cmpl 0(%edx),%eax > db> trace > DEVICE_PROBE(c0d32400,c0d32400,c0d32800,0,0) at DEVICE_PROBE+0xe > device_probe_child(c0d32800,c0d32400,c0d32500,0,c0d32530) at device_probe_child+0xc1 > device_probe_and_attach(c0d32400) at device_probe_and_attach+0x3d > usbd_probe_and_attach(c0d32800,c0d32500,2,3,c0d32500) at usbd_probe_and_attach+0xef > usbd_new_device(c0d32800,c0d33000,1,200,2,c0d327c0) at usbd_new_device+0x1dd > uhub_explore(c0d32980,c0d32a00,c0d31580,0,c030be50) at uhub_explore+0x1d4 > usb_attach(c0d32a00,c030be6c,c0154967,c0d32a00,c0d33000) at usb_attach+0xf1 > DEVICE_ATTACH(c0d32a00,c0d33000,c0d31580,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d32a00) at device_probe_and_attach+0x63 > uhci_pci_attach(c0d31580,c030beb8,c0154967,c0d31580,c0d31580) at uhci_pci_attach+0x33f > DEVICE_ATTACH(c0d31580,c0d31580,c0d31b00,0,0) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31580) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31a80,c030bef0,c0154967,c0d31a80,c0d31a80) at bus_generic_attach+0x16 > DEVICE_ATTACH(c0d31a80,c0d31a80,c0d31c80,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31a80) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31b00,c030bf28,c0154967,c0d31b00,c0d31b00) at bus_generic_attach+0x16 > DEVICE_ATTACH(c0d31b00,c0d31b00,c0a25800,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31b00) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31c80,c0d31c80,c030bf54,c011d60e,c0d31c80) at bus_generic_attach+0x16 > nexus_attach(c0d31c80,c030bf70,c0154967,c0d31c80,c0d31c80) at nexus_attach+0xd > DEVICE_ATTACH(c0d31c80,c0d31c80,c02791f0,310000,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31c80) at device_probe_and_attach+0x63 > root_bus_configure(c0a25800,c0258f8c,0) at root_bus_configure+0x16 > configure(0,309c00,310000,0,c011d014) at configure+0x33 > mi_startup(c030bfb4,b0206,ffe,310000,c0159069) at mi_startup+0x70 > begin() at begin+0x4b > db> > > > --- > Jon Simola | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 15:23:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (dhcp244.osd.bsdi.com [204.216.28.244]) by hub.freebsd.org (Postfix) with ESMTP id 68CB237B402; Mon, 8 Jan 2001 15:23:33 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f08Nape02093; Mon, 8 Jan 2001 15:36:51 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200101082336.f08Nape02093@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: hackers@FreeBSD.org, Mike Smith Cc: Peter Brezny Subject: Re: 3ware 3dmd control/reporting utility for 3ware ide raid card In-reply-to: Your message of "Mon, 08 Jan 2001 17:29:56 EST." <20010108172956.R649@puck.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jan 2001 15:36:51 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [.. redirected to hackers@ and msmith@, quotes kept for context ..] > > On Mon, Jan 08, 2001 at 04:22:30PM -0800, Peter Brezny wrote: > > I've been trying to find the port for this utility. > > > > Mike Smith mentioned that it was in the testing phase, close to being > > released, but I'm not sure what category to look under in the ports > > collection for it. Er, why are you looking in the ports collection if it's still being tested? Once the package is finalised, it'll probably be in sysutils. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 16:22: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 4574937B401; Mon, 8 Jan 2001 16:21:47 -0800 (PST) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id TAA62967; Mon, 8 Jan 2001 19:21:41 -0500 (EST) Date: Mon, 8 Jan 2001 19:21:41 -0500 (EST) From: "Matthew N. Dodd" To: cristian nicolae Cc: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 In-Reply-To: <3A5870B9.D4402452@chello.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 7 Jan 2001, cristian nicolae wrote: > I have a Compaq DL380 with an integrated Compaq Smart Array Controller. > I have succesfully managed to install the FreeBSD 4.2-20010104 > and everything is fine but the DAT drive which is not detected. The SCSI passthrough interface on that controller isn't supported by FreeBSD's 'ida' driver. My impression from reading various docs is that it is likely to be quite slow as well. Hook the DAT drive up to the internal SCSI adapter (I assume it has one since it would be fairly silly not to.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 16:25:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dune.clickarray.com (unknown [216.132.92.2]) by hub.freebsd.org (Postfix) with ESMTP id DE55D37B401 for ; Mon, 8 Jan 2001 16:25:26 -0800 (PST) Received: from b52.clickarray.com ([10.2.1.211]) by dune.clickarray.com (8.9.3/8.9.3) with SMTP id QAA51912; Mon, 8 Jan 2001 16:31:45 -0800 (PST) (envelope-from vijo@clickarray.com) From: Vijo Cherian To: hackers@freebsd.org Subject: kobj, makedevops.pl etc. Date: Mon, 8 Jan 2001 17:29:25 -0800 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: mhsu@clickarray.com MIME-Version: 1.0 Message-Id: <01010817314705.21412@b52.clickarray.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, I have some questions... but most of them may be prerry lame because I am new to FreeBSD. I am running 5.0 and I have a driver for a card which was written for 4.1. The driver uses bus_if.h, device_if.h and pci_if.h and these files are generated by makedevops.pl. The driver is written as a module and is loaded using kldload. But loading fails because BUS_READ_IVAR and friends are not available. Using makeobjops.pl works. My questions are 1. Is this the right way? 2. When did kobj find place in the kernel? (which release) (that is what makeobjops.pl does,right?) 3. If all that I did is wrong, what is the right way? 4. Can you point me to a driver that can be loaded as kld? waiting to see how the community treats a new convert ;-) -- vijo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 16:43:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id E463437B400; Mon, 8 Jan 2001 16:43:01 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id SAA09957; Mon, 8 Jan 2001 18:47:32 -0600 (CST) Date: Mon, 8 Jan 2001 18:47:32 -0600 From: Robert Lipe To: John Baldwin Cc: freebsd-hackers@FreeBSD.org Subject: Re: kthread_exit & zombification Message-ID: <20010108184732.N1400@rjlhome.sco.com> References: <20010107211159.C1400@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from jhb@FreeBSD.org on Mon, Jan 08, 2001 at 03:01:09PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 08-Jan-01 Robert Lipe wrote: > > I'm having problems with kthread_exit(). The problem is that the thread > > goes zombie after I kthread_exit in it, but it never gets reaped. Since > > I'm doing this during a MOD_UNLOAD phase, if I happen to do a `ps -ax' > > after the module has been unmapped, a panic results becuase it's trying > > to get the lwp name and wchan string from what is now unmapped memory. > > kthreads are children of the swapper (pid 0), which doesn't harvest zombies. Bummer. I can get past the zombies as they're merely unsightly. Panics are a drag. :-) > Hmm, a fix was committed to kthread_exit() in -current in rev 1.8 of > sys/kern/kern_kthread.c. Actually, if you could test out both rev 1.8 and 1.9 > that would be good, as both need to be backported to -stable. Only 1.8 seems to be be pertinent to 4.1.1. I've stitched in the call to proc_reparent() and life seems pretty good. `ps' no longer panics and the lwp does indeed disappear from the ps listing instead of merely going zombie. This doesn't quite seem to jive with what you described above, though. Thanx! RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 17: 4: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 05B4137B401 for ; Mon, 8 Jan 2001 17:03:50 -0800 (PST) Received: from newsguy.com (p16-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.145]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id KAA00301; Tue, 9 Jan 2001 10:03:31 +0900 (JST) Message-ID: <3A5A62D9.D0B70E72@newsguy.com> Date: Tue, 09 Jan 2001 10:01:13 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Vijo Cherian Cc: hackers@FreeBSD.ORG, mhsu@clickarray.com Subject: Re: kobj, makedevops.pl etc. References: <01010817314705.21412@b52.clickarray.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Vijo Cherian wrote: > > 2. When did kobj find place in the kernel? (which release) > (that is what makeobjops.pl does,right?) Kobj was added to 5.0-current (which is not (yet) a release). > 4. Can you point me to a driver that can be loaded as kld? Look at /sys/modules or check out /boot/defaults/loader.conf. BTW, also check out /usr/share/examples/make_device_driver.sh. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 17:31:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (dhcp244.osd.bsdi.com [204.216.28.244]) by hub.freebsd.org (Postfix) with ESMTP id 1CD6C37B401; Mon, 8 Jan 2001 17:31:20 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f091i1e02711; Mon, 8 Jan 2001 17:44:02 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200101090144.f091i1e02711@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Matthew N. Dodd" Cc: cristian nicolae , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 In-reply-to: Your message of "Mon, 08 Jan 2001 19:21:41 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jan 2001 17:44:01 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hook the DAT drive up to the internal SCSI adapter (I assume it has one > since it would be fairly silly not to.) Actually, I'm not sure that it does. They use the Symbios part with the integrated ARM processor, and assume that SCSI passthrough works. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 17:41:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D07F537B401 for ; Mon, 8 Jan 2001 17:41:31 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f091dWG52735; Mon, 8 Jan 2001 17:39:32 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010108184732.N1400@rjlhome.sco.com> Date: Mon, 08 Jan 2001 17:41:35 -0800 (PST) From: John Baldwin To: Robert Lipe Subject: Re: kthread_exit & zombification Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Jan-01 Robert Lipe wrote: > John Baldwin wrote: >> >> On 08-Jan-01 Robert Lipe wrote: > >> > I'm having problems with kthread_exit(). The problem is that the thread >> > goes zombie after I kthread_exit in it, but it never gets reaped. Since >> > I'm doing this during a MOD_UNLOAD phase, if I happen to do a `ps -ax' >> > after the module has been unmapped, a panic results becuase it's trying >> > to get the lwp name and wchan string from what is now unmapped memory. >> >> kthreads are children of the swapper (pid 0), which doesn't harvest zombies. > > Bummer. I can get past the zombies as they're merely unsightly. Panics > are a drag. :-) Unloading modules adds all sorts of new problems. Right now the WITNESS code will do bad bad things if you kldunload a module that contains a mutex. Even if the mutex is mtx_destroy'd because it still has a reference to its name in the internal lists it keeps. >> Hmm, a fix was committed to kthread_exit() in -current in rev 1.8 of >> sys/kern/kern_kthread.c. Actually, if you could test out both rev 1.8 and >> 1.9 >> that would be good, as both need to be backported to -stable. > > Only 1.8 seems to be be pertinent to 4.1.1. I've stitched in the call > to proc_reparent() and life seems pretty good. `ps' no longer panics > and the lwp does indeed disappear from the ps listing instead of merely > going zombie. This doesn't quite seem to jive with what you described > above, though. By reparenting to init, the zombie is harvested isntead of lying around. Now I just need to MFC this. > Thanx! > RJL -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 17:46:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 0BA8337B402; Mon, 8 Jan 2001 17:46:29 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-214.nnj.dialup.bellatlantic.net [151.198.117.214]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA15224; Mon, 8 Jan 2001 20:46:18 -0500 (EST) Message-ID: <3A5A6D6A.4115A4BD@bellatlantic.net> Date: Mon, 08 Jan 2001 20:46:18 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: cristian nicolae , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 References: <3A5870B9.D4402452@chello.at> <20010107133757.A55049@panzer.kdm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kenneth D. Merry" wrote: > > On Sun, Jan 07, 2001 at 14:35:53 +0100, cristian nicolae wrote: > > Dear all, > > I have a Compaq DL380 with an integrated Compaq Smart Array Controller. > > I have succesfully managed to install the FreeBSD 4.2-20010104 > > and everything is fine but the DAT drive which is not detected. > > The DAT is connected to the same Controller as the RAID system. > I don't think the ida driver in FreeBSD has SCSI passthrough capability. > > I don't know whether or not the hardware itself has passthrough capability; I think it does (I suspect that UnixWare supports it) but I'm not 100% sure. > > On the other hand does any of you have info whether Compaq will support > > officially FreeBSD in the future? > > I don't know. They offer FreeBSD in their test drive program, though: It may be worth it calling them and asking anyway. If they hear from the customers that the customers want FreeBSD they would eventually add its support. I think this is approximately how they started supporting Linux. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 18: 0:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from c21bowman.com (unknown [216.140.51.98]) by hub.freebsd.org (Postfix) with SMTP id 29E3837B404 for ; Mon, 8 Jan 2001 18:00:18 -0800 (PST) Received: (qmail 5617 invoked by uid 0); 9 Jan 2001 02:00:07 -0000 Received: from unknown (HELO mike) (10.10.10.200) by 10.10.10.203 with SMTP; 9 Jan 2001 02:00:07 -0000 From: Michael Owens Reply-To: owensmk@earthlink.net Date: Mon, 8 Jan 2001 20:02:53 -0600 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" To: hackers@freebsd.org Subject: FIN_WAIT_2 / TIME_WAIT Confusion MIME-Version: 1.0 Message-Id: <01010820025300.00397@mike> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If this is not proper place to ask this, let me know and I'll go elsewhere as it is a TCP question. . . but I specifically use (and prefer) FreeBSD. I wrote a simple little I/O multiplexing thing that can act as a client or server as a personal project in network programming. Everything seems fine, except that when I use the client to make multiple connections to a web server. Even though I don't primarly use it for this, the following behvior has me curious. I will run my client about 2 or three times, each time it makes 5 connections, pulling back the main page. Then the weird behavior starts: 1. I will get all data back from all connections except for one, perhaps two, which then sit in a FIN_WAIT_2 or sometimes TIME_WAIT state. 2. When I run netstat -a, it indicates that there is data in the read queue for these clients, but select() always returns 0 ready file descriptors. That's what puzzles me. There is data there to be gotten, but I am not getting it. When I look at the data that comes back in tcpflow, it doesn't look like the whole document has made it back either. A couple of runs might work perfectly, then once or twice will be weird. And it seems to multiplex more connections more reliably than fewer (the weird behavior seems inversely proportional to the number connections---to a point of course. The client runs reliably more times with 50 connections than with 5). Three notes: 1. It seems to happen more if I access machines on my LAN than over the Internet. 2. I do make sure and shutdown the write side of the socket after I send the HTTP request so as to avoid keeping the web server in FIN_WAIT_2. 3. I am sure about having the maxfd + 1 in select() correct, so that's not the problem. Does anyone have any ideas as to what's going on? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 18: 4:27 2001 Delivered-To: freebsd-hackers@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 2E2F837B699 for ; Mon, 8 Jan 2001 18:04:06 -0800 (PST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:lhk7oBoQr54nHQi+ChrqpRmJ8D5UUQxp@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.11.0/3.7Wpl2) with ESMTP id f0923tH02292; Tue, 9 Jan 2001 11:03:59 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:ZmNAt1ifc/My6iHDMWXkVyAzDREk2+21@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 LAA02768; Tue, 9 Jan 2001 11:11:36 +0900 (JST) Message-Id: <200101090211.LAA02768@zodiac.mech.utsunomiya-u.ac.jp> To: Greg Black Cc: hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: psmintr: out of sync In-reply-to: Your message of "Sun, 07 Jan 2001 10:52:21 +1000." References: Date: Tue, 09 Jan 2001 11:11:35 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There is a workaround, if not a fix, for this problem in -CURRENT. Apply the following patch to /sys/isa/psm.c and add flags 0x8000 to psm driver in your kernel config file as follows. device psm0 at atkbdc? irq 12 flags 0x8000 Kazu >I have an intermittent (and fairly rare) problem with various >PS/2 mice on a set of boxes running 4.1-R (but the problem was >also evident under 3.{1,2,3,4}-R). The boxes all run X and, on >occasion, the mouse will stop working and hundreds of "psmintr: >out of sync" messages will be logged. > >It happens maybe once in 6 weeks on one of seven machines, so is >not easy to diagnose. > >I can fix it by logging in with ssh (or switching to one of the >virtual consoles if the box is handy), killing and re-starting >moused. > >This is not a very useful solution for distant clients who are >not competent to do stuff like that and tend to resort to the >power switch if I'm not available instantly -- and that leads to >undesirable collateral damage. > >I'm keen to hear practical suggestions for a fix, or even better >that a bug has been found and fixed. Index: psm.c =================================================================== RCS file: /src/CVS/src/sys/isa/psm.c,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- psm.c 2000/12/01 05:24:30 1.33 +++ psm.c 2000/12/01 05:26:24 1.34 @@ -20,7 +20,7 @@ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $FreeBSD: src/sys/isa/psm.c,v 1.33 2000/12/01 05:24:30 yokota Exp $ + * $FreeBSD: src/sys/isa/psm.c,v 1.34 2000/12/01 05:26:24 yokota Exp $ */ /* @@ -176,10 +176,12 @@ #define PSM_CONFIG_IGNPORTERROR 0x1000 /* ignore error in aux port test */ #define PSM_CONFIG_HOOKRESUME 0x2000 /* hook the system resume event */ #define PSM_CONFIG_INITAFTERSUSPEND 0x4000 /* init the device at the resume event */ +#define PSM_CONFIG_SYNCHACK 0x8000 /* enable `out-of-sync' hack */ #define PSM_CONFIG_FLAGS (PSM_CONFIG_RESOLUTION \ | PSM_CONFIG_ACCEL \ | PSM_CONFIG_NOCHECKSYNC \ + | PSM_CONFIG_SYNCHACK \ | PSM_CONFIG_NOIDPROBE \ | PSM_CONFIG_NORESET \ | PSM_CONFIG_FORCETAP \ @@ -1900,6 +1902,15 @@ log(LOG_DEBUG, "psmintr: out of sync (%04x != %04x).\n", c & sc->mode.syncmask[0], sc->mode.syncmask[1]); sc->inputbytes = 0; + if (sc->config & PSM_CONFIG_SYNCHACK) { + /* + * XXX: this is a grotesque hack to get us out of + * dreaded "out of sync" error. + */ + log(LOG_DEBUG, "psmintr: re-enable the mouse.\n"); + disable_aux_dev(sc->kbdc); + enable_aux_dev(sc->kbdc); + } continue; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 18:24: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 4E84937B402; Mon, 8 Jan 2001 18:23:46 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id UAA10592; Mon, 8 Jan 2001 20:28:23 -0600 (CST) Date: Mon, 8 Jan 2001 20:28:23 -0600 From: Robert Lipe To: John Baldwin Cc: freebsd-hackers@FreeBSD.org Subject: Re: kthread_exit & zombification Message-ID: <20010108202823.A10376@rjlhome.sco.com> References: <20010108184732.N1400@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from jhb@FreeBSD.org on Mon, Jan 08, 2001 at 05:41:35PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > Unloading modules adds all sorts of new problems. Right now the WITNESS code > will do bad bad things if you kldunload a module that contains a mutex. Even > if the mutex is mtx_destroy'd because it still has a reference to its name in > the internal lists it keeps. Funny. I fixed a related problem in the UDI code just this morning. Those linked lists that walk into modules that have been unmapped can be a killer. :-) But this solves the problem I have right now. Thanx! > > to proc_reparent() and life seems pretty good. `ps' no longer panics > > and the lwp does indeed disappear from the ps listing instead of > > merely going zombie. This doesn't quite seem to jive with what you > > described above, though. > > By reparenting to init, the zombie is harvested isntead of lying > around. Now I just need to MFC this. Aaaah. Now I understand. Later, RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 18:43:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id BD75037B401 for ; Mon, 8 Jan 2001 18:43:32 -0800 (PST) Received: from jehovah ([24.202.203.37]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G6VJKJ01.7Q3; Mon, 8 Jan 2001 21:43:31 -0500 Message-ID: <003b01c079e6$2303bb60$25cbca18@jehovah> From: "Bosko Milekic" To: , References: <01010820025300.00397@mike> Subject: Re: FIN_WAIT_2 / TIME_WAIT Confusion Date: Mon, 8 Jan 2001 21:44:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Michael, What version of FreeBSD are you running? If it's not too much trouble, can you please provide the code you're using to simulate the problem? Are the TIME_WAIT state connections eventually timing out/disappearing? Michael wrote: > If this is not proper place to ask this, let me know and I'll go elsewhere as > it is a TCP question. . . but I specifically use (and prefer) FreeBSD. > > I wrote a simple little I/O multiplexing thing that can act as a client or > server as a personal project in network programming. Everything seems fine, > except that when I use the client to make multiple connections to a web > server. > > Even though I don't primarly use it for this, the following behvior has me > curious. > > I will run my client about 2 or three times, each time it makes 5 > connections, pulling back the main page. Then the weird behavior starts: > > 1. I will get all data back from all connections except for one, perhaps > two, which then sit in a FIN_WAIT_2 or sometimes TIME_WAIT state. > > 2. When I run netstat -a, it indicates that there is data in the read queue > for these clients, but select() always returns 0 ready file descriptors. > > That's what puzzles me. There is data there to be gotten, but I am not > getting it. When I look at the data that comes back in tcpflow, it doesn't > look like the whole document has made it back either. > > A couple of runs might work perfectly, then once or twice will be weird. And > it seems to multiplex more connections more reliably than fewer (the weird > behavior seems inversely proportional to the number connections---to a point > of course. The client runs reliably more times with 50 connections than with > 5). > > > Three notes: > > 1. It seems to happen more if I access machines on my LAN than over the > Internet. > > 2. I do make sure and shutdown the write side of the socket after I send the > HTTP request so as to avoid keeping the web server in FIN_WAIT_2. > > 3. I am sure about having the maxfd + 1 in select() correct, so that's not > the problem. > > Does anyone have any ideas as to what's going on? > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 23:33:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 430B537B402 for ; Mon, 8 Jan 2001 23:33:23 -0800 (PST) Received: (qmail 9341 invoked by uid 0); 8 Jan 2001 17:31:20 -0000 Received: from pd9508811.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.17) by mail.gmx.net (mail06) with SMTP; 8 Jan 2001 17:31:20 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id PAA23804; Sun, 7 Jan 2001 15:59:35 +0100 Date: Sun, 7 Jan 2001 15:59:34 +0100 From: Gerhard Sittig To: Doug Barton Cc: freebsd-hackers@FreeBSD.org Subject: Re: OT: silence as an answer? (was: how to test out cron.c changes?) Message-ID: <20010107155934.F253@speedy.gsinet> References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102125247.U253@speedy.gsinet> <3A564E90.A49E1BE1@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A564E90.A49E1BE1@gorean.org>; from DougB@gorean.org on Fri, Jan 05, 2001 at 02:45:36PM -0800 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote: > > [ -chat or -advocacy parts deleted :) ] Since I wanted this OT subthread to die soon and to keep the technical discussion away from it, I will cite your message in the other subthread to keep the "solution" (or put better: the way leading to one) in there. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 8 23:33:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 70FB337B404 for ; Mon, 8 Jan 2001 23:33:24 -0800 (PST) Received: (qmail 9448 invoked by uid 0); 8 Jan 2001 17:31:21 -0000 Received: from pd9508811.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.17) by mail.gmx.net (mail06) with SMTP; 8 Jan 2001 17:31:21 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id RAA23882; Sun, 7 Jan 2001 17:08:41 +0100 Date: Sun, 7 Jan 2001 17:08:40 +0100 From: Gerhard Sittig To: freebsd-hackers@FreeBSD.org Cc: Doug Barton Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010107170840.G253@speedy.gsinet> References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010102133239.V253@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Tue, Jan 02, 2001 at 01:32:39PM +0100 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ citing from Doug's message in the "OT: silence ..." subthread to keep the technical discussion in the "how to test" subthread ] On Tue, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote: > > You stated in another post that you wished I had elaborated > more. I was in a hurry when I wrote that post, so here are more > details. While this is, as you say, "an eternal problem," it is > not a problem entirely without remedy. The proper solution is > simply to avoid scheduling mission/time critical events during > the DST change period for your time zone. Without improperly > revealing sources, I can say that I did a lot of research on > this topic in a past life, and it is by no means clear that > your proposed solution is the best one. Well, the "don't schedule jobs for these times" is the problem here: The fact that all FreeBSD users are potentially struck is caused by the jobs execution time to be delivered with the distribution. It's not a wanton act of some administrators to schedule their jobs this way, but it's the status after installing FreeBSD on a machine. Plus the fact that this machine (by chance? but it's an increasing chance as has been stated in an other message) is located in a region with DST changes. Of course everybody knows there's a need to check, correct and add quite a few things an installer is not capable to handle in all the variety of arrangements humans come up with. And some things aren't just the job of an installer. But how many of us are aware of checking scheduled jobs' timings and how they could collide in the near future (in the next year after setting up the machine) or in the general future (when you somehow "forgot" the machine because it just works flawlessly)? What if some government later decides to introduce DST, too? What if these jumps are shifted to a different week? It may be rare, but it definitely would be tedious to keep up with these details for machines you don't need to spend too much attention for or regions you don't live in or care too much about. Even if the user gets it right after the installation, there's a chance that a commit to the timezone database will cause new trouble. Strictly speaking you wouldn't even have to check crontab(5) against the Real World (TM), but against the zdump(8) output. Since the /etc/localtime description is what makes the clock jump on the computer. It boils down to: Do we want to keep putting tedious (and mostly nonintuitive) work on FreeBSD users? Or do we want to free some of their resources for more important tasks (maybe even the actual tasks they install FreeBSD as a tool / vehicle for:)? Imagine you would be yourself in the situation to handle a few wide spread machines in different regions of the earth. Add your experience with the nontrivial nature of DST handling and job scheduling. Actually I would expect you to welcome when cron(8) would be intelligent enough to save you from thinking about these low level details. :) There already are much more (and more important) things to care about when setting up a server ... It's not that I want to talk you into something you don't want. Currently I'm about to setup a spare machine for the tests (the one I had last year is not available for toying any longer). Since this machine lacks any kind of connectivity, I have to fallback to 4.1-R from the Lehmann's CD set. With the CVS repo from CD#2 I checked there's no diff between the -STABLE and -CURRENT usr.sbin/cron tree. And I would expect mdocification to be the only change made to cron since then. While I write this "make world" is running and will take some seven hours. I scheduled DST changes for Jan 8th, 9th, 10th, and 11th (to, from, to, and from DST, respectively). If things go well, I can send-pr the code and the testing environment next weekend (Sergey Babkin was so kind to help me with setting it up). > Consider the following. We are in the spring and DST is > "springing forward" at 2am. We have a job scheduled at 2:15 > that takes one hour to run. There is another job scheduled at > 3:20 that ABSOLUTELY POSITIVELY cannot run unless the first job > finishes. Aside from the fact that this is bad design, how > should cron handle this situation? You can (and probably > should) respond that this is not cron's responsibility, and > come up with all kinds of ways to ameliorate this situation. My > response will then be that if you can "fix" this situation > without "fixing" cron, then cron doesn't really need to be > "fixed." Well, the only valid "fix" for this situation would be to fix the jobs' arrangement / interaction / synchronisation. This can be done with coordinating interdependent jobs by means of locks or making them one job with several stages or something". Do you agree that the proposed cron extension merely reveals the brokenness of the above asumption that a job has a given length and unforced synchronisation always will work? Talking about a UNIX environment there's no way of reliably operating based on computation time, anyway. You may have an expectation, you may even have an estimate, but you never have determined execution lengths. But all of this is basically what you state yourself. In the current situation (and in future, too, of course) cron wouldn't even force these jobs to really start at the given time. They're just dispatched, queued, or whatever term is the best. Availability of resources is what influences scheduling more than users' wishes. :) This means the above example is defective without touching cron, already. But without the proposed fix to cron the 2:15 job wouldn't even get run and and thus possibly damage(?) the prerequisites the 3:20 job wants to run under. No matter how defective the above example may be, it's hard to decide which "brokenness" is worse in the above scenario: not to run needed jobs or to have them run interleaved while they should be sequenced. But in any normal scenario it surely is a bug when scheduled jobs aren't run at all or multiple times. Out of curiousity: can cron(8) already handle situations where it is woken up after some minutes have passed since the last "tick"? Or is this absolutely out of imagination that a machine's workload is this bad? > With very little imagination you could easily come up with > other situations where your proposed changes will cause more > harm than good. You might be shocked, but sorry I *cannot* come up with _any_ situation that's to get broken by a cron which keeps up with its job list. :) Isn't it exactly the user's expectation that cronjobs are run (for nitpicking: queued immediately and waited for resources to become available for running them) as soon as the scheduled time is reached _or_ _passed_? And making sure that cron "gets bored" about "hey, I know this job. I just ran it. Just because somebody turned back the clock doesn't mean I *want* to do it all again" would IMO better match users' expectations, too. To make things clear: This doesn't touch the "every five minutes" and "hourly" jobs, only those scheduled for one given daytime and at least daily. Anyway. The reminder I sent seems to prove there *is* interest among FreeBSD users. And not everyone is keen on having the discussion in late March once more, and in October again. :) So I will do my part and contribute what I can. :> May others with more knowledge jump in and join or prove me wrong ... For the record I will cite the manpage again, which is meant to clarify the motivation for the change. It seems my presentation of what I try to achieve was wrong. And I expect the PR with code to change this. ----------------------------------------------------------------- --- /usr/src/usr.sbin/cron/cron/cron.8 1999/08/28 01:15:49 1.7 +++ /usr/src/usr.sbin/cron/cron/cron.8 2000/12/03 12:44:53 @@ -68,6 +68,25 @@ .Xr crontab 1 command updates the modtime of the spool directory whenever it changes a crontab. +.Pp +Special considerations exist when the clock is changed by less than 3 +hours; for example, at the beginning and end of Daylight Saving +Time. +If the time has moved forward, those jobs which would have +run in the time that was skipped will be run soon after the change. +Conversely, if the time has moved backward by less than 3 hours, +those jobs that fall into the repeated time will not be run. +.Pp +Only jobs that run at a particular time (not specified as @hourly, nor with +.Ql * +in the hour or minute specifier) +are +affected. +Jobs which are specified with wildcards are run based on the +new time immediately. +.Pp +Clock changes of more than 3 hours are considered to be corrections to +the clock, and the new time is used immediately. .Sh SEE ALSO .Xr crontab 1 , .Xr crontab 5 ----------------------------------------------------------------- virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 0: 6:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 5C24D37B400 for ; Tue, 9 Jan 2001 00:06:14 -0800 (PST) Received: (qmail 2988 invoked by uid 1000); 9 Jan 2001 08:05:01 -0000 Date: Tue, 9 Jan 2001 10:05:01 +0200 From: Peter Pentchev To: freebsd-hackers@FreeBSD.org Subject: escape sequence for 'Ic' terminal capability Message-ID: <20010109100501.C2550@ringworld.oblivion.bg> Mail-Followup-To: freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm thinking of messing with the syscons ioctl handler to allow setting of color values - all EGA- and VGA-compatible video controllers allow this. The idea is to later define my termcap(5) entry to let ncurses deal with color setting. termcap(5) lists the 'cc' - 'can change color' and 'Ic' - 'initialize color' capabilities. Setting the boolean 'cc' is easy, 'Ic' however presents a bit of a problem to me - does anyone know what it is set to on any other terms so I can keep a bit of compatibility here, or do I just randomly pick an esc sequence, and lead on a happy existence until someone else defines this same esc sequence to do something else? :) G'luck, Peter -- This sentence was in the past tense. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 0:25:20 2001 Delivered-To: freebsd-hackers@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 751EE37B401 for ; Tue, 9 Jan 2001 00:25:01 -0800 (PST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:zo8Jmvms3eB4X1EIKpWs4VyvgS0krbT1@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.11.0/3.7Wpl2) with ESMTP id f098OlH08022; Tue, 9 Jan 2001 17:24:51 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:bm3iVtmRGCLUwwqi95+dd+gyIrB4Z5nd@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 RAA08905; Tue, 9 Jan 2001 17:32:30 +0900 (JST) Message-Id: <200101090832.RAA08905@zodiac.mech.utsunomiya-u.ac.jp> To: Peter Pentchev Cc: freebsd-hackers@FreeBSD.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: escape sequence for 'Ic' terminal capability In-reply-to: Your message of "Tue, 09 Jan 2001 10:05:01 +0200." <20010109100501.C2550@ringworld.oblivion.bg> References: <20010109100501.C2550@ringworld.oblivion.bg> Date: Tue, 09 Jan 2001 17:32:29 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG syscons is already capable of changing forground and background colors via escape sequences. Is it not sufficient for your intended application? Kazu >Hi, > >I'm thinking of messing with the syscons ioctl handler to allow setting >of color values - all EGA- and VGA-compatible video controllers allow this. >The idea is to later define my termcap(5) entry to let ncurses deal with >color setting. > >termcap(5) lists the 'cc' - 'can change color' and 'Ic' - 'initialize color' >capabilities. Setting the boolean 'cc' is easy, 'Ic' however presents a bit >of a problem to me - does anyone know what it is set to on any other terms >so I can keep a bit of compatibility here, or do I just randomly pick an esc >sequence, and lead on a happy existence until someone else defines this same >esc sequence to do something else? :) > >G'luck, >Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 0:36: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id A3FD537B400 for ; Tue, 9 Jan 2001 00:35:47 -0800 (PST) Received: (qmail 3954 invoked by uid 1000); 9 Jan 2001 08:34:34 -0000 Date: Tue, 9 Jan 2001 10:34:34 +0200 From: Peter Pentchev To: Kazutaka YOKOTA Cc: freebsd-hackers@FreeBSD.org Subject: Re: escape sequence for 'Ic' terminal capability Message-ID: <20010109103434.E2550@ringworld.oblivion.bg> Mail-Followup-To: Kazutaka YOKOTA , freebsd-hackers@FreeBSD.org References: <20010109100501.C2550@ringworld.oblivion.bg> <200101090832.RAA08905@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101090832.RAA08905@zodiac.mech.utsunomiya-u.ac.jp>; from yokota@zodiac.mech.utsunomiya-u.ac.jp on Tue, Jan 09, 2001 at 05:32:29PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 09, 2001 at 05:32:29PM +0900, Kazutaka YOKOTA wrote: > syscons is already capable of changing forground and background colors > via escape sequences. Is it not sufficient for your intended > application? > > Kazu > Since I received the same question in private mail more than once, I guess I'll have to clarify. What I'm after is not exactly color changes, but *palette* changes - changing the RGB/HLS components of an existing color index, in order to display a new color. I'm writing a full-screen interactive console application (and yes, it has to be a console app for many reasons). One of the design requirements is a customizable palette, so users can have some say about what they'll be staring at for hours day after day :) G'luck, Peter -- This sentence contradicts itself - or rather - well, no, actually it doesn't! > >Hi, > > > >I'm thinking of messing with the syscons ioctl handler to allow setting > >of color values - all EGA- and VGA-compatible video controllers allow this. > >The idea is to later define my termcap(5) entry to let ncurses deal with > >color setting. > > > >termcap(5) lists the 'cc' - 'can change color' and 'Ic' - 'initialize color' > >capabilities. Setting the boolean 'cc' is easy, 'Ic' however presents a bit > >of a problem to me - does anyone know what it is set to on any other terms > >so I can keep a bit of compatibility here, or do I just randomly pick an esc > >sequence, and lead on a happy existence until someone else defines this same > >esc sequence to do something else? :) > > > >G'luck, > >Peter > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 1:17: 9 2001 Delivered-To: freebsd-hackers@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 E995037B69F for ; Tue, 9 Jan 2001 01:16:49 -0800 (PST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:3mBy/DHRJEBvHmxnc15St+2n/ZfPzKP0@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.11.0/3.7Wpl2) with ESMTP id f099GlH09050; Tue, 9 Jan 2001 18:16:48 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:JnHT+7U3/acrb0dSKtlryZkaWwrFzjm6@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 SAA09223; Tue, 9 Jan 2001 18:24:31 +0900 (JST) Message-Id: <200101090924.SAA09223@zodiac.mech.utsunomiya-u.ac.jp> To: Peter Pentchev Cc: freebsd-hackers@FreeBSD.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: escape sequence for 'Ic' terminal capability In-reply-to: Your message of "Tue, 09 Jan 2001 10:34:34 +0200." <20010109103434.E2550@ringworld.oblivion.bg> References: <20010109100501.C2550@ringworld.oblivion.bg> <200101090832.RAA08905@zodiac.mech.utsunomiya-u.ac.jp> <20010109103434.E2550@ringworld.oblivion.bg> Date: Tue, 09 Jan 2001 18:24:30 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Tue, Jan 09, 2001 at 05:32:29PM +0900, Kazutaka YOKOTA wrote: >> syscons is already capable of changing forground and background colors >> via escape sequences. Is it not sufficient for your intended >> application? >> >> Kazu >> > >Since I received the same question in private mail more than once, >I guess I'll have to clarify. What I'm after is not exactly color >changes, but *palette* changes - changing the RGB/HLS components >of an existing color index, in order to display a new color. > >I'm writing a full-screen interactive console application (and yes, >it has to be a console app for many reasons). One of the design >requirements is a customizable palette, so users can have some say >about what they'll be staring at for hours day after day :) In that case, have you looked at ioctls defined in /usr/include/sys/fbio.h: FBIO_GETPALETTE and FBIO_SETPALETTE? Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 1:29:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 0EF9B37B400 for ; Tue, 9 Jan 2001 01:29:29 -0800 (PST) Received: (qmail 23558 invoked by uid 1000); 9 Jan 2001 09:28:08 -0000 Date: Tue, 9 Jan 2001 11:28:07 +0200 From: Peter Pentchev To: Kazutaka YOKOTA Cc: freebsd-hackers@FreeBSD.org Subject: Re: escape sequence for 'Ic' terminal capability Message-ID: <20010109112807.F2550@ringworld.oblivion.bg> Mail-Followup-To: Kazutaka YOKOTA , freebsd-hackers@FreeBSD.org References: <20010109100501.C2550@ringworld.oblivion.bg> <200101090832.RAA08905@zodiac.mech.utsunomiya-u.ac.jp> <20010109103434.E2550@ringworld.oblivion.bg> <200101090924.SAA09223@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101090924.SAA09223@zodiac.mech.utsunomiya-u.ac.jp>; from yokota@zodiac.mech.utsunomiya-u.ac.jp on Tue, Jan 09, 2001 at 06:24:30PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 09, 2001 at 06:24:30PM +0900, Kazutaka YOKOTA wrote: > > >On Tue, Jan 09, 2001 at 05:32:29PM +0900, Kazutaka YOKOTA wrote: > >> syscons is already capable of changing forground and background colors > >> via escape sequences. Is it not sufficient for your intended > >> application? > >> > >> Kazu > >> > > > >Since I received the same question in private mail more than once, > >I guess I'll have to clarify. What I'm after is not exactly color > >changes, but *palette* changes - changing the RGB/HLS components > >of an existing color index, in order to display a new color. > > > >I'm writing a full-screen interactive console application (and yes, > >it has to be a console app for many reasons). One of the design > >requirements is a customizable palette, so users can have some say > >about what they'll be staring at for hours day after day :) > > In that case, have you looked at ioctls defined in /usr/include/sys/fbio.h: > FBIO_GETPALETTE and FBIO_SETPALETTE? > > Kazu Yes, I have, and I'm considering reusing that code, or possibly calling it. However, I still wonder why there isn't an escape sequence interface - kinda hard to specify ioctl's in termcap(5) :) -- G'luck, Peter -- This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 2:15: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 38C7E37B400 for ; Tue, 9 Jan 2001 02:14:44 -0800 (PST) Received: from gorean.org (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id CAA63405; Tue, 9 Jan 2001 02:14:41 -0800 (PST) (envelope-from DougB@gorean.org) Message-ID: <3A5AE490.D251F590@gorean.org> Date: Tue, 09 Jan 2001 02:14:40 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gerhard Sittig Cc: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gerhard Sittig wrote: > > [ citing from Doug's message in the "OT: silence ..." subthread > to keep the technical discussion in the "how to test" subthread ] > > On Tue, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote: > > > > You stated in another post that you wished I had elaborated > > more. I was in a hurry when I wrote that post, so here are more > > details. While this is, as you say, "an eternal problem," it is > > not a problem entirely without remedy. The proper solution is > > simply to avoid scheduling mission/time critical events during > > the DST change period for your time zone. Without improperly > > revealing sources, I can say that I did a lot of research on > > this topic in a past life, and it is by no means clear that > > your proposed solution is the best one. > > Well, the "don't schedule jobs for these times" is the problem > here: The fact that all FreeBSD users are potentially struck is > caused by the jobs execution time to be delivered with the > distribution. It's not a wanton act of some administrators to > schedule their jobs this way, but it's the status after > installing FreeBSD on a machine. Plus the fact that this machine > (by chance? but it's an increasing chance as has been stated in > an other message) is located in a region with DST changes. You're blowing the significance of this part of your argument WAY out of proportion. After long discussion we've picked times for the periodic jobs that are the best overall choices, and you make my followup point for me below. > Of course everybody knows there's a need to check, correct and > add quite a few things an installer is not capable to handle in > all the variety of arrangements humans come up with. And some > things aren't just the job of an installer. But how many of us > are aware of checking scheduled jobs' timings and how they could > collide in the near future (in the next year after setting up the > machine) or in the general future (when you somehow "forgot" the > machine because it just works flawlessly)? The people to whom this is important already know how to check it, and set it accordingly. This is the last thing a novice admin needs to worry about. > It's not that I want to talk you into something you don't want. But that's exactly what you're trying to do. I will not bother to re-re-restate my points as to why what you're proposing is a bad idea. Do all the testing you want, but make sure you understand that there will be vigorous resistance to incorporating your proposed changes. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 2:31:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id A15FA37B400 for ; Tue, 9 Jan 2001 02:31:25 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 14Fw3i-000KZm-0K; Tue, 9 Jan 2001 10:31:19 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.1/8.8.8) with ESMTP id f09AVHs22335; Tue, 9 Jan 2001 10:31:18 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 9 Jan 2001 10:31:17 +0000 (GMT) From: Doug Rabson To: Vijo Cherian Cc: hackers@freebsd.org, mhsu@clickarray.com Subject: Re: kobj, makedevops.pl etc. In-Reply-To: <01010817314705.21412@b52.clickarray.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 8 Jan 2001, Vijo Cherian wrote: > hi, > > I have some questions... but most of them may be prerry lame because I am new > to FreeBSD. > > I am running 5.0 and I have a driver for a card which was written for 4.1. > The driver uses bus_if.h, device_if.h and pci_if.h and these files are generated > by makedevops.pl. The driver is written as a module and is loaded using kldload. > But loading fails because BUS_READ_IVAR and friends are not available. > Using makeobjops.pl works. My questions are > 1. Is this the right way? > 2. When did kobj find place in the kernel? (which release) > (that is what makeobjops.pl does,right?) > 3. If all that I did is wrong, what is the right way? > 4. Can you point me to a driver that can be loaded as kld? > > waiting to see how the community treats a new convert ;-) Unfortunately, the device driver ABIs (and many others) are different between 4.1 and 5.0-current so you cannot load a binary driver intended for 4.1 on a 5.0-current system. For newbus at least, the programming API is the same, although in 5.0 it uses kobj for its object model instead of the slightly less flexible system used in 4.x. You need to rebuild the driver, using makeobjops.pl instead of makedevops.pl. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 2:38: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by hub.freebsd.org (Postfix) with ESMTP id 8644437B400 for ; Tue, 9 Jan 2001 02:37:46 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 9 Jan 2001 10:37:24 +0000 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 14Fw7q-0004lq-00; Tue, 09 Jan 2001 10:35:34 +0000 Date: Tue, 9 Jan 2001 10:35:34 +0000 (GMT) From: Jan Grant To: Doug Barton Cc: Gerhard Sittig , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <3A5AE490.D251F590@gorean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 9 Jan 2001, Doug Barton wrote: > But that's exactly what you're trying to do. I will not bother to > re-re-restate my points as to why what you're proposing is a bad idea. > Do all the testing you want, but make sure you understand that there > will be vigorous resistance to incorporating your proposed changes. Not if there's a cron_dtrt="NO" # Get cron to do the right thing in /etc/defaults/rc.conf -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk If it's broken really badly - don't fix it either. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 2:41:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id 15CE537B400 for ; Tue, 9 Jan 2001 02:40:58 -0800 (PST) Received: (qmail 30466 invoked by uid 1003); 9 Jan 2001 10:40:44 -0000 Date: Tue, 9 Jan 2001 12:40:44 +0200 From: Neil Blakey-Milner To: Doug Barton Cc: Gerhard Sittig , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010109124044.A16276@mithrandr.moria.org> References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5AE490.D251F590@gorean.org>; from DougB@gorean.org on Tue, Jan 09, 2001 at 02:14:40AM -0800 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue 2001-01-09 (02:14), Doug Barton wrote: > Gerhard Sittig wrote: > > > > [ citing from Doug's message in the "OT: silence ..." subthread > > to keep the technical discussion in the "how to test" subthread ] > > > > On Tue, Jan 05, 2001 at 14:45 -0800, Doug Barton wrote: > > > > > > You stated in another post that you wished I had elaborated > > > more. I was in a hurry when I wrote that post, so here are more > > > details. While this is, as you say, "an eternal problem," it is > > > not a problem entirely without remedy. The proper solution is > > > simply to avoid scheduling mission/time critical events during > > > the DST change period for your time zone. Without improperly > > > revealing sources, I can say that I did a lot of research on > > > this topic in a past life, and it is by no means clear that > > > your proposed solution is the best one. > > > > Well, the "don't schedule jobs for these times" is the problem > > here: The fact that all FreeBSD users are potentially struck is > > caused by the jobs execution time to be delivered with the > > distribution. It's not a wanton act of some administrators to > > schedule their jobs this way, but it's the status after > > installing FreeBSD on a machine. Plus the fact that this machine > > (by chance? but it's an increasing chance as has been stated in > > an other message) is located in a region with DST changes. > > You're blowing the significance of this part of your argument WAY out > of proportion. After long discussion we've picked times for the periodic > jobs that are the best overall choices, and you make my followup point > for me below. You yourself, in your commit, say that "Please note that this time was chosen with input from people in various countries with various methods and schedules for switching to and from DST. There is no perfect time to schedule this job that works for everyone, but this time both A) Works for more people, and B) Causes problems for fewer people. And, ultimately, you can always change it if you need to." Now, consider NTP calibrations, possibly automated every few hours (one suggested way of doing so, and much easier than setting up ntpd from scratch, since we don't come with a default or example ntp.conf, but that's another story). Now, say that adjusts the clock back 5 minutes. Any hourly run (which may specifically need to be run only every hour, on the hour, say for generating statistics, log rotation, or whatever, would then be run twice in quick succession. Knock it forward enough, and you'll skip jobs (note, I'm talking stepping, not slew). That isn't expected behaviour to the vast majority of people, since I've only ever heard complaints about the DST handling, and never has anyone suggested before you that we should just ignore it, and that in fact, people are ignorant if they expect cron to do this work for them. Now, the fix itself is to honour DST changes, and that will work for everyone. An alternative is to add better heuristics to see if the change in time is "almost exactly" a factor of 30 minutes (do any countries do anything but exactly 1 hour changes?). This way, we never repeat jobs, and never lose jobs. Which makes cron reliable. "Timing" problems with separate cron jobs will always be a hack job, and undoubtably they'll lose or double jobs by mistake anyway. > > Of course everybody knows there's a need to check, correct and > > add quite a few things an installer is not capable to handle in > > all the variety of arrangements humans come up with. And some > > things aren't just the job of an installer. But how many of us > > are aware of checking scheduled jobs' timings and how they could > > collide in the near future (in the next year after setting up the > > machine) or in the general future (when you somehow "forgot" the > > machine because it just works flawlessly)? > > The people to whom this is important already know how to check it, and > set it accordingly. This is the last thing a novice admin needs to worry > about. The novice expects that if you set up a job to run once a day, by telling it to run at 2am, it will be run at 2am, exactly once. In fact, that's the behaviour I expect. Without this code, cron is doing something stupid - running a daily thing more than once a day, or maybe even not at all. > > It's not that I want to talk you into something you don't want. > > But that's exactly what you're trying to do. I will not bother to > re-re-restate my points as to why what you're proposing is a bad idea. > Do all the testing you want, but make sure you understand that there > will be vigorous resistance to incorporating your proposed changes. And when you finally realize that everyone else thinks this is a great idea, you'll stop your sole campaign to vigourously resist the incorporation of this code? If it helps, we can have an option ('-i') to ignore DST changes, for "advanced administrators who know what they're doing and expect jobs to be lost or run multiple times depending on exactly when they schedule their jobs", and the "clueless newbies who ignorantly expect a job scheduled at 2am to not only run, but run only once" can be served too, by default. (Attitude almost entirely feigned to match Doug's) Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 3: 1:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.klondike.ru (ns.klondike.ru [195.170.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 9C68537B402 for ; Tue, 9 Jan 2001 03:01:15 -0800 (PST) Received: from freebsd.klondike.ru (freebsd [195.170.237.64]) by ns.klondike.ru (8.9.3/8.9.3) with SMTP id OAA11391 for ; Tue, 9 Jan 2001 14:01:09 +0300 (MSK) Message-Id: <200101091101.OAA11391@ns.klondike.ru> Date: Tue, 9 Jan 2001 14:00:22 +0000 From: Kaltashkin Eugene To: freebsd-hackers@freebsd.org Subject: sswrap broken ? X-Mailer: stuphead version 0.4.5 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Organization: Klondike Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Today found any problem. What is it ? freebsd:/usr/ports/security/sslwrap# make ===> Building for sslwrap-2.0.5 cc -o sslwrap s_server.c s_socket.c s_cb.c -O -pipe -DFLAT_INC -DOPENSSL="\"openssl/\"" -L/usr/lib -lssl -lcrypto -I/usr/include s_server.c: In function `sv_body': s_server.c:621: warning: assignment makes pointer from integer without a cast /tmp/cce37081.o: In function `sv_body': /tmp/cce37081.o(.text+0xc29): undefined reference to `Malloc' /tmp/cce37081.o(.text+0xf3f): undefined reference to `Free' /tmp/ccO37081.o: In function `do_server': /tmp/ccO37081.o(.text+0x36c): undefined reference to `Free' /tmp/ccO37081.o: In function `do_accept': /tmp/ccO37081.o(.text+0x571): undefined reference to `Malloc' *** Error code 1 Stop in /usr/ports/security/sslwrap/work/sslwrap205. *** Error code 1 Stop in /usr/ports/security/sslwrap. *** Error code 1 Stop in /usr/ports/security/sslwrap. *** Error code 1 Stop in /usr/ports/security/sslwrap. freebsd:/usr/ports/security/sslwrap# uname -a FreeBSD freebsd.klondike.ru 4.2-STABLE FreeBSD 4.2-STABLE #2: Fri Dec 8 16:16:33 GMT 2000 zhecka@freebsd.klondike.ru:/usr/src/sys/compile/zhecka i386 freebsd:/usr/ports/security/sslwrap# -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 3:12:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 0303E37B402 for ; Tue, 9 Jan 2001 03:11:51 -0800 (PST) Received: (qmail 26942 invoked by uid 1000); 9 Jan 2001 11:10:38 -0000 Date: Tue, 9 Jan 2001 13:10:21 +0200 From: Peter Pentchev To: Kaltashkin Eugene Cc: freebsd-ports@freebsd.org, ZGabor@CoDe.HU Subject: Re: sswrap broken ? Message-ID: <20010109131021.J2550@ringworld.oblivion.bg> Mail-Followup-To: Kaltashkin Eugene , freebsd-ports@freebsd.org, ZGabor@CoDe.HU References: <200101091101.OAA11391@ns.klondike.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101091101.OAA11391@ns.klondike.ru>; from zhecka@klondike.ru on Tue, Jan 09, 2001 at 02:00:22PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This post would be better suited for the -ports mailing list, as it is a list which deals specifically with the FreeBSD Ports Collection. Also, one of the first people you could ask about a port problem would be the port maintainer as specified in the Makefile. In this case, it is ZGabor@CoDe.HU, and I'm CC'ing him. I tried to reproduce your problem, but I failed on an even earlier stage: [root@ringworld:v2 /usr/ports/security/sslwrap]# make extract >> sslwrap.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from http://www.rickk.com/sslwrap/. Receiving sslwrap.tar.gz (21170 bytes): 100% 21170 bytes transferred in 17.0 seconds (1.22 kBps) ===> Extracting for sslwrap-2.0.5 >> Checksum mismatch for sslwrap.tar.gz. Make sure the Makefile and distinfo file (/usr/ports/security/sslwrap/distinfo) are up to date. If you are absolutely sure you want to override this check, type "make NO_CHECKSUM=yes [other args]". *** Error code 1 It seems somebody changed the distfile on www.rickk.com :( In a day or two, I'll try to fetch the old file from a FreeBSD mirror, and see if it builds. Meanwhile, I think this is something the port maintainer should look into :) G'luck, Peter -- I am jealous of the first word in this sentence. On Tue, Jan 09, 2001 at 02:00:22PM +0000, Kaltashkin Eugene wrote: > Today found any problem. What is it ? > > freebsd:/usr/ports/security/sslwrap# make > ===> Building for sslwrap-2.0.5 > cc -o sslwrap s_server.c s_socket.c s_cb.c -O -pipe -DFLAT_INC -DOPENSSL="\"openssl/\"" -L/usr/lib -lssl -lcrypto -I/usr/include > s_server.c: In function `sv_body': > s_server.c:621: warning: assignment makes pointer from integer without a cast > /tmp/cce37081.o: In function `sv_body': > /tmp/cce37081.o(.text+0xc29): undefined reference to `Malloc' > /tmp/cce37081.o(.text+0xf3f): undefined reference to `Free' > /tmp/ccO37081.o: In function `do_server': > /tmp/ccO37081.o(.text+0x36c): undefined reference to `Free' > /tmp/ccO37081.o: In function `do_accept': > /tmp/ccO37081.o(.text+0x571): undefined reference to `Malloc' > *** Error code 1 > > Stop in /usr/ports/security/sslwrap/work/sslwrap205. > *** Error code 1 > > Stop in /usr/ports/security/sslwrap. > *** Error code 1 > > Stop in /usr/ports/security/sslwrap. > *** Error code 1 > > Stop in /usr/ports/security/sslwrap. > freebsd:/usr/ports/security/sslwrap# uname -a > FreeBSD freebsd.klondike.ru 4.2-STABLE FreeBSD 4.2-STABLE #2: Fri Dec 8 16:16:33 GMT 2000 zhecka@freebsd.klondike.ru:/usr/src/sys/compile/zhecka i386 > freebsd:/usr/ports/security/sslwrap# To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 4: 5:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id BB29937B400 for ; Tue, 9 Jan 2001 04:05:01 -0800 (PST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id OAA29575; Tue, 9 Jan 2001 14:04:52 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 29494; Tue Jan 9 14:04:42 2001 Message-ID: <3A5AE617.E8644889@cequrux.com> Date: Tue, 09 Jan 2001 12:21:11 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Cc: markster@marko.net Subject: Size of struct ifreq/returned buffer of SIOCGIFCONF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all I am attempting to port the cheops network mapping/diagnostic program from Linux to FreeBSD (see www.marko.net/cheops). One of the first snags I have hit comes in using SIOCGIFCONF to queries the network interface names and addresses. The cheops code assumes that the buffer returned will have an array of struct ifreq elements. Stevens vol 2 p 121 on the other hand shows the returned buffer having an array of elements each 36 bytes in size. I figure that under Linux, sizeof(struct ifreq) must be 36 bytes so this works well, but under FreeBSD sizeof(struct ifreq) returns 32 bytes. I haven't been able to find any definitive documentation on SIOCGIFCONF, so I'm note sure whether this means that in 4.4BSD-Lite sizeof(struct ifreq) was indeed 36 bytes, and that the return buffer should contain an array of these structures, and that FreeBSD has broken this, or whether the only assumption that can be made about the return buffer is that it is an array of 36-byte elts, the first 16 bytes of each one being a name and the remainder being an address - in which case the cheops code is wrong, as it is assuming that these are struct ifreq's. Can anyone shed any light on this? Another interesting aspect is that the returned buffer under FreeBSD does have 36-byte elements, but the name of every second entry is empty. It would be interesting to know why this is the case too. regards Graham -- Dr Graham Wheeler E-mail: gram@cequrux.com Director, Research and Development WWW: http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN Specialists Fax: +27(21)424-3656 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 4:15:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id 9456237B400 for ; Tue, 9 Jan 2001 04:15:17 -0800 (PST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id OAA00630; Tue, 9 Jan 2001 14:15:14 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 534; Tue Jan 9 14:14:14 2001 Message-ID: <3A5AE854.F769B86C@cequrux.com> Date: Tue, 09 Jan 2001 12:30:44 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Cc: markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just a follow up on this: on Stevens vol 2 pg 117, code line 299, is the implication that the returned buffer DOES hold an array of struct ifreq elements. So this does seem to indicate that something may be broken on FreeBSD. At the very least there is some ambiguity - is this an array of struct ifreq's, or an array of struct ifreq's at 36 byte intervals? Just to add to my confusion, the value returned in ifc_len is 784 - which is neither a multiple of 36, nor a multiple of sizeof(struct ifreq). Weirdfull. -- Dr Graham Wheeler E-mail: gram@cequrux.com Director, Research and Development WWW: http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN Specialists Fax: +27(21)424-3656 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 4:47:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 83B1437B400; Tue, 9 Jan 2001 04:47:06 -0800 (PST) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id EAA88501; Tue, 9 Jan 2001 04:47:05 -0800 (PST) Date: Tue, 9 Jan 2001 04:47:04 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Robert Lipe , freebsd-hackers@FreeBSD.org Subject: Re: kthread_exit & zombification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 8 Jan 2001, John Baldwin wrote: > > Unloading modules adds all sorts of new problems. Right now the WITNESS code > will do bad bad things if you kldunload a module that contains a mutex. Even > if the mutex is mtx_destroy'd because it still has a reference to its name in > the internal lists it keeps. > what? I have mutexes in structures I free().. I presumed doing a mtx_destroy() would be enough! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 5: 6:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 2E95237B401 for ; Tue, 9 Jan 2001 05:06:03 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 14FySy-0001ZW-00; Tue, 09 Jan 2001 15:05:32 +0200 Date: Tue, 9 Jan 2001 15:05:32 +0200 (IST) From: Roman Shterenzon To: Greg Lehey , Yonatan Bokovza Cc: Subject: Re: Dump analysis (was: Ideas? (fwd)) In-Reply-To: <20010108185709.D83353@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-876146300-261693850-979045532=:31208" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---876146300-261693850-979045532=:31208 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 8 Jan 2001, Greg Lehey wrote: > On Monday, 8 January 2001 at 10:04:44 +0200, Roman Shterenzon wrote: > > * Roman Shterenzon [010107 10:24] wrote: > >> Hi, > >> > >> Could you please take a look at : > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=24019 > >> It's my friend's PR. Can you give me some hints on how can I debug this > >> issue. I'm completely puzzled here. > >> It panics on "goto out" with page fault. What I understand from it is that > (kgdb) x/10i epread > (kgdb) x/10i 0xc012a038 > > (kgdb) x/10i epread > 0xc0165f8c : push %ebp > 0xc0165f8d : mov %esp,%ebp > 0xc0165f8f : sub $0x1c,%esp > 0xc0165f92 : push %edi > 0xc0165f93 : push %esi > 0xc0165f94 : push %ebx > 0xc0165f95 : mov 0x8(%ebp),%eax > 0xc0165f98 : mov %eax,0xfffffff4(%ebp) > 0xc0165f9b : mov 0x118(%eax),%edx > 0xc0165fa1 : add $0x8,%edx The addresses changed (he erased the old crash dump, but attached's the gdb output from the dump we captured). The "lea" instruction, should it be there? --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] ---876146300-261693850-979045532=:31208 Content-Type: TEXT/plain; name="gdb.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="gdb.txt" U2NyaXB0IHN0YXJ0ZWQgb24gVHVlIEphbiAgOSAxNDo0ODoxNiAyMDAxDQpU ZW11amluOi9yb290IyBnZGIgLWsgL3Vzci9vYmovdXNyL3NyYy9zeXMvVEVN VUpJTi9rZXJuZWwuZGVidWcgL3Vzci9jcmFzaC92bWNvcmUuMQ0KR05VIGdk YiA0LjE4DQpDb3B5cmlnaHQgMTk5OCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp b24sIEluYy4NCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRo ZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUNCndl bGNvbWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBv ZiBpdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMuDQpUeXBlICJzaG93IGNv cHlpbmciIHRvIHNlZSB0aGUgY29uZGl0aW9ucy4NClRoZXJlIGlzIGFic29s dXRlbHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFu dHkiIGZvciBkZXRhaWxzLg0KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMg ImkzODYtdW5rbm93bi1mcmVlYnNkIi4uLg0KSWRsZVBURCAzNjI0OTYwDQpp bml0aWFsIHBjYiBhdCAyZGJiNjANCnBhbmljc3RyOiBmcm9tIGRlYnVnZ2Vy DQpwYW5pYyBtZXNzYWdlczoNCi0tLQ0KRmF0YWwgdHJhcCAxMjogcGFnZSBm YXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQ0KZmF1bHQgdmlydHVhbCBhZGRy ZXNzCT0gMHg3M2MwN2EwMA0KZmF1bHQgY29kZQkJPSBzdXBlcnZpc29yIHJl YWQsIHBhZ2Ugbm90IHByZXNlbnQNCmluc3RydWN0aW9uIHBvaW50ZXIJPSAw eDg6MHhjMDEyYTBhMA0Kc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgxMDow eGMwMjkxNDkwDQpmcmFtZSBwb2ludGVyCSAgICAgICAgPSAweDEwOjB4YzAy OTE0YjgNCmNvZGUgc2VnbWVudAkJPSBiYXNlIDB4MCwgbGltaXQgMHhmZmZm ZiwgdHlwZSAweDFiDQoJCQk9IERQTCAwLCBwcmVzIDEsIGRlZjMyIDEsIGdy YW4gMQ0KcHJvY2Vzc29yIGVmbGFncwk9IGludGVycnVwdCBlbmFibGVkLCBy ZXN1bWUsIElPUEwgPSAwDQpjdXJyZW50IHByb2Nlc3MJCT0gSWRsZQ0KaW50 ZXJydXB0IG1hc2sJCT0gbmV0IGJpbyBjYW0gDQpwYW5pYzogZnJvbSBkZWJ1 Z2dlcg0KcGFuaWM6IGZyb20gZGVidWdnZXINClVwdGltZTogMjltNTdzDQoN CmR1bXBpbmcgdG8gZGV2ICNhZC8weDMwMDAxLCBvZmZzZXQgMjYyNTI4DQpk dW1wIGF0YTA6IHJlc2V0dGluZyBkZXZpY2VzIC4uIGRvbmUNCjEyNyAxMjYg MTI1IDEyNCAxMjMgMTIyIDEyMSAxMjAgMTE5IDExOCAxMTcgMTE2IDExNSAx MTQgMTEzIDExMiAxMTEgMTEwIDEwOSAxMDggMTA3IDEwNiAxMDUgMTA0IDEw MyAxMDIgMTAxIDEwMCA5OSA5OCA5NyA5NiA5NSA5NCA5MyA5MiA5MSA5MCA4 OSA4OCA4NyA4NiA4NSA4NCA4MyA4MiA4MSA4MCA3OSA3OCA3NyA3NiA3NSA3 NCA3MyA3MiA3MSA3MCA2OSA2OCA2NyA2NiA2NSA2NCA2MyA2MiA2MSA2MCA1 OSA1OCA1NyA1NiA1NSA1NCA1MyA1MiA1MSA1MCA0OSA0OCA0NyA0NiA0NSA0 NCA0MyA0MiA0MSA0MCAzOSAzOCAzNyAzNiAzNSAzNCAzMyAzMiAzMSAzMCAy OSAyOCAyNyAyNiAyNSAyNCAyMyAyMiAyMSAyMCAxOSAxOCAxNyAxNiAxNSAx NCAxMyAxMiAxMSAxMCA5IDggNyA2IDUgNCAzIDIgMSAwIA0KLS0tDQojMCAg ZHVtcHN5cyAoKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3du LmM6NDY5DQo0NjkJCWlmIChkdW1waW5nKyspIHsNCihrZ2RiKSBidA0KIzAg IGR1bXBzeXMgKCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93 bi5jOjQ2OQ0KIzEgIDB4YzAxNTBmYjQgaW4gYm9vdCAoaG93dG89MjYwKSBh dCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6MzA5DQojMiAg MHhjMDE1MTM1NSBpbiBwYW5pYyAoZm10PTB4YzAyNTk0MTQgImZyb20gZGVi dWdnZXIiKQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRv d24uYzo1NTYNCiMzICAweGMwMTI2ZGQ5IGluIGRiX3BhbmljIChhZGRyPS0x MDcyNTIxMDU2LCBoYXZlX2FkZHI9MCwgY291bnQ9LTEsIA0KICAgIG1vZGlm PTB4YzAyOTEyZmMgIiIpIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFu ZC5jOjQzMw0KIzQgIDB4YzAxMjZkNzcgaW4gZGJfY29tbWFuZCAobGFzdF9j bWRwPTB4YzAyOTU5NGMsIGNtZF90YWJsZT0weGMwMjk1N2FjLCANCiAgICBh dXhfY21kX3RhYmxlcD0weGMwMmQ2ZmZjKSBhdCAvdXNyL3NyYy9zeXMvZGRi L2RiX2NvbW1hbmQuYzozMzMNCiM1ICAweGMwMTI2ZTNlIGluIGRiX2NvbW1h bmRfbG9vcCAoKSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo0 NTUNCiM2ICAweGMwMTI4ZmRmIGluIGRiX3RyYXAgKHR5cGU9MTIsIGNvZGU9 MCkgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl90cmFwLmM6NzENCiM3ICAweGMw MjM4MDJjIGluIGtkYl90cmFwICh0eXBlPTEyLCBjb2RlPTAsIHJlZ3M9MHhj MDI5MTQ1MCkNCiAgICBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2RiX2lu dGVyZmFjZS5jOjE1OA0KIzggIDB4YzAyNDQ0N2MgaW4gdHJhcF9mYXRhbCAo ZnJhbWU9MHhjMDI5MTQ1MCwgZXZhPTE5NDE5OTM5ODQpDQogICAgYXQgL3Vz ci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6OTQ2DQojOSAgMHhjMDI0NDEz ZCBpbiB0cmFwX3BmYXVsdCAoZnJhbWU9MHhjMDI5MTQ1MCwgdXNlcm1vZGU9 MCwgZXZhPTE5NDE5OTM5ODQpDQogICAgYXQgL3Vzci9zcmMvc3lzL2kzODYv aTM4Ni90cmFwLmM6ODQ0DQojMTAgMHhjMDI0M2NjYiBpbiB0cmFwIChmcmFt ZT17dGZfZnMgPSAtMTA2NjEzOTYzMiwgdGZfZXMgPSAtMTA2NjEzOTYzMiwg DQogICAgICB0Zl9kcyA9IC0xMDY2MTM5NjMyLCB0Zl9lZGkgPSAxLCB0Zl9l c2kgPSAxLCB0Zl9lYnAgPSAtMTA3MTA0OTU0NCwgDQogICAgICB0Zl9pc3Ag PSAtMTA3MTA0OTYwNCwgdGZfZWJ4ID0gNzIyNTQxNiwgdGZfZWR4ID0gMTk0 MTk5Mzk4NCwgDQogICAgICB0Zl9lY3ggPSAtMTA1MzA3OTU1MiwgdGZfZWF4 ID0gNzIyNTQxNiwgdGZfdHJhcG5vID0gMTIsIHRmX2VyciA9IDAsIA0KICAg ICAgdGZfZWlwID0gLTEwNzI1MjEwNTYsIHRmX2NzID0gOCwgdGZfZWZsYWdz ID0gNjYwNTQsIHRmX2VzcCA9IDgyMDgsIA0KICAgICAgdGZfc3MgPSAtMTA1 MzA3OTU1Mn0pIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjQ0 Mw0KIzExIDB4YzAxMmEwYTAgaW4gZXByZWFkIChzYz0weGMxM2I0ODAwKSBh dCAvdXNyL3NyYy9zeXMvZGV2L2VwL2lmX2VwLmM6NjkwDQojMTIgMHhjMDEy OWYxYiBpbiBlcF9pbnRyIChhcmc9MHhjMTNiNDgwMCkgYXQgL3Vzci9zcmMv c3lzL2Rldi9lcC9pZl9lcC5jOjU3Mg0KLS0tVHlwZSA8cmV0dXJuPiB0byBj b250aW51ZSwgb3IgcSA8cmV0dXJuPiB0byBxdWl0LS0tDQojMTMgMHhjMDE0 ZjMzYiBpbiBhZGRfaW50ZXJydXB0X3JhbmRvbW5lc3MgKHZzYz0weGMwMmYy ZDY0KQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcmFuZG9tLmM6 MjQ1DQojMTQgMHhjMDIzOWU3YSBpbiB2ZWMzICgpDQojMTUgMHhjMDE5OGRh NyBpbiBldGhlcl9vdXRwdXQgKGlmcD0weGMxM2I0ODAwLCBtPTB4YzA3M2Jm MDAsIGRzdD0weGMwMmRlYjU0LCANCiAgICBydDA9MHhjMTNmY2UwMCkgYXQg L3Vzci9zcmMvc3lzL25ldC9pZl9ldGhlcnN1YnIuYzozNTQNCiMxNiAweGMw MWFmMzEzIGluIGlwX291dHB1dCAobTA9MHhjMDczYmYwMCwgb3B0PTB4MCwg cm89MHhjMDJkZWI1MCwgZmxhZ3M9MSwgDQogICAgaW1vPTB4MCkgYXQgL3Vz ci9zcmMvc3lzL25ldGluZXQvaXBfb3V0cHV0LmM6Nzg3DQojMTcgMHhjMDFh ZTUxNSBpbiBpcF9mb3J3YXJkIChtPTB4YzA3M2JmMDAsIHNyY3J0PTApDQog ICAgYXQgL3Vzci9zcmMvc3lzL25ldGluZXQvaXBfaW5wdXQuYzoxNTUyDQoj MTggMHhjMDFhZDU2NyBpbiBpcF9pbnB1dCAobT0weGMwNzNiZjAwKQ0KICAg IGF0IC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX2lucHV0LmM6NTYzDQojMTkg MHhjMDFhZDhkMyBpbiBpcGludHIgKCkgYXQgL3Vzci9zcmMvc3lzL25ldGlu ZXQvaXBfaW5wdXQuYzo3NTkNCihrZ2RiKSB4LzIwaSBlcHJlYWQNCjB4YzAx MmEwNmMgPGVwcmVhZD46CXB1c2ggICAlZWJwDQoweGMwMTJhMDZkIDxlcHJl YWQrMT46CW1vdiAgICAlZXNwLCVlYnANCjB4YzAxMmEwNmYgPGVwcmVhZCsz PjoJc3ViICAgICQweDFjLCVlc3ANCjB4YzAxMmEwNzIgPGVwcmVhZCs2PjoJ cHVzaCAgICVlZGkNCjB4YzAxMmEwNzMgPGVwcmVhZCs3PjoJcHVzaCAgICVl c2kNCjB4YzAxMmEwNzQgPGVwcmVhZCs4PjoJcHVzaCAgICVlYngNCjB4YzAx MmEwNzUgPGVwcmVhZCs5PjoJbW92ICAgIDB4OCglZWJwKSwlZWF4DQoweGMw MTJhMDc4IDxlcHJlYWQrMTI+Ogltb3YgICAgJWVheCwweGZmZmZmZmY0KCVl YnApDQoweGMwMTJhMDdiIDxlcHJlYWQrMTU+Ogltb3YgICAgMHgxMTgoJWVh eCksJWVkeA0KMHhjMDEyYTA4MSA8ZXByZWFkKzIxPjoJYWRkICAgICQweDgs JWVkeA0KMHhjMDEyYTA4NCA8ZXByZWFkKzI0PjoJaW4gICAgICglZHgpLCVh eA0KMHhjMDEyYTA4NiA8ZXByZWFkKzI2PjoJbW92ICAgICVheCwweGZmZmZm ZmVjKCVlYnApDQoweGMwMTJhMDhhIDxlcHJlYWQrMzA+Ogltb3YgICAgMHhm ZmZmZmZlYyglZWJwKSwlZWR4DQoweGMwMTJhMDhkIDxlcHJlYWQrMzM+Ogl0 ZXN0ICAgJDB4NDAsJWRoDQoweGMwMTJhMDkwIDxlcHJlYWQrMzY+OglqZSAg ICAgMHhjMDEyYTEwYyA8ZXByZWFkKzE2MD4NCjB4YzAxMmEwOTIgPGVwcmVh ZCszOD46CW1vdiAgICAweGZmZmZmZmY0KCVlYnApLCVlY3gNCjB4YzAxMmEw OTUgPGVwcmVhZCs0MT46CWluY2wgICAweDRjKCVlY3gpDQoweGMwMTJhMDk4 IDxlcHJlYWQrNDQ+OglqbXAgICAgMHhjMDEyYTVmYyA8ZXByZWFkKzE0MjQ+ DQoweGMwMTJhMDlkIDxlcHJlYWQrNDk+OglsZWEgICAgMHgwKCVlc2kpLCVl c2kNCjB4YzAxMmEwYTAgPGVwcmVhZCs1Mj46CW1vdiAgICAoJWVkeCksJWVh eA0KKGtnZGIpIHgvMjBpIDB4YzAxMmEwOWUNCjB4YzAxMmEwOWUgPGVwcmVh ZCs1MD46CWpiZSAgICAweGMwMTJhMGEwIDxlcHJlYWQrNTI+DQoweGMwMTJh MGEwIDxlcHJlYWQrNTI+Ogltb3YgICAgKCVlZHgpLCVlYXgNCjB4YzAxMmEw YTIgPGVwcmVhZCs1ND46CW1vdiAgICAlZWF4LDB4YzAyZjQ3MmMNCjB4YzAx MmEwYTcgPGVwcmVhZCs1OT46CWRlY2wgICAweGMwMmY0NzQwDQoweGMwMTJh MGFkIDxlcHJlYWQrNjU+Ogltb3YgICAgJWRpLDB4MTAoJWVkeCkNCjB4YzAx MmEwYjEgPGVwcmVhZCs2OT46CWxlYSAgICAweDAoLCVlZGksNCksJWVheA0K MHhjMDEyYTBiOCA8ZXByZWFkKzc2PjoJaW5jbCAgIDB4YzAyZjQ3NDAoJWVh eCkNCjB4YzAxMmEwYmUgPGVwcmVhZCs4Mj46CW1vdmwgICAkMHgwLCglZWR4 KQ0KMHhjMDEyYTBjNCA8ZXByZWFkKzg4PjoJbW92bCAgICQweDAsMHg0KCVl ZHgpDQoweGMwMTJhMGNiIDxlcHJlYWQrOTU+OglsZWEgICAgMHgyYyglZWR4 KSwlZWF4DQoweGMwMTJhMGNlIDxlcHJlYWQrOTg+Ogltb3YgICAgJWVheCww eDgoJWVkeCkNCjB4YzAxMmEwZDEgPGVwcmVhZCsxMDE+Ogltb3Z3ICAgJDB4 MiwweDEyKCVlZHgpDQoweGMwMTJhMGQ3IDxlcHJlYWQrMTA3PjoJbW92bCAg ICQweDAsMHgxNCglZWR4KQ0KMHhjMDEyYTBkZSA8ZXByZWFkKzExND46CW1v dmwgICAkMHgwLDB4MjAoJWVkeCkNCjB4YzAxMmEwZTUgPGVwcmVhZCsxMjE+ Ogltb3ZsICAgJDB4MCwweDI4KCVlZHgpDQoweGMwMTJhMGVjIDxlcHJlYWQr MTI4PjoJbW92ICAgICVlZHgsJWVzaQ0KMHhjMDEyYTBlZSA8ZXByZWFkKzEz MD46CXB1c2ggICAlZWJ4DQoweGMwMTJhMGVmIDxlcHJlYWQrMTMxPjoJY2Fs bCAgIDB4YzAyNGNhODAgPHNwbHg+DQoweGMwMTJhMGY0IDxlcHJlYWQrMTM2 PjoJYWRkICAgICQweDQsJWVzcA0KMHhjMDEyYTBmNyA8ZXByZWFkKzEzOT46 CWptcCAgICAweGMwMTJhMTdhIDxlcHJlYWQrMjcwPg0KKGtnZGIpIHF1aXQN ClRlbXVqaW46L3Jvb3QjIA0KDQpTY3JpcHQgZG9uZSBvbiBUdWUgSmFuICA5 IDE0OjU4OjA0IDIwMDENCg== ---876146300-261693850-979045532=:31208-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 6: 8:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id A6C2037B400 for ; Tue, 9 Jan 2001 06:07:53 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 9 Jan 2001 14:07:52 +0000 (GMT) Date: Tue, 9 Jan 2001 14:07:52 +0000 From: David Malone To: Graham Wheeler Cc: freebsd-hackers@freebsd.org, markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF Message-ID: <20010109140752.A52761@walton.maths.tcd.ie> References: <3A5AE617.E8644889@cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5AE617.E8644889@cequrux.com>; from gram@cequrux.com on Tue, Jan 09, 2001 at 12:21:11PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 09, 2001 at 12:21:11PM +0200, Graham Wheeler wrote: > I am attempting to port the cheops network mapping/diagnostic program > from Linux to FreeBSD (see www.marko.net/cheops). One of the first snags > I have hit comes in using SIOCGIFCONF to queries the network interface > names and addresses. Could you use getifaddrs() for this? It would probably provide the info you need in a easier to digest form. If not, the code below might be useful. It gets a list of interface properties using sysctl(), but I believe the info is packed in the same way as it is for SIOCGIFCONF. (I wrote the code to figure out how the process worked, I think it is correct, but you never know). David. #include #include #include #include #include #include #include #include #include #include #include #include /* * This is an example of how to find info about the currently configured * interfaces. * * The code in rwhod and ifconfig if pretty hard to understand as it * doesn't really exploit the structure of what you're returned. We use * a sysctl to get the interface list, which returns a buffer with a * list of things each starting with: * * msglen * version * type * * The generic type used to with this start in the kernel seems to be * "struct rt_msghdr". For this sysctl we call it returns a message of * type RTM_IFINFO followed by a list of RTM_NEWADDR for each interface. * This corrisponds to the interface and each of the configurations you * "put" on it with ifconfig. * * The RTM_IFINFO message contains a struct if_msghdr followed by a * list of struct sockaddr. The RTM_NEWADDR contains a struct ifa_msghdr * followed by a list of struct sockaddr. * * The struct sockaddr's sizes have been truncated to the nearest * power of two into which the data will fit. The struct sockaddr's * included depend on what is apropriate to this message. You can tell * which of RTAX_* sockaddr's have been included by looking at the set * bits of ifm_addrs or ifam_addrs, so you have to expand them out into * an array of struct sockaddr's of size RTAX_MAX. */ void unpack_addrs(struct sockaddr *packed,struct sockaddr *unpacked,int rti_addrs); void print_addrs(struct sockaddr *unpacked,int rti_addrs); int main(int argc, char **argv) { char *buf, *lim, *next; /* For sysctl */ size_t needed; int mib[6]; struct rt_msghdr *rtm; /* For decoding messages */ struct if_msghdr *ifm; struct ifa_msghdr *ifam; struct sockaddr *packed_addr; /* For decoding addresses */ struct sockaddr unpacked_addr[RTAX_MAX]; mib[0] = CTL_NET; mib[1] = PF_ROUTE; mib[2] = 0; mib[3] = AF_INET; mib[4] = NET_RT_IFLIST; mib[5] = 0; if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) errx(1, "route-sysctl-estimate"); if ((buf = malloc(needed)) == NULL) errx(1, "malloc"); if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) errx(1, "actual retrieval of interface table"); lim = buf + needed; for( next = buf; next < lim; next += rtm->rtm_msglen ) { rtm = (struct rt_msghdr *)next; switch( rtm->rtm_type ) { case RTM_IFINFO: ifm = (struct if_msghdr *)next; packed_addr = (struct sockaddr *)(next + sizeof(struct if_msghdr)); printf("Found an interface.\n"); if( ifm->ifm_flags & IFF_UP ) printf("It is currently up.\n"); if( ifm->ifm_addrs != 0 ) { printf("These addresses were available:\n"); unpack_addrs(packed_addr,unpacked_addr, ifm->ifm_addrs); print_addrs(unpacked_addr,ifm->ifm_addrs); } else printf("No addresses were available.\n"); break; case RTM_NEWADDR: ifam = (struct ifa_msghdr *)next; packed_addr = (struct sockaddr *)(next + sizeof(struct ifa_msghdr)); printf("Found extra addresses associated with interface.\n"); unpack_addrs(packed_addr,unpacked_addr, ifam->ifam_addrs); print_addrs(unpacked_addr,ifam->ifam_addrs); break; default: errx(1, "unexpected rtm type"); } } exit(0); } #define ROUNDUP(a) \ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) void unpack_addrs(struct sockaddr *packed,struct sockaddr *unpacked,int rti_addrs) { int i; for( i = 0; i < RTAX_MAX; i++ ) { bzero(&unpacked[i],sizeof(unpacked[i])); if( rti_addrs & (1<sa_len); packed = (struct sockaddr *)(((char *)packed) + ROUNDUP(packed->sa_len)); } } } void print_addrs(struct sockaddr *unpacked,int rti_addrs) { int i; for( i = 0; i < RTAX_MAX; i++ ) { if( (rti_addrs & (1<sin_addr)); break; default: printf("address in family %d", unpacked[i].sa_family); break; } printf(".\n"); } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 6:21: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id B4D9F37B400 for ; Tue, 9 Jan 2001 06:20:44 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 9 Jan 2001 14:20:44 +0000 (GMT) Date: Tue, 9 Jan 2001 14:20:43 +0000 From: David Malone To: Graham Wheeler Cc: freebsd-hackers@freebsd.org, markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF Message-ID: <20010109142043.B52761@walton.maths.tcd.ie> References: <3A5AE854.F769B86C@cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5AE854.F769B86C@cequrux.com>; from gram@cequrux.com on Tue, Jan 09, 2001 at 12:30:44PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 09, 2001 at 12:30:44PM +0200, Graham Wheeler wrote: > Just a follow up on this: on Stevens vol 2 pg 117, code line 299, is the > implication that the returned buffer DOES hold an array of struct ifreq > elements. So this does seem to indicate that something may be broken on > FreeBSD. At the very least there is some ambiguity - is this an array of > struct ifreq's, or an array of struct ifreq's at 36 byte intervals? If you read the paragraph below that code, it notes that the ifreq structures are of variable length. The spacing depends on the size of the returned info. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 7:21:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id CD6D237B401 for ; Tue, 9 Jan 2001 07:21:11 -0800 (PST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id RAA17015; Tue, 9 Jan 2001 17:19:55 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 16924; Tue Jan 9 17:18:42 2001 Message-ID: <3A5B1390.A5453C78@cequrux.com> Date: Tue, 09 Jan 2001 15:35:12 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: David Malone Cc: hackers@freebsd.org, markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF References: <3A5AE617.E8644889@cequrux.com> <20010109140752.A52761@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Malone wrote: > > On Tue, Jan 09, 2001 at 12:21:11PM +0200, Graham Wheeler wrote: > > > I am attempting to port the cheops network mapping/diagnostic program > > from Linux to FreeBSD (see www.marko.net/cheops). One of the first snags > > I have hit comes in using SIOCGIFCONF to queries the network interface > > names and addresses. > > Could you use getifaddrs() for this? It would probably provide the > info you need in a easier to digest form. If not, the code below > might be useful. It gets a list of interface properties using > sysctl(), but I believe the info is packed in the same way as it > is for SIOCGIFCONF. I have code similar to yours I wrote myself used in our firewall product, but I would ideally like to have code that compiles and works on both Linux and FreeBSD, to reduce the work required to maintain the cheops port once it is done, and ease porting to other Unices as well - accessing kernel mibs or using other non-standard API calls will be my means of last resort. Marko - does Linux have getifaddrs()? I somehow doubt it... gr. -- Dr Graham Wheeler E-mail: gram@cequrux.com Director, Research and Development WWW: http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN Specialists Fax: +27(21)424-3656 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 7:24:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id 3440537B402 for ; Tue, 9 Jan 2001 07:24:12 -0800 (PST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id RAA17367; Tue, 9 Jan 2001 17:23:37 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 17277; Tue Jan 9 17:22:52 2001 Message-ID: <3A5B148A.5F139188@cequrux.com> Date: Tue, 09 Jan 2001 15:39:22 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: David Malone Cc: freebsd-hackers@freebsd.org, markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF References: <3A5AE854.F769B86C@cequrux.com> <20010109142043.B52761@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Malone wrote: > > If you read the paragraph below that code, it notes that the ifreq > structures are of variable length. The spacing depends on the size > of the returned info. That's true. In which case the cheops code is wrong, as it iterates through the list by incrementing a pointer to a struct ifreq. I'll try fix that and get Mark to test under Linux and hopefully get a portable solution. Thanks Dave. regards gram -- Dr Graham Wheeler E-mail: gram@cequrux.com Director, Research and Development WWW: http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN Specialists Fax: +27(21)424-3656 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 7:29:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id 8BD1737B69B for ; Tue, 9 Jan 2001 07:29:09 -0800 (PST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id RAA17627; Tue, 9 Jan 2001 17:26:42 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 17539; Tue Jan 9 17:25:58 2001 Message-ID: <3A5B1544.36E7F8C3@cequrux.com> Date: Tue, 09 Jan 2001 15:42:28 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: David Malone Cc: freebsd-hackers@freebsd.org, markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF References: <3A5AE854.F769B86C@cequrux.com> <20010109142043.B52761@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Malone wrote: > > If you read the paragraph below that code, it notes that the ifreq > structures are of variable length. The spacing depends on the size > of the returned info. > > David. Something that isn't clear to me - do you know (Mark for Linux, Dave or someone else for FreeBSD) whether it is reasonable to assume the ifr_name if the struct ifreq will be NUL terminated? I know that the name in a struct sockaddr_dl is not necessarily so terminated, but for the ifr_name field, if it isn't NUL terminated this could get really messy. -- Dr Graham Wheeler E-mail: gram@cequrux.com Director, Research and Development WWW: http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN Specialists Fax: +27(21)424-3656 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 7:39:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id BEC5F37B6A5 for ; Tue, 9 Jan 2001 07:39:14 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 9 Jan 2001 15:39:13 +0000 (GMT) To: Graham Wheeler Cc: freebsd-hackers@freebsd.org, markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF In-reply-to: Your message of "Tue, 09 Jan 2001 15:42:28 +0200." <3A5B1544.36E7F8C3@cequrux.com> X-Request-Do: Date: Tue, 09 Jan 2001 15:39:13 +0000 From: David Malone Message-ID: <200101091539.aa14307@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Something that isn't clear to me - do you know (Mark for Linux, Dave or > someone else for FreeBSD) whether it is reasonable to assume the > ifr_name if the struct ifreq will be NUL terminated? I know that the > name in a struct sockaddr_dl is not necessarily so terminated, but for > the ifr_name field, if it isn't NUL terminated this could get really > messy. In Steven's "Unix Network Programming" book (2nd Edition, Volume 1) he impliments a get_ifi_info function in section 16.6. He NUL terminates the interface name on the bottom of page 436. It would be more up to date and seems better explained than the TCP/IP Illustrated section on the same topic. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 7:51:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 158A337B6A8 for ; Tue, 9 Jan 2001 07:51:14 -0800 (PST) Received: from maccullagh.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 9 Jan 2001 15:51:13 +0000 (GMT) To: Graham Wheeler Cc: hackers@freebsd.org, markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF In-reply-to: Your message of "Tue, 09 Jan 2001 15:35:12 +0200." <3A5B1390.A5453C78@cequrux.com> X-Request-Do: Date: Tue, 09 Jan 2001 15:51:11 +0000 From: David Malone Message-ID: <200101091551.aa18666@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Marko - does Linux have getifaddrs()? I somehow doubt it... Linux should have getifaddrs() if it has support for IPv6 in userland libraries. There is an implimentation of it at: http://www.linux-ipv6.org/cvsweb/libinet6/?cvsroot=usagi-libc David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 9:33:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from haali.cs.msu.ru (haali.po.cs.msu.su [158.250.16.1]) by hub.freebsd.org (Postfix) with ESMTP id 67E3E37B69D for ; Tue, 9 Jan 2001 09:33:21 -0800 (PST) Received: (from mike@localhost) by haali.cs.msu.ru (8.9.3/8.9.3) id UAA10578; Tue, 9 Jan 2001 20:32:54 +0300 (MSK) (envelope-from mike) Date: Tue, 9 Jan 2001 20:32:53 +0300 From: "Mike E. Matsnev" To: Graham Wheeler Cc: David Malone , freebsd-hackers@FreeBSD.ORG, markster@marko.net Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF Message-ID: <20010109203253.A10537@haali.cs.msu.ru> References: <3A5AE854.F769B86C@cequrux.com> <20010109142043.B52761@walton.maths.tcd.ie> <3A5B148A.5F139188@cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5B148A.5F139188@cequrux.com>; from gram@cequrux.com on Tue, Jan 09, 2001 at 03:39:22PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 09, 2001 at 03:39:22PM +0200, Graham Wheeler wrote: > David Malone wrote: > > > > If you read the paragraph below that code, it notes that the ifreq > > structures are of variable length. The spacing depends on the size > > of the returned info. > > That's true. In which case the cheops code is wrong, as it iterates > through the list by incrementing a pointer to a struct ifreq. I'll try > fix that and get Mark to test under Linux and hopefully get a portable > solution. You can get the portable code from BIND, where it looks at the interface list. /Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 9:41: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 54DD337B6D2; Tue, 9 Jan 2001 09:40:45 -0800 (PST) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id MAA77292; Tue, 9 Jan 2001 12:40:44 -0500 (EST) Date: Tue, 9 Jan 2001 12:39:47 -0500 (EST) From: "Matthew N. Dodd" To: Mike Smith Cc: cristian nicolae , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 In-Reply-To: <200101090144.f091i1e02711@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 8 Jan 2001, Mike Smith wrote: > Actually, I'm not sure that it does. They use the Symbios part with > the integrated ARM processor, and assume that SCSI passthrough works. Maybe I was reading the docs for the passthrough interface incorrectly but I was under the impression that the RAID is paused while the passthrough interface is open. Granted, we don't have very current documentation... -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 9:49:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id B097037B6D5 for ; Tue, 9 Jan 2001 09:48:57 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f09HkJG65166; Tue, 9 Jan 2001 09:46:19 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 09 Jan 2001 09:48:31 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: kthread_exit & zombification Cc: freebsd-hackers@FreeBSD.org, Robert Lipe Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Jan-01 Julian Elischer wrote: > > > On Mon, 8 Jan 2001, John Baldwin wrote: >> >> Unloading modules adds all sorts of new problems. Right now the WITNESS >> code >> will do bad bad things if you kldunload a module that contains a mutex. >> Even >> if the mutex is mtx_destroy'd because it still has a reference to its name >> in >> the internal lists it keeps. >> > > what? > I have mutexes in structures I free().. > I presumed doing a mtx_destroy() would be enough! It is enough, the witness code is just broken right now. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 10:20:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 803AE37B6A5 for ; Tue, 9 Jan 2001 10:20:23 -0800 (PST) Received: from FreeBSD.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA79516; Tue, 9 Jan 2001 10:20:07 -0800 (PST) (envelope-from DougB@FreeBSD.org) Message-ID: <3A5B5656.E2AAF0B5@FreeBSD.org> Date: Tue, 09 Jan 2001 10:20:06 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Neil Blakey-Milner Cc: Gerhard Sittig , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010109124044.A16276@mithrandr.moria.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Neil Blakey-Milner wrote: > > On Tue 2001-01-09 (02:14), Doug Barton wrote: > > Gerhard Sittig wrote: > > You're blowing the significance of this part of your argument WAY out > > of proportion. After long discussion we've picked times for the periodic > > jobs that are the best overall choices, and you make my followup point > > for me below. > > You yourself, in your commit, say that . . . Yes, I said in my commit that we got, effectively, "the best overall" time to run the periodic jobs. I have said all along that this part of the system is not, and cannot be perfect. > Now, consider NTP calibrations, . . . Your example basically says, "Imagine a case where we have an admin with time-critical jobs who refuses to set up proper time synchronization." I don't think we should break cron to accomodate cases where admins insist on loading the gun and pointing it at their foot. I agree that setting up ntp properly is "one more thing" that you need to be able to do in order to be a real system admin, but I'm not sure how to lower this bar. Your point about us not including a sample ntp.conf file is well taken however, I'll have a go at that as soon as I get my current project off my plate. > Now, the fix itself is to honour DST changes, and that will work for > everyone. The point I'm trying (obviously in vain) to make is having cron do what amounts to "slewing its internal clock" will not work for everyone, and violates POLA. > An alternative is to add better heuristics to see if the > change in time is "almost exactly" a factor of 30 minutes (do any > countries do anything but exactly 1 hour changes?). Yes. > This way, we never repeat jobs, and never lose jobs. Which makes cron > reliable. For your definition of "reliable." Personally, I find cron doing exactly what it's told and not trying to think for itself "reliable." > "Timing" problems with separate cron jobs will always be a > hack job, and undoubtably they'll lose or double jobs by mistake anyway. You (pl.) keep referring to the "We need to hand-hold users who are too stupid to figure this stuff out for themselves" argument. While there are a lot of areas of the system that I try to make simpler and easier to understand, I don't see how we can possibly make this problem foolproof. The universe keeps producing better fools. > > > It's not that I want to talk you into something you don't want. > > > > But that's exactly what you're trying to do. I will not bother to > > re-re-restate my points as to why what you're proposing is a bad idea. > > Do all the testing you want, but make sure you understand that there > > will be vigorous resistance to incorporating your proposed changes. > > And when you finally realize that everyone else thinks this is a great > idea, In fact, I'm quite sure that this is not true. I happen to be the only one who is currently voicing opposition. > you'll stop your sole campaign to vigourously resist the > incorporation of this code? If it helps, we can have an option ('-i') > to ignore DST changes, for "advanced administrators who know what > they're doing and expect jobs to be lost or run multiple times depending > on exactly when they schedule their jobs", and the "clueless newbies who > ignorantly expect a job scheduled at 2am to not only run, but run only > once" can be served too, by default. At minimum, the proposed change would have to be described in detail in the man page so that people who expect traditional cron behavior will know what the heck is going on when cron starts to think for itself. I would prefer that this new behavior be an option that is off by default, however there would have to be an option to turn it off if ultimately it ends up being the default. > (Attitude almost entirely feigned to match Doug's) Don't give up your day job. :) Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 10:58:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 185F037B69C for ; Tue, 9 Jan 2001 10:58:30 -0800 (PST) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with ESMTP id OAA52921; Tue, 9 Jan 2001 14:04:45 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010109140348.03103660@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 09 Jan 2001 14:04:10 -0500 To: David Malone , Graham Wheeler From: Dennis Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF Cc: hackers@FreeBSD.ORG, markster@marko.net In-Reply-To: <200101091551.aa18666@salmon.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:51 AM 01/09/2001, David Malone wrote: > > Marko - does Linux have getifaddrs()? I somehow doubt it... > >Linux should have getifaddrs() if it has support for IPv6 in >userland libraries. There is an implimentation of it at: > > http://www.linux-ipv6.org/cvsweb/libinet6/?cvsroot=usagi-libc > >David. Depends WHICH linux you are referring to :-) dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 11:35:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id 83C5B37B402 for ; Tue, 9 Jan 2001 11:35:20 -0800 (PST) Received: (qmail 17881 invoked by uid 1078); 9 Jan 2001 19:35:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jan 2001 19:35:30 -0000 Date: Tue, 9 Jan 2001 11:35:30 -0800 (PST) From: Gordon Tetlow X-X-Sender: To: Doug Barton Cc: Neil Blakey-Milner , Gerhard Sittig , Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <3A5B5656.E2AAF0B5@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello again. On Tue, 9 Jan 2001, Doug Barton wrote: > Neil Blakey-Milner wrote: > > > > On Tue 2001-01-09 (02:14), Doug Barton wrote: > > The point I'm trying (obviously in vain) to make is having cron do what > amounts to "slewing its internal clock" will not work for everyone, and > violates POLA. Why won't "slewing it internal close" not work for everyone, I'm not trying to be a pain, but I just don't know. Also, what is POLA? > > This way, we never repeat jobs, and never lose jobs. Which makes cron > > reliable. > > For your definition of "reliable." Personally, I find cron doing exactly > what it's told and not trying to think for itself "reliable." This is obviously a personal preference that no amount of talk is going to change. > > "Timing" problems with separate cron jobs will always be a > > hack job, and undoubtably they'll lose or double jobs by mistake anyway. > > You (pl.) keep referring to the "We need to hand-hold users who are too > stupid to figure this stuff out for themselves" argument. While there are a > lot of areas of the system that I try to make simpler and easier to > understand, I don't see how we can possibly make this problem foolproof. > The universe keeps producing better fools. I don't consider myself stupid (maybe other's do =) but when I'm admin'ing a box, I have a bunch of other things that I'm thinking about and this usually falls through the cracks. I have a hard time even remembering when the DST shift is so I can change my alarm clock to make it into work at a resonable hour. > > you'll stop your sole campaign to vigourously resist the > > incorporation of this code? If it helps, we can have an option ('-i') > > to ignore DST changes, for "advanced administrators who know what > > they're doing and expect jobs to be lost or run multiple times depending > > on exactly when they schedule their jobs", and the "clueless newbies who > > ignorantly expect a job scheduled at 2am to not only run, but run only > > once" can be served too, by default. > > At minimum, the proposed change would have to be described in detail in > the man page so that people who expect traditional cron behavior will know > what the heck is going on when cron starts to think for itself. I would > prefer that this new behavior be an option that is off by default, however > there would have to be an option to turn it off if ultimately it ends up > being the default. I believe that there is already a bit in patch that updates the man page. That can always be expanded. If this does make it in, it should have an option to turn it on/off. However, I think that it should default to on. Doug, you think that this patch is bad. The fact that this thread keeps coming up twice a year makes me think that *something* should be done about DST changes. Do you have alternate suggestion for what can/should be done? -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 12:20:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from viemta06.chello.at (viemta06.chello.at [195.34.133.56]) by hub.freebsd.org (Postfix) with ESMTP id BEA2D37B401; Tue, 9 Jan 2001 12:20:18 -0800 (PST) Received: from chello.at ([212.186.125.116]) by viemta06.chello.at (InterMail vK.4.03.01.00 201-232-122 license 9caa03a7df1d31c048ffcc0d31ac5855) with ESMTP id <20010109202004.TXO17545.viemta06@chello.at>; Tue, 9 Jan 2001 21:20:04 +0100 Message-ID: <3A5B7295.2ECE4210@chello.at> Date: Tue, 09 Jan 2001 21:20:37 +0100 From: cristian nicolae X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sergey Babkin Cc: "Kenneth D. Merry" , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 References: <3A5870B9.D4402452@chello.at> <20010107133757.A55049@panzer.kdm.org> <3A5A6D6A.4115A4BD@bellatlantic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear all, I continued investigating the problem and at http://www5.compaq.com/products/servers/linux/OptionsMatrix.html I was surprised to find out that not even Linux supports tape drives (cpqarray) driver with the Compaq Integrated Smart Array Controller. I say "not even" as Compaq claims that officially supports Linux and DL380 is one of their certified Linux servers. I was in contact with one of the Compaq support engineers who told me that if I connect the tape to the controller SCSI Port 1 it should work. Well, it gets detected at boot time by the BIOS but not by the OS. I've deciced to give up in favor of a network based backup. The alternative is to stick another SCSI controller which is detectable by FreeBSD. Actually with a plain Adaptec UW2940 everything is just fine. But sticking an Adaptec into a Compaq machine covered by warranty and support will lead to other complications I don't even want to think about. Thanks for all your time spent on this. Yours, Cristian Nicolae Sergey Babkin wrote: > > "Kenneth D. Merry" wrote: > > > > On Sun, Jan 07, 2001 at 14:35:53 +0100, cristian nicolae wrote: > > > Dear all, > > > I have a Compaq DL380 with an integrated Compaq Smart Array Controller. > > > I have succesfully managed to install the FreeBSD 4.2-20010104 > > > and everything is fine but the DAT drive which is not detected. > > > The DAT is connected to the same Controller as the RAID system. > > > I don't think the ida driver in FreeBSD has SCSI passthrough capability. > > > > I don't know whether or not the hardware itself has passthrough capability; > > I think it does (I suspect that UnixWare supports it) but I'm not > 100% sure. > > > > On the other hand does any of you have info whether Compaq will support > > > officially FreeBSD in the future? > > > > I don't know. They offer FreeBSD in their test drive program, though: > > It may be worth it calling them and asking anyway. If they hear from > the customers that the customers want FreeBSD they would eventually > add its support. I think this is approximately how they started > supporting Linux. > > -SB > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 14:51:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 1111E37B402 for ; Tue, 9 Jan 2001 14:51:25 -0800 (PST) Received: (qmail 4596 invoked by uid 1001); 10 Jan 2001 08:51:16 +1000 X-Posted-By: GJB-Post 2.08 05-Jan-2001 (FreeBSD) X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Wed, 10 Jan 2001 08:51:16 +1000 From: Greg Black To: Doug Barton Cc: Neil Blakey-Milner , Gerhard Sittig , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010109124044.A16276@mithrandr.moria.org> <3A5B5656.E2AAF0B5@FreeBSD.org> In-reply-to: <3A5B5656.E2AAF0B5@FreeBSD.org> of Tue, 09 Jan 2001 10:20:06 PST Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Barton wrote: > Neil Blakey-Milner wrote: > > > > On Tue 2001-01-09 (02:14), Doug Barton wrote: > > > Gerhard Sittig wrote: > > > This way, we never repeat jobs, and never lose jobs. Which makes cron > > reliable. > > For your definition of "reliable." Personally, I find cron doing exactly > what it's told and not trying to think for itself "reliable." Indeed. > > And when you finally realize that everyone else thinks this is a great > > idea, > > In fact, I'm quite sure that this is not true. I happen to be the only one > who is currently voicing opposition. No, you're not the only one opposed. I've stated my opposition previously and will re-state it here. If any change to expected cron behaviour is to be introduced, the traditional behaviour must be the default, with a knob documented in the man pages that can be twisted to get the oddball behaviour that is being proposed here. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 15:48: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from node7.cluster.srrc.usda.gov (symbion.srrc.usda.gov [199.133.86.40]) by hub.freebsd.org (Postfix) with ESMTP id 86E7637B401 for ; Tue, 9 Jan 2001 15:47:51 -0800 (PST) Received: (from glenn@localhost) by node7.cluster.srrc.usda.gov (8.11.1/8.11.1) id f09Nlnt69253 for hackers@freebsd.org; Tue, 9 Jan 2001 17:47:49 -0600 (CST) (envelope-from glenn) From: Glenn Johnson Date: Tue, 9 Jan 2001 17:47:49 -0600 To: hackers@freebsd.org Subject: gmake to make Message-ID: <20010109174749.A69192@node7.cluster.srrc.usda.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How can I convert the following gmake syntax into something that FreeBSD's make can understand? %.x: %.o libtinker.a ${F77} ${LINKFLAGS} -o $@ $^ ${LIBS} Thanks. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: gjohnson@nola.srrc.usda.gov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 16: 4:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 930BA37B400 for ; Tue, 9 Jan 2001 16:04:30 -0800 (PST) Received: from flu (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 08BF93A4C0 for ; Tue, 9 Jan 2001 16:04:30 -0800 (PST) Message-ID: <014201c07a98$e76be740$0402010a@biohz.net> From: "Renaud Waldura" To: References: <005801c07037$47ae6ea0$0402010a@biohz.net> Subject: Re: Silent FreeBSD Date: Tue, 9 Jan 2001 16:04:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks to all of you for your very useful answers! Here is how I solved my noise problem: 1- the hard drive was by far the biggest culprit: I swapped it with an old laptop HD (2.5 inch) with the appropriate connector/converter that connects to a regular IDE ribbon cable and AT power, 2- cut the CPU frequency by half and removed the heatsink fan, 3- got a new case with a quieter power supply. And now I can fully enjoy the street noise coming from down below... :> ----- Original Message ----- From: "Renaud Waldura" To: Sent: Wednesday, December 27, 2000 11:00 AM Subject: Silent FreeBSD > I've got that FreeBSD gateway in a corner at my house, it works fine & dandy > but the constant noise (whirring fans, hard drives) gets on my nerves. > > What solutions have people explored to quiet down a computer system? (actual > experience will be preferred over wild speculations). I'm already aware of > PicoBSD, but I need more storage than just a floppy. Has anybody > experimented with RAM cards? How about noise-proof enclosures? > > --Renaud > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 16:11:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0913737B400 for ; Tue, 9 Jan 2001 16:11:17 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0A092G72445; Tue, 9 Jan 2001 16:09:02 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010109174749.A69192@node7.cluster.srrc.usda.gov> Date: Tue, 09 Jan 2001 16:11:18 -0800 (PST) From: John Baldwin To: Glenn Johnson Subject: RE: gmake to make Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Jan-01 Glenn Johnson wrote: > How can I convert the following gmake syntax into something that > FreeBSD's make can understand? > > %.x: %.o libtinker.a > ${F77} ${LINKFLAGS} -o $@ $^ ${LIBS} > .o.x: ${F77} ${LINKFLAGS} -o $@ $< libtinker.a ${LIBS} Try that. My mailer has screwed up the tab I think, so make sure the first char on the line is a tab. > Thanks. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 9 23:19: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id 05AA137B401 for ; Tue, 9 Jan 2001 23:18:28 -0800 (PST) Received: (qmail 3610 invoked by uid 1000); 10 Jan 2001 07:16:23 -0000 Date: Wed, 10 Jan 2001 09:16:23 +0200 From: Peter Pentchev To: John Baldwin Cc: Glenn Johnson , hackers@FreeBSD.org Subject: Re: gmake to make Message-ID: <20010110091622.A3205@ringworld.oblivion.bg> Mail-Followup-To: John Baldwin , Glenn Johnson , hackers@FreeBSD.org References: <20010109174749.A69192@node7.cluster.srrc.usda.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Jan 09, 2001 at 04:11:18PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 09, 2001 at 04:11:18PM -0800, John Baldwin wrote: > > On 09-Jan-01 Glenn Johnson wrote: > > How can I convert the following gmake syntax into something that > > FreeBSD's make can understand? > > > > %.x: %.o libtinker.a > > ${F77} ${LINKFLAGS} -o $@ $^ ${LIBS} > > > > .o.x: > ${F77} ${LINKFLAGS} -o $@ $< libtinker.a ${LIBS} > > Try that. My mailer has screwed up the tab I think, so make sure the first > char on the line is a tab. Hmm.. does this not remove the original dependency on libtinker.a? G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 0: 9:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id 8B9AE37B400 for ; Wed, 10 Jan 2001 00:09:22 -0800 (PST) Received: (qmail 17651 invoked by uid 1003); 10 Jan 2001 08:09:16 -0000 Date: Wed, 10 Jan 2001 10:09:16 +0200 From: Neil Blakey-Milner To: Greg Black Cc: Doug Barton , Gerhard Sittig , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010110100915.A90618@mithrandr.moria.org> References: <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010109124044.A16276@mithrandr.moria.org> <3A5B5656.E2AAF0B5@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gjb@gbch.net on Wed, Jan 10, 2001 at 08:51:16AM +1000 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2001-01-10 (08:51), Greg Black wrote: > If any change to expected cron behaviour is to be introduced, > the traditional behaviour must be the default, with a knob > documented in the man pages that can be twisted to get the > oddball behaviour that is being proposed here. The oddball behaviour that is what, I imagine, the vast majority of people expect. We could take a vote here, if you like. Are you at all deluded into believing your position would win? I'm sorry, but cron should never miss jobs. And it should preferably not run the same job twice. All the hacks we've had to go through to simply get our daily jobs to run reliably (yes, this "reliable" word again). This oddball behaviour, unlike the numerous hacks tried before, and which still don't solve the intrinsic problem, has been tested, and is default, on OpenBSD, for the past 3 years. My reading of the code seems to indicate it does the right thing in all time update cases - it doesn't repeat wildcard jobs multiple times for the "medium" jump (1 to 3 hours), it doesn't miss jobs for any size jump forward, and it doesn't repeat jobs for negative jumps. It just ignores insanely big jumps (ie, over 3 hours). Since this is the default in OpenBSD, and we want to not randomly diverge from their code, and since they're more likely to accept code to ignore DST changes that a couple of people thinks is the correct thing, and so forth, we should have the behaviour as default. (Not to mention that it'll solve the endless complaints about missed or repeated runs we get twice every year. And no, these aren't clueless administrators as you and Doug believe, but people who expect tools to be reliable and do the obvious thing. Also, the only reason cron is doing the wrong thing now is that it is trying to be clever to let people set jobs in their local time, and we get bit because of silly things like DST. It should, of course, be expressed as UTC.) Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 0:20:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id B9A3237B404; Wed, 10 Jan 2001 00:20:17 -0800 (PST) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id VAA28529; Wed, 10 Jan 2001 21:20:14 +1300 (NZDT) Message-Id: <200101100820.VAA28529@ducky.nz.freebsd.org> From: "Dan Langille" Organization: The FreeBSD Diary / FreshPorts To: Doug Barton Date: Wed, 10 Jan 2001 21:20:13 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Reply-To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: <3A5B5656.E2AAF0B5@FreeBSD.org> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 9 Jan 2001, at 10:20, Doug Barton wrote: > > And when you finally realize that everyone else thinks this is a great > > idea, I do not like being included in "everyone". I don't think it's a great idea. > > In fact, I'm quite sure that this is not true. I happen to be the only one > who is currently voicing opposition. IMHO, the solution is not to schedule jobs during during the changeover period. However, *if* the mods are adopted, it should default to off. Add a switch to turn them on. See how that runs for a few years. Then, and only then, if the feedback is positive, consider changing it to the default behaviour. Such a radical change to cron cannot be implemented without sufficient field testing. That will take years. It cannot be simulated. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 1:25:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id C10AA37B401 for ; Wed, 10 Jan 2001 01:24:57 -0800 (PST) Received: (qmail 57883 invoked by uid 1003); 10 Jan 2001 09:24:51 -0000 Date: Wed, 10 Jan 2001 11:24:51 +0200 From: Neil Blakey-Milner To: Dan Langille Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010110112451.A52255@mithrandr.moria.org> References: <3A5B5656.E2AAF0B5@FreeBSD.org> <200101100820.VAA28529@ducky.nz.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101100820.VAA28529@ducky.nz.freebsd.org>; from dan@langille.org on Wed, Jan 10, 2001 at 09:20:13PM +1300 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2001-01-10 (21:20), Dan Langille wrote: > > > And when you finally realize that everyone else thinks this is a great > > > idea, > > I do not like being included in "everyone". I don't think it's a great idea. If you didn't miss the comment, I was (and am now) attempting to emulate Doug's style. (The "I don't like this change, and since nobody commented, it must be a terrible thing" style.) > > In fact, I'm quite sure that this is not true. I happen to be the only one > > who is currently voicing opposition. > > IMHO, the solution is not to schedule jobs during during the changeover > period. However, *if* the mods are adopted, it should default to off. Add > a switch to turn them on. See how that runs for a few years. Then, and > only then, if the feedback is positive, consider changing it to the default > behaviour. Such a radical change to cron cannot be implemented > without sufficient field testing. That will take years. It cannot be > simulated. These changes have been tested in OpenBSD for 3 years. The "solution" is _not_ to tell people they're stupid to schedule jobs during the changeover. It has nothing to do with them. If they want jobs at 2am in the morning, that's cool. The fact the changeover is a problem is cron-specific. It shouldn't be trying to be clever and work with local time when local time does weird things like randomly add and remove time from existence. However, since it _does_ have this "feature", we should accomodate people who are negatively affected by it. It _will_ fix the twice-yearly complaint about extra and missing jobs. It may create unexpected behaviour for a tiny percentage. Those people should be reading the release notes ("or they shouldn't be system administrators or run FreeBSD"). Again, this change is from OpenBSD. We will synchronise with their changes, and perhaps offer them back a patch to ignore what "ultra leet sysadmins who rely on broken behaviour because people who don't are simply stupid and shouldn't be running FreeBSD anyway!" with an option. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 1:29:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 968E637B400 for ; Wed, 10 Jan 2001 01:29:25 -0800 (PST) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.11.1/8.11.0) id f0A9T3r98854; Wed, 10 Jan 2001 10:29:03 +0100 (CET) (envelope-from asmodai) Date: Wed, 10 Jan 2001 10:29:03 +0100 From: Jeroen Ruigrok van der Werven To: clp@nji.com Cc: hackers@FreeBSD.ORG Subject: Re: help! Message-ID: <20010110102903.A98642@lucifer.bart.nl> References: <000a01c07531$f2b26a00$48752cd8@clp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000a01c07531$f2b26a00$48752cd8@clp>; from clp@nji.com on Tue, Jan 02, 2001 at 10:04:51PM -0500 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20010103 03:55], clp@nji.com (clp@nji.com) wrote: >Hi. I have a netgear Ethernet card installed in my computer. In order >to reconnect my computer to the internet, I have to reinstall the >drivers and they're missing. So, I opened up my computer to look at the >Ethernet card and I copied down the necessary numbers. However, I do >not know how to download the program. I found this e-mail address on >the web and would greatly appreciate some help. Thank you! -Christina, >clp@nji.com And does your computer run FreeBSD? Also, a question such as this should not have been sent to hackers@freebsd.org, but questions@freebsd.org. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Killing me is not enough to make me go away... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 1:36:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 8D96D37B400; Wed, 10 Jan 2001 01:36:18 -0800 (PST) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id WAA28697; Wed, 10 Jan 2001 22:35:53 +1300 (NZDT) Message-Id: <200101100935.WAA28697@ducky.nz.freebsd.org> From: "Dan Langille" Organization: The FreeBSD Diary / FreshPorts To: Neil Blakey-Milner Date: Wed, 10 Jan 2001 22:35:48 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Reply-To: dan@langille.org Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG In-reply-to: <20010110112451.A52255@mithrandr.moria.org> References: <200101100820.VAA28529@ducky.nz.freebsd.org>; from dan@langille.org on Wed, Jan 10, 2001 at 09:20:13PM +1300 X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 10 Jan 2001, at 11:24, Neil Blakey-Milner wrote: > These changes have been tested in OpenBSD for 3 years. That's a relatively smaller user-base compared to FreeBSD. Do you consider that sufficient? > The "solution" > is _not_ to tell people they're stupid to schedule jobs during the > changeover. It has nothing to do with them. If they want jobs at 2am > in the morning, that's cool. The fact the changeover is a problem is > cron-specific. It shouldn't be trying to be clever and work with local > time when local time does weird things like randomly add and remove time > from existence. However, since it _does_ have this "feature", we should > accomodate people who are negatively affected by it. It _will_ fix the > twice-yearly complaint about extra and missing jobs. It may create > unexpected behaviour for a tiny percentage. Those people should be > reading the release notes ("or they shouldn't be system administrators > or run FreeBSD"). I don't see how the above relates to my point about sufficient testing. It seems to be a repeat of what you've said before. > Again, this change is from OpenBSD. We will synchronise with their > changes, and perhaps offer them back a patch to ignore what "ultra leet > sysadmins who rely on broken behaviour because people who don't are > simply stupid and shouldn't be running FreeBSD anyway!" with an option. Maybe I'm stupid. I couldn't parse that. But I get the drift. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 1:44:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id 3148537B401 for ; Wed, 10 Jan 2001 01:44:22 -0800 (PST) Received: (qmail 68380 invoked by uid 1003); 10 Jan 2001 09:44:06 -0000 Date: Wed, 10 Jan 2001 11:44:06 +0200 From: Neil Blakey-Milner To: Dan Langille Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010110114406.A64092@mithrandr.moria.org> References: <200101100820.VAA28529@ducky.nz.freebsd.org>; <20010110112451.A52255@mithrandr.moria.org> <200101100935.WAA28697@ducky.nz.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101100935.WAA28697@ducky.nz.freebsd.org>; from dan@langille.org on Wed, Jan 10, 2001 at 10:35:48PM +1300 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2001-01-10 (22:35), Dan Langille wrote: > That's a relatively smaller user-base compared to FreeBSD. Do you > consider that sufficient? I would, yes, considering it has been three years. You may feel free to disagree, of course, and I'll get to why next: > I don't see how the above relates to my point about sufficient testing. It > seems to be a repeat of what you've said before. I obviously agree sufficient testing is required. Luckily, we have -CURRENT for "sufficient testing". If it's an incredible concern, this change could be postponed to being in a release until 5.0; by then we'd have had our own testing for at least one DST change, and OpenBSD's testing for at least 7. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 3: 4:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ada.eu.org (marvin.enst.fr [137.194.161.2]) by hub.freebsd.org (Postfix) with ESMTP id BBEBD37B400 for ; Wed, 10 Jan 2001 03:04:11 -0800 (PST) Received: by ada.eu.org (Postfix, from userid 10) id 5AFD9190B0; Wed, 10 Jan 2001 12:04:05 +0100 (CET) Received: by trillian.enst.fr (Postfix, from userid 1000) id 75E5359; Wed, 10 Jan 2001 12:03:26 +0100 (CET) Date: Wed, 10 Jan 2001 12:03:26 +0100 To: hackers@freebsd.org Subject: Link up/down events Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: Samuel Tardieu Organization: Ecole Nationale Superieure des Telecommunications Reply-To: Samuel Tardieu Content-Transfer-Encoding: 8bit X-WWW: http://www.rfc1149.net/sam X-Mail-Processing: Sam's procmail tools X-ICQ: 21547599 X-Sam-Laptop: yes Message-Id: <2001-01-10-12-03-26+trackit+sam@inf.enst.fr> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there a way to be warned about ethernet link up/down events? I have a laptop with an internal fxp0 interface, and I'd like to launch/kill dhclient whenever the link goes up/down. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 3:10:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id 7E8F937B400 for ; Wed, 10 Jan 2001 03:10:22 -0800 (PST) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id NAA22906; Wed, 10 Jan 2001 13:10:02 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 22757; Wed Jan 10 13:08:57 2001 Message-ID: <3A5C2A87.C7591D2B@cequrux.com> Date: Wed, 10 Jan 2001 11:25:27 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: David Malone , freebsd-hackers@freebsd.org Subject: Re: Size of struct ifreq/returned buffer of SIOCGIFCONF References: <3A5AE854.F769B86C@cequrux.com> <20010109142043.B52761@walton.maths.tcd.ie> <3A5B148A.5F139188@cequrux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Graham Wheeler wrote: > > David Malone wrote: > > > > If you read the paragraph below that code, it notes that the ifreq > > structures are of variable length. The spacing depends on the size > > of the returned info. > > That's true. In which case the cheops code is wrong, as it iterates > through the list by incrementing a pointer to a struct ifreq. I'll try > fix that and get Mark to test under Linux and hopefully get a portable > solution. Interestingly enough, a similar bug probably once existed in sysinstall. In /usr/src/release/sysinstall/devices.c, routine deviceGetAll(), there is a loop through these structures which also erroneously uses ++ to increment the struct ifreq* pointer. At the end of the loop, after the label loopend:, there is a line of code that fixes the pointer, together with a comment "I'm not sure why this is here - it's inherited". gr. -- Dr Graham Wheeler E-mail: gram@cequrux.com Director, Research and Development WWW: http://www.cequrux.com CEQURUX Technologies Phone: +27(21)423-6065 Firewalls/VPN Specialists Fax: +27(21)424-3656 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 3:36:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 9399A37B404 for ; Wed, 10 Jan 2001 03:35:45 -0800 (PST) Received: (qmail 7815 invoked by uid 1001); 10 Jan 2001 21:35:13 +1000 X-Posted-By: GJB-Post 2.08 05-Jan-2001 (FreeBSD) X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Wed, 10 Jan 2001 21:35:13 +1000 From: Greg Black To: Neil Blakey-Milner Cc: Dan Langille , Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <3A5B5656.E2AAF0B5@FreeBSD.org> <200101100820.VAA28529@ducky.nz.freebsd.org> <20010110112451.A52255@mithrandr.moria.org> In-reply-to: <20010110112451.A52255@mithrandr.moria.org> of Wed, 10 Jan 2001 11:24:51 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Neil Blakey-Milner wrote: > On Wed 2001-01-10 (21:20), Dan Langille wrote: > > > > IMHO, the solution is not to schedule jobs during during the changeover > > period. However, *if* the mods are adopted, it should default to off. Add > > a switch to turn them on. See how that runs for a few years. Then, and > > only then, if the feedback is positive, consider changing it to the default > > behaviour. Such a radical change to cron cannot be implemented > > without sufficient field testing. That will take years. It cannot be > > simulated. > > These changes have been tested in OpenBSD for 3 years. That's not the same as testing under FreeBSD. And it's not just a matter of testing anyway -- it's a matter of changing well known and understood behaviour that has been in place for decades for no other reason than that some people seem to be unable to understand simple facts, such as the fact that playing arbitrarily with clocks for DST leads inevitably to certain anomalies in all kinds of scheduling. Solutions to this include running the scheduler under a more sensible time regime, such as UTC or TAI -- always an option for cron, or avoiding the scheduling of tasks for times that can either occur twice or not at all -- usually an option for Unix cron tasks. None of this is rocket science. Fiddling with cron to work around incompetent sysadmins just exposes the rest of us to new bugs in cron -- a program that we depend on for a large range of important tasks. Of course, those of us who don't want to be bitten by the weird new behaviour will have the option of retaining the current (rather unattractive) BSD (aka Vixie) cron or of replacing it with an entirely new tool and disabling the supplied cron altogether, in much the same way as many people remove sendmail in favour of qmail or named in favour of djbdns. > The "solution" > is _not_ to tell people they're stupid to schedule jobs during the > changeover. It's not a matter of telling people "they're stupid to schedule jobs during the changeover," it's a matter of expecting them to understand what it means to do that in those benighted places that resort to DST. > However, since it _does_ have this "feature", we should > accomodate people who are negatively affected by it. I think we should accommodate them in exactly the same way we accommodate people who are negatively affected by the lack of support for Word documents in vi, surely a far more pressing problem. > It _will_ fix the > twice-yearly complaint about extra and missing jobs. And that will reduce the list traffic of that type by a truly insignificant amount. > It may create > unexpected behaviour for a tiny percentage. Those people should be > reading the release notes ("or they shouldn't be system administrators > or run FreeBSD"). Those people do read the release notes, just as they read the stuff that gets on this list -- and at least some of them have expressed strong reservations about the proposed changes. It seems clear that the loudest noise comes from the proponents, so I guess I'll have to dust off the sources to my old personal cron implementation in readiness for the day when this thing gets into the distribution. > Again, this change is from OpenBSD. We will synchronise with their > changes, and perhaps offer them back a patch to ignore what "ultra leet > sysadmins who rely on broken behaviour because people who don't are > simply stupid and shouldn't be running FreeBSD anyway!" with an option. I cannot parse the final sentence above and don't think it adds much to the case that is being made here. Since it seems that heat rather than light is the base of much of the discussion, I think I'll drop it now -- apart from a final plea that the new behaviour be made to default to off if it gets up enough support to be incorporated into FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 5:12:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id B271D37B402 for ; Wed, 10 Jan 2001 05:12:15 -0800 (PST) Received: (qmail 79104 invoked by uid 1003); 10 Jan 2001 13:12:11 -0000 Date: Wed, 10 Jan 2001 15:12:11 +0200 From: Neil Blakey-Milner To: Greg Black Cc: Dan Langille , Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010110151211.A37285@mithrandr.moria.org> References: <3A5B5656.E2AAF0B5@FreeBSD.org> <200101100820.VAA28529@ducky.nz.freebsd.org> <20010110112451.A52255@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gjb@gbch.net on Wed, Jan 10, 2001 at 09:35:13PM +1000 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2001-01-10 (21:35), Greg Black wrote: > > These changes have been tested in OpenBSD for 3 years. > > That's not the same as testing under FreeBSD. Of course not, but it's a reasonably similar population type. > And it's not just a matter of testing anyway -- it's a matter of > changing well known and understood behaviour that has been in place > for decades for no other reason than that some people seem to be > unable to understand simple facts, such as the fact that playing > arbitrarily with clocks for DST leads inevitably to certain > anomalies in all kinds of scheduling. To summarise: It is broken, we have the fix, but some people don't need it, because they've given up on cron, beacsuse it's broken, and avoid using the broken bits. Not only that, but people who don't understand that it is broken are unable to understand simple facts. In addition, it took the FreeBSD project about 7 years to finally get their daily runs to run exactly once, once every day. > Solutions to this include running the scheduler under a more > sensible time regime, such as UTC or TAI -- always an option for > cron, or avoiding the scheduling of tasks for times that can > either occur twice or not at all -- usually an option for Unix > cron tasks. None of this is rocket science. You left out "detecting DST changes, and acting accordingly". > Fiddling with cron to work around incompetent sysadmins just > exposes the rest of us to new bugs in cron -- a program that we > depend on for a large range of important tasks. Here you are doing it again. You're calling people who expect a tool to work in a reliable and obvious way "incompetent", and the few people who know the arcane arts to be some sort of elite. If you hadn't noticed (despite my indication of the fact), I was attempting to emulate the style of the detraction; that's why you seem to believe I'm getting worked up over this. Trust me, I'm not. If these people who know the arcane system administrator's art upgrade their systems, don't read the release notes, and don't use the options I'm suggesting we attempt to give them, then we've done all we can to provide an alternative reliable and obvious scheduler (without "don't schedule tasks in the morning! Beware!" notices). > Of course, those of us who don't want to be bitten by the weird > new behaviour will have the option of retaining the current > (rather unattractive) BSD (aka Vixie) cron or of replacing it > with an entirely new tool and disabling the supplied cron > altogether, in much the same way as many people remove sendmail > in favour of qmail or named in favour of djbdns. Or using the supplied option. > > The "solution" > > is _not_ to tell people they're stupid to schedule jobs during the > > changeover. > > It's not a matter of telling people "they're stupid to schedule > jobs during the changeover," it's a matter of expecting them to > understand what it means to do that in those benighted places > that resort to DST. Or of providing them with the option to not have to worry about all that stuff? Or does that make FreeBSD too easy for plebs to use? (: > > However, since it _does_ have this "feature", we should > > accomodate people who are negatively affected by it. > > I think we should accommodate them in exactly the same way we > accommodate people who are negatively affected by the lack of > support for Word documents in vi, surely a far more pressing > problem. You seem to believe this is a feature. This is a bugfix for a feature that already exists. > > It may create > > unexpected behaviour for a tiny percentage. Those people should be > > reading the release notes ("or they shouldn't be system administrators > > or run FreeBSD"). > > Those people do read the release notes, just as they read the > stuff that gets on this list -- and at least some of them have > expressed strong reservations about the proposed changes. It > seems clear that the loudest noise comes from the proponents, so > I guess I'll have to dust off the sources to my old personal > cron implementation in readiness for the day when this thing > gets into the distribution. Or just do the least-work thing and use the option provided to act in the old way? In summary: I do not see a valid argument for not having the bugfix at all, available as an option. I do see the argument for not changing the default. I also see that everyone who opposes seems to believe that it is only people without major skills that get confused by all this, since people with major skills know not to rely on any behaviour over DST changes. 66% of them agree (33% haven't expressed an opinion) without provocation that those people with major skills will read the release notes. Common sense indicates that they are able to use a command line option that disable the new reliable behaviour. There has been expressed a need for testing. That is dealt with by three years in OpenBSD, and a period of time in the development branch, as per most development. What we haven't seen is any technical opposition to the algorithm used, which has been explained. If there is a problem with it, then that should be determined. My review of it indicates the OpenBSD cron behaviour is very specific, reliable, and obvious. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 5:57:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5CDF437B400 for ; Wed, 10 Jan 2001 05:57:35 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f0ADvE778982; Wed, 10 Jan 2001 08:57:15 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 10 Jan 2001 08:57:14 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Samuel Tardieu Cc: hackers@freebsd.org Subject: Re: Link up/down events In-Reply-To: <2001-01-10-12-03-26+trackit+sam@inf.enst.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Jan 2001, Samuel Tardieu wrote: > Is there a way to be warned about ethernet link up/down events? I have a > laptop with an internal fxp0 interface, and I'd like to launch/kill > dhclient whenever the link goes up/down. I've been wondering about this also -- Darwin has this, and it's pretty cool to watch dhclient run as soon as the ethernet cable is stuck in, and not have to dig around to find out how to pursuade the system to make the change. Windows 2000 also appears to do this for appropriate ethernet cards. The traditional means of notifying userland processes of interface/network events has been the routing socket -- presumably we want to notify on interface arrive / depart, as well as for condition changes, including a link up / down (differentiated from administrative up / down). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 6:51:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9155E37B402 for ; Wed, 10 Jan 2001 06:51:02 -0800 (PST) Received: (from uucp@localhost) by ns.internet.dk (8.11.1/8.11.1) with UUCP id f0AEp1V78892 for freebsd-hackers@FreeBSD.ORG; Wed, 10 Jan 2001 15:51:01 +0100 (CET) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.11.1/8.11.0) with ESMTP id f0AEoZi24067 for ; Wed, 10 Jan 2001 15:50:41 +0100 (CET) (envelope-from leifn@neland.dk) Date: Wed, 10 Jan 2001 15:50:35 +0100 (CET) From: Leif Neland Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <20010110151211.A37285@mithrandr.moria.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In summary: I do not see a valid argument for not having the bugfix at > all, available as an option. I do see the argument for not changing the > default. I also see that everyone who opposes seems to believe that it > is only people without major skills that get confused by all this, since > people with major skills know not to rely on any behaviour over DST > changes. 66% of them agree (33% haven't expressed an opinion) without > provocation that those people with major skills will read the release > notes. Common sense indicates that they are able to use a command line > option that disable the new reliable behaviour. There has been > expressed a need for testing. That is dealt with by three years in > OpenBSD, and a period of time in the development branch, as per most > development. > If this is turning into a vote: I'm for the new colour of the bikeshed. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 7:53:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (unknown [194.128.198.234]) by hub.freebsd.org (Postfix) with ESMTP id 9367E37B69F; Wed, 10 Jan 2001 07:51:33 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 876353243; Wed, 10 Jan 2001 15:51:34 +0000 (GMT) Date: Wed, 10 Jan 2001 15:51:34 +0000 From: Josef Karthauser To: Robert Watson Cc: Samuel Tardieu , hackers@FreeBSD.ORG, n_hibma@freebsd.org Subject: Re: Link up/down events Message-ID: <20010110155134.B524@tao.org.uk> References: <2001-01-10-12-03-26+trackit+sam@inf.enst.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Wed, Jan 10, 2001 at 08:57:14AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 10, 2001 at 08:57:14AM -0500, Robert Watson wrote: > On Wed, 10 Jan 2001, Samuel Tardieu wrote: > > > Is there a way to be warned about ethernet link up/down events? I have a > > laptop with an internal fxp0 interface, and I'd like to launch/kill > > dhclient whenever the link goes up/down. > > I've been wondering about this also -- Darwin has this, and it's pretty > cool to watch dhclient run as soon as the ethernet cable is stuck in, and > not have to dig around to find out how to pursuade the system to make the > change. Windows 2000 also appears to do this for appropriate ethernet > cards. The traditional means of notifying userland processes of > interface/network events has been the routing socket -- presumably we want > to notify on interface arrive / depart, as well as for condition changes, > including a link up / down (differentiated from administrative up / down). There's an ongoing discussion about building a generic devd (device daemon) to deal with this kind of thing. Nick Hibma proposed a spec for one, but as far as I'm aware there's been no feedback to him yet. Nick, maybe you should re-propose it via the -arch list. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 8:11:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 72B6037B69E; Wed, 10 Jan 2001 08:11:03 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f0AGAa780127; Wed, 10 Jan 2001 11:10:36 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 10 Jan 2001 11:10:35 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Josef Karthauser Cc: Samuel Tardieu , hackers@FreeBSD.ORG, n_hibma@FreeBSD.ORG Subject: Re: Link up/down events In-Reply-To: <20010110155134.B524@tao.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Jan 2001, Josef Karthauser wrote: > On Wed, Jan 10, 2001 at 08:57:14AM -0500, Robert Watson wrote: > > On Wed, 10 Jan 2001, Samuel Tardieu wrote: > > > > > Is there a way to be warned about ethernet link up/down events? I have a > > > laptop with an internal fxp0 interface, and I'd like to launch/kill > > > dhclient whenever the link goes up/down. > > > > I've been wondering about this also -- Darwin has this, and it's pretty > > cool to watch dhclient run as soon as the ethernet cable is stuck in, and > > not have to dig around to find out how to pursuade the system to make the > > change. Windows 2000 also appears to do this for appropriate ethernet > > cards. The traditional means of notifying userland processes of > > interface/network events has been the routing socket -- presumably we want > > to notify on interface arrive / depart, as well as for condition changes, > > including a link up / down (differentiated from administrative up / down). > > There's an ongoing discussion about building a generic devd (device > daemon) to deal with this kind of thing. Nick Hibma proposed a spec for > one, but as far as I'm aware there's been no feedback to him yet. I would argue that, for this question, a devd interface would be the wrong answer. This may be a deficiency in the device API, but it's also a deficiency in the network API, which is different. Recall that there are network interfaces that are not associated with actually devices (lo0, vpn's, etc, for example), where it may be desirable to monitor link state asynchronously without using our platform-specific device API. Using routing sockets to monitor network conditions is a portable and fairly well-defined interface, and it's arguable that monitoring link state would be an appropriate additional event to provide via the interface. Presumably at some point in the stack, that notification is translated from a hardware event, which might be associated with devd in some manner (and possibly also exposed there). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 9: 8:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ada.eu.org (marvin.enst.fr [137.194.161.2]) by hub.freebsd.org (Postfix) with ESMTP id AC3A637B404; Wed, 10 Jan 2001 09:08:00 -0800 (PST) Received: by ada.eu.org (Postfix, from userid 10) id 916131909A; Wed, 10 Jan 2001 18:07:47 +0100 (CET) Received: by trillian.enst.fr (Postfix, from userid 1000) id 8DFE260; Wed, 10 Jan 2001 18:06:45 +0100 (CET) Date: Wed, 10 Jan 2001 18:06:45 +0100 To: Robert Watson Cc: Josef Karthauser , hackers@FreeBSD.ORG, n_hibma@FreeBSD.ORG Subject: Re: Link up/down events References: <20010110155134.B524@tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Wed, Jan 10, 2001 at 11:10:35AM -0500 From: Samuel Tardieu Organization: Ecole Nationale Superieure des Telecommunications Reply-To: Samuel Tardieu Content-Transfer-Encoding: 8bit X-WWW: http://www.rfc1149.net/sam X-Mail-Processing: Sam's procmail tools X-ICQ: 21547599 X-Sam-Laptop: yes Message-Id: <2001-01-10-18-06-45+trackit+sam@inf.enst.fr> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 10/01, Robert Watson wrote: | Presumably at some point in the stack, that notification is translated | from a hardware event, which might be associated with devd in some manner | (and possibly also exposed there). This is the ideal situation. The other one being that the status can be read, which would require some polling to monitor the link status. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 11:14:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kira.epconline.net (kira.epconline.net [209.83.132.2]) by hub.freebsd.org (Postfix) with ESMTP id AC38A37B402 for ; Wed, 10 Jan 2001 11:14:10 -0800 (PST) Received: from therock (betterguard.epconline.net [209.83.132.193]) by kira.epconline.net (8.11.1/8.11.1) with SMTP id f0AJE8g80667 for ; Wed, 10 Jan 2001 13:14:09 -0600 (CST) (envelope-from carock@epconline.net) From: "Chuck Rock" To: "FreeBSD Hackers" Subject: RE: Link up/down events Date: Wed, 10 Jan 2001 13:17:29 -0600 Message-ID: <001d01c07b39$f9a97ac0$1805010a@epconline.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <2001-01-10-18-06-45+trackit+sam@inf.enst.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has anyone looked into using SNMP with MRTG or some of the other utilities that comes with UCD-SNMP? I think this would be very easy this way. We use Castle Rock's SNMPc running on NT to montior our servers and connections. UCD-SNMP is a daemon and SNMP utilities for Linux and FreeBSD flavors that work well too. http://ucd-snmp.ucdavis.edu/ http://www.mrtg.org http://www.castlerock.com Chuck > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Samuel Tardieu > Sent: Wednesday, January 10, 2001 11:07 AM > To: Robert Watson > Cc: Josef Karthauser; hackers@FreeBSD.ORG; n_hibma@FreeBSD.ORG > Subject: Re: Link up/down events > > > On 10/01, Robert Watson wrote: > > | Presumably at some point in the stack, that notification is translated > | from a hardware event, which might be associated with devd in > some manner > | (and possibly also exposed there). > > This is the ideal situation. The other one being that the status can be > read, which would require some polling to monitor the link status. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 12: 3: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relayout1.micronpc.com (meihost.micronpc.com [209.19.139.2]) by hub.freebsd.org (Postfix) with ESMTP id C87F337B402 for ; Wed, 10 Jan 2001 12:02:41 -0800 (PST) Received: from mei00wssout01.micron.com (mei00wssout01.micronpc.com [172.30.41.216]) by relayout1.micronpc.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id NAA10321 for ; Wed, 10 Jan 2001 13:02:34 -0700 Received: from 172.30.41.146 by mei00wssout01.micron.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 10 Jan 2001 13:02:35 -0700 X-Server-Uuid: 6b1d535a-5b27-11d3-bf09-00902786a6a3 Received: by imcout1.micronpc.com with Internet Mail Service ( 5.5.2650.21) id ; Wed, 10 Jan 2001 13:02:34 -0700 Message-ID: <8D18712B2604D411A6BB009027F644980DD82F@0SEA01EXSRV1> From: "Matt Simerson" To: "'freebsd-hackers@freebsd.org'" Subject: RE: Link up/down events Date: Wed, 10 Jan 2001 13:02:18 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-WSS-ID: 16426051618641-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While it can be done (I do it), using MRTG/rateup/Cricket/etc. without SNMP is much like pushing a car down the street. Sometimes it's The Right Thing to do but for the other 99.4% of the time, it's far preferable to use the engine to power it. UCD-SNMP is more than just the UCD SNMP daemon. It's also the client programs and a collection of SNMP utilities. With them you can do most of what you'd ever want to use SNMP for. MRTG is simply a data graphing utility. It uses SNMP to collect the data points but that's pretty much all of the relationship between the two. Matt > -----Original Message----- > From: Chuck Rock [mailto:carock@epconline.net] > Sent: Wednesday, January 10, 2001 11:17 AM > To: FreeBSD Hackers > Subject: RE: Link up/down events > > > Has anyone looked into using SNMP with MRTG or some of the > other utilities that comes with UCD-SNMP? > > I think this would be very easy this way. We use Castle > Rock's SNMPc running > on NT to montior our servers and connections. > > UCD-SNMP is a daemon and SNMP utilities for Linux and FreeBSD > flavors that > work well too. > > http://ucd-snmp.ucdavis.edu/ > http://www.mrtg.org > http://www.castlerock.com > > Chuck > > > -----Original Message----- > > From: owner-freebsd-hackers@FreeBSD.ORG > > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of > Samuel Tardieu > > Sent: Wednesday, January 10, 2001 11:07 AM > > To: Robert Watson > > Cc: Josef Karthauser; hackers@FreeBSD.ORG; n_hibma@FreeBSD.ORG > > Subject: Re: Link up/down events > > > > > > On 10/01, Robert Watson wrote: > > > > | Presumably at some point in the stack, that notification > is translated > > | from a hardware event, which might be associated with devd in > > some manner > > | (and possibly also exposed there). > > > > This is the ideal situation. The other one being that the > status can be > > read, which would require some polling to monitor the link status. > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 12:11:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pilchuck.reedmedia.net (unknown [63.145.197.178]) by hub.freebsd.org (Postfix) with ESMTP id 3151337B404 for ; Wed, 10 Jan 2001 12:11:02 -0800 (PST) Received: from reed by pilchuck.reedmedia.net with local-esmtp (Exim 3.12 #1 (Debian)) id 14GRa9-00079b-00; Wed, 10 Jan 2001 12:10:53 -0800 Date: Wed, 10 Jan 2001 12:10:52 -0800 (PST) From: "Jeremy C. Reed" To: freebsd-hackers@freebsd.org Subject: what is swapper? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am working on a non-technical, generic BSD article about special system processes. I am trying to figure out some details about swapper (process 0) -- and I have a few questions. I understand that the "swapper process swaps in runnable processes that are currently swapped out, if there is room." Does anyone have an example or an easy-to-understand description? What is a frame? How is it related to swapper? What is a PCB (pcb)? How is is it related to swapper? Why is process 0 (zero) also called the "scheduler"? Is this the same as the swapper? What does "uao" (maybe "? anonymous object") mean? How is this related to the swapper (or pagedaemon)? On a related note, are there any special system processes other than the swapper, pagedaemon, reaper and ioflush? Where is this well documented? Thanks, Jeremy C. Reed http://www.reedmedia.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 12:19:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 07EF937B401 for ; Wed, 10 Jan 2001 12:19:08 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0AKJ6w15451; Wed, 10 Jan 2001 12:19:06 -0800 (PST) Date: Wed, 10 Jan 2001 12:19:06 -0800 From: Alfred Perlstein To: "Jeremy C. Reed" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: what is swapper? Message-ID: <20010110121906.I7240@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from reed@reedmedia.net on Wed, Jan 10, 2001 at 12:10:52PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jeremy C. Reed [010110 12:11] wrote: > I am working on a non-technical, generic BSD article about special system > processes. I am trying to figure out some details about swapper (process > 0) -- and I have a few questions. [snip] > > Where is this well documented? "The Design and Implementation of the 4.4BSD Operating System" as well as our mailing list archives. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 12:20:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 6F58C37B400 for ; Wed, 10 Jan 2001 12:20:05 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id D554D2B349; Wed, 10 Jan 2001 14:19:54 -0600 (CST) Date: Wed, 10 Jan 2001 14:19:54 -0600 From: Bill Fumerola To: "Jeremy C. Reed" Cc: freebsd-hackers@freebsd.org Subject: Re: what is swapper? Message-ID: <20010110141954.D35827@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from reed@reedmedia.net on Wed, Jan 10, 2001 at 12:10:52PM -0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 10, 2001 at 12:10:52PM -0800, Jeremy C. Reed wrote: > I am working on a non-technical, generic BSD article about special system > processes. I am trying to figure out some details about swapper (process > 0) -- and I have a few questions. [... lots of questions ...] > Where is this well documented? "The Design and Implementation of the 4.4BSD Operating System" -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 12:44:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 6FFAA37B402 for ; Wed, 10 Jan 2001 12:43:57 -0800 (PST) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id MAA91264; Wed, 10 Jan 2001 12:42:15 -0800 (PST) (envelope-from DougB@gorean.org) Date: Wed, 10 Jan 2001 12:42:14 -0800 (PST) From: Doug Barton X-X-Sender: To: Neil Blakey-Milner Cc: Dan Langille , Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <20010110112451.A52255@mithrandr.moria.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, we've obviously hit a hot button issue for you here Neil, for reasons that I don't pretend to understand. Please try to reduce the amount of emotion that's going into your argument.... It's just a computer thing after all. :) On Wed, 10 Jan 2001, Neil Blakey-Milner wrote: > On Wed 2001-01-10 (21:20), Dan Langille wrote: > > > > And when you finally realize that everyone else thinks this is a great > > > > idea, > > > > I do not like being included in "everyone". I don't think it's a great idea. > > If you didn't miss the comment, I was (and am now) attempting to emulate > Doug's style. As I said previously, don't give up your day job. > (The "I don't like this change, and since nobody > commented, it must be a terrible thing" style.) Actually, that's not my postition at all. I have stated clearly and on several occasions that I oppose this change on its merits. When I was doing consulting work as a business I got hired to research this exact issue. I can't tell you who the customer was, unfortunately. The problem is that while the existing behavior of cron is somewhat confusing for certain edge cases (like DST, or poorly configured system timekeeping) it is the only behavior that makes sense for the vast majority of cases. In addition, while the problems are somewhat confusing to novice admins, the solutions are well known, and what's more, well documented, particularly in sources outside the freebsd project. Therefore, changing existing behavior, especially to something as dramatic as the proposed change is ill advised. > These changes have been tested in OpenBSD for 3 years. With all due respect to our friends in the openbsd project, I don't consider this a significant factor. Others have expressed reasons why this may or may not be the case in other threads, I'll leave it to that. > The "solution" is _not_ to tell people they're stupid to schedule jobs > during the changeover. Woah.... who said anything about people being stupid? What I said was that novice system admins, all the way down to desktop freebsd users don't really care about this issue (other than the occasional "how come my periodic thingy ran twice?" e-mails). More experienced admins, and/or people who have really time critical jobs will take the appropriate steps to make sure things happen the way they want. Our current cron is working exactly as it is (or should be) expected. Therefore, like so many other parts of the system, the "fix" is user education, rather than violating POLA in a major way by changing many years of established behavior. > It has nothing to do with them. If they want jobs at 2am > in the morning, that's cool. What if there is no 2am on a given day? You have defined a fairly limited problem set wherein your proposed changes are the solution. What I'm trying to tell you is that the problem set is much larger then what you're seeing. > The fact the changeover is a problem is > cron-specific. It shouldn't be trying to be clever and work with local > time when local time does weird things like randomly add and remove time > from existence. Once again, the current implementation of cron isn't trying to be clever. It's just doing what it's told, namely running jobs when the system clock tells it what time it is. > Again, this change is from OpenBSD. We will synchronise with their > changes, and perhaps offer them back a patch to ignore what "ultra leet > sysadmins who rely on broken behaviour because people who don't are > simply stupid and shouldn't be running FreeBSD anyway!" with an option. Well, this paragraph is obviously an attempted dig at me, but you're dramatically misrepresenting my position, as explained above. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 12:47: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id E22F837B400 for ; Wed, 10 Jan 2001 12:46:51 -0800 (PST) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id MAA91286; Wed, 10 Jan 2001 12:46:39 -0800 (PST) (envelope-from DougB@gorean.org) Date: Wed, 10 Jan 2001 12:46:39 -0800 (PST) From: Doug Barton X-X-Sender: To: Gordon Tetlow Cc: Gerhard Sittig , Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 9 Jan 2001, Gordon Tetlow wrote: > Hello again. > > On Tue, 9 Jan 2001, Doug Barton wrote: > > > Neil Blakey-Milner wrote: > > > > > > On Tue 2001-01-09 (02:14), Doug Barton wrote: > > > > The point I'm trying (obviously in vain) to make is having cron do what > > amounts to "slewing its internal clock" will not work for everyone, and > > violates POLA. > > Why won't "slewing it internal close" not work for everyone, I'm not > trying to be a pain, but I just don't know. Also, what is POLA? I've commented in detail in previous messages as to why cron not sticking to what the system clock tells it is a bad idea. POLA stands for "The Principle Of Least Astonishment," which means that when you introduce changes into an established system you should do so in a way that does the least damage to continuity from one system to another. The FreeBSD project introducing a variety of cron that departs dramatically from many years of established behavior would be a POLA violation. > > You (pl.) keep referring to the "We need to hand-hold users who are too > > stupid to figure this stuff out for themselves" argument. While there are a > > lot of areas of the system that I try to make simpler and easier to > > understand, I don't see how we can possibly make this problem foolproof. > > The universe keeps producing better fools. > > I don't consider myself stupid (maybe other's do =) but when I'm admin'ing > a box, I have a bunch of other things that I'm thinking about and this > usually falls through the cracks. I have a hard time even remembering when > the DST shift is so I can change my alarm clock to make it into work at a > resonable hour. With all due respect, we can't change the laws of physics to help you with this one. :) Time is one of those things that system administrators have to manage, in more ways than one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 12:55:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id C6F0737B699 for ; Wed, 10 Jan 2001 12:55:17 -0800 (PST) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id MAA91291; Wed, 10 Jan 2001 12:52:29 -0800 (PST) (envelope-from DougB@gorean.org) Date: Wed, 10 Jan 2001 12:52:29 -0800 (PST) From: Doug Barton X-X-Sender: To: Neil Blakey-Milner Cc: Greg Black , Dan Langille , Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <20010110151211.A37285@mithrandr.moria.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Jan 2001, Neil Blakey-Milner wrote: > To summarise: It is broken, According to your definition of broken, which we have not necessarily reached a consensus on. > Not only that, but people who don't understand that it is broken are > unable to understand simple facts. Or perhaps we understand the simple facts, but there are more complex facts that make this change a bad idea. > In addition, it took the FreeBSD > project about 7 years to finally get their daily runs to run exactly > once, once every day. This is overstating the case. It was never really considered a huge issue by most, and at various times in the past the "correct" change for the majority of our userbase got mired down in socio-political arguments that had nothing to do with the technical merits. > What we haven't seen is any technical opposition to the algorithm used, > which has been explained. What you are seeing is opposition to the idea itself. I'm not going to waste time analyzing the implementation of what I think is a bad idea. :) Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 13:46:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with ESMTP id 0AEEA37B400 for ; Wed, 10 Jan 2001 13:46:14 -0800 (PST) Received: from localhost (dphoenix@localhost) by gandalf.bravenet.com (8.10.1/8.10.1) with ESMTP id f0ALk0A14301 for ; Wed, 10 Jan 2001 13:46:00 -0800 (PST) X-Authentication-Warning: gandalf.bravenet.com: dphoenix owned process doing -bs Date: Wed, 10 Jan 2001 13:46:00 -0800 (PST) From: Dan Phoenix To: freebsd-hackers@freebsd.org Subject: apache PMAP_SHPGPERPROC (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have tried much ..increasing limits in the kernel etc.... real questions is ......how do you increase the socket buffer space? ---------- example.... 230 User dphoenix logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls ftp: socket: No buffer space available ftp> ls 425 Can't open passive connection: No buffer space available. Passive mode refused. ftp> ---------- Forwarded message ---------- Date: Fri, 5 Jan 2001 17:44:55 -0800 (PST) From: Dan Phoenix To: questions@FreeBSD.ORG Subject: apache PMAP_SHPGPERPROC Jan 5 15:42:53 www /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC Jan 5 15:49:59 www /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC Jan 5 16:11:04 www /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC Jan 5 16:16:44 www /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC apache is running with 170 deamons. ftp telling me it us running out of buffer space....there is 256 megs of ram.....top reports 11 megs left. What is this from? PMAP_SHPGPERPROC=201 from lint apparently. so going to increase it to 500 and see if that fixes this........ it is a php apache server than connects to another internal mysql server. i get this error trying to connect with mysql every third time or so. ERROR 2004: Can't create TCP/IP socket (55) yet when apache is not running ....it seems to work alright! -- Dan +-----------------------------------------------------------------------+ | ----- Daniel Phoenix Mail to:dan@bravenet.com | | | | / ___ ____ ____ |____ ____ | | | | / |/ / | \ / | \ | \ | \ __|__ | | | \ | | | \ / |____/ | | |____/ | | | | / | | | \ / | | | | | | | |__/ | \____\ \/ \____ | | \____ | | +_______________________________________________________________________+ mv /lib/ld.so /lib/ld.so.old;echo "Damnit" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 13:49:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EDB2337B400; Wed, 10 Jan 2001 13:49:05 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f0ALml784324; Wed, 10 Jan 2001 16:48:47 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 10 Jan 2001 16:48:47 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Samuel Tardieu Cc: Josef Karthauser , hackers@FreeBSD.ORG, n_hibma@FreeBSD.ORG Subject: Re: Link up/down events In-Reply-To: <2001-01-10-18-06-45+trackit+sam@inf.enst.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Jan 2001, Samuel Tardieu wrote: > On 10/01, Robert Watson wrote: > > | Presumably at some point in the stack, that notification is translated > | from a hardware event, which might be associated with devd in some manner > | (and possibly also exposed there). > > This is the ideal situation. The other one being that the status can be > read, which would require some polling to monitor the link status. If can already be polled, I believe through an ioctl, in -CURRENT at least: fxp0: flags=8802 mtu 1500 ether 00:d0:b7:68:4a:7b media: autoselect status: no carrier supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP P 10baseT/UTP xl0: flags=8843 mtu 1500 inet6 fe80::2b0:d0ff:fe2b:76d5%xl0 prefixlen 64 scopeid 0x3 inet 10.33.40.80 netmask 0xffff0000 broadcast 10.33.255.255 ether 00:b0:d0:2b:76:d5 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP Not that fxp0 is reporting no carrier, whereas xl0 is reporting an active link. A quick glance at the ifmedia.c from ifconfig shows: if (ifmr.ifm_status & IFM_AVALID) { printf(" status: "); switch (IFM_TYPE(ifmr.ifm_active)) { case IFM_ETHER: if (ifmr.ifm_status & IFM_ACTIVE) printf("active"); else printf("no carrier"); break; case IFM_FDDI: case IFM_TOKEN: if (ifmr.ifm_status & IFM_ACTIVE) printf("inserted"); else printf("no ring"); break; } As I stated previously, I believe that the link change event should be propagated up through the network stack and announced to applications via the routing socket primitive, which already announces the arrival and departure of interfaces. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 13:50:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.colltech.com (ausproxy.colltech.com [208.229.236.19]) by hub.freebsd.org (Postfix) with ESMTP id 062A237B400 for ; Wed, 10 Jan 2001 13:50:06 -0800 (PST) Received: from mail2.colltech.com (mail2.colltech.com [208.229.236.41]) by mx1.colltech.com (8.9.3/8.9.3/not) with ESMTP id PAA22329; Wed, 10 Jan 2001 15:50:01 -0600 Received: from colltech.com (dhcp5212.wdc.colltech.com [10.20.5.212]) by mail2.colltech.com (8.9.3/8.9.3/not) with ESMTP id PAA13241; Wed, 10 Jan 2001 15:48:10 -0600 Message-ID: <3A5CD933.C4FD1EFE@colltech.com> Date: Wed, 10 Jan 2001 16:50:43 -0500 From: Daniel Hagan X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Phoenix , freebsd-hackers@freebsd.org Subject: Re: apache PMAP_SHPGPERPROC (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are you running out of mbufs? Try running netstat -m and comparing peak and max mbuf allocations. If you're running out, you'll need to recompile your kernel (I can't remember the option off-hand, but it should be in LINT). Daniel Dan Phoenix wrote: > > I have tried much ..increasing limits in the kernel etc.... > real questions is ......how do you increase the socket buffer space? > > ---------- > > example.... > > 230 User dphoenix logged in. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> ls > ftp: socket: No buffer space available > ftp> ls > 425 Can't open passive connection: No buffer space available. > Passive mode refused. > ftp> > > ---------- Forwarded message ---------- > Date: Fri, 5 Jan 2001 17:44:55 -0800 (PST) > From: Dan Phoenix > To: questions@FreeBSD.ORG > Subject: apache PMAP_SHPGPERPROC > > Jan 5 15:42:53 www /kernel: pmap_collect: collecting pv entries -- > suggest increasing PMAP_SHPGPERPROC > Jan 5 15:49:59 www /kernel: pmap_collect: collecting pv entries -- > suggest increasing PMAP_SHPGPERPROC > Jan 5 16:11:04 www /kernel: pmap_collect: collecting pv entries -- > suggest increasing PMAP_SHPGPERPROC > Jan 5 16:16:44 www /kernel: pmap_collect: collecting pv entries -- > suggest increasing PMAP_SHPGPERPROC > > apache is running with 170 deamons. > ftp telling me it us running out of buffer space....there is 256 megs of > ram.....top reports 11 megs left. What is this from? > PMAP_SHPGPERPROC=201 from lint apparently. > so going to increase it to 500 and see if that fixes this........ > it is a php apache server than connects to another internal mysql server. > > i get this error trying to connect with mysql every third time or so. > ERROR 2004: Can't create TCP/IP socket (55) > > yet when apache is not running ....it seems to work alright! > > -- > Dan > > +-----------------------------------------------------------------------+ > | ----- Daniel Phoenix Mail to:dan@bravenet.com | | > | | / ___ ____ ____ |____ ____ | | > | | / |/ / | \ / | \ | \ | \ __|__ | > | | \ | | | \ / |____/ | | |____/ | | > | | / | | | \ / | | | | | | > | |__/ | \____\ \/ \____ | | \____ | | > +_______________________________________________________________________+ > mv /lib/ld.so /lib/ld.so.old;echo "Damnit" > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 13:59: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with ESMTP id 32CA537B69F for ; Wed, 10 Jan 2001 13:58:43 -0800 (PST) Received: from localhost (dphoenix@localhost) by gandalf.bravenet.com (8.10.1/8.10.1) with ESMTP id f0ALwMC16914; Wed, 10 Jan 2001 13:58:22 -0800 (PST) X-Authentication-Warning: gandalf.bravenet.com: dphoenix owned process doing -bs Date: Wed, 10 Jan 2001 13:57:00 -0800 (PST) From: Dan Phoenix To: Daniel Hagan Cc: freebsd-hackers@freebsd.org Subject: Re: apache PMAP_SHPGPERPROC (fwd) In-Reply-To: <3A5CD933.C4FD1EFE@colltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ya i checked that out already. netstat -m seems fine. What I am trying to do is move apache off this linux box to a freebsd one to split up the load. I leave mysql on linux box for the SMP. currently I have it moved back to linux box till I can fix this error. Here are some error logs from linux box right now. What I am thinking of trying...if in fact it is an openfile issue is to.... [Wed Jan 10 01:08:20 2001] [notice] Apache/1.3.11 (Unix) PHP/3.0.16 configured -- resuming normal operations [Wed Jan 10 11:57:53 2001] [error] (23)Too many open files in system: accept: (client socket) [Wed Jan 10 12:50:41 2001] [error] (32)Broken pipe: accept: (client socket) [Wed Jan 10 13:14:34 2001] [error] (32)Broken pipe: accept: (client socket) [Wed Jan 10 14:20:55 2001] [error] (32)Broken pipe: accept: (client socket) [Wed Jan 10 14:36:54 2001] [error] (32)Broken pipe: accept: (client socket) [Wed Jan 10 14:36:54 2001] [error] (32)Broken pipe: accept: (client socket) ...add these 3 lines to /usr/local/apache/bin/apachectl start section.... sysctl -w kern.maxfiles=1000000 sysctl -w kern.maxfilesperproc=1000000 ulimit -n 100000 #open more files than standard I pray this works....any suggestions for my move back to freebsd machine to fix this would be appreciated....so far I have cvsup'd the latest source and gone to a snapshot php version that had some freebsd fixes.... I doubt that will solve this...but if anyone has seen this before please offer me some insite...thankyou On Wed, 10 Jan 2001, Daniel Hagan wrote: > Date: Wed, 10 Jan 2001 16:50:43 -0500 > From: Daniel Hagan > To: Dan Phoenix , freebsd-hackers@freebsd.org > Subject: Re: apache PMAP_SHPGPERPROC (fwd) > > Are you running out of mbufs? Try running netstat -m and comparing peak > and max mbuf allocations. If you're running out, you'll need to > recompile your kernel (I can't remember the option off-hand, but it > should be in LINT). > > Daniel > > Dan Phoenix wrote: > > > > I have tried much ..increasing limits in the kernel etc.... > > real questions is ......how do you increase the socket buffer space? > > > > ---------- > > > > example.... > > > > 230 User dphoenix logged in. > > Remote system type is UNIX. > > Using binary mode to transfer files. > > ftp> ls > > ftp: socket: No buffer space available > > ftp> ls > > 425 Can't open passive connection: No buffer space available. > > Passive mode refused. > > ftp> > > > > ---------- Forwarded message ---------- > > Date: Fri, 5 Jan 2001 17:44:55 -0800 (PST) > > From: Dan Phoenix > > To: questions@FreeBSD.ORG > > Subject: apache PMAP_SHPGPERPROC > > > > Jan 5 15:42:53 www /kernel: pmap_collect: collecting pv entries -- > > suggest increasing PMAP_SHPGPERPROC > > Jan 5 15:49:59 www /kernel: pmap_collect: collecting pv entries -- > > suggest increasing PMAP_SHPGPERPROC > > Jan 5 16:11:04 www /kernel: pmap_collect: collecting pv entries -- > > suggest increasing PMAP_SHPGPERPROC > > Jan 5 16:16:44 www /kernel: pmap_collect: collecting pv entries -- > > suggest increasing PMAP_SHPGPERPROC > > > > apache is running with 170 deamons. > > ftp telling me it us running out of buffer space....there is 256 megs of > > ram.....top reports 11 megs left. What is this from? > > PMAP_SHPGPERPROC=201 from lint apparently. > > so going to increase it to 500 and see if that fixes this........ > > it is a php apache server than connects to another internal mysql server. > > > > i get this error trying to connect with mysql every third time or so. > > ERROR 2004: Can't create TCP/IP socket (55) > > > > yet when apache is not running ....it seems to work alright! > > > > -- > > Dan > > > > +-----------------------------------------------------------------------+ > > | ----- Daniel Phoenix Mail to:dan@bravenet.com | | > > | | / ___ ____ ____ |____ ____ | | > > | | / |/ / | \ / | \ | \ | \ __|__ | > > | | \ | | | \ / |____/ | | |____/ | | > > | | / | | | \ / | | | | | | > > | |__/ | \____\ \/ \____ | | \____ | | > > +_______________________________________________________________________+ > > mv /lib/ld.so /lib/ld.so.old;echo "Damnit" > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 14:24:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from max5.rrze.uni-erlangen.de (max5.rrze.uni-erlangen.de [131.188.3.50]) by hub.freebsd.org (Postfix) with ESMTP id BC04237B69B for ; Wed, 10 Jan 2001 14:23:54 -0800 (PST) Received: from devil.rrze.uni-erlangen.de by max5.rrze.uni-erlangen.de with ESMTP for freebsd-hackers@FreeBSD.ORG; Wed, 10 Jan 2001 23:23:53 +0100 Received: (from unrza2@localhost) by devil.rrze.uni-erlangen.de (8.9.3/8.9.3) id XAA22178 for freebsd-hackers@FreeBSD.ORG; Wed, 10 Jan 2001 23:28:07 +0100 (CET) From: Jochen Kaiser Date: Wed, 10 Jan 2001 23:28:06 +0100 To: freebsd-hackers@FreeBSD.ORG Subject: optmizations/real time conditions Message-Id: <20010110232806.A17500@devil.rrze.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi ! I am working on some modifications in the netinet code. I therefore want as little intereferences/side affects as possible. I would like real time conditions ... but I think thats just an illusion :) However, I want to minimize the effects done by userland processes, getty,login,cron et cetera ... and I need to optimize the kernel. Are there any documents about this issue? I wonder wether the scheduler works right when I disable the swapper for example ... I did search via google - but did not find any really reasonable stuff. I'd appreciate any help or pointers according to this matter. tia Jochen -- Jochen Kaiser kind@IRCNET, phone +49 9131 85-28134 Network Administration mailto:jochen.kaiser@rrze.uni-erlangen.de Regionales Rechenzentrum Universitaet Erlangen-Nuernberg, Germany GPG public key: http://www.uni-erlangen.de/~unrza2/public_key.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 15:52:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with ESMTP id F353537B6A2 for ; Wed, 10 Jan 2001 15:51:51 -0800 (PST) Received: from localhost (dphoenix@localhost) by gandalf.bravenet.com (8.10.1/8.10.1) with ESMTP id f0ANpXs08537; Wed, 10 Jan 2001 15:51:34 -0800 (PST) X-Authentication-Warning: gandalf.bravenet.com: dphoenix owned process doing -bs Date: Wed, 10 Jan 2001 15:51:33 -0800 (PST) From: Dan Phoenix To: Daniel Hagan Cc: freebsd-hackers@freebsd.org Subject: Re: apache PMAP_SHPGPERPROC (fwd) In-Reply-To: <3A5CD933.C4FD1EFE@colltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok i fixed it....nfsbufs or something and maxusers i increased solved this problem. On Wed, 10 Jan 2001, Daniel Hagan wrote: > Date: Wed, 10 Jan 2001 16:50:43 -0500 > From: Daniel Hagan > To: Dan Phoenix , freebsd-hackers@freebsd.org > Subject: Re: apache PMAP_SHPGPERPROC (fwd) > > Are you running out of mbufs? Try running netstat -m and comparing peak > and max mbuf allocations. If you're running out, you'll need to > recompile your kernel (I can't remember the option off-hand, but it > should be in LINT). > > Daniel > > Dan Phoenix wrote: > > > > I have tried much ..increasing limits in the kernel etc.... > > real questions is ......how do you increase the socket buffer space? > > > > ---------- > > > > example.... > > > > 230 User dphoenix logged in. > > Remote system type is UNIX. > > Using binary mode to transfer files. > > ftp> ls > > ftp: socket: No buffer space available > > ftp> ls > > 425 Can't open passive connection: No buffer space available. > > Passive mode refused. > > ftp> > > > > ---------- Forwarded message ---------- > > Date: Fri, 5 Jan 2001 17:44:55 -0800 (PST) > > From: Dan Phoenix > > To: questions@FreeBSD.ORG > > Subject: apache PMAP_SHPGPERPROC > > > > Jan 5 15:42:53 www /kernel: pmap_collect: collecting pv entries -- > > suggest increasing PMAP_SHPGPERPROC > > Jan 5 15:49:59 www /kernel: pmap_collect: collecting pv entries -- > > suggest increasing PMAP_SHPGPERPROC > > Jan 5 16:11:04 www /kernel: pmap_collect: collecting pv entries -- > > suggest increasing PMAP_SHPGPERPROC > > Jan 5 16:16:44 www /kernel: pmap_collect: collecting pv entries -- > > suggest increasing PMAP_SHPGPERPROC > > > > apache is running with 170 deamons. > > ftp telling me it us running out of buffer space....there is 256 megs of > > ram.....top reports 11 megs left. What is this from? > > PMAP_SHPGPERPROC=201 from lint apparently. > > so going to increase it to 500 and see if that fixes this........ > > it is a php apache server than connects to another internal mysql server. > > > > i get this error trying to connect with mysql every third time or so. > > ERROR 2004: Can't create TCP/IP socket (55) > > > > yet when apache is not running ....it seems to work alright! > > > > -- > > Dan > > > > +-----------------------------------------------------------------------+ > > | ----- Daniel Phoenix Mail to:dan@bravenet.com | | > > | | / ___ ____ ____ |____ ____ | | > > | | / |/ / | \ / | \ | \ | \ __|__ | > > | | \ | | | \ / |____/ | | |____/ | | > > | | / | | | \ / | | | | | | > > | |__/ | \____\ \/ \____ | | \____ | | > > +_______________________________________________________________________+ > > mv /lib/ld.so /lib/ld.so.old;echo "Damnit" > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 16:17:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id B98A937B402 for ; Wed, 10 Jan 2001 16:17:33 -0800 (PST) Received: (qmail 21645 invoked by uid 0); 11 Jan 2001 00:17:31 -0000 Received: from evrtwa1-ar5-105-005.elnk.dsl.gtei.net (HELO bsd.localnet) (4.35.105.5) by mail.gmx.net (mail08) with SMTP; 11 Jan 2001 00:17:31 -0000 Received: (from richard@localhost) by bsd.localnet (8.11.1/8.11.1) id f0ANBAw36717 for hackers@FreeBSD.ORG; Wed, 10 Jan 2001 15:11:10 -0800 (PST) Date: Wed, 10 Jan 2001 15:11:10 -0800 From: Richard Krush To: hackers@FreeBSD.ORG Subject: Re: help! Message-ID: <20010110151110.A36692@bsd.localnet> Mail-Followup-To: hackers@FreeBSD.ORG References: <000a01c07531$f2b26a00$48752cd8@clp> <20010110102903.A98642@lucifer.bart.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010110102903.A98642@lucifer.bart.nl>; from jruigrok@via-net-works.nl on Wed, Jan 10, 2001 at 10:29:03AM +0100 X-Operating-System: FreeBSD 4.2-RELEASE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 10, 2001 at 10:29:03AM +0100, Jeroen Ruigrok van der Werven wrote: > -On [20010103 03:55], clp@nji.com (clp@nji.com) wrote: > >Hi. I have a netgear Ethernet card installed in my computer. In order > >to reconnect my computer to the internet, I have to reinstall the > >drivers and they're missing. So, I opened up my computer to look at the > >Ethernet card and I copied down the necessary numbers. However, I do > >not know how to download the program. I found this e-mail address on > >the web and would greatly appreciate some help. Thank you! -Christina, > >clp@nji.com > > And does your computer run FreeBSD? > > Also, a question such as this should not have been sent to > hackers@freebsd.org, but questions@freebsd.org. > I doubt she is even subscribed to this mailing list (she is refering to it as "email address"). Also I doubt she is running any kind of UNIX at all (she's asking for help with drivers). -- Richard Krushelnitskiy "A mathematician is a blind man in a dark richard_k@gmx.net room looking for a black cat which isn't http://rkrush.cjb.net there." -- Charles Darwin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 17:41:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 4B4C537B401 for ; Wed, 10 Jan 2001 17:41:23 -0800 (PST) Received: from newsguy.com (p51-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.116]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id KAA01741; Thu, 11 Jan 2001 10:41:11 +0900 (JST) Message-ID: <3A5D0EAC.4E6E00B1@newsguy.com> Date: Thu, 11 Jan 2001 10:38:52 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Chris Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: forth/loader question.. References: <3A472397.A806A3FD@iastate.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris wrote: > > I am attempting to add some functionality to the loader, but have come > across a minor problem. Is there some way to include forth files, > given a string? > > s" file" included (gforth example) Yes, there is... I just can't recall the exact name right now. :-) You can always do a s" include file" evaluate, but... :-) Also, "include" is a builtin, so you can pass arguments to it when compiling it: : whatever s" file" include ; Read the finer details for builtins on the loader.4th(8) man page, or, worse yet, check out it's exact definition on /sys/boot/common/interp_forth.c. Their behavior is highly complex... > What I would like to do is read in a /boot/loader.rc.$ip or something > similar. This would allow a number of machines to be booted diskless > and yet have different boot configurations. IMHO, what *should* be done is expanding environment variables in the loader_conf_files="xyzyz" lines. Previously, there was no support in loader(8) to be able to do this on support.4th, but now there is. A function that went through all environment variables in a string and expanded them would be an useful addition in a number of places. One such a function is written, it can be used at set_conf_files, right after strdup. Then you can have loader_conf_files="loader.conf.$ip". If you still wish to have Forth code executing, you can just place an exec="include loader.rc.whatever" line there, but I'd prefer to keep the configuration passive as much as possible. > : read_loader_rc_specific > s" boot.netif.hwaddr" getenv > dup -1 = if > drop > s" boot.netif.ip" getenv > dup -1 = if > drop 0 0 > then > then > s" /boot/loader.rc." > 2over nip over + allocate > if ( out of memory ) > 2drop 2drop > 100 exit > then > 0 2swap strcat 2swap strcat > read-conf > ; read-conf reads conf files, it doesn't execute anything. In a private discussion long ago, Jordan said he would like for .rc and .4th files to remain scripts, and .conf files to be variable-setting files (like they are now :). Except, of course, that there are a couple of exceptions on the .conf files format to allow for the cases where it is absolutely necessary to execute code. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 18:23:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4F1B137B404 for ; Wed, 10 Jan 2001 18:23:14 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f0B2ND786838 for ; Wed, 10 Jan 2001 21:23:13 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 10 Jan 2001 21:23:13 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-hackers@FreeBSD.org Subject: Setting default hostname to localhost Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Under FreeBSD, the default hostname in /etc/defaults/rc.conf is currently an empty string, "". If the hostname is not later defined, then the system will use this through multi-user mode, which can disrupt application behavior. This can occur if DHCP doesn't provide a hostname, or if the user neglects to configure one. Applications such as lpd get very upset and refuse to run with no hostname, which breaks printing on hosts not connected to the network. Similarly, cvsup refuses to run with a GUI since it can't resolve the hostname; similar sorts of situations can arise with SSH X11 forwarding and other applications (GNOME whined at me for a while, but that may have been fixed?). In any case, the failure to define a hostname seems to result in application failures. Apple's Darwin addresses this by setting the default hostname to "localhost" which, due to /etc/hosts, generally resolves properly and means applications can behave moderately correctly. Unless there are some really good reasons not to (which there may be), I'd like to commit changes to -CURRENT's /etc/default/rc.conf to change the default hostname to "localhost". If the user configures a hostname, or DHCP provides one, it will be overridden, of course, so should not impact any configuration but one where the hostname is left undefined. Thoughts? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 18:35:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail5.sc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by hub.freebsd.org (Postfix) with ESMTP id 733E637B400; Wed, 10 Jan 2001 18:35:03 -0800 (PST) Received: from sc.rr.com ([24.88.102.101]) by mail5.sc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Wed, 10 Jan 2001 21:34:54 -0500 Received: (from dmaddox@localhost) by sc.rr.com (8.11.1/8.11.1) id f0B2Zc000693; Wed, 10 Jan 2001 21:35:38 -0500 (EST) (envelope-from dmaddox) Date: Wed, 10 Jan 2001 21:35:38 -0500 From: "Donald J . Maddox" To: Robert Watson Cc: freebsd-hackers@FreeBSD.org Subject: Re: Setting default hostname to localhost Message-ID: <20010110213538.A668@cae88-102-101.sc.rr.com> Reply-To: dmaddox@sc.rr.com Mail-Followup-To: Robert Watson , freebsd-hackers@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Wed, Jan 10, 2001 at 09:23:13PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 10, 2001 at 09:23:13PM -0500, Robert Watson wrote: > /etc/default/rc.conf to change the default hostname to "localhost". If > the user configures a hostname, or DHCP provides one, it will be > overridden, of course, so should not impact any configuration but one > where the hostname is left undefined. A cursory glance at /sbin/dhclient-script seems to indicate that DHCP will NOT override the hostname unless it is an empty string. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 18:36:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id A7D1B37B400 for ; Wed, 10 Jan 2001 18:36:00 -0800 (PST) Received: (qmail 16234 invoked by uid 1001); 11 Jan 2001 12:35:32 +1000 X-Posted-By: GJB-Post 2.08 05-Jan-2001 (FreeBSD) X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Thu, 11 Jan 2001 12:35:32 +1000 From: Greg Black To: Neil Blakey-Milner Cc: Dan Langille , Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <3A5B5656.E2AAF0B5@FreeBSD.org> <200101100820.VAA28529@ducky.nz.freebsd.org> <20010110112451.A52255@mithrandr.moria.org> <20010110151211.A37285@mithrandr.moria.org> In-reply-to: <20010110151211.A37285@mithrandr.moria.org> of Wed, 10 Jan 2001 15:12:11 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Neil Blakey-Milner wrote: > On Wed 2001-01-10 (21:35), Greg Black wrote: > > To summarise: It is broken, we have the fix, No. You believe it is broken; you believe you have a fix. Not everybody agrees that it is broken or that any fix is required. > > Fiddling with cron to work around incompetent sysadmins just > > exposes the rest of us to new bugs in cron -- a program that we > > depend on for a large range of important tasks. > > Here you are doing it again. You're calling people who expect a tool to > work in a reliable and obvious way "incompetent", No, I'm calling people who can't be bothered finding out how things work incompetent. > If you hadn't noticed > (despite my indication of the fact), I was attempting to emulate the > style of the detraction; that's why you seem to believe I'm getting > worked up over this. Trust me, I'm not. You appear to be worked up, and denials don't reduce that appearance. > What we haven't seen is any technical opposition to the algorithm used, > which has been explained. If there is a problem with it, then that > should be determined. My review of it indicates the OpenBSD cron > behaviour is very specific, reliable, and obvious. People who don't believe in the justification for the change are not going to waste their time reviewing the implementation. If that's going to be done, it will have to be done by somebody who thinks the idea makes sense. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 18:46:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bsdhome.dyndns.org (unknown [24.25.2.13]) by hub.freebsd.org (Postfix) with ESMTP id EDCE137B400 for ; Wed, 10 Jan 2001 18:46:27 -0800 (PST) Received: from vger.bsdhome.com (vger [192.168.220.2]) by bsdhome.dyndns.org (8.11.1/8.11.1) with ESMTP id f0B2kQt09613 for ; Wed, 10 Jan 2001 21:46:26 -0500 (EST) (envelope-from bsd@bsdhome.com) Received: (from bsd@localhost) by vger.bsdhome.com (8.11.1/8.11.1) id f0B2kQv57381 for hackers@freebsd.org; Wed, 10 Jan 2001 21:46:26 -0500 (EST) (envelope-from bsd) Date: Wed, 10 Jan 2001 21:46:26 -0500 From: Brian Dean To: hackers@freebsd.org Subject: Re: KVM switch vs. FreeBSD psm driver (Solved!) Message-ID: <20010110214626.B57045@vger.bsdhome.com> References: <200101062359.f06NxIv11832@vashon.polstra.com> <3A580ABB.1C35C44C@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A580ABB.1C35C44C@softweyr.com>; from wes@softweyr.com on Sat, Jan 06, 2001 at 11:20:43PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 06, 2001 at 11:20:43PM -0700, Wes Peters wrote: > John Polstra wrote: > > > > I'm happy to report that this problem is solved now. After one fellow > > wrote to me and reported that his switch of the same model worked OK, > > I hunted around on the Belkin web site. It turns out that Belkin > > assembled a few thousand of the units with two EPROMs swapped, and > > mine was one of them. I moved the chips to their proper sockets, and > > now everything works fine. You can find the gory details here: > > Snort. Let's hear it for good web support, though. Now that's some robust firmware; what's amazing is that it even worked at all! -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 19:17:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id E0C5737B400 for ; Wed, 10 Jan 2001 19:17:29 -0800 (PST) Received: (qmail 24917 invoked by uid 0); 11 Jan 2001 03:17:27 -0000 Received: from pd9508835.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.53) by mail.gmx.net (mail05) with SMTP; 11 Jan 2001 03:17:27 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id XAA31472; Wed, 10 Jan 2001 23:39:07 +0100 Date: Wed, 10 Jan 2001 23:39:07 +0100 From: Gerhard Sittig To: Doug Barton Cc: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010110233907.L253@speedy.gsinet> References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A5AE490.D251F590@gorean.org>; from DougB@gorean.org on Tue, Jan 09, 2001 at 02:14:40AM -0800 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 09, 2001 at 02:14 -0800, Doug Barton wrote: > Gerhard Sittig wrote: > > > > It's not that I want to talk you into something you don't > > want. > > But that's exactly what you're trying to do. Honestly -- no! :) OK, I've been unclear there. I did reply to your message, but writing to lists I usually do so for a broader audience -- for everything else I could use PM instead. So my continued proposal and discussion is mainly meant for those who do have interest in making cron work the way many users expect it to. Maybe more silent readers may find reasons against the proposal I fail to see, so far? I have no doubt that there is positive - while silent - agreement. Although I recognize you've dealt with the subject in much detail, know it's anything but trivial, and are aware that FreeBSD currently has no real solution, I realize you like telling all the concerned admins to shift their jobs around instead of accepting code changes meaning to make things work OOTB. It's nothing I can change. And it's nothing I would want to change after some amount of effort. We both (as well as others) have stated our impressions and that they're quite fixed and won't move. Let's end it here. > I will not bother to re-re-restate my points as to why what > you're proposing is a bad idea. Do all the testing you want, > but make sure you understand that there will be vigorous > resistance to incorporating your proposed changes. I take notice of your (and Greg Black's) reservation / being opposed, respect it and conclude that the change will have to - default to the current behaviour (something quite usual for expanding changes) - be well documented (something absolutely clear to all of us, strictly speaking it's way out of imagination for us how somebody could contribute undocumented stuff ... :) - yet be enabled easily for those interested in the change to work for them and free up some of their resources for more important tasks - maybe provide knobs (besides the on-off-switch) to customize behaviour in a more fine grained way Looking at the echo returning so far I see _much_ more "yes" than "nope" answers. There's consent that *something* has to be done. And I read the answers ranging from "yes, please do it!" (some six) via "I don't care -- as long as there's no impact on me ..." (one or two) to the few "I don't like it, I don't have this problem / I don't see this as a problem" (two, and the "explanation" is my guess -- but it's the only reason I could see for this position). Although I'm aware that statistics won't work for these small numbers - ten people took part in the thread so far - there's a trend visible to me. :> When in doubt, one could dig up in the archives how many threads took place in the past that "cron does strange things", which would enormously put weight on the "please do change something" section ... BTW: There's good news for those with a dislike regarding the change: While testing I'm stuck again, so there will be some more delay. It looks like I have to setup another OpenBSD machine to look into it a little deeper. Those who are interested in the status reached so far may contact me off list. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 19:17:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 09D9037B401 for ; Wed, 10 Jan 2001 19:17:30 -0800 (PST) Received: (qmail 24926 invoked by uid 0); 11 Jan 2001 03:17:28 -0000 Received: from pd9508835.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.53) by mail.gmx.net (mail05) with SMTP; 11 Jan 2001 03:17:28 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id XAA31476; Wed, 10 Jan 2001 23:50:48 +0100 Date: Wed, 10 Jan 2001 23:50:48 +0100 From: Gerhard Sittig To: Doug Barton Cc: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010110235048.M253@speedy.gsinet> References: <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010109124044.A16276@mithrandr.moria.org> <3A5B5656.E2AAF0B5@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A5B5656.E2AAF0B5@FreeBSD.org>; from DougB@FreeBSD.org on Tue, Jan 09, 2001 at 10:20:06AM -0800 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ note to nbm: would you like getting cc'ed, too? I'm used to keep receiver lists as short as possible, but feel free to state your wishes :) ] On Tue, Jan 09, 2001 at 10:20 -0800, Doug Barton wrote: > Neil Blakey-Milner wrote: > > > > Now, consider NTP calibrations, > > . . . > > Your example basically says, "Imagine a case where we have an > admin with time-critical jobs who refuses to set up proper time > synchronization." No, I read the example somewhat different: The admin told its system to run a job - every day - once a day - when 2:00 (or what the time was) is reached -- we already agree that this is more of a *hint* to the UNIX system than a strict regime, experience tells us the job won't get run before 2:00 but might start a while after "2:00 sharp" took place In the above example I wouldn't even dare to refer to the job as "time-critical" in the meaning that it is meant to run at an exact time. What's much more important to the usual backup / indexing / statistics / cleanup / whatever jobs is that they _do_ happen, and do so with the specified frequency. The reason why the discussion about "cron(8) is broken" comes up twice a year: Saying "'once a day' may be 'at least once' or 'maybe not at all'" is somewhat counter intuitive. There might be reasons why a given implementation shows some effect. But this doesn't necessarily mean that the mechanism is supposed to act this way (we don't blame UNIX to be broken just because the FreeBSD implementation has some bugs, do we?) ... That's the whole point where I see cron(8) to deviate from human expectation: Imagine you have a daily job - in your Real Life(TM) - to fetch your mail from the physical box, usually scheduled for 6:00 since you get up at 5:30. Would you skip it once you wake up late at 6:05 or would you try to catch up by walking through your todo list in the form it has accumulated in? I thought the latter would be what dispatching jobs and scheduling them in the possible way is meant to be like ... It's your dammit job on the list and it's the next tick after going to bed having done the previous day's jobs. Let's start the new day with its first job and do everything that's been scheduled. > > Now, the fix itself is to honour DST changes, and that will > > work for everyone. > > The point I'm trying (obviously in vain) to make is having cron > do what amounts to "slewing its internal clock" will not work > for everyone, and violates POLA. Whether there's a "violation" obviously depends on the expectation one has. That's why there will be a switch for what policy is the one the user wants to follow. This should satisfy those who believe cron to be correct in its current shape as well as those thinking that cron should behave differently. Do we have to discuss what DST changes mean? The different opinions what's expected behaviour seem to stem from the points of view "the skipped hour doesn't happen" vs. "the hour is squeezed into the one second" as well as "the hour willingly happens twice" vs. "there's a gap to be filled, we only count something to _have_ a datetime without really meaning it's this time, again (we already had it)". Or is it more of "in all the DST period it's not really that late"? As much as I like Neil's idea of using UTC for specifying execution times and thereby eliminating any ambiguity, I'm afraid this will make FreeBSD do something nobody else does this way -- I'm not clear as to how much this would confuse admins. What do other sibling projects do in this situation? Admittedly I haven't looked at NetBSD's and BSD/OS' documentation regarding this topic, but it seems I will have to in the very near future. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 20:42: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wartch.sapros.com (rularan.sapros.com [204.182.55.17]) by hub.freebsd.org (Postfix) with ESMTP id 0018537B400 for ; Wed, 10 Jan 2001 20:41:40 -0800 (PST) Received: from wartch.sapros.com (localhost [127.0.0.1]) by wartch.sapros.com (8.11.1/8.11.1) with ESMTP id f0B4fe008116 for ; Wed, 10 Jan 2001 20:41:40 -0800 (PST) (envelope-from peterh@wartch.sapros.com) Message-Id: <200101110441.f0B4fe008116@wartch.sapros.com> To: freebsd-hackers@freebsd.org Subject: pthread_attr_setschedparam, mozilla, and PTHREAD_MAX_PRIORITY Date: Wed, 10 Jan 2001 20:41:40 -0800 From: Peter Haight Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I rebuilt mozilla after upgrading to 4.2 and was getting an assertion because pthread_attr_setschedparam() was failing with a ENOTSUP. It turns out Mozilla was trying to set the thread priority to 42 which is above the new limit of 31 which changed a little before 4.2-RELEASE. To patch mozilla I had to do a '#if __FreeBSD_version >= 420000' because PTHREAD_MAX_PRIORITY is in a private pthreads header file. I'm wondering if it might not be a good idea to have that define show up somewhere public? The only other thing I can think of is to call pthread_attr_setschedparam() a couple of times to scope out the range of accepted values. Or maybe I'm missing some better solution. (I'm not on the list, so please cc me). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 20:50:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 3B95E37B401; Wed, 10 Jan 2001 20:50:35 -0800 (PST) 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 PAA23883; Thu, 11 Jan 2001 15:20:33 +1030 (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: Date: Thu, 11 Jan 2001 15:20:33 +1030 (CST) From: "Daniel O'Connor" To: Robert Watson Subject: RE: Setting default hostname to localhost Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11-Jan-01 Robert Watson wrote: > not to (which there may be), I'd like to commit changes to -CURRENT's > /etc/default/rc.conf to change the default hostname to "localhost". If > the user configures a hostname, or DHCP provides one, it will be > overridden, of course, so should not impact any configuration but one > where the hostname is left undefined. > > Thoughts? Sounds like a nice idea. --- 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-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 21: 0:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 90B3237B401 for ; Wed, 10 Jan 2001 21:00:21 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA26798; Wed, 10 Jan 2001 23:59:57 -0500 (EST) Date: Wed, 10 Jan 2001 23:59:57 -0500 (EST) From: Daniel Eischen To: Peter Haight Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthread_attr_setschedparam, mozilla, and PTHREAD_MAX_PRIORITY In-Reply-To: <200101110441.f0B4fe008116@wartch.sapros.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Jan 2001, Peter Haight wrote: > I rebuilt mozilla after upgrading to 4.2 and was getting an assertion > because pthread_attr_setschedparam() was failing with a ENOTSUP. It turns > out Mozilla was trying to set the thread priority to 42 which is above the > new limit of 31 which changed a little before 4.2-RELEASE. > > To patch mozilla I had to do a '#if __FreeBSD_version >= 420000' because > PTHREAD_MAX_PRIORITY is in a private pthreads header file. I'm wondering if > it might not be a good idea to have that define show up somewhere public? > The only other thing I can think of is to call pthread_attr_setschedparam() > a couple of times to scope out the range of accepted values. As far as I read the POSIX spec, this is not exported. I'll have a look at it again when I get the chance. That said, POSIX only guarantees priorities in the range 0-31 (which is what we now allow). The exception is for SCHED_OTHER which can be implementation defined. Either way you look at it, it seems that a properly coded threaded application ought to rely on priorities in the range 0-31 (for non-SCHED_OTHER), or should scope them out at run-time. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 21:15:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by hub.freebsd.org (Postfix) with ESMTP id DB93937B400 for ; Wed, 10 Jan 2001 21:14:55 -0800 (PST) Received: (from chandras@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA18152 for hackers@freebsd.org; Thu, 11 Jan 2001 10:44:44 +0530 (IST) Date: Thu, 11 Jan 2001 10:44:44 +0530 From: S Chandrasekaran To: hackers@freebsd.org Subject: Reg: Adaptec AIC-7892 on board SCSI controller .. Message-ID: <20010111104444.A16089@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, I don't know if this is the appropriate forum, but nevertheless. I have a HP Kayak XU 800. This machine has a Adaptec AIC-7892 SCSI controller and a quantum hard disk (Atlas 10k). I tried to install FreeBSD 3.3 on this machine, but the hardware probe is unable to probe this card and I am unable to proceed (I have only one hard disk) I went through the FAQ and at the boot prompt, I typed 'boot -c', to go to config mode. then tried out the command 'eisa 12' and then exited, but of no use. This machine was running NT previously and is now running Red Hat linux 6.2. Both these OS's could recognise the SCSI controller. Given below is the output of linux 'dmesg' and 'lspci -v', if that would be of any use. I bought 3.3 CD's from Walnut Creek and use BSD at home, but that has a IDE disk. This is my first attempt at installing one with SCSI. Upgrading to 4.x is not an option. Many thanks in advance for all your help! -- regards, Chandra mailto: chandras@cisco.com ==================================================================== Linux dmesg ----------- Linux version 2.2.12-20 (root@chandras-pc) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Wed Jan 10 17:46:07 IST 2001 Detected 598119550 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 596.38 BogoMIPS Memory: 257224k/262144k available (1512k kernel code, 416k reserved, 2924k data, 68k init) DENTRY hash table entries: 262144 (order: 9, 2097152 bytes) Buffer-cache hash table entries: 262144 (order: 8, 1048576 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) VFS: Diskquotas version dquot_6.4.0 initialized CPU: Intel Pentium III (Coppermine) stepping 01 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch (rgooch@atnf.csiro.au) PCI: PCI BIOS revision 2.10 entry at 0xfdb91 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Enabling memory for device 03:00 Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 262144 bhash 65536) Initializing RT netlink socket Starting kswapd v 1.5 Detected PS/2 Mouse Port. Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 8250 pty: 256 Unix98 ptys configured apm: BIOS version 1.2 Flags 0x03 (Driver version 1.9) Real Time Clock Driver v1.09 Sound initialization started Sound initialization complete RAM disk driver initialized: 16 RAM disks of 4096K size loop: registered device at major 7 PCI_IDE: unknown IDE controller on PCI bus 00 device f9, VID=8086, DID=2411 PCI_IDE: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hdc: FX4820T, ATAPI CDROM drive ide1 at 0x170-0x177,0x376 on irq 15 hdc: ATAPI 48X CD-ROM drive, 128kB Cache Uniform CDROM driver Revision: 2.56 Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12 raid5: measuring checksumming speed raid5: MMX detected, trying high-speed MMX checksum routines pII_mmx : 1328.928 MB/sec p5_mmx : 1395.984 MB/sec 8regs : 1027.557 MB/sec 32regs : 584.073 MB/sec using fastest function: p5_mmx (1395.984 MB/sec) (scsi0) found at PCI 9/0 (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 374 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.20/3.2.4 scsi : 1 host. (scsi0:0:0:0) Synchronous at 160.0 Mbyte/sec, offset 31. Vendor: QUANTUM Model: ATLAS 10K 9WLS Rev: UCHK Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 scsi : detected 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB] PPP: version 2.3.7 (demand dialling) TCP compression code copyright 1989 Regents of the University of California PPP line discipline registered. Partition check: sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 > md.c: sizeof(mdp_super_t) = 4096 autodetecting RAID arrays autorun ... ... autorun DONE. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 68k freed Adding Swap: 530104k swap-space (priority -1) ======================================================================== linux 'lspci -v' ---------------- 00:00.0 Host bridge: Intel Corporation: Unknown device 1a21 (rev 01) Flags: bus master, fast devsel, latency 0 Memory at f8000000 (32-bit, prefetchable) Capabilities: 00:01.0 PCI bridge: Intel Corporation: Unknown device 1a23 (rev 01) Flags: bus master, 66Mhz, fast devsel, latency 64 Bus: primary=00, secondary=04, subordinate=04, sec-latency=64 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: fda00000-feafffff Prefetchable memory behind bridge: f3300000-f53fffff 00:02.0 PCI bridge: Intel Corporation: Unknown device 1a24 (rev 01) Flags: bus master, 66Mhz, fast devsel, latency 64 Bus: primary=00, secondary=02, subordinate=03, sec-latency=64 I/O behind bridge: 0000b000-0000cfff Memory behind bridge: fd800000-fd9fffff Prefetchable memory behind bridge: f3100000-f32fffff 00:1e.0 PCI bridge: Intel Corporation: Unknown device 2418 (rev 02) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 0000a000-0000afff Memory behind bridge: fd500000-fd7fffff Prefetchable memory behind bridge: f3000000-f30fffff 00:1f.0 ISA bridge: Intel Corporation: Unknown device 2410 (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation: Unknown device 2411 (rev 02) (prog-if 80) Subsystem: Unknown device 8086:2411 Flags: bus master, medium devsel, latency 0 I/O ports at ffa0 00:1f.2 USB Controller: Intel Corporation: Unknown device 2412 (rev 02) Subsystem: Unknown device 8086:2412 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at ef80 00:1f.3 Class 0c05: Intel Corporation: Unknown device 2413 (rev 02) Subsystem: Unknown device 8086:2413 Flags: medium devsel I/O ports at 0540 01:05.0 Multimedia audio controller: Cirrus Logic CS 4614 (rev 01) Subsystem: Unknown device 1013:4280 Flags: medium devsel, IRQ 5 Memory at fd7fe000 (32-bit, non-prefetchable) Memory at fd600000 (32-bit, non-prefetchable) Capabilities: 01:0b.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10) Subsystem: Unknown device 103c:9207 Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at a800 Memory at fd7ffc00 (32-bit, non-prefetchable) Expansion ROM at fd7e0000 02:1f.0 PCI bridge: Intel Corporation: Unknown device 1360 (rev 02) Flags: bus master, 66Mhz, fast devsel, latency 0 Bus: primary=02, secondary=03, subordinate=03, sec-latency=64 I/O behind bridge: 0000b000-0000bfff Memory behind bridge: fd800000-fd8fffff Prefetchable memory behind bridge: f3100000-f31fffff 03:00.0 PIC: Intel Corporation: Unknown device 1161 (rev 01) (prog-if 20) Subsystem: Unknown device 8086:1161 Flags: fast devsel Memory at fffff000 (32-bit, non-prefetchable) 03:09.0 SCSI storage controller: Adaptec 7892P (rev 02) Subsystem: Unknown device 103c:1241 Flags: bus master, 66Mhz, medium devsel, latency 44, IRQ 10 BIST result: 00 I/O ports at b800 Memory at fd8ff000 (64-bit, non-prefetchable) Capabilities: 04:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP [Millennium AGP] (rev 03) Subsystem: Unknown device 102b:ca6c Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at f4000000 (32-bit, prefetchable) Memory at feafc000 (32-bit, non-prefetchable) Memory at fe000000 (32-bit, non-prefetchable) Capabilities: ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 21:22:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 277BB37B402 for ; Wed, 10 Jan 2001 21:22:05 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0B5Lxs24826; Wed, 10 Jan 2001 22:21:59 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101110521.f0B5Lxs24826@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: S Chandrasekaran Cc: hackers@FreeBSD.ORG Subject: Re: Reg: Adaptec AIC-7892 on board SCSI controller .. In-Reply-To: Your message of "Thu, 11 Jan 2001 10:44:44 +0530." <20010111104444.A16089@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Jan 2001 22:21:59 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I bought 3.3 CD's from Walnut Creek and use BSD at home, but that >has a IDE disk. This is my first attempt at installing one with SCSI. >Upgrading to 4.x is not an option. FreeBSD 3.3 does not include support for the 7892. IIRC 3.4 and all releases after it, supports the 7892. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 21:30:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by hub.freebsd.org (Postfix) with ESMTP id D605437B400 for ; Wed, 10 Jan 2001 21:30:22 -0800 (PST) Received: (from chandras@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA19718; Thu, 11 Jan 2001 11:00:03 +0530 (IST) Date: Thu, 11 Jan 2001 11:00:03 +0530 From: S Chandrasekaran To: "Justin T. Gibbs" Cc: S Chandrasekaran , hackers@FreeBSD.ORG Subject: Re: Reg: Adaptec AIC-7892 on board SCSI controller .. Message-ID: <20010111110003.A19232@cisco.com> References: <20010111104444.A16089@cisco.com> <200101110521.f0B5Lxs24826@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101110521.f0B5Lxs24826@aslan.scsiguy.com>; from gibbs@scsiguy.com on Wed, Jan 10, 2001 at 10:21:59PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 10, 2001 at 10:21:59PM -0700, Justin T. Gibbs wrote: > > I bought 3.3 CD's from Walnut Creek and use BSD at home, but that > >has a IDE disk. This is my first attempt at installing one with SCSI. > >Upgrading to 4.x is not an option. > > FreeBSD 3.3 does not include support for the 7892. > IIRC 3.4 and all releases after it, supports the 7892. > > -- > Justin Justin, Thanks for your prompt response, but I did see the 3.3 release notes, before attempting the install. It does say that "Adaptec AIC7850, AIC7860, AIC7880, AIC789x, on-board SCSI controllers." are supported. Btw, the release notes for 3.4 also says the same. Can anyone throw more light on this ? Thanks for your time. Chandra To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 22:34:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 6EB8A37B401 for ; Wed, 10 Jan 2001 22:34:18 -0800 (PST) Received: (qmail 17299 invoked by uid 1001); 11 Jan 2001 16:33:57 +1000 X-Posted-By: GJB-Post 2.08 05-Jan-2001 (FreeBSD) X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Thu, 11 Jan 2001 16:33:57 +1000 From: Greg Black To: Gerhard Sittig Cc: Doug Barton , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010110233907.L253@speedy.gsinet> In-reply-to: <20010110233907.L253@speedy.gsinet> of Wed, 10 Jan 2001 23:39:07 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gerhard Sittig wrote: > I take notice of your (and Greg Black's) reservation / being > opposed, respect it and conclude that the change will have to > - default to the current behaviour (something quite usual for > expanding changes) We'd need some guarantees that the attempt to maintain current behaviour was done correctly -- i.e., without introducing bugs that broke things. > - be well documented (something absolutely clear to all of us, > strictly speaking it's way out of imagination for us how > somebody could contribute undocumented stuff ... :) One of the things that would need to be documented is what will happen to the new algorithm in the situation where cron is stopped and re-started during one of the time periods that gets repeated. > - yet be enabled easily for those interested in the change to > work for them and free up some of their resources for more > important tasks > - maybe provide knobs (besides the on-off-switch) to customize > behaviour in a more fine grained way In the beginning, something like CRON_DST_HACK="NO" in rc.conf with a comment pointing to the explanation should cover both these items. If more is needed later, then it can be added. > BTW: There's good news for those with a dislike regarding the > change: While testing I'm stuck again, so there will be some > more delay. Previously we were told that this stuff had already been tested for years under another OS and was therefore robust and reliable. Now we learn that these claims are not correct. And you wonder why people are reluctant to even consider these changes ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 22:48:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 5E8A237B402 for ; Wed, 10 Jan 2001 22:48:07 -0800 (PST) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id TAA32661; Thu, 11 Jan 2001 19:47:25 +1300 (NZDT) Message-Id: <200101110647.TAA32661@ducky.nz.freebsd.org> From: "Dan Langille" Organization: The FreeBSD Diary / FreshPorts To: Greg Black Date: Thu, 11 Jan 2001 19:47:21 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Reply-To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: References: <20010110233907.L253@speedy.gsinet> of Wed, 10 Jan 2001 23:39:07 +0100 X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11 Jan 2001, at 16:33, Greg Black wrote: > We'd need some guarantees that the attempt to maintain current > behaviour was done correctly -- i.e., without introducing bugs > that broke things. What sort of guarantees are acceptable? > In the beginning, something like CRON_DST_HACK="NO" in rc.conf > with a comment pointing to the explanation should cover both > these items. If more is needed later, then it can be added. Do you mean /etc/defaults/rc.conf? -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 23: 7:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 5E6DA37B401 for ; Wed, 10 Jan 2001 23:06:50 -0800 (PST) Received: (qmail 17577 invoked by uid 1001); 11 Jan 2001 17:06:14 +1000 X-Posted-By: GJB-Post 2.08 05-Jan-2001 (FreeBSD) X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Thu, 11 Jan 2001 17:06:14 +1000 From: Greg Black To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <20010110233907.L253@speedy.gsinet> of Wed, 10 Jan 2001 23:39:07 +0100 <200101110647.TAA32661@ducky.nz.freebsd.org> In-reply-to: <200101110647.TAA32661@ducky.nz.freebsd.org> of Thu, 11 Jan 2001 19:47:21 +1300 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Dan Langille" wrote: > On 11 Jan 2001, at 16:33, Greg Black wrote: > > > We'd need some guarantees that the attempt to maintain current > > behaviour was done correctly -- i.e., without introducing bugs > > that broke things. > > What sort of guarantees are acceptable? It would need to be tested against a set of "suitable" test crontab files across both ends of DST transitions using real timezone files -- either by running it for several months in -current or by dedicating a test machine that was rebooted several times for date changes a few days before and after the DST transitions. Faking timezone files leads to suspicions about bugs in them. Changing the date on a running system without rebooting leads to uncertainty about side-effects of large date changes. If I was doing this, I'd be looking for input with test data for the crontab files and I'd be looking hard (in advance) at the kinds of outcomes that would serve to validate the behaviour. Having once written and then maintained a cron implementation (more than 10 years ago), I do know that covering all bases is non-trivial. And, as I said previously, I'd want to know how the new code coped with cron being stopped and restarted during one of the DST transition times, as well as seeing assurances that the legacy version would do the same thing then as it does now. > > In the beginning, something like CRON_DST_HACK="NO" in rc.conf > > with a comment pointing to the explanation should cover both > > these items. If more is needed later, then it can be added. > > Do you mean /etc/defaults/rc.conf? One of the ways we break the POLA is the habit of changing the names and locations of those files. But yes -- if that's still its name when/if this thing happens. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 10 23:24:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 8ABDE37B400 for ; Wed, 10 Jan 2001 23:24:37 -0800 (PST) Received: from FreeBSD.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id XAA01696 for ; Wed, 10 Jan 2001 23:24:36 -0800 (PST) (envelope-from DougB@FreeBSD.org) Message-ID: <3A5D5FB3.D6412F4D@FreeBSD.org> Date: Wed, 10 Jan 2001 23:24:35 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@FreeBSD.org Subject: Re: KVM switch vs. FreeBSD psm driver (Solved!) References: <200101062359.f06NxIv11832@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > > In article , > John Polstra wrote: > > > > I've got a Belkin OmniView Pro 8-Port KVM switch which thinks it's > > much smarter than it really is. When I try to use the mouse through > > it with FreeBSD (-current from around Christmas, but I also had > > problems with -stable) it doesn't work right at all. It's got the > > same symptoms everybody else has reported: the cursor jumps around, > > and lots of "psmintr: out of sync" messages get logged. > > I'm happy to report that this problem is solved now. After one fellow > wrote to me and reported that his switch of the same model worked OK, > I hunted around on the Belkin web site. It turns out that Belkin > assembled a few thousand of the units with two EPROMs swapped This is an all time classic! -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 0:47:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id 126EA37B404 for ; Thu, 11 Jan 2001 00:47:08 -0800 (PST) Received: (qmail 1565 invoked by uid 1003); 11 Jan 2001 08:47:05 -0000 Date: Thu, 11 Jan 2001 10:47:05 +0200 From: Neil Blakey-Milner To: Doug Barton Cc: Greg Black , Dan Langille , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010111104705.A74850@mithrandr.moria.org> References: <20010110151211.A37285@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from DougB@gorean.org on Wed, Jan 10, 2001 at 12:52:29PM -0800 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2001-01-10 (12:52), Doug Barton wrote: > > To summarise: It is broken, > > According to your definition of broken, which we have not > necessarily reached a consensus on. I agree - there is no consensus, and there never will be. Some people want cron to be reliable, and not skip jobs or run jobs multiple times, and other people want cron to be reliable, and to skip jobs and run jobs multiple times. I believe the reliable behaviour is to never skip jobs. People schedule fixed-time jobs (the _only_ type affected by this change) with the intention that they will be run. I also believe people schedule fixed-time jobs (tagain, the only type affected by this change), with the anticipation that it will be run only once. Time doesn't really go backwards or forwards merely due to timezone changes or corrective time changing. Wildcard jobs are not affected by this change. Your hourly jobs will run every hour still. _Every_ hour. If there are two two-o'clocks in a row, it will be run twice, because in reality, there has been an hour passing. Every five minutes will run every five minutes, even if you correct the time backwards 18 minutes - it'll run at 10:30, 10:15, 10:20, 10:25, and 10:30 again (just like the current cron behaviour). One side says POLA means never changing a programs, and others say POLA means that a program shouldn't act in an astonishing way. They both have merit. > > Not only that, but people who don't understand that it is broken are > > unable to understand simple facts. > > Or perhaps we understand the simple facts, but there are more > complex facts that make this change a bad idea. Note, I was quoting a detractor, not saying this myself to anyone. I don't attack people when I don't agree with their argument. > > In addition, it took the FreeBSD > > project about 7 years to finally get their daily runs to run exactly > > once, once every day. > > This is overstating the case. It was never really considered a > huge issue by most, and at various times in the past the "correct" change > for the majority of our userbase got mired down in socio-political > arguments that had nothing to do with the technical merits. Of course it's hyperbole - what I'm saying is that every 6 months people get confused (and astonished) that jobs get skipped or doubled, and still nobody could agree on a simple way to fix this. My personal concern isn't DST changes (since I'm not influenced by them), but other corrective time measures that cron really should act reliably around. > > What we haven't seen is any technical opposition to the algorithm used, > > which has been explained. > > What you are seeing is opposition to the idea itself. I'm not > going to waste time analyzing the implementation of what I think is a bad > idea. :) The opposition I've summarised already: "People who don't know that cron is not reliable are unable to understand basic facts" (rough paraphrase). The arguments have often been against the idea in it's entirety, saying that this behaviour should never occur, even as an option, since it's a stupid idea. That is policy, and should be ignored - we don't enforce policy on our users. The only argument people can have is against the implementation of the change, and whether it should be default or an option. The implementation is good, unless someone cares to review it. I think it should be default, as the only people who will be inconvenienced by the new behaviour will be people who already consider cron to not be reliable around time changes. If they rely on it being unreliable, they can always use an option supplied to get the old behaviour, since they already spend a lot of time thinking of how to avoid the problems inherent in the old behaviour, and remembering a command line option (or looking it up in the man page) shouldn't be an issue for them. Yes, this is a POLA issue - it is astonishing to people that cron behaves this way, when they first see it. It will be "astonishing" to very fewer people if the default changes to the new behaviour, and we accomodate these people by placing it in the release notes, having an option for the old behaviour, and possibly delaying the use of the new system in the -STABLE branch until 5.0, if that is deemed necessary. Now, if anyone has a reasoned argument about the new algorithm (like, how it handles certain kinds of events in a surprising way), I'd like to hear it, or we can proceed to make it an option. If anyone has some clear cases why this is a truly astonishing change for people that can't adequately be handled in the accomodations listed above, we can hear your concerns too. If there is no clear winner, we can have it as just an option. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 1: 3: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id B80D237B401 for ; Thu, 11 Jan 2001 01:02:32 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 14Gdd1-0001NU-00 for freebsd-hackers@freebsd.org; Thu, 11 Jan 2001 11:02:39 +0200 Date: Thu, 11 Jan 2001 11:02:39 +0200 (IST) From: Roman Shterenzon To: Subject: Reverse Engineering Mwave? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, There's a Mwave linux driver on the IBM website: http://oss.software.ibm.com/developerworks/opensource/linux/projects/mwave/ I looked at it, and seems that some work is done in userspace (binaries, libraries, wav-files), and the driver itself is rather small. I wonder if it's possible (and how hard it is) to reverse engineer the kernel module and user linuxulator for all the rest? --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 1: 5:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 14F5E37B404 for ; Thu, 11 Jan 2001 01:05:42 -0800 (PST) Received: from FreeBSD.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id BAA02204; Thu, 11 Jan 2001 01:05:39 -0800 (PST) (envelope-from DougB@FreeBSD.org) Message-ID: <3A5D7762.DC8DE5D@FreeBSD.org> Date: Thu, 11 Jan 2001 01:05:38 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Gerhard Sittig Cc: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010110233907.L253@speedy.gsinet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gerhard Sittig wrote: > > On Tue, Jan 09, 2001 at 02:14 -0800, Doug Barton wrote: > > Gerhard Sittig wrote: > > > > > > It's not that I want to talk you into something you don't > > > want. > > > > But that's exactly what you're trying to do. > > Honestly -- no! :) Alright, I give up. Your post just before this one shows me that you are unwilling, or unable to accept the reality of the situation you're discussing, or even the proper definitions of the terms involved, so my efforts here are futile. > I take notice of your (and Greg Black's) reservation / being > opposed, respect it and conclude that the change will have to > - default to the current behaviour (something quite usual for > expanding changes) > - be well documented (something absolutely clear to all of us, > strictly speaking it's way out of imagination for us how > somebody could contribute undocumented stuff ... :) > - yet be enabled easily for those interested in the change to > work for them and free up some of their resources for more > important tasks > - maybe provide knobs (besides the on-off-switch) to customize > behaviour in a more fine grained way I'd say these are the minimal acceptable design parameters for the project. The options you describe need to be command line options, not environment variables as someone else described. > Looking at the echo returning so far Which represents a very small percentage of the people who need to look at the change. A significant percentage (probably a majority) of the people who are freebsd developers abandoned -hackers long ago. When you have a working set of patches you should post a message to -arch with details and download instructions. > BTW: There's good news for those with a dislike regarding the > change: You and your associates keep trying to cast this in personal terms. It is not that I dislike your idea. I think your idea is dangerous, and wrong for the project. There is a big difference. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 2: 9:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id C644237B400 for ; Thu, 11 Jan 2001 02:09:35 -0800 (PST) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id XAA33155; Thu, 11 Jan 2001 23:08:46 +1300 (NZDT) Message-Id: <200101111008.XAA33155@ducky.nz.freebsd.org> From: "Dan Langille" Organization: The FreeBSD Diary / FreshPorts To: Greg Black Date: Thu, 11 Jan 2001 23:08:45 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Reply-To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: References: <200101110647.TAA32661@ducky.nz.freebsd.org> of Thu, 11 Jan 2001 19:47:21 +1300 X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11 Jan 2001, at 17:06, Greg Black wrote: > And, as I said previously, I'd want to know how the new code > coped with cron being stopped and restarted during one of the > DST transition times, as well as seeing assurances that the > legacy version would do the same thing then as it does now. If the changes are modular, and I sure hope they are, it would almost be a matter of: if newcode then call new stutt end if But I'm guessing it's going to be a *bit* more complicated than that. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 2:26:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcs113.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 1A5B937B400 for ; Thu, 11 Jan 2001 02:26:06 -0800 (PST) Received: from localhost (pmk@localhost) by pcs113.sasi.com (8.9.3/8.9.3) with ESMTP id PAA01350 for ; Thu, 11 Jan 2001 15:55:56 +0530 X-Authentication-Warning: pcs113.sasi.com: pmk owned process doing -bs Date: Thu, 11 Jan 2001 15:55:56 +0530 (IST) From: Mohana Krishna Penumetcha To: freebsd-hackers@FreeBSD.ORG Subject: kernel debugging!!! In-Reply-To: <39C1BC04.4A534A80@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG we are testing our driver for 4.0 freeBSD. kernel is panicing in the attach routine with the message "double fault". the longest sequence of function calls from the attach routine use 180 bytes of kernel stack(this includes only the local variable), i read in the mailing lists that kernel stack size is 256 bytes. is there a way i can know what is my current kernel stack usage? we enabled the DDB by selecting the DDB option in the configuration file. After kernel panics control doesn't always go to DDB, did i miss anything while enabling DDB? when control goes to DDB, it is printing eip, esp, ebp register values along with some other information. but when i use trace command, it is listing the trace from trap only. i think when kernel double faults, original stack trace won't be available. can i know where is the problem from the above three register values? -- mohan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 2:40: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C612837B400 for ; Thu, 11 Jan 2001 02:39:45 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0BAdS309075; Thu, 11 Jan 2001 02:39:28 -0800 (PST) Date: Thu, 11 Jan 2001 02:39:28 -0800 From: Alfred Perlstein To: Mohana Krishna Penumetcha Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kernel debugging!!! Message-ID: <20010111023928.X7240@fw.wintelcom.net> References: <39C1BC04.4A534A80@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pmk@sasi.com on Thu, Jan 11, 2001 at 03:55:56PM +0530 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mohana Krishna Penumetcha [010111 02:26] wrote: > > > we are testing our driver for 4.0 freeBSD. kernel is panicing in the > attach routine with the message "double fault". the longest sequence of > function calls from the attach routine use 180 bytes of kernel stack(this > includes only the local variable), i read in the mailing lists that kernel > stack size is 256 bytes. is there a way i can know what is my current > kernel stack usage? Afaik, on i386 you have ~4k of kernel stack, however you have to realize that driver entry can come from an interrupt generated when the stack is already nearly exhausted. I'm not really that much of a driver programmer, but I've heard of people facing this problem before, solutions varied, but since each driver instance is single threaded you can pre-allocate via malloc (i think) the space you need and attach it to the per-driver data structure (softc afaik). > we enabled the DDB by selecting the DDB option in the configuration file. > After kernel panics control doesn't always go to DDB, did i miss anything > while enabling DDB? Probably not. > when control goes to DDB, it is printing eip, esp, ebp register values > along with some other information. but when i use trace command, it is > listing the trace from trap only. i think when kernel double faults, > original stack trace won't be available. can i know where is the problem > from the above three register values? My first solution would be to rip out your current "attach" code and make sure you're actually getting into it by replacing the routine with a simple 'printf("hello world")' before worrying about kernel stacks and whatnot. If even that does work, then try to take a simple driver from the kernel source (or there may be examples in /usr/share/examples) and try to get it to link properly. Basically, take small steps first, and tread lightly, I don't write drivers, just chat with a bunch of people that do. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 3: 9: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcs113.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 2760137B400 for ; Thu, 11 Jan 2001 03:08:40 -0800 (PST) Received: from localhost (pmk@localhost) by pcs113.sasi.com (8.9.3/8.9.3) with ESMTP id QAA01407; Thu, 11 Jan 2001 16:38:06 +0530 X-Authentication-Warning: pcs113.sasi.com: pmk owned process doing -bs Date: Thu, 11 Jan 2001 16:38:06 +0530 (IST) From: Mohana Krishna Penumetcha To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kernel debugging!!! In-Reply-To: <20010111023928.X7240@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Afaik, on i386 you have ~4k of kernel stack, however you have to > realize that driver entry can come from an interrupt generated when > the stack is already nearly exhausted. I'm not really that much > of a driver programmer, but I've heard of people facing this problem > before, solutions varied, but since each driver instance is single > threaded you can pre-allocate via malloc (i think) the space you > need and attach it to the per-driver data structure (softc afaik). i am confused between the kernel stack in kernel space (where ISRs are called) and kernel stack each process has. the UPAGES constant defines the size of process kernel stack. does it define kernel stack in kernel space also?? (fig 3.1, page 51, BSD book) BTW, memory for softc is allocated from the heap in newbus architecture. -- mohan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 3:11:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7A43F37B401 for ; Thu, 11 Jan 2001 03:10:59 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0BBAnZ09827; Thu, 11 Jan 2001 03:10:49 -0800 (PST) Date: Thu, 11 Jan 2001 03:10:49 -0800 From: Alfred Perlstein To: Mohana Krishna Penumetcha Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kernel debugging!!! Message-ID: <20010111031049.Y7240@fw.wintelcom.net> References: <20010111023928.X7240@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pmk@sasi.com on Thu, Jan 11, 2001 at 04:38:06PM +0530 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mohana Krishna Penumetcha [010111 03:08] wrote: > > > > Afaik, on i386 you have ~4k of kernel stack, however you have to > > realize that driver entry can come from an interrupt generated when > > the stack is already nearly exhausted. I'm not really that much > > of a driver programmer, but I've heard of people facing this problem > > before, solutions varied, but since each driver instance is single > > threaded you can pre-allocate via malloc (i think) the space you > > need and attach it to the per-driver data structure (softc afaik). > > i am confused between the kernel stack in kernel space (where ISRs > are called) and kernel stack each process has. the UPAGES constant > defines the size of process kernel stack. does it define kernel stack in > kernel space also?? (fig 3.1, page 51, BSD book) > > BTW, memory for softc is allocated from the heap in newbus > architecture. I'm pretty sure interrupts are piggybacked on the user-kernel-stack. How about trying the simple printf idea and letting us know if that works? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 3:11:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 1C74237B402 for ; Thu, 11 Jan 2001 03:11:11 -0800 (PST) Received: from morgan.alcove-int ([10.16.1.2] ident=mail) by smtp.alcove.fr with esmtp (Exim 3.12 #1 (Debian)) id 14GfdL-0002Hf-00; Thu, 11 Jan 2001 12:11:07 +0100 Received: from nsouch by morgan.alcove-int with local (Exim 3.12 #1 (Debian)) id 14GfdK-0007eA-00; Thu, 11 Jan 2001 12:11:06 +0100 Date: Thu, 11 Jan 2001 12:11:05 +0100 From: Nicolas Souchu To: Volker Stolz Cc: freebsd-hackers@freebsd.org Subject: Re: Questions on i2c Message-ID: <20010111121105.B29170@morgan.alcove-int> References: <20010104101041.A7651@agamemnon.informatik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <20010104101041.A7651@agamemnon.informatik.rwth-aachen.de>; from stolz@I2.Informatik.RWTH-Aachen.DE on Thu, Jan 04, 2001 at 10:10:41AM +0100 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 04, 2001 at 10:10:41AM +0100, Volker Stolz wrote: > Hi, is someone working actively on new i2c-stuff? > I´d be interested in talking to someone who could take a short peek at > http://www2.lm-sensors.nu/~lm78/info.html, a Linux-site providing > i2c-drivers to various things, and could comment on the feasibility of > using their stuff to implement FreeBSD-drivers. What do you want? ISA support for the lm78? Or true I2C / SMBus? You'd like to see the FreeBSD stuff compatible with Linux API? Port Linux code (which is GPL :(? > > Devices include video-devices like TV-Out on the Voodoo3 which could > seemingly be enabled using i2c. > > FreeBSD´s bktr-driver seems too big for me to get me started on trying > to attach only a driver which would look for the Voodoo. > > Is there any further documentation on what I can do with /dev/iic*? Have you looked at http://www.freebsd.org/~nsouch? Have you looked at the lmmon port? Any suggestion is welcome! Nicholas -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 3:43:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id B301F37B400 for ; Thu, 11 Jan 2001 03:43:09 -0800 (PST) Received: (qmail 96835 invoked by uid 1003); 11 Jan 2001 11:43:06 -0000 Date: Thu, 11 Jan 2001 13:43:06 +0200 From: Neil Blakey-Milner To: Greg Black Cc: dan@langille.org, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010111134306.A78413@mithrandr.moria.org> References: <20010110233907.L253@speedy.gsinet> <200101110647.TAA32661@ducky.nz.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gjb@gbch.net on Thu, Jan 11, 2001 at 05:06:14PM +1000 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > And, as I said previously, I'd want to know how the new code > coped with cron being stopped and restarted during one of the > DST transition times, as well as seeing assurances that the > legacy version would do the same thing then as it does now. The legacy version only checks for jobs that fire in the exact current minute. If it was stopped, it wouldn't run jobs for the missed time. The new behaviour is to run the fixed-time jobs that are between the last known time, and the current time, if the stop time is less than 3 hours (if it is more, assume that the change is not a standard DST thing or normal corrective time change). If the time change is less than 5 minutes, then cron should try run all jobs for each minute that passed between the last known time and the current time. If over 5 minutes, then cron will check for all wildcard jobs that would have fired, and run it only once, even if it would have run multiple times). If time goes backwards, fixed-time jobs are assumed to have already run, and if we happen to match a wildcard job for the current minute, run it. If there is a fixed job at 2:40, and we pass 2:40, run the job, and then at 3, time goes backwards, don't run it. If cron gets killed at 2:50, and started at 2:55, and time goes backwards to 2:00, the 2:40 job isn't run either, since the virtual time is still at 3:00. If cron is running at 2:40, the job is run, cron is killed, and restarted just after the change back to 2:00, it will run the 2:40 job, as it wasn't around to experience the DST change. Similarly, if cron isn't around to experience a forward jump, it won't magically know to run the jobs missed. All of which makes me ponder putting cron_tz option in rc.conf and suggesting people set it to UTC or some other non-DST-afflicted place, but that isn't the only use of these changes. However, the new behaviour does do the expected things for common changes - if it's a relatively small forward jump, run whatever jobs would have run. If it's a medium-sized jump, run all the fixed-time jobs, and one of each wildcard job that would have occured. If it's a massive jump, assume something unusual is up, and don't run any jobs. If it's a small backwards jump, assume fixed-time jobs shouldn't be run again until we reach the time we jumped back. And if it's a big backwards jump, assume something unusual is up, and just start functioning as if the time hadn't changed. The previous behaviour says not to care what changes occur in time whatsoever, and only compare this exact current minute of the waking up to the crontab list, and run those jobs. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 3:46: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcs113.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id B142E37B400 for ; Thu, 11 Jan 2001 03:45:46 -0800 (PST) Received: from localhost (pmk@localhost) by pcs113.sasi.com (8.9.3/8.9.3) with ESMTP id RAA01423; Thu, 11 Jan 2001 17:15:26 +0530 X-Authentication-Warning: pcs113.sasi.com: pmk owned process doing -bs Date: Thu, 11 Jan 2001 17:15:26 +0530 (IST) From: Mohana Krishna Penumetcha To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kernel debugging!!! In-Reply-To: <20010111031049.Y7240@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Mohana Krishna Penumetcha [010111 03:08] wrote: > > > > > > > Afaik, on i386 you have ~4k of kernel stack, however you have to > > > realize that driver entry can come from an interrupt generated when > > > the stack is already nearly exhausted. I'm not really that much > > > of a driver programmer, but I've heard of people facing this problem > > > before, solutions varied, but since each driver instance is single > > > threaded you can pre-allocate via malloc (i think) the space you > > > need and attach it to the per-driver data structure (softc afaik). > > > > i am confused between the kernel stack in kernel space (where ISRs > > are called) and kernel stack each process has. the UPAGES constant > > defines the size of process kernel stack. does it define kernel stack in > > kernel space also?? (fig 3.1, page 51, BSD book) > > > > BTW, memory for softc is allocated from the heap in newbus > > architecture. > > I'm pretty sure interrupts are piggybacked on the user-kernel-stack. > this is o.k. when the system is up and running. but what about boot-up time when there is no process, is there any stack meant for this? > How about trying the simple printf idea and letting us know if that > works? panic is coming in the middle of the routine. i am printing many messages before the panic. -- mohan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 5: 5:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gallions-reach.inpharmatica.co.uk (gallions-reach.inpharmatica.co.uk [193.115.214.5]) by hub.freebsd.org (Postfix) with ESMTP id 0344237B400 for ; Thu, 11 Jan 2001 05:05:17 -0800 (PST) Received: from mailhost.inpharmatica.co.uk (euston.inpharmatica.co.uk [193.115.214.6]) by gallions-reach.inpharmatica.co.uk (8.9.3/8.9.3) with ESMTP id NAA72797; Thu, 11 Jan 2001 13:03:30 GMT (envelope-from m.seaman@inpharmatica.co.uk) Received: from w-hampstead.inpharmatica.co.uk (root@w-hampstead.inpharmatica.co.uk [192.168.122.87]) by mailhost.inpharmatica.co.uk (8.11.1/8.11.1) with ESMTP id f0BD3Ur48177; Thu, 11 Jan 2001 13:03:30 GMT (envelope-from m.seaman@inpharmatica.co.uk) Received: from inpharmatica.co.uk (matthew@localhost [127.0.0.1]) by w-hampstead.inpharmatica.co.uk (8.9.3/8.9.3) with ESMTP id NAA25333; Thu, 11 Jan 2001 13:03:29 GMT X-Authentication-Warning: w-hampstead.inpharmatica.co.uk: Host matthew@localhost [127.0.0.1] claimed to be inpharmatica.co.uk Message-ID: <3A5DAF21.68DCD58D@inpharmatica.co.uk> Date: Thu, 11 Jan 2001 13:03:29 +0000 From: Matthew Seaman X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-desktop i586) X-Accept-Language: en-GB, en MIME-Version: 1.0 To: dan@langille.org Cc: Greg Black , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <20010110233907.L253@speedy.gsinet> of Wed, 10 Jan 2001 23:39:07 +0100 <200101110647.TAA32661@ducky.nz.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Langille wrote: > > On 11 Jan 2001, at 16:33, Greg Black wrote: > > > We'd need some guarantees that the attempt to maintain current > > behaviour was done correctly -- i.e., without introducing bugs > > that broke things. > > What sort of guarantees are acceptable? > > > In the beginning, something like CRON_DST_HACK="NO" in rc.conf > > with a comment pointing to the explanation should cover both > > these items. If more is needed later, then it can be added. > > Do you mean /etc/defaults/rc.conf? > Howabout having a setting: TZ=GMT0BST or TZ=Europe/London in the crontab file, analogous to the MAILTO= or USER= settings that already exist. That would mean individual user crontabs could run on different timezones --- or would that just be too complicated? I suppose the default (with no TZ= setting) should be to work just as cron does now, using the system standard timezone, without DST hacks, or you could choose a timezone setting without DST changes: TZ=UTC and probably TZ=localtime to use the system default time zone, with DST hacks. Matthew PS. If anyone is counting, put me down as one who thinks the DST hack is a good idea. -- Certe, Toto, sentio nos in Kansate non iam adesse. Dr. Matthew Seaman, Inpharmatica Ltd, 60 Charlotte St, London, W1T 2NU Tel: +44 20 7631 4644 x229 Fax: +44 20 7631 4844 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 5:25:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bartu.bos.a2e.de (bitmu.openecs.org [62.154.243.66]) by hub.freebsd.org (Postfix) with ESMTP id A94A537B402 for ; Thu, 11 Jan 2001 05:25:29 -0800 (PST) Received: from aliuC2.oas.a2e.de (aliuC2.oas.a2e.de [10.0.0.117]) by bartu.bos.a2e.de (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id OAA19593; Thu, 11 Jan 2001 14:17:45 +0100 Received: by aliuC2.oas.a2e.de via sendmail with stdio id for freebsd-hackers@FreeBSD.ORG; Thu, 11 Jan 2001 15:25:29 +0100 (CET) (Smail-3.2 1996-Jul-4 #1 built 2000-Jul-29) Message-Id: Date: Thu, 11 Jan 2001 15:25:29 +0100 (CET) From: PILCH Hartmut To: "Julian Stacey Jhs@jhs.muc.de" Cc: Peter Mutsaers , freebsd-hackers@FreeBSD.ORG Subject: Re: Software Patents References: <200012220120.eBM1KVp10419@jhs.muc.de> Gcc: nnml+archive:archive Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Do we have any chance of putting a statement from a BSD organisation on http://petition.eurolinux.org/statements and a logo on http://petition.eurolinux.org/sponsors ? Maybe Julian could draft that statement and have someone sign it in the name of the FreeBSD project? -phm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 6:37: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id D58BA37B400 for ; Thu, 11 Jan 2001 06:36:45 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0BEags28411; Thu, 11 Jan 2001 07:36:43 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101111436.f0BEags28411@aslan.scsiguy.com> To: S Chandrasekaran Cc: hackers@FreeBSD.ORG Subject: Re: Reg: Adaptec AIC-7892 on board SCSI controller .. In-Reply-To: Your message of "Thu, 11 Jan 2001 11:00:03 +0530." <20010111110003.A19232@cisco.com> Date: Thu, 11 Jan 2001 07:36:42 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Justin, > > Thanks for your prompt response, but I did see the 3.3 release >notes, before attempting the install. It does say that >"Adaptec AIC7850, AIC7860, AIC7880, AIC789x, on-board SCSI controllers." >are supported. Btw, the release notes for 3.4 also says the same. > > Can anyone throw more light on this ? > > Thanks for your time. When those release notes were written, only the aic7895 existed in the aic789X range. That chip is supported by 3.3. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 7:12:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 10FC937B400 for ; Thu, 11 Jan 2001 07:12:13 -0800 (PST) Received: from jade (jade.cs.binghamton.edu [128.226.140.161]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f0BFCCp02663 for ; Thu, 11 Jan 2001 10:12:12 -0500 (EST) Date: Thu, 11 Jan 2001 10:10:16 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@jade To: freebsd-hackers@freebsd.org Subject: Process virtual memory question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Although the 4.4 BSD design and implementation book says the text part of a process starts from 0x0000,0000, it actually starts from some place around 0x800,0000 (or 0x8048000 to be exact). What's in the area between 0 - 0x800,0000? Why do we not use it if it is left empty as shown by /proc/pid/map? How is the magic number 0x8048000 determined? Thanks. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 7:55:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 41FCB37B401 for ; Thu, 11 Jan 2001 07:55:11 -0800 (PST) Received: from luanda-56.budapest.interware.hu ([195.70.51.56] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14Gk4C-0005vA-00; Thu, 11 Jan 2001 16:55:09 +0100 Message-ID: <3A5DCFE0.D52CD8E6@elischer.org> Date: Thu, 11 Jan 2001 07:23:12 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Mohana Krishna Penumetcha Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: kernel debugging!!! References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mohana Krishna Penumetcha wrote: > > > * Mohana Krishna Penumetcha [010111 03:08] wrote: > > > > > > > > > > Afaik, on i386 you have ~4k of kernel stack, however you have to > > > > realize that driver entry can come from an interrupt generated when > > > > the stack is already nearly exhausted. I'm not really that much > > > > of a driver programmer, but I've heard of people facing this problem > > > > before, solutions varied, but since each driver instance is single > > > > threaded you can pre-allocate via malloc (i think) the space you > > > > need and attach it to the per-driver data structure (softc afaik). > > > > > > i am confused between the kernel stack in kernel space (where ISRs > > > are called) and kernel stack each process has. the UPAGES constant > > > defines the size of process kernel stack. does it define kernel stack in > > > kernel space also?? (fig 3.1, page 51, BSD book) > > > > > > BTW, memory for softc is allocated from the heap in newbus > > > architecture. > > > > I'm pretty sure interrupts are piggybacked on the user-kernel-stack. > > > > this is o.k. when the system is up and running. but what about > boot-up time when there is no process, is there any stack meant for > this? There is always a stack for you..(there is an idle stack for just this case). The example driver in -current (not the one in 4.x) might be if interest to you. http://www.freebsd.org/cgi/cvsweb.cgi/src/share/examples/drivers/make_device_driver.sh (beware that that may have been wrapped by my mailer on tranmit.) > > > How about trying the simple printf idea and letting us know if > that > works? > > panic is coming in the middle of the routine. i am printing many > messages before the panic. > > -- > mohan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 8:55:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 91FA137B401 for ; Thu, 11 Jan 2001 08:55:39 -0800 (PST) Received: by smtp.nettoll.com; Thu, 11 Jan 2001 17:54:39 +0100 (MET) Message-ID: <3A5DE59F.6060602@enition.com> Date: Thu, 11 Jan 2001 17:55:59 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Need help for kernel crash dump analysis References: <20010111163903.E6FF737B400@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everybody, I am currently working with FreeBSD 4.1 on i386 platform on a pseudo-device driver that interacts with the networking subsystem in the kernel. Basically, we are intercepting both incoming and outgoing IP-level trafficfor specific processing. Obviously, there is also some administrative processingthat is conducted from a user-land daemon. I have detected a problem with my driver occuring in the context of the network SWI, as shown by the following basic stack: #14 in ... /* private code */ #15 in ip_input #16 in ipintr My problem comes from that I would like to get the stack frame of the interrupted execution process (everything that would be frame #17 and below) and I do not know how to do this with the GDB debugger. Is there anybody how could provide me with the steps to achieve this ? Regards, X. Galleri To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 9:11:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id 58CF537B404 for ; Thu, 11 Jan 2001 09:11:19 -0800 (PST) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14GlFu-00066c-00 for freebsd-hackers@freebsd.org; Thu, 11 Jan 2001 17:11:18 +0000 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.11.1/8.11.1) id f0BHBHr00430 for freebsd-hackers@freebsd.org; Thu, 11 Jan 2001 17:11:17 GMT (envelope-from jcm) Date: Thu, 11 Jan 2001 17:11:17 +0000 From: j mckitrick To: freebsd-hackers@freebsd.org Subject: scsi and PS2 mode parallel port programming Message-ID: <20010111171117.A323@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greets to everyone, I'm new to hackers, but I'm trying to tackle a couple of bugs in the parallel port zip driver under newbus/4.x. I was able to fix the big one (nibble mode didn't work at all) so now I am trying to get PS2 mode working, which is much faster on reads. I have 2 questions: 1. Is anyone familiar with PS2 transfer protocols with a parallel port set in ECP mode? It could always be a buggy BIOS, but I cannot get PS2 mode to work on my laptop with pport set to ECP mode. But it works in standard bi-directional mode. 2. In the list of scsi error codes, 0x00 is no error, and the defacto errors start with 0x02. However, in PS2 mode, when asked for status, the zip drive returns 0x01. If I ignore any byte with this bit set, the drive seems to work okay, but this is a crude and potentially risky fix. Is there any way to find out what this actually means? Could it just be a stray bit? Or is it an additional scsi status that should be handled? I *believe* PS2 mode quit working for parallel port zips after a commit to the cam/scsi system Dec 1999, but I am not familiar with that code, so I didn't know where to start looking. I am very interested in contributing my meager skills to the BSD effort in this manner, but I need a little help getting pointed in the right direction. Thanks in advance for any help anyone can offer. jcm -- o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o | ~~~~~~~~~~~~ Jonathon McKitrick ~~~~~~~~~~~~~ | | "I prefer the term 'Artificial Person' myself." | o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 9:21: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from henny.webweaving.org (unknown [212.113.16.243]) by hub.freebsd.org (Postfix) with ESMTP id A77A937B401 for ; Thu, 11 Jan 2001 09:20:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id RAA01948; Thu, 11 Jan 2001 17:17:17 GMT (envelope-from n_hibma@calcaphon.com) Date: Thu, 11 Jan 2001 17:17:17 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: j mckitrick Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: scsi and PS2 mode parallel port programming In-Reply-To: <20010111171117.A323@dogma.freebsd-uk.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 2. In the list of scsi error codes, 0x00 is no error, and the defacto > errors start with 0x02. However, in PS2 mode, when asked for status, the > zip drive returns 0x01. If I ignore any byte with this bit set, the drive > seems to work okay, but this is a crude and potentially risky fix. Is there > any way to find out what this actually means? Could it just be a stray bit? > Or is it an additional scsi status that should be handled? I *believe* PS2 > mode quit working for parallel port zips after a commit to the cam/scsi > system Dec 1999, but I am not familiar with that code, so I didn't know > where to start looking. Could you point a date (or date range) when that commit to CAM was? I'm vaguely familiar with it and more than willing to help. Where does the 0x01 come from? From the drive or from the drivers? > I am very interested in contributing my meager skills to the BSD effort in > this manner, but I need a little help getting pointed in the right > direction. Thanks in advance for any help anyone can offer. -hackers is probably the best place for these questions if you want to try and find a person with the necessary skills. Nick -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 9:22:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 73DBD37B401 for ; Thu, 11 Jan 2001 09:22:33 -0800 (PST) Received: from ted.isi.edu (ted.isi.edu [128.9.160.104]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA15391 for ; Thu, 11 Jan 2001 09:22:32 -0800 (PST) Received: (from faber@localhost) by ted.isi.edu (8.11.1/8.11.1) id f0BHMWv77320 for freebsd-hackers@FreeBSD.org; Thu, 11 Jan 2001 09:22:32 -0800 (PST) (envelope-from faber) Date: Thu, 11 Jan 2001 09:22:31 -0800 From: Ted Faber To: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010111092231.C17955@ted.isi.edu> References: <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010110233907.L253@speedy.gsinet> <3A5D7762.DC8DE5D@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=php-sha1; protocol="application/pgp-signature"; boundary="ZwgA9U+XZDXt4+m+" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5D7762.DC8DE5D@FreeBSD.org>; from DougB@FreeBSD.org on Thu, Jan 11, 2001 at 01:05:38AM -0800 X-url: http://www.isi.edu/~faber Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ZwgA9U+XZDXt4+m+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I know I'm going to regret this, but since silence is being taken to be consent here, I'd better speak up. My opinion, for those keeping count: Changing cron to internally compensate for changing timezones seems to open more doors for bugs and misfeatures than it closes. FreeBSD is in use worldwide, and compensating for all the various timezone shifts has the potential to cause serious code bloat. If you don't catch all the possible shifts, it's hard to claim the solution is complete. I oppose such changes. If someone wants to change cron's behavior to make DST (and other timezone shenanigans) behave intuitively, add a flag to make cron work exclusively in UTC as someone else suggested. It's simple to explain which means less user confusion, and covers all the cases (even crossing the International Date line with a mobile laptop) which reduces code bloat. Finally it's conceptually simpler and more elegant. I think that's worth something. I don't think that changing cron's behavior for DST is a pressing issue. However, if a change is made, I support the change to using UTC (as a user configurable option, default off), not detecting and correcting for all possible local time mods. --ZwgA9U+XZDXt4+m+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6XevXaUz3f+Zf+XsRAhRcAJ9IG7bRqGxC7poPhs8wAUcN+A0uQwCfT0WA Y37WeB/+2+PQDBaUdNb5mtY= =YSRv -----END PGP SIGNATURE----- --ZwgA9U+XZDXt4+m+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 9:41:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id 1970D37B400 for ; Thu, 11 Jan 2001 09:40:57 -0800 (PST) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14Glia-000789-00; Thu, 11 Jan 2001 17:40:56 +0000 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.11.1/8.11.1) id f0BHetL01616; Thu, 11 Jan 2001 17:40:55 GMT (envelope-from jcm) Date: Thu, 11 Jan 2001 17:40:55 +0000 From: j mckitrick To: Nick Hibma Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: scsi and PS2 mode parallel port programming Message-ID: <20010111174055.A1581@dogma.freebsd-uk.eu.org> References: <20010111171117.A323@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from n_hibma@calcaphon.com on Thu, Jan 11, 2001 at 05:17:17PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | Could you point a date (or date range) when that commit to CAM was? I'm | vaguely familiar with it and more than willing to help. I can *try*, but it was someone else who spotted the changes, and I can't seem to contact him. But he also did not find a specific change. I can give it a shot, but I would guess it has to do with handling the scsi status codes. | Where does the 0x01 come from? From the drive or from the drivers? Directly from the drive. The imm module asks the drive itself if it has any more status to return, and it returns the 0x01 value. Also, have you ever gotten r_dtr to work in PS2 mode? All I ever get is 0x01 returned, never any valid data, even though the negociate routine says PS2 is working an accepted. jcm -- o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o | ~~~~~~~~~~~~ Jonathon McKitrick ~~~~~~~~~~~~~ | | "I prefer the term 'Artificial Person' myself." | o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 9:42:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 7451F37B402 for ; Thu, 11 Jan 2001 09:42:39 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id JAA26519; Thu, 11 Jan 2001 09:42:23 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f0BHgMt10004; Thu, 11 Jan 2001 09:42:22 -0800 (PST) (envelope-from jdp) Date: Thu, 11 Jan 2001 09:42:22 -0800 (PST) Message-Id: <200101111742.f0BHgMt10004@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Reply-To: hackers@freebsd.org Cc: zzhang@cs.binghamton.edu Subject: Re: Process virtual memory question In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Zhiui Zhang wrote: > Although the 4.4 BSD design and implementation book says the text > part of a process starts from 0x0000,0000, it actually starts from > some place around 0x800,0000 (or 0x8048000 to be exact). What's in > the area between 0 - 0x800,0000? Why do we not use it if it is left > empty as shown by /proc/pid/map? How is the magic number 0x8048000 > determined? Thanks. Processes used to be mapped at address 0 when we used the a.out object file format. We changed the starting address to 0x8048000 when we switched to the ELF format. That magic address came from SVR4, the first system to use ELF. I am not 100% sure why the SVR4 developers chose that address. I think it may have been so that they could map libc and the dynamic linker at the fixed address 0, thereby avoiding the need to do any run-time relocations on them. In any case, all ELF-based systems on the x86 architecture seem to use this same address. On other architecutures such as the Alpha it is entirely different, of course. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 9:53:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 3C5B237B698 for ; Thu, 11 Jan 2001 09:52:58 -0800 (PST) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id GAA34508; Fri, 12 Jan 2001 06:52:42 +1300 (NZDT) Message-Id: <200101111752.GAA34508@ducky.nz.freebsd.org> From: "Dan Langille" Organization: The FreeBSD Diary / FreshPorts To: PILCH Hartmut Date: Fri, 12 Jan 2001 06:52:40 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Software Patents Reply-To: dan@langille.org Cc: Peter Mutsaers , freebsd-hackers@FreeBSD.ORG In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11 Jan 2001, at 15:25, PILCH Hartmut wrote: > Do we have any chance of putting a statement from a BSD organisation > on > > http://petition.eurolinux.org/statements > > and a logo on > > http://petition.eurolinux.org/sponsors > > ? > > Maybe Julian could draft that statement and have someone sign it in > the name of the FreeBSD project? Speaking of patents, I hope you've all read: -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 10:20:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.state.me.us (mailhub.state.me.us [141.114.122.227]) by hub.freebsd.org (Postfix) with ESMTP id 35C3C37B404 for ; Thu, 11 Jan 2001 10:20:28 -0800 (PST) Received: from katahdin.bmv.state.me.us by mailhub.state.me.us with ESMTP; Thu, 11 Jan 2001 13:12:02 -0500 Received: from localhost (darren@localhost) by katahdin.bmv.state.me.us (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA38936; Thu, 11 Jan 2001 13:19:50 -0500 (EST) Date: Thu, 11 Jan 2001 13:19:49 -0500 (EST) From: Darren Henderson To: Gerhard Sittig Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <20010110233907.L253@speedy.gsinet> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Jan 2001, Gerhard Sittig wrote: > Looking at the echo returning so far I see _much_ more "yes" than > "nope" answers. There's consent that *something* has to be done. Heh, if its votes you are looking for then you can add another to your "nope" column for what its worth. The current behavior is the expected behavior and should remain. I'd suggest moving the man 5 conrtab BUGS section content (really doesn't belong there, its not really what I would call a bug) up to the section discussing field contents so admins/users are hit with it each time they look. Or perhaps adding a note to the default crontab comments. I'd see this as being more helpful. ________________________________________________________________________ Darren Henderson darren@bmv.state.me.us darren.henderson@state.me.us To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 10:25:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 5967137B402; Thu, 11 Jan 2001 10:25:28 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f0BIPPY00924; Thu, 11 Jan 2001 10:25:25 -0800 Date: Thu, 11 Jan 2001 10:25:25 -0800 From: Brooks Davis To: "Donald J . Maddox" Cc: Robert Watson , freebsd-hackers@FreeBSD.ORG Subject: Re: Setting default hostname to localhost Message-ID: <20010111102525.B28915@Odin.AC.HMC.Edu> References: <20010110213538.A668@cae88-102-101.sc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010110213538.A668@cae88-102-101.sc.rr.com>; from dmaddox@sc.rr.com on Wed, Jan 10, 2001 at 09:35:38PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 10, 2001 at 09:35:38PM -0500, Donald J . Maddox wrote: > On Wed, Jan 10, 2001 at 09:23:13PM -0500, Robert Watson wrote: > > /etc/default/rc.conf to change the default hostname to "localhost". If > > the user configures a hostname, or DHCP provides one, it will be > > overridden, of course, so should not impact any configuration but one > > where the hostname is left undefined. > > A cursory glance at /sbin/dhclient-script seems to indicate that > DHCP will NOT override the hostname unless it is an empty string. I submitted one possiable solution to this problem in PR:conf/18583 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18583 Other solutions include just letting DHCP smash the hostname all the time or having a variable like dhcp_override_hostname in rc.conf. While I understand the concern that we don't want to maintain out own dhcp version, dhclient-script isn't on the vendor branch anyway. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 10:31:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.147.224.201]) by hub.freebsd.org (Postfix) with ESMTP id DCC2437B401; Thu, 11 Jan 2001 10:31:04 -0800 (PST) Received: from thehousleys.net (baby.int.thehousleys.net [192.168.0.24]) by thehousleys.net (8.11.1/8.11.1) with ESMTP id f0BIUK562112; Thu, 11 Jan 2001 13:30:20 -0500 (EST) (envelope-from jim@thehousleys.net) Message-ID: <3A5DFBBC.AC54758C@thehousleys.net> Date: Thu, 11 Jan 2001 13:30:20 -0500 From: James Housley X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: The Hermit Hacker Cc: Ben Goren , ports@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Where have all the md5s gone? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Hermit Hacker wrote: > > distinfo > > On Thu, 11 Jan 2001, Ben Goren wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > In checking the output from my daily.local script which runs cvsup, I > > couldn't help but notice that *ALL* the md5 files have been deleted. > > > > Pardon the paranoia...but this seems quite peculiar. > > > > I'm using the Arizona mirror, cvsup5.FreeBSD.org. > > > > I'm not a subscriber to this list, but I will be monitoring the > > archives. Still, I'd appreciate being Cc:d on replies. > > Actually. A couple of months ago the PORTS tree was reorganized to use fewer directories and such save space. The files from the pkg/ directory was moved up one level and files/md5 became distinfo. If a port had patches they are now in the files directory. Yesterday all the old files were removed since there has been no problems with the new system. Jim -- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net --------------------------------------------------------------------- PC hardware is the ductape of the computer inustry... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 10:34:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from germanium.xtalwind.net (germanium.xtalwind.net [205.160.242.5]) by hub.freebsd.org (Postfix) with ESMTP id E602B37B402 for ; Thu, 11 Jan 2001 10:34:05 -0800 (PST) Received: from localhost (localhost.xtalwind.net [127.0.0.1]) by germanium.xtalwind.net (8.11.1/8.11.1) with ESMTP id f0BIY3h03891 for ; Thu, 11 Jan 2001 13:34:03 -0500 (EST) (envelope-from jack@germanium.xtalwind.net) Date: Thu, 11 Jan 2001 13:34:03 -0500 (EST) From: jack To: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Today Darren Henderson wrote: > > Looking at the echo returning so far I see _much_ more "yes" than > > "nope" answers. There's consent that *something* has to be done. > > Heh, if its votes you are looking for then you can add another to your > "nope" column for what its worth. The current behavior is the expected > behavior and should remain. And another "nope". Added as a knob that could be tweaked would be ok but only if the current behavior is retained as the default. -------------------------------------------------------------------------- Jack O'Neill Systems Administrator / Systems Analyst jack@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger jack@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -------------------------------------------------------------------------- A Microsoft Certified Systems Engineer is to computing what a McDonalds Certified Food Specialist is to fine cuisine. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 10:48:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by hub.freebsd.org (Postfix) with SMTP id 4702337B69C for ; Thu, 11 Jan 2001 10:48:01 -0800 (PST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Jan 11 13:47:35 EST 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Thu Jan 11 13:47:34 EST 2001 Received: (from jkf@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id NAA11876; Thu, 11 Jan 2001 13:47:34 -0500 (EST) Date: Thu, 11 Jan 2001 13:47:34 -0500 (EST) From: Jeff Fellin Message-Id: <200101111847.NAA11876@aura.research.bell-labs.com> To: freebsd-hackers@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: PCI interface Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is posted on hackers and questions mailing lists. I am porting a PCI device driver from BSD 3.1 to current. I noticed the interfaces for the PCI support functions has changed. I have looked at the hackers, questions, current mail lists and cannot find any description of the interface changes for the PCI system. I have noticed some drivers have a COMPAT_OLDPCI, but that isn't a supported config option. Is there a description of how to convert the old pci support function interface into the current pci support funtion interface that someone could point me to. If not, is there a description of the current pci support function interface. I need to memory map two board regions, board registers and board memory, and to access the PCI configuration registers. Thank you in advance. Jeff Fellin MH 2A-352 (908) 582-7673 fellin@lucent.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 11: 5:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id EDA4337B400 for ; Thu, 11 Jan 2001 11:05:27 -0800 (PST) Received: from jade (jade.cs.binghamton.edu [128.226.140.161]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f0BJ5Op00864; Thu, 11 Jan 2001 14:05:24 -0500 (EST) Date: Thu, 11 Jan 2001 14:03:27 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@jade To: John Polstra Cc: hackers@freebsd.org Subject: Re: Process virtual memory question In-Reply-To: <200101111742.f0BHgMt10004@vashon.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks. It just occurs to me that Linux kernel used to have something like this in routine BUG(): * ((char *) 0) = 0; It is called when there is a kernel bug. So address 0 should not be mapped writable, otherwise all C statements " char * p = NULL; * p = value; " would be legal. The book "Unix Internals - A Practical Approach" by S.D. Pate has a figure showing in ELF format, the stack lies BELOW the code segment and grows downwards. This might have something to do with code starting from 0x8048000. -Zhihui On Thu, 11 Jan 2001, John Polstra wrote: > In article , Zhiui > Zhang wrote: > > > Although the 4.4 BSD design and implementation book says the text > > part of a process starts from 0x0000,0000, it actually starts from > > some place around 0x800,0000 (or 0x8048000 to be exact). What's in > > the area between 0 - 0x800,0000? Why do we not use it if it is left > > empty as shown by /proc/pid/map? How is the magic number 0x8048000 > > determined? Thanks. > > Processes used to be mapped at address 0 when we used the a.out object > file format. We changed the starting address to 0x8048000 when we > switched to the ELF format. That magic address came from SVR4, the > first system to use ELF. > > I am not 100% sure why the SVR4 developers chose that address. I > think it may have been so that they could map libc and the dynamic > linker at the fixed address 0, thereby avoiding the need to do any > run-time relocations on them. > > In any case, all ELF-based systems on the x86 architecture seem to > use this same address. On other architecutures such as the Alpha > it is entirely different, of course. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 11:12: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from email_server.midstream.com (unknown [63.113.115.195]) by hub.freebsd.org (Postfix) with ESMTP id 3B4CA37B400; Thu, 11 Jan 2001 11:11:30 -0800 (PST) Received: by EMAIL_SERVER with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 11:13:47 -0800 Message-ID: <31E4B6337A4FD411BD45000102472E0C05E724@EMAIL_SERVER> From: Jeff Roberson To: 'Jeff Fellin' , freebsd-hackers@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: RE: PCI interface Date: Thu, 11 Jan 2001 11:13:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07C02.9F7442E0" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07C02.9F7442E0 Content-Type: text/plain; charset="iso-8859-1" The Daemon News has a decent article on the new device driver framework. The article is at http://www.daemonnews.org/200007/newbus-intro.html. Jeff -----Original Message----- From: Jeff Fellin [mailto:jkf@research.bell-labs.com] Sent: Thursday, January 11, 2001 10:48 AM To: freebsd-hackers@FreeBSD.org; freebsd-questions@FreeBSD.org Subject: PCI interface This is posted on hackers and questions mailing lists. I am porting a PCI device driver from BSD 3.1 to current. I noticed the interfaces for the PCI support functions has changed. I have looked at the hackers, questions, current mail lists and cannot find any description of the interface changes for the PCI system. I have noticed some drivers have a COMPAT_OLDPCI, but that isn't a supported config option. Is there a description of how to convert the old pci support function interface into the current pci support funtion interface that someone could point me to. If not, is there a description of the current pci support function interface. I need to memory map two board regions, board registers and board memory, and to access the PCI configuration registers. Thank you in advance. Jeff Fellin MH 2A-352 (908) 582-7673 fellin@lucent.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------_=_NextPart_001_01C07C02.9F7442E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PCI interface

The Daemon News has a decent article on the new = device driver framework.  The article is at http://www.daemonnews.org/200007/newbus-intro.html= .

Jeff

-----Original Message-----
From: Jeff Fellin [mailto:jkf@research.bell-labs= .com]
Sent: Thursday, January 11, 2001 10:48 AM
To: freebsd-hackers@FreeBSD.org; = freebsd-questions@FreeBSD.org
Subject: PCI interface



This is posted on hackers and questions mailing = lists.


I am porting a PCI device driver from BSD 3.1 to = current. I noticed
the interfaces for the PCI support functions has = changed. I have
looked at the hackers, questions, current mail lists = and cannot
find any description of the interface changes for = the PCI system.

I have noticed some drivers have a COMPAT_OLDPCI, but = that isn't
a supported config option.

Is there a description of how to convert the old pci = support
function interface into the current pci support = funtion interface
that someone could point me to. If not, is there a = description of
the current pci support function interface.

I need to memory map two board regions, board = registers and
board memory, and to access the PCI configuration = registers.

Thank you in advance.


        Jeff = Fellin
        MH = 2A-352
        (908) = 582-7673
        fellin@lucent.com


To Unsubscribe: send mail to = majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the = body of the message

------_=_NextPart_001_01C07C02.9F7442E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 11:16:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from henny.webweaving.org (unknown [212.113.16.243]) by hub.freebsd.org (Postfix) with ESMTP id 11F1F37B401 for ; Thu, 11 Jan 2001 11:16:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id TAA02254; Thu, 11 Jan 2001 19:14:52 GMT (envelope-from n_hibma@calcaphon.com) Date: Thu, 11 Jan 2001 19:14:52 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: j mckitrick Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: scsi and PS2 mode parallel port programming In-Reply-To: <20010111174055.A1581@dogma.freebsd-uk.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I can *try*, but it was someone else who spotted the changes, and I can't > seem to contact him. But he also did not find a specific change. I can > give it a shot, but I would guess it has to do with handling the scsi status > codes. I'll put this on my pile of things to and dig through the CAM changes to find it. There weren't that many in the past year. > | Where does the 0x01 come from? From the drive or from the drivers? > > Directly from the drive. The imm module asks the drive itself if it has any > more status to return, and it returns the 0x01 value. > > Also, have you ever gotten r_dtr to work in PS2 mode? All I ever get is > 0x01 returned, never any valid data, even though the negociate routine says > PS2 is working an accepted. I don't know much about the PS2 mode nor the parallel port driver (allthough I've had my fingers in there, as you know). Nick -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 11:25:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id 5FE3837B699 for ; Thu, 11 Jan 2001 11:24:47 -0800 (PST) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14GnL4-000AAh-00; Thu, 11 Jan 2001 19:24:46 +0000 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.11.1/8.11.1) id f0BJOk305846; Thu, 11 Jan 2001 19:24:46 GMT (envelope-from jcm) Date: Thu, 11 Jan 2001 19:24:46 +0000 From: j mckitrick To: Nick Hibma Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: scsi and PS2 mode parallel port programming Message-ID: <20010111192445.A5805@dogma.freebsd-uk.eu.org> References: <20010111174055.A1581@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from n_hibma@calcaphon.com on Thu, Jan 11, 2001 at 07:14:52PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | I'll put this on my pile of things to and dig through the CAM changes to | find it. There weren't that many in the past year. I finally heard from the guy who noticed the change, and asked if he could help localize it. | I don't know much about the PS2 mode nor the parallel port driver | (allthough I've had my fingers in there, as you know). A parallel port in ECP mode should support PS2 without any problem, correct? And if I recall, it worked under 3.x, so that *should* rule out a buggy BIOS or hardware anomaly. I *hate* when problems only afflict my machine. jcm -- o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o | ~~~~~~~~~~~~ Jonathon McKitrick ~~~~~~~~~~~~~ | | "I prefer the term 'Artificial Person' myself." | o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 11:27: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id CE40E37B400 for ; Thu, 11 Jan 2001 11:26:48 -0800 (PST) Received: by smtp.nettoll.com; Thu, 11 Jan 2001 20:25:48 +0100 (MET) Message-ID: <3A5E090B.40601@enition.com> Date: Thu, 11 Jan 2001 20:27:07 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis References: <20010111163903.E6FF737B400@hub.freebsd.org> <3A5DE59F.6060602@enition.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everybody, I have reached a point where I am wondering if a call to 'malloc' with the M_NOWAIT flag is not falling asleep ! In fact, I suspect that the interrupted context is somewhere during a call to 'malloc' (I increment a counter just before calling malloc and increment another just after and the difference is one !) while I have called 'splnet' beforehand, thus normally preventing competing with any network isr. I assume that this shouldnever occur unless the code is somewhere calling 'sleep' and provoke acontext switch. Is there anybody who can help on this ? Best regards, Xavier P.S.: I am still looking how I could dump the kernel stack frame of an interrupted process from the actual interrupt kernel stack ... Xavier Galleri wrote: > Hi everybody, > > I am currently working with FreeBSD 4.1 on i386 platform on a > pseudo-device driver that interacts with the networking subsystem in > the kernel. Basically, we are intercepting both incoming and outgoing > IP-level trafficfor specific processing. Obviously, there is also some > administrative processingthat is conducted from a user-land daemon. > > I have detected a problem with my driver occuring in the context of > the network SWI, as shown by the following basic stack: > > #14 in ... /* private code */ > #15 in ip_input > #16 in ipintr > > My problem comes from that I would like to get the stack frame of the > interrupted execution process (everything that would be frame #17 and > below) and I do not know how to do this with the GDB debugger. > > Is there anybody how could provide me with the steps to achieve this ? > > Regards, > > X. Galleri > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 11:43:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id DF53C37B404 for ; Thu, 11 Jan 2001 11:43:21 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0BJhJk22386; Thu, 11 Jan 2001 11:43:19 -0800 (PST) Date: Thu, 11 Jan 2001 11:43:19 -0800 From: Alfred Perlstein To: Xavier Galleri Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis Message-ID: <20010111114318.C7240@fw.wintelcom.net> References: <20010111163903.E6FF737B400@hub.freebsd.org> <3A5DE59F.6060602@enition.com> <3A5E090B.40601@enition.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5E090B.40601@enition.com>; from xgalleri@enition.com on Thu, Jan 11, 2001 at 08:27:07PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Xavier Galleri [010111 11:27] wrote: > Hi everybody, > > I have reached a point where I am wondering if a call to 'malloc' with > the M_NOWAIT flag is not falling asleep ! M_NOWAIT shouldn't sleep. > In fact, I suspect that the interrupted context is somewhere during a > call to 'malloc' (I increment a counter just before calling malloc and > increment another just after and the difference is one !) while I have > called 'splnet' beforehand, thus normally preventing competing with any > network isr. I assume that this shouldnever occur unless the code is > somewhere calling 'sleep' and provoke acontext switch. if you add 1 to a variable the difference is expected to be one. > Is there anybody who can help on this ? I'm not sure, you need to be more specific/clear. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 11:54:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 21D5637B400 for ; Thu, 11 Jan 2001 11:54:20 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id LAA27319; Thu, 11 Jan 2001 11:54:07 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f0BJs6T10330; Thu, 11 Jan 2001 11:54:06 -0800 (PST) (envelope-from jdp) Date: Thu, 11 Jan 2001 11:54:06 -0800 (PST) Message-Id: <200101111954.f0BJs6T10330@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Reply-To: hackers@freebsd.org Cc: zzhang@cs.binghamton.edu Subject: Re: Process virtual memory question In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Zhiui Zhang wrote: > > Thanks. It just occurs to me that Linux kernel used to have something > like this in routine BUG(): > > * ((char *) 0) = 0; > > It is called when there is a kernel bug. So address 0 should not be > mapped writable, otherwise all C statements " char * p = NULL; * p = > value; " would be legal. Right. Address 0 is not mapped writable in FreeBSD. > The book "Unix Internals - A Practical Approach" by S.D. Pate has a > figure showing in ELF format, the stack lies BELOW the code segment > and grows downwards. This might have something to do with code > starting from 0x8048000. Yes, I think you are right, now that my memory is returning. :-) In SVR4 the stack grew downwards from 0x8000000. I think that libc and the dynamic linker (all together in one shared library) were mapped between 0x8000000 and 0x8048000. But that is just a guess. Most modern libcs wouldn't fit in that amount of space these days. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 12: 0:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from luke.immure.com (luke.immure.com [207.8.42.74]) by hub.freebsd.org (Postfix) with ESMTP id 33E8437B69E for ; Thu, 11 Jan 2001 11:59:10 -0800 (PST) Received: (from bob@localhost) by luke.immure.com (8.11.1/8.11.1) id f0BJwpF16198 for freebsd-hackers@freebsd.org; Thu, 11 Jan 2001 13:58:51 -0600 (CST) (envelope-from bob) Date: Thu, 11 Jan 2001 13:58:51 -0600 From: Bob Willcox To: hackers list Subject: FreeBSD boot manager, where is latest version? Message-ID: <20010111135851.A16078@luke.immure.com> Reply-To: Bob Willcox Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, I installed FreeBSD 4.2-Release on the last 10GB of a 25GB disk. Later I then installed W98SE on the first 15GB of the same disk. Unfortunately, Winblows replaced the boot program (FreeBSD's boot manager) with its own program. I now need to restore the FreeBSD boot manager (preferably w/o re-installing FreeBSD) on the disk. Note that prior to insalling W98, FreeBSD happily booted of of the second partition (by pressing F2 at the prompt). I already did install the version of the boot program found in the tools directory on the FreeBSD 4.2 CDROM, but it appears to be an older version (doesn't recognize the W98 FAT32 partition) that refuses to boot the FreeBSD partition (because it starts 15GB from the front of the disk, perhaps?). I know there _must_ be a newer version of this program somehwere (before I installed W98 it was on my disk)! Anybody able to give me any pointers to where? Thanks, Bob -- Bob Willcox There's a long-standing bug relating to the x86 bob@VIEO.com architecture that allows you to install Windows. Austin, TX -- Matthew D. Fuller To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 12: 3:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7FB2837B400 for ; Thu, 11 Jan 2001 12:03:33 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0BK3WK22993; Thu, 11 Jan 2001 12:03:32 -0800 (PST) Date: Thu, 11 Jan 2001 12:03:32 -0800 From: Alfred Perlstein To: Bob Willcox Cc: hackers list Subject: Re: FreeBSD boot manager, where is latest version? Message-ID: <20010111120332.D7240@fw.wintelcom.net> References: <20010111135851.A16078@luke.immure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010111135851.A16078@luke.immure.com>; from bob@immure.com on Thu, Jan 11, 2001 at 01:58:51PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bob Willcox [010111 12:00] wrote: > Hi All, > > I installed FreeBSD 4.2-Release on the last 10GB of a 25GB disk. > Later I then installed W98SE on the first 15GB of the same disk. > Unfortunately, Winblows replaced the boot program (FreeBSD's boot > manager) with its own program. I now need to restore the FreeBSD boot > manager (preferably w/o re-installing FreeBSD) on the disk. Hmm, no guarantees but you may have luck with OS-BS, it's a bit nicer looking than the FreeBSD multi boot program: ftp://ftp.freebsd.org/pub/FreeBSD/tools/osbs135.exe -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 12: 5:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by hub.freebsd.org (Postfix) with ESMTP id 5ED7E37B401 for ; Thu, 11 Jan 2001 12:05:38 -0800 (PST) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [161.44.133.25]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA17834 for ; Thu, 11 Jan 2001 15:05:34 -0500 (EST) Received: from bmcgover-pc.cisco.com (localhost [127.0.0.1]) by bmcgover-pc.cisco.com (8.11.1/8.11.1) with ESMTP id f0BK5T406464 for ; Thu, 11 Jan 2001 15:05:33 -0500 (EST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <200101112005.f0BK5T406464@bmcgover-pc.cisco.com> To: hackers@freebsd.org Subject: Question about 'open' files.... Date: Thu, 11 Jan 2001 15:05:29 -0500 From: "Brian J. McGovern" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm doing some tests for Greg on vinum (trying to crash it), and I've run across a problem that is not particular to vinum. I'm hoping someone can explain it to me and/or tell me how to work around it. Using the code fragment (note: The code I'm using is actually more complex, and checks for errors in opening, writing, etc, but I'm keeping it basic for the discussion): for (counter = 0; counter < 20000; counter++) { x = open(filename,O_CREAT | O_WRONLY); write(x, buffer, size); close(x); } I will run anywhere between 1-5 instances of the code loop above. After there are about 2050 files on the disk (it _appears_ to be variations of 2048, plus files already on the disk, . and .., etc.), the programs crash with "too many open files". The problem, in my mind, is that the files are _closed_ (not open). I'm curious if this is some type of accounting error on a per-login basis, or whether there is some type of garbage collection not happening. Typically, after all of the applications die with this error, if I immediately restart, they die pretty quickly. If I wait like 10+ seconds, they can run again, and generate the 2048+/- files again before dying, which leads me to believe its something to do with per-user accounting/garbage collection. I would be curious to understand this, and its impact, as this does not appear to be 'good' (tm) behavior, particularly if one wishes to run a program that opens and closes a lot of small files. I welcome any thoughts. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 12:22: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3773937B401 for ; Thu, 11 Jan 2001 12:21:48 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0BKLlp23562; Thu, 11 Jan 2001 12:21:47 -0800 (PST) Date: Thu, 11 Jan 2001 12:21:47 -0800 From: Alfred Perlstein To: "Brian J. McGovern" Cc: hackers@FreeBSD.ORG Subject: Re: Question about 'open' files.... Message-ID: <20010111122147.E7240@fw.wintelcom.net> References: <200101112005.f0BK5T406464@bmcgover-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101112005.f0BK5T406464@bmcgover-pc.cisco.com>; from bmcgover@cisco.com on Thu, Jan 11, 2001 at 03:05:29PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Brian J. McGovern [010111 12:06] wrote: > I'm doing some tests for Greg on vinum (trying to crash it), and I've run > across a problem that is not particular to vinum. I'm hoping someone can > explain it to me and/or tell me how to work around it. > > Using the code fragment (note: The code I'm using is actually more complex, > and checks for errors in opening, writing, etc, but I'm keeping it basic > for the discussion): > > for (counter = 0; counter < 20000; counter++) > { > x = open(filename,O_CREAT | O_WRONLY); > write(x, buffer, size); > close(x); > } ok, I tried this: ~/tst % cat t.c #include int main(int argc, char **argv) { int x, i, counter; char buf[200]; char buffer[2048]; memset(buffer, '%', sizeof(buffer)); for (counter = 0; counter < 20000; counter++) { sprintf(buf, "%s/%d", argv[1], counter); x = open(buf,O_CREAT | O_WRONLY); if (x == -1) { perror("open"); exit(1); } write(x, buffer, sizeof(buffer)); close(x); } return 0; } mkdir a b c d e f g h for i in a b c d e f g h ; do ./a.out $i & ; done ~/tst % find . | wc -l 74246 Looks like your test program has a bug. Can you try to reduce it down to a reproduceable case? FreeBSD xxx.wintelcom.net 4.2-STABLE FreeBSD 4.2-STABLE #0: Wed Jan 10 19:58:03 PST 2001 bright@xxx.wintelcom.net:/usr/obj/usr/src/sys/xxx i386 ~/tst % find . | wc -l 99470 :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 12:26:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by hub.freebsd.org (Postfix) with ESMTP id 0AFF237B6A0 for ; Thu, 11 Jan 2001 12:26:27 -0800 (PST) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [161.44.133.25]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA20639; Thu, 11 Jan 2001 15:26:21 -0500 (EST) Received: from bmcgover-pc.cisco.com (localhost [127.0.0.1]) by bmcgover-pc.cisco.com (8.11.1/8.11.1) with ESMTP id f0BKQJ406592; Thu, 11 Jan 2001 15:26:20 -0500 (EST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <200101112026.f0BKQJ406592@bmcgover-pc.cisco.com> To: Alfred Perlstein Cc: "Brian J. McGovern" , hackers@FreeBSD.ORG Subject: Re: Question about 'open' files.... In-reply-to: Your message of "Thu, 11 Jan 2001 12:21:47 PST." <20010111122147.E7240@fw.wintelcom.net> Date: Thu, 11 Jan 2001 15:26:19 -0500 From: "Brian J. McGovern" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just for chuckles, try them in the same directory. That will emulate what I've been doing here when having problems. -Brian > * Brian J. McGovern [010111 12:06] wrote: > > I'm doing some tests for Greg on vinum (trying to crash it), and I've run > > across a problem that is not particular to vinum. I'm hoping someone can > > explain it to me and/or tell me how to work around it. > > > > Using the code fragment (note: The code I'm using is actually more complex , > > and checks for errors in opening, writing, etc, but I'm keeping it basic > > for the discussion): > > > > for (counter = 0; counter < 20000; counter++) > > { > > x = open(filename,O_CREAT | O_WRONLY); > > write(x, buffer, size); > > close(x); > > } > > ok, I tried this: > > ~/tst % cat t.c > #include > int main(int argc, char **argv) { > int x, i, counter; > char buf[200]; > char buffer[2048]; > memset(buffer, '%', sizeof(buffer)); > > for (counter = 0; counter < 20000; counter++) > { > sprintf(buf, "%s/%d", argv[1], counter); > x = open(buf,O_CREAT | O_WRONLY); > if (x == -1) { > perror("open"); > exit(1); > } > write(x, buffer, sizeof(buffer)); > close(x); > } > return 0; > } > > mkdir a b c d e f g h > for i in a b c d e f g h ; do ./a.out $i & ; done > ~/tst % find . | wc -l > 74246 > > Looks like your test program has a bug. > > Can you try to reduce it down to a reproduceable case? > > FreeBSD xxx.wintelcom.net 4.2-STABLE FreeBSD 4.2-STABLE #0: Wed Jan 10 19:58 :03 PST 2001 bright@xxx.wintelcom.net:/usr/obj/usr/src/sys/xxx i386 > > ~/tst % find . | wc -l > 99470 > > :) > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 12:35: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 20BFD37B724 for ; Thu, 11 Jan 2001 12:34:42 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0BKYgI23932; Thu, 11 Jan 2001 12:34:42 -0800 (PST) Date: Thu, 11 Jan 2001 12:34:42 -0800 From: Alfred Perlstein To: "Brian J. McGovern" Cc: hackers@FreeBSD.ORG Subject: Re: Question about 'open' files.... Message-ID: <20010111123442.H7240@fw.wintelcom.net> References: <20010111122147.E7240@fw.wintelcom.net> <200101112026.f0BKQJ406592@bmcgover-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101112026.f0BKQJ406592@bmcgover-pc.cisco.com>; from bmcgover@cisco.com on Thu, Jan 11, 2001 at 03:26:19PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Brian J. McGovern [010111 12:26] wrote: > Just for chuckles, try them in the same directory. That will emulate what > I've been doing here when having problems. I don't think so: #include int main(int argc, char **argv) { int x, i, counter; char buf[200]; char buffer[2048]; memset(buffer, '%', sizeof(buffer)); for (counter = 0; counter < 20000; counter++) { sprintf(buf, "files/%s%d", argv[1], counter); x = open(buf,O_CREAT | O_WRONLY); if (x == -1) { perror("open"); exit(1); } write(x, buffer, sizeof(buffer)); close(x); } return 0; } ~/tst % gcc t.c ~/tst % for i in a b c d e f g h ; do ./a.out $i & ; done ~/tst % find . | wc -l 26783 ... ~/tst % find . | wc -l 40524 Sure the directory ops start to get pretty slow once a UFS dir gets to be this size, but that's just a problem with UFS. I really can't reproduce this behavior here and can't suggest a fix unless you can come up with a test program of your own to produce it. sorry, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 12:41:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by hub.freebsd.org (Postfix) with ESMTP id 70A6137B400 for ; Thu, 11 Jan 2001 12:41:32 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA22765 for ; Thu, 11 Jan 2001 15:41:30 -0500 (EST) Received: from mailsrv2.mitre.org (mailsrv2.mitre.org [129.83.221.17]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA29687 for ; Thu, 11 Jan 2001 15:41:29 -0500 (EST) Received: from mitre.org ([128.29.145.140]) by mailsrv2.mitre.org (Netscape Messaging Server 4.15) with ESMTP id G70MT400.L36; Thu, 11 Jan 2001 15:41:28 -0500 Message-ID: <3A5E1A3E.5A17AF9E@mitre.org> Date: Thu, 11 Jan 2001 15:40:30 -0500 From: "Andresen,Jason R." X-Mailer: Mozilla 4.75 [en]C-20000818M (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: hackers list Subject: Re: FreeBSD boot manager, where is latest version? References: <20010111135851.A16078@luke.immure.com> <20010111120332.D7240@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You might also try xosl (http://www.xosl.org), which has a lot of addtional features over both os-bs and booteasy, including an optional partition manager. It is also being maintained currently, unlike both Booteasy and OS-BS. Alfred Perlstein wrote: > > * Bob Willcox [010111 12:00] wrote: > > Hi All, > > > > I installed FreeBSD 4.2-Release on the last 10GB of a 25GB disk. > > Later I then installed W98SE on the first 15GB of the same disk. > > Unfortunately, Winblows replaced the boot program (FreeBSD's boot > > manager) with its own program. I now need to restore the FreeBSD boot > > manager (preferably w/o re-installing FreeBSD) on the disk. > > Hmm, no guarantees but you may have luck with OS-BS, it's a bit nicer > looking than the FreeBSD multi boot program: > > ftp://ftp.freebsd.org/pub/FreeBSD/tools/osbs135.exe -- _ _ _ ___ ____ ___ ______________________________________ / \/ \ | ||_ _|| _ \|___| | Jason Andresen -- jandrese@mitre.org / /\/\ \ | | | | | |/ /|_|_ | Views expressed may not reflect those /_/ \_\|_| |_| |_|\_\|___| | of the Mitre Corporation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 13:17:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by hub.freebsd.org (Postfix) with ESMTP id 2099337B404 for ; Thu, 11 Jan 2001 13:17:01 -0800 (PST) Received: from localhost (s340-modem2068.dial.xs4all.nl [194.109.168.20]) by smtp9.xs4all.nl (8.9.3/8.9.3) with SMTP id WAA13356 for ; Thu, 11 Jan 2001 22:16:53 +0100 (CET) Message-ID: <3A5C843C.794BDF32@xs4all.nl> Date: Wed, 10 Jan 2001 15:48:12 +0000 From: "W.H.Scholten" Organization: . X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 4.1-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: pppd & mkdir diff Content-Type: multipart/mixed; boundary="------------1CFBAE3959E2B60015FB7483" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------1CFBAE3959E2B60015FB7483 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit L.S. Here are two patches I've been using for a while on both 3.3R and 4.1R: 1. a pppd patch which sends the pppd messages to stderr. This is useful for dialup connections under X (I use a script to startup pppd, when the script is killed, so is pppd). Now the pppd startup messages are sent to e.g. the xterm the script is started on (using syslog.conf I can get this too but then all xterms get the messages which is annoying; or is there a way to do this that I'm not aware of?). Perhaps it's useful as a compile option or a runtime option. 2. a mkdir patch changing an error message. If for example /tmp/aa does not exist then mkdir /tmp/aa/bb will report /tmp/aa/bb: No such file or directory This is true but not the point. The patch makes it say: /tmp/aa: No such file or directory Wouter --------------1CFBAE3959E2B60015FB7483 Content-Type: text/plain; charset=us-ascii; name="pppd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pppd.diff" --- /usr/src/usr.sbin/pppd/main.c~ Sun Aug 29 17:47:05 1999 +++ /usr/src/usr.sbin/pppd/main.c Mon Jun 12 21:09:47 2000 @@ -191,7 +191,7 @@ #ifdef ULTRIX openlog("pppd", LOG_PID); #else - openlog("pppd", LOG_PID | LOG_NDELAY, LOG_PPP); + openlog("pppd", LOG_PID | LOG_NDELAY | LOG_PERROR, LOG_PPP); setlogmask(LOG_UPTO(LOG_INFO)); #endif --------------1CFBAE3959E2B60015FB7483 Content-Type: text/plain; charset=us-ascii; name="mkdir.diff2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mkdir.diff2" diff -ruN mkdir.orig/mkdir.c mkdir/mkdir.c --- mkdir.orig/mkdir.c Sat Sep 4 05:19:38 1999 +++ mkdir/mkdir.c Fri Jan 5 07:56:35 2001 @@ -58,6 +58,8 @@ int build __P((char *, mode_t)); void usage __P((void)); +char *path_prefix __P((char *)); + int vflag; @@ -108,7 +110,10 @@ if (build(*argv, omode)) success = 0; } else if (mkdir(*argv, omode) < 0) { - warn("%s", *argv); + if (errno == ENOTDIR || errno == ENOENT) + warn("%s", path_prefix(*argv)); + else + warn("%s", *argv); success = 0; } else if (vflag) (void)printf("%s\n", *argv); @@ -129,6 +134,19 @@ } exit(exitval); } + + +char *path_prefix(char *path) { + char *slash; + + if (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; + + slash = strrchr(path, '/'); + if (slash) *slash = 0; + + return path; +} + int build(path, omode) --------------1CFBAE3959E2B60015FB7483-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 13:25:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4E1F237B401 for ; Thu, 11 Jan 2001 13:25:18 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0BLP9K25477; Thu, 11 Jan 2001 13:25:09 -0800 (PST) Date: Thu, 11 Jan 2001 13:25:09 -0800 From: Alfred Perlstein To: "W.H.Scholten" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff Message-ID: <20010111132509.J7240@fw.wintelcom.net> References: <3A5C843C.794BDF32@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5C843C.794BDF32@xs4all.nl>; from whs@xs4all.nl on Wed, Jan 10, 2001 at 03:48:12PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * W.H.Scholten [010111 13:17] wrote: > L.S. > > Here are two patches I've been using for a while on both 3.3R and 4.1R: > > 1. a pppd patch which sends the pppd messages to stderr. not sure about this one, I would open a PR about it. > 2. a mkdir patch changing an error message. > > If for example /tmp/aa does not exist then mkdir /tmp/aa/bb will report > /tmp/aa/bb: No such file or directory > This is true but not the point. The patch makes it say: > /tmp/aa: No such file or directory > > diff -ruN mkdir.orig/mkdir.c mkdir/mkdir.c > +char *path_prefix(char *path) { > + char *slash; > + > + if (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; > + > + slash = strrchr(path, '/'); > + if (slash) *slash = 0; > + > + return path; > +} Ok, I may be misreading this, but this doesn't fix it really: mkdir /tmp/a/b/c/d/e/f/s perhaps if you called "stat" in a loop to on each patch component until it failed you'd be able to trim off the directory paths one by one. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 13:45:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from www.parkcity.net (www.parkcity.net [63.79.78.12]) by hub.freebsd.org (Postfix) with ESMTP id A0D0737B402; Thu, 11 Jan 2001 13:45:21 -0800 (PST) Received: from [63.79.78.121] (usr3-26-pm-2pc.parkcity.net [63.79.78.121]) by www.parkcity.net (8.9.3/8.9.1) with ESMTP id PAA11285; Thu, 11 Jan 2001 15:32:32 -0700 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Thu, 11 Jan 2001 14:24:38 -0700 Subject: Upcoming Concert at the Canyons From: "lharlow@parkcity.net" To: Park City Businesses , Festival Interest , Fusion Media Home Theater Cc: Vip List , Leslie Festival List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Chaplin with Chamber Music Concerts are big favorites at the Park City International Music Festival, Utah's oldest classical music festival. Join us January 23 at 8 PM in the Ballroom at Canyons Resort for "The Immigrant", the classic silent film by Charles Chaplin, along with performances of other Festival favorites. Performers will be violinist Arturo Delmoni, cellist Gayle Smith, pianist Doris Stevenson, clarinetist Russell Harlow and violist Leslie Harlow. Tickets are being offered at a special "film festival" price for this concert:$5 at the door. Parking is an additional $7 per car at the Canyons Grand Summit Hotel. The Festival would like to thank Canyons for its generous support of the arts in Park City/Summit County. The restaurants at the Canyons have become destinations for Festival artists and patrons. For more information on this and other yearround Festival events, visit the festival website at http://www.pcmusicfestival.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 14: 7:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from luke.immure.com (luke.immure.com [207.8.42.74]) by hub.freebsd.org (Postfix) with ESMTP id C49E337B400 for ; Thu, 11 Jan 2001 14:06:57 -0800 (PST) Received: (from bob@localhost) by luke.immure.com (8.11.1/8.11.1) id f0BM6r017710; Thu, 11 Jan 2001 16:06:53 -0600 (CST) (envelope-from bob) Date: Thu, 11 Jan 2001 16:06:53 -0600 From: Bob Willcox To: "Andresen,Jason R." Cc: Alfred Perlstein , hackers list Subject: Re: FreeBSD boot manager, where is latest version? Message-ID: <20010111160653.A16818@luke.immure.com> Reply-To: Bob Willcox References: <20010111135851.A16078@luke.immure.com> <20010111120332.D7240@fw.wintelcom.net> <3A5E1A3E.5A17AF9E@mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5E1A3E.5A17AF9E@mitre.org>; from jandrese@mitre.org on Thu, Jan 11, 2001 at 03:40:30PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, ob-bs didn't work either. I went to the referenced site for XOSL and it certainly looked interesting...but was way more than I was looking for at this time (I was happy with the default FreeBSD installed boot manager before W98 trashed it and I certainly didn't want to create partion for it...which seemed to be required). On the XOSL web site I found a refernence to the "Ranish Partition Manager" which I wound up installing and it worked for me. :-) Thanks, Bob On Thu, Jan 11, 2001 at 03:40:30PM -0500, Andresen,Jason R. wrote: > You might also try xosl (http://www.xosl.org), which has a lot of > addtional features over both os-bs and booteasy, including an optional > partition manager. It is also being maintained currently, unlike > both Booteasy and OS-BS. > > Alfred Perlstein wrote: > > > > * Bob Willcox [010111 12:00] wrote: > > > Hi All, > > > > > > I installed FreeBSD 4.2-Release on the last 10GB of a 25GB disk. > > > Later I then installed W98SE on the first 15GB of the same disk. > > > Unfortunately, Winblows replaced the boot program (FreeBSD's boot > > > manager) with its own program. I now need to restore the FreeBSD boot > > > manager (preferably w/o re-installing FreeBSD) on the disk. > > > > Hmm, no guarantees but you may have luck with OS-BS, it's a bit nicer > > looking than the FreeBSD multi boot program: > > > > ftp://ftp.freebsd.org/pub/FreeBSD/tools/osbs135.exe > > -- > _ _ _ ___ ____ ___ ______________________________________ > / \/ \ | ||_ _|| _ \|___| | Jason Andresen -- jandrese@mitre.org > / /\/\ \ | | | | | |/ /|_|_ | Views expressed may not reflect those > /_/ \_\|_| |_| |_|\_\|___| | of the Mitre Corporation. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Bob Willcox There's a long-standing bug relating to the x86 bob@VIEO.com architecture that allows you to install Windows. Austin, TX -- Matthew D. Fuller To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 15: 3:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 885ED37B402 for ; Thu, 11 Jan 2001 15:03:21 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id PAA44943; Thu, 11 Jan 2001 15:03:20 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f0BN3Ij76810; Thu, 11 Jan 2001 15:03:18 -0800 (PST) (envelope-from obrien) Date: Thu, 11 Jan 2001 15:03:18 -0800 From: "David O'Brien" To: Bob Willcox Cc: hackers@freebsd.org Subject: Re: FreeBSD boot manager, where is latest version? Message-ID: <20010111150318.A76759@dragon.nuxi.com> Reply-To: hackers@freebsd.org References: <20010111135851.A16078@luke.immure.com> <20010111120332.D7240@fw.wintelcom.net> <3A5E1A3E.5A17AF9E@mitre.org> <20010111160653.A16818@luke.immure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010111160653.A16818@luke.immure.com>; from bob@immure.com on Thu, Jan 11, 2001 at 04:06:53PM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 11, 2001 at 04:06:53PM -0600, Bob Willcox wrote: > Well, ob-bs didn't work either. I went to the referenced site for The 1.35 version doesn't for me either. Can you the the "2.08 beta" version? Also at ftp://ftp.freebsd.org/pub/FreeBSD/tools/. BTW, you can get the old F1/F2/etc.. thing back by using ?booteasy? also in ftp://ftp.freebsd.org/pub/FreeBSD/tools/. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 15:18:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 50EE237B400 for ; Thu, 11 Jan 2001 15:18:33 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id PAA45015; Thu, 11 Jan 2001 15:18:31 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f0BNIU278196; Thu, 11 Jan 2001 15:18:30 -0800 (PST) (envelope-from obrien) Date: Thu, 11 Jan 2001 15:18:30 -0800 From: "David O'Brien" To: Brooks Davis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting default hostname to localhost Message-ID: <20010111151829.B76759@dragon.nuxi.com> Reply-To: freebsd-hackers@FreeBSD.ORG References: <20010110213538.A668@cae88-102-101.sc.rr.com> <20010111102525.B28915@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010111102525.B28915@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Thu, Jan 11, 2001 at 10:25:25AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 11, 2001 at 10:25:25AM -0800, Brooks Davis wrote: > I submitted one possiable solution to this problem in PR:conf/18583 > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18583 Have you submitted this back to the ISC? > Other solutions include just letting DHCP smash the hostname all the > time or having a variable like dhcp_override_hostname in rc.conf. While The ISC's dhclient mailing list would be the right place to discuss this and find a good fix. > I understand the concern that we don't want to maintain out own dhcp > version, dhclient-script isn't on the vendor branch anyway. So? Do you not understand the maintance headache this creates? -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 16: 2:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from luke.immure.com (luke.immure.com [207.8.42.74]) by hub.freebsd.org (Postfix) with ESMTP id CF18237B69D for ; Thu, 11 Jan 2001 16:02:12 -0800 (PST) Received: (from bob@localhost) by luke.immure.com (8.11.1/8.11.1) id f0C02CK19409 for hackers@freebsd.org; Thu, 11 Jan 2001 18:02:12 -0600 (CST) (envelope-from bob) Date: Thu, 11 Jan 2001 18:02:12 -0600 From: Bob Willcox To: hackers@freebsd.org Subject: Re: FreeBSD boot manager, where is latest version? Message-ID: <20010111180212.A19337@luke.immure.com> Reply-To: Bob Willcox References: <20010111135851.A16078@luke.immure.com> <20010111120332.D7240@fw.wintelcom.net> <3A5E1A3E.5A17AF9E@mitre.org> <20010111160653.A16818@luke.immure.com> <20010111150318.A76759@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010111150318.A76759@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Thu, Jan 11, 2001 at 03:03:18PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 11, 2001 at 03:03:18PM -0800, David O'Brien wrote: > On Thu, Jan 11, 2001 at 04:06:53PM -0600, Bob Willcox wrote: > > Well, ob-bs didn't work either. I went to the referenced site for > > The 1.35 version doesn't for me either. Can you the the "2.08 beta" > version? Also at ftp://ftp.freebsd.org/pub/FreeBSD/tools/. BTW, you can > get the old F1/F2/etc.. thing back by using ?booteasy? also in > ftp://ftp.freebsd.org/pub/FreeBSD/tools/. No, the os-bs that I tried was "2.08 beta". Also, the version of the standard FreeBSD boot manager at the above url appears to be the older one that doesn't work either (same timestamps and sizes). I suspect that the problem is that the older boot managers can't boot partitions beyond 8GB on the disk. Bob -- Bob Willcox There's a long-standing bug relating to the x86 bob@VIEO.com architecture that allows you to install Windows. Austin, TX -- Matthew D. Fuller To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 17: 2:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id CC82137B402 for ; Thu, 11 Jan 2001 17:02:32 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f0C0x2s21884; Thu, 11 Jan 2001 19:59:02 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200101120059.f0C0x2s21884@hda.hda.com> Subject: Re: pthread_attr_setschedparam, mozilla, and PTHREAD_MAX_PRIORITY In-Reply-To: from Daniel Eischen at "Jan 10, 2001 11:59:57 pm" To: Daniel Eischen Date: Thu, 11 Jan 2001 19:57:46 -0500 (EST) Cc: Peter Haight , freebsd-hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > As far as I read the POSIX spec, this is not exported. I'll have a look > at it again when I get the chance. Look at 13.4.1, in particular where it says the meaning of the priority value is the same as in section 13.2. I guess that means it should be in the range of sched_getpriority_min() and sched_getpriority_max(). Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 18:29:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.hiwaay.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 6D83A37B401 for ; Thu, 11 Jan 2001 18:29:07 -0800 (PST) Received: from bonsai.knology.net (user-24-214-88-8.knology.net [24.214.88.8]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id f0C2T1o09487 for ; Thu, 11 Jan 2001 20:29:01 -0600 (CST) Received: (from steve@localhost) by bonsai.knology.net (8.11.1/8.11.1) id f0C2SvK60780 for hackers@freebsd.org; Thu, 11 Jan 2001 20:28:57 -0600 (CST) (envelope-from steve) Date: Thu, 11 Jan 2001 20:28:56 -0600 From: Steve Price To: hackers@freebsd.org Subject: synchronous IO Message-ID: <20010111202855.Y36120@bonsai.knology.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What are the secrets to doing synchronous IO with FreeBSD? I have this application that I'm writing where I need to play a WAV file but I need to make sure all the bits are sent on there way before I move on. The WAV file is being played through a controller that I have to toggle some bits via a serial port to get the WAV file through. Without doing a sleep(3) and praying that IO is complete is there another way? I'm pretty sure what I need is the equivalent of O_SYNC in SVR4, but I think I'm drain-bamaged (sic) because I haven't found the equivalent in BSD. Thanks in advance. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 18:43:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from reddog.yi.org (cg632877-a.adubn1.nj.home.com [24.12.124.217]) by hub.freebsd.org (Postfix) with ESMTP id 2A1E337B400 for ; Thu, 11 Jan 2001 18:43:27 -0800 (PST) Received: by reddog.yi.org (Postfix, from userid 1001) id CAD74D250; Thu, 11 Jan 2001 21:46:07 -0500 (EST) Date: Thu, 11 Jan 2001 21:46:07 -0500 From: spectre To: Zhiui Zhang Cc: John Polstra , hackers@freebsd.org Subject: Re: Process virtual memory question Message-ID: <20010111214607.A5230@reddog.yi.org> References: <200101111742.f0BHgMt10004@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Lime V3.141 In-Reply-To: ; from zzhang@cs.binghamton.edu on Thu, Jan 11, 2001 at 02:03:27PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Thanks. It just occurs to me that Linux kernel used to have something > like this in routine BUG(): > > * ((char *) 0) = 0; > > It is called when there is a kernel bug. So address 0 should not be > mapped writable, otherwise all C statements " char * p = NULL; * p = > value; " would be legal. > > The book "Unix Internals - A Practical Approach" by S.D. Pate has a figure > showing in ELF format, the stack lies BELOW the code segment and grows > downwards. This might have something to do with code starting from > 0x8048000. > Also remember that for CPUs with virtually indexed caches, base addresses for text, data, and stack matter a great deal. Perhaps this is a remanence? For reference, see: "UNIX Systems for Modern Architectures" by Curt Schimmel, chapter 7. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 19:45:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id B4D4E37B400 for ; Thu, 11 Jan 2001 19:44:52 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f0C3inL28097; Thu, 11 Jan 2001 21:44:49 -0600 (CST) (envelope-from dan) Date: Thu, 11 Jan 2001 21:44:49 -0600 From: Dan Nelson To: Steve Price Cc: hackers@FreeBSD.ORG Subject: Re: synchronous IO Message-ID: <20010111214449.A26983@dan.emsphone.com> References: <20010111202855.Y36120@bonsai.knology.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: <20010111202855.Y36120@bonsai.knology.net>; from "Steve Price" on Thu Jan 11 20:28:56 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jan 11), Steve Price said: > What are the secrets to doing synchronous IO with FreeBSD? I have > this application that I'm writing where I need to play a WAV file but > I need to make sure all the bits are sent on there way before I move > on. The WAV file is being played through a controller that I have to > toggle some bits via a serial port to get the WAV file through. > Without doing a sleep(3) and praying that IO is complete is there > another way? I'm pretty sure what I need is the equivalent of O_SYNC > in SVR4, but I think I'm drain-bamaged (sic) because I haven't found > the equivalent in BSD. I don't think you really mean synchronous IO; All you need is some buffering. If the toggling you're talking about is direct wave generation (i.e. you have to do something for each byte in the sample), your time restrictions are probably tight enough that you'll want multiple buffers, filled by one process and drained by another one. You mmap() some shared buffer space, fork your process into two, and send buffer status messages over a pipe connecting the two. Process 1: read a block of data from input file, fill an empty buffer, send the buffer address over the pipe, repeat. Process 2: read a full buffer, toggle buffer through the serial port, send the address of the buffer back over the pipe for reuse. This ensures that the only operations P2 does apart from waveform generation are a select, two reads, and a write every sizeof(buffer). You could even toss the pipe and use another bit of shared memory to keep track of buffer usage. If, on the other hand, the toggling merely tells the controller to play a sample that you have already stored in the device's memory, then you presumably have looser timing requirements and can get away with having one process drain and fill the buffers as appropriate. This is similar to how the kernel's soundcard drivers work; most soundcards read system memory directly and signal the kernel via interrupts when its buffers are getting empty. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 20:16: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail2.iadfw.net (mail2.iadfw.net [206.66.12.234]) by hub.freebsd.org (Postfix) with SMTP id 1DDFE37B401 for ; Thu, 11 Jan 2001 20:15:46 -0800 (PST) Received: from Jason from [64.31.207.237] by mail2.iadfw.net (/\##/\ Smail3.1.30.16 #30.27) with smtp for sender: id ; Thu, 11 Jan 2001 21:56:31 -0600 (CST) Message-ID: <00a701c07c4c$61db61e0$edcf1f40@pdq.net> From: "Jason Smethers" To: Subject: Mutexs: checking for initialization Date: Thu, 11 Jan 2001 22:01:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got some kernel code that passes untrusted data containing mutic. I'd like to be able to check if the mutic have been initialized and return an error if they haven't. As of now I don't see a standard way of checking for initialization. I'd like to do it this way to abstract out the way things are locked, and in FreeBSD's case the mutex's description. I known I can do this other ways, but it'd be nice if there was a standard way to check for this. Just a thought, or else I'd have a diff =O. Thanks - Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 21:49:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcs113.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 2B38837B401 for ; Thu, 11 Jan 2001 21:49:19 -0800 (PST) Received: from localhost (pmk@localhost) by pcs113.sasi.com (8.9.3/8.9.3) with ESMTP id LAA01879; Fri, 12 Jan 2001 11:18:53 +0530 X-Authentication-Warning: pcs113.sasi.com: pmk owned process doing -bs Date: Fri, 12 Jan 2001 11:18:53 +0530 (IST) From: Mohana Krishna Penumetcha To: Julian Elischer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kernel debugging!!! In-Reply-To: <3A5DCFE0.D52CD8E6@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 11 Jan 2001, Julian Elischer wrote: > Mohana Krishna Penumetcha wrote: > > > > > * Mohana Krishna Penumetcha [010111 03:08] wrote: > > > > > > > > > > > > > Afaik, on i386 you have ~4k of kernel stack, however you have to > > > > > realize that driver entry can come from an interrupt generated when > > > > > the stack is already nearly exhausted. I'm not really that much > > > > > of a driver programmer, but I've heard of people facing this problem > > > > > before, solutions varied, but since each driver instance is single > > > > > threaded you can pre-allocate via malloc (i think) the space you > > > > > need and attach it to the per-driver data structure (softc afaik). > > > > > > > > i am confused between the kernel stack in kernel space (where ISRs > > > > are called) and kernel stack each process has. the UPAGES constant > > > > defines the size of process kernel stack. does it define kernel stack in > > > > kernel space also?? (fig 3.1, page 51, BSD book) > > > > > > > > BTW, memory for softc is allocated from the heap in newbus > > > > architecture. > > > > > > I'm pretty sure interrupts are piggybacked on the user-kernel-stack. > > > > > > > this is o.k. when the system is up and running. but what about > > boot-up time when there is no process, is there any stack meant for > > this? > > > There is always a stack for you..(there is an idle stack for just this case). that means this idle stack is used during boot up time. and what will kernel do when there is no curproc i.e. all processes are in sleep/waitng for some event?? can you give me some pointers?? BTW, i need some pointers about how to use the information given by DDB, basically instruction,stack, base pointers, registers etc. in our case DDB is n't showing any stack trace. it is printing a stack trace which either starts from one on its internal routines or from trap. thanks, mohan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 22:52:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id 799F037B400 for ; Thu, 11 Jan 2001 22:52:08 -0800 (PST) Received: (qmail 4299 invoked by uid 1020); 12 Jan 2001 06:48:34 -0000 Date: Thu, 11 Jan 2001 22:48:34 -0800 (PST) From: Jon Simola X-Sender: jon@newmail.netbistro.com Reply-To: Jon Simola To: Nick Hibma Cc: FreeBSD Hackers Mailing List Subject: Re: Broken-by-design USB device? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 8 Jan 2001, Nick Hibma wrote: > Just as a note on the side, the fact that the attach of the generic > driver fails (while setting config 0, which is a sort of a soft > reset) could indicate that there is something fishy going on with > respect to fetching the report descriptor. I seems to freeze. I'd still bet on the hardware being suspect. It's got all the prime labelling of a quality product: "PS-PC USB Converter" "Full Colors" "Special Design, Extra Stable & Highly Compatibility" > And now back to your scheduled 'panic' demolition: > > It still bombs in the middle of DEVOPMETH in: > > device_probe_t *m = (device_probe_t *) DEVOPMETH(dev, device_probe); > > which is > > #define DEVOPMETH(DEV, OP) \ > ((DEVOPDESC(OP)->offset >= DEVOPS(DEV)->maxoffset) \ > ? DEVOPDESC(OP)->deflt \ > : DEVOPS(DEV)->methods[DEVOPDESC(OP)->offset]) > > while executing > > 56: 3b 02 cmp (%edx),%eax > > with edx == dev->ops and eax == device_probe_ops->offset (don't you hate > i386 assembler syntax?) and edx apparently being 0. > > Which as far as I can see is impossible in the subr_bus.c code. So that > leaves 'memory spamming' as the only option :-( Apart from that, I have > no clue which driver tries to attach after the > ugen driver is finished. Because that is the last driver that makes an > attempt. > > Could you do the following: Boot the machine and when it panics type the > following commands: > > show registers db> show registers cs 0x8 ds 0xc0a20010 es 0xc0150010 await+0xe4 fs 0xc0300010 ss 0x10 eax 0x9 ecx 0xc0d32400 edx 0 ebx 0x6 esp 0xc030b920 ebp 0xc030b920 esi 0xc0a227b0 edi 0xc0d32400 eip 0xc011d58a DEVICE_PROBE+0xe efl 0x90282 > x/x $ecx,0x20 db> x/x $ecx,0x20 0xc0d32400: 0 0 0 0 0xc0d32410: 0 0 0 c0d2ac40 0xc0d32420: 0 c0a22040 0 0 0xc0d32430: 0 0 0 0 0xc0d32440: 0 0 0 0 0xc0d32450: 0 0 0 0 0xc0d32460: 0 0 0 0 0xc0d32470: 0 0 0 0 > x/c *($ecx+0x24),0x10 db> x/c *($ecx+0x24),0x10 0xc0a22040: uhid0\000\000\000\000\000\000\000\000\000\000\000 > which will print three things: the contents of all registers (show > registers), then the 32 longs at address $ecx (x/x $ecx,20), basically > the contents of the struct device in DEVICE_PROBE, in which the 6th > element (at +0x14) should be zero. And then the string that is pointed > to by the nameunit element in the struct device. This last one should > give us a hint at which device is failing. > > Never mind if the last one gives you a page fault. nameunit might be > zero. > > I really am at a loss what this could be :( If I'm following you, the info above will just prove that something is too broken to figure out. If I can find another one of these things I'll just mail it to you. Other than that, I'll stop wasting your time :) Thank you very much for the help. --- Jon Simola | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 23:15:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay3.sion.com (unknown [200.43.36.250]) by hub.freebsd.org (Postfix) with ESMTP id A4B4737B400; Thu, 11 Jan 2001 23:10:43 -0800 (PST) Received: from localhost (ol184-58.fibertel.com.ar [24.232.58.184]) by relay3.sion.com (8.9.3/8.9.3) with ESMTP id EAA25847; Fri, 12 Jan 2001 04:00:53 -0300 Message-Id: <200101120700.EAA25847@relay3.sion.com> X-Sender: info@globbalcomm.com From: "info@globbalcomm.com" To: "Paq1-1" Date: Fri, 12 Jan 2001 04:01:07 -0300 Subject: Image Communications Inc.. MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_001__16659973_14467,92" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a Multipart MIME message. ------=_NextPart_000_001__16659973_14467,92 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002__16659973_14467,92" ------=_NextPart_001_002__16659973_14467,92 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_001_002__16659973_14467,92 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iIzAwMDAwMCIgbGVm dG1hcmdpbj0iMCIgdG9wbWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0 PSIwIj4NCjxkaXYgaWQ9IkxheWVyMSIgc3R5bGU9InBvc2l0aW9uOmFic29sdXRlOyBsZWZ0 OjBweDsgdG9wOjBweDsgd2lkdGg6MjIwcHg7IGhlaWdodDo4MnB4OyB6LWluZGV4OjEiPjxp bWcgc3JjPSJjaWQ6MTY2NTk5NzMyOTE2QGFsdG8uanBnIiB3aWR0aD0iNzc4IiBoZWlnaHQ9 IjIwNSI+PC9kaXY+DQo8ZGl2IGlkPSJMYXllcjIiIHN0eWxlPSJwb3NpdGlvbjphYnNvbHV0 ZTsgbGVmdDo4cHg7IHRvcDoxOXB4OyB3aWR0aDoyNTZweDsgaGVpZ2h0OjIwcHg7IHotaW5k ZXg6MiI+PGltZyBzcmM9ImNpZDoxNjY1OTk3ODc3ODZAdGV4dG9hcnJpYmEuZ2lmIiB3aWR0 aD0iMzQzIiBoZWlnaHQ9IjI5Ij48L2Rpdj4NCjxkaXYgaWQ9IkxheWVyMyIgc3R5bGU9InBv c2l0aW9uOmFic29sdXRlOyBsZWZ0OjBweDsgdG9wOjIwN3B4OyB3aWR0aDoyMzBweDsgaGVp Z2h0OjMzcHg7IHotaW5kZXg6MyI+PGltZyBzcmM9ImNpZDoxNjY1OTk3ODE0NTdAYmFqby5n aWYiIHdpZHRoPSI3NzgiIGhlaWdodD0iMTczIj48L2Rpdj4NCjxkaXYgaWQ9IkxheWVyNCIg c3R5bGU9InBvc2l0aW9uOmFic29sdXRlOyBsZWZ0OjU0NXB4OyB0b3A6MzQ4cHg7IHdpZHRo OjE3NnB4OyBoZWlnaHQ6MjVweDsgei1pbmRleDo0Ij48aW1nIHNyYz0iY2lkOjE2NjU5OTc4 MjA0NDVAd3cuZ2lmIiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjI5IiB1c2VtYXA9IiNNYXAiIGJv cmRlcj0iMCI+PG1hcCBuYW1lPSJNYXAiPjxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9IjYs MiwxNzIsMjMiIGhyZWY9Im1haWx0bzpsZW9uYXJkb0BpbWFnZWNvbW0uY29tIj48YXJlYSBz aGFwZT0icmVjdCIgY29vcmRzPSIxNCw3LDE1LDE5IiBocmVmPSIjIj48YXJlYSBzaGFwZT0i cmVjdCIgY29vcmRzPSI4OCwyNCw4OSwzOCIgaHJlZj0iIyI+PC9tYXA+PC9kaXY+DQo8ZGl2 IGlkPSJMYXllcjUiIHN0eWxlPSJwb3NpdGlvbjphYnNvbHV0ZTsgbGVmdDozMDhweDsgdG9w OjM0OHB4OyB3aWR0aDoxNTRweDsgaGVpZ2h0OjFweDsgei1pbmRleDo1Ij48aW1nIHNyYz0i Y2lkOjE2NjU5OTc4MjA0NDVAd3cuZ2lmIiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjI5IiB1c2Vt YXA9IiNNYXAyIiBib3JkZXI9IjAiPjxtYXAgbmFtZT0iTWFwMiI+PGFyZWEgc2hhcGU9InJl Y3QiIGNvb3Jkcz0iNSwzLDE3NSwyNCIgaHJlZj0iaHR0cDovL3d3dy5pbWFnZWNvbW0uY29t L2ltYWdlMi5odG1sIj48L21hcD48L2Rpdj4NCjxkaXYgaWQ9IkxheWVyNiIgc3R5bGU9InBv c2l0aW9uOmFic29sdXRlOyBsZWZ0OjY3cHg7IHRvcDozNDlweDsgd2lkdGg6MTU2cHg7IGhl aWdodDoxN3B4OyB6LWluZGV4OjYiPjxpbWcgc3JjPSJjaWQ6MTY2NTk5NzgyMDQ0NUB3dy5n aWYiIHdpZHRoPSIxODAiIGhlaWdodD0iMzAiIHVzZW1hcD0iI01hcDMiIGJvcmRlcj0iMCI+ PG1hcCBuYW1lPSJNYXAzIj48YXJlYSBzaGFwZT0icmVjdCIgY29vcmRzPSI3LDQsMTc2LDI1 IiBocmVmPSJodHRwOi8vd3d3LmltYWdlY29tbS5jb20iPjwvbWFwPjwvZGl2Pg0KPGltZyBz cmM9ImNpZDoxNjY1OTk3ODIwNDQ1QHd3LmdpZiIgd2lkdGg9IjE4MCIgaGVpZ2h0PSIxOCI+ PGltZyBzcmM9ImNpZDoxNjY1OTk3ODIwNDQ1QHd3LmdpZiIgd2lkdGg9IjE4MCIgaGVpZ2h0 PSIxOCI+PGltZyBzcmM9ImNpZDoxNjY1OTk3ODIwNDQ1QHd3LmdpZiIgd2lkdGg9IjE4MCIg aGVpZ2h0PSIxOCI+PGltZyBzcmM9Im1haWwuZ2lmIiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjE4 Ij4gDQo8L2JvZHk+DQo8L2h0bWw+DQo= ------=_NextPart_001_002__16659973_14467,92-- ------=_NextPart_000_001__16659973_14467,92 Content-Type: image/jpeg; name="alto.jpg" Content-Transfer-Encoding: base64 Content-ID: <166599732916@alto.jpg> /9j/4AAQSkZJRgABAQEA3ADcAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wgAR CADSAwoDASIAAhEBAxEB/8QAGgAAAgMBAQAAAAAAAAAAAAAAAgMAAQQFBv/EABkBAAMBAQEA AAAAAAAAAAAAAAABAgMEBf/aAAwDAQACEAMQAAABqPX28i4cAKdQKjREEKMGyoBhUFS4OpcF VFQVJAqijAo4AQqCqODCHQDCgDRwAhwa4ygCHSYUcGEb2s74J+qPLTx4+w51Lz9bcu2a4VUV RQBhUFS4FVdjGXAqioJV2AwqTqXAGXE6lxFSzTXGigLLWnhne15vy09NmDhT0Jp+brucqkiF VKqumXVwJLgu6vSusE04GqaqwYSYmSnMDK0yBC9lBjpq6mpdMlXAqXAqXQVRQKoqCoUAYVBV FAGXAqXAqrodS2Klada+bfoaOft5tio8gayyuBnH7A6R5EdebtwGilSMuDGXYDLgDCgxhUFU VIqXBjLiKl2qvpaH8ujdON2NvXZtY8/WxBk2cnXnr0WZ81Zlq5G6a38xme55ifUu1jxtdXmb SFFKKksXftUrBgywqmLABaTWcyjAFgCqSMqSglXBVLgVLgVVxlSQJV0EkgSXQSSgkkCqKAMK h1syMz06WnDs83tRn6uQbspbhczbMyOgeXRpHM5PrOb048Knr6MlwqYMPdnpl1Vo5N70RiBx 9G6Xlw7vH68Uy6tVJETo5etz62tNcXRtdh1OXmg2tFCVzy9o7Irmc7bgLLG/IGjdlfN9TTi2 Xhm876rmbxxqOt5GXGvQrdFkgdS2k2NUmkopcs2xeRe6hYa1ruUU0LgZcZUugkkCpcCiGwYS aTICjQQoAUwRDCjYwogYVBNuTqYbjoIuLpuDyw1PByZmF3BSrEdVdLHwvUcfaOWLS6MwI9Hm 9yOgOlFKdwbjVvz7M7apda58IfT8frw58KtY6cWvzusaXeW+ndl1vJrQbcXgDPN9R/Oe5esz pUDo1iY8087jjWPZlbL4WLoYOzMZcqe6dWZSRWduWEi7mbNNdGZm5WZAKegs5j0RLApWm9M+ dXQy9XOmFNcwhQQwrGFNIERlAFHBBCsYU0gTDpoIdAT8x8vTs18zo8nSnMzRLJwlpBVLENxY MJCk2cqlbwbkMw1ZoQyXowNa1g6DWsRw2rWm/bg2KNXF6/C68M1FOrDdTw4Orn20cdtmvnvc b7xPE6hukImtDrVAdaSA7VTNBIIT4sqnFxfUZNV56mDtHbgm8w5e1fJ0wkTO9HE6amYelx1O fRn57an1Ig5bjAgY1DAeWdloUbb1y503p3xyxkuVxhAm3ti1vAufdin85GolvDMOurjGrq1S 5g6k65kdJ4uvY/O+KZKtzd1Gqzly1WjGpusCLB2zY/M7h6imeh625NRL2Idc35/0oMzu5z5r RwO/y+nDn3J14dnM1Xm9mZZrjUtOXUk0xa5OwY5pblMkGpZioQczLYbjyvqTNZtMsY1xcHQw defZtZvLn10svL0wgmdvWDmua1ucG5ugTXGDu01g1kU0wlsArAkMsLBpKYFodLjJeoOjIMu3 l8/Rpdyt2WnQ5u57nj71gO09PzRXdPh9VLaBHpllx9BKpOzn6s71mDLzkJFLnczRjjToXD9H gCjlLLCV5npCYsitOwdV5ATcLT6XqDlaxyqt3Mbm0hVdTJ04DpwhlpoQdcvULQJGjVkuo1nj YTqTCazieZVYAJWgs2hJ7UG51GptyYzj6QgJXXl3KGTOC9ePm3e7A3PTTzmc4TdIEq0EhyDM LEdgTKaAgw0EDbSxNlgEvWWZzlkh3OenItcs9mTHbe7G1zzOpSytyRc4yo6Jj5XQ0mLg9MQV bOd0+e5c7HpTdl0ZHPHxPQtnd7zXWeXQpyXnjw6ss709L4vY7NorPZow7dM+Y6hm8OT0/AbZ zu41HLvNc2E19bTLgr9XjHxIRY6rsrET0G5curFlDQkoLODhgxyxydjgrHlb5HmuurGpca2y 5jUYtibE5759+HuzOY9qH56mQMQdjYiMIDJUcidCF2FzTLBoW4DaYxJ1LFlBck65S16bsL5e iBCTvMkfTZznC6DcTbnSWc6nRSja59bfOZ67uYsFpY0FBQFk9yuCdZ9Ak3nsy0LDra+HuU9b dwdd54HNaVejM0l5pOpbVW0nP0KHlfZpc/m+jErzc24ctbNRg9y2uKXsBrnVoJVnY7Q0NZOb vjqDOPRlorPGn0mM7csuXUbqwvJrtPzU9NxlQPQeWrmKtNlgaCJZg01nUlCJyu7sdS7RDowh VGFazSvg9+U/JP7XMmzZxbF2caNKqjC5rS/n2112cZ5PUPn6KnZka+p8av1vi6bgUCblq0PP NrvILo1jKdnrWLlvV4fQT6JqkabnY3kPJZNOJJIaSo0+0206Jtj7VbTMWkg864zy1jbKolWb Wc2sCsrcVxyj6d1HPV1IHHnXazhj6GwSfIxp+gDiKF6KvMQfdTwaDsP4OuNOxeXTFldEnDAw M1tERCTRjBC7AU32mBpPMTWksptaLUTRyrBXO61D8zy/cIT8np3+fpdecDrRemCM6atfKMXZ 08rS46/j+rxNFygMNMG9DmdOX1PL9XnDBue6lwBSDMPTDQ4Tx2tyCz01uw6KnTFtc1dLaMcg zWlmQg2lg1C0XSbnOQyaaxB1LCAmiMIAZ9w1GAOlQuerpwOKXaprkj17DzES5twVQ06HaEZ8 PesPNJ9KDXltvoSDkbdhReNmkU1FSprQWMw0kggdFEFjcCEETYecmtB5yDTaCpNpJIZSzGSm QXkcHvuTpHMMDy6ahChl501J5aVeawOrxGFAGM0jxRgiCFYCV9dOdTnKiw3Yco+4znty26De ZYugrCLNoZonsHK8evZj1kacW3jaRotL5BKUxhUImXdtMipUlQpDVWawKltTtbBDivx9PSMu HuqT5Hc0tBEMZfJ17BCiaYJjaBdioCrGQ3ytYZDcxCV6VjzFqGWo5KRC6AlkYiSG0mziYVZA uMsazKBn53ZgecX6LKr4Wb0janx09jsrPy9erWHlD9RJrz/Q6a2KHRSWXndu2eVT6ww8n0O2 9Hma9XVz45Pt4n4pvrVzflg76lXFX6YmvNdDq6UcrRCQ/wA922tY3GtGss76mCwAgsJpFOpi FtQmVA6QWVGKzbwY+SVCwkliUg2LkRm0SD045Ba88jGSQMZSD01I1m0yS6CRGpcjC4ck33Rk cmUjSnSMipEW+RgMkClSBWiRDBkahSAuSDTmkT5eqTPTsXJplMckssUjOhcgE+Sps5GhuRlh IClSRVMkZj2SSDgkBmmQdLkaauSXokmk0qRPSuRzfmZHWXqSZ3sOQiDJa//EACwQAAICAQQC AQMEAgMBAAAAAAABAhEDBBASIRMxIBQyQQUVIkAwMyNCUEX/2gAIAQEAAQUCorev/KUWzxyK /wDSdbVt7OJx/vUV81G3i0+OAui2SjGanooSMmnnjK/tKLOLKKIaeczHosR9Jph6LCx6Cn9H iPosDJ/p7J45Qf8Aga+NnRxHA4lHjPGyv72LDzcMeOJ0UXv7NRpqVf1knJ49IQxYkroux4sc h6XGNtPyMjKxM/CmhNFmsjzXhyDi1872qytrLOQpl3tyOZ0yVf24xcn9Mknk8Sx5oyF6M3Uo yFLZ9rJHjP8AqJGHGsUeQixPfU4+SXuLF2ZNQkRk7gyWeMBTcnH00pLVafx/JM5bUcRordfC /wC5i6UJ2dNT0sJFzg4WajmpQkJ2LbUYGNfOOGchaVCwYkLFiPp8EjJoBxp/LT4iUxTE1shb SSlGELax96qXEo5pE80riiDISLNV/o/ycTj/AODFkMTQoiRnxu4ZSMrMmGEjwZCMJRFtm01j VfBK3HjjHkbIPZFqJHJZqcEskpQcX8MUOcrUU5FikI9sTJSUYwQjV/7WUT6yREu4dJDUchn0 dFfDgjgU0WWXvZ0Nf0FR0cSv8mGBfaYmOaTcYWvnmwrIpRp7R62jGxR6SM2ZYYx5TcSJqYxl jfwwKscmNiYvaZHZEsvLIrORKMZn0+M8UB4sbHpYihQl2+oY5CZqVWbe92rOO1i7FFFQP4M8 cDxHikcWv7SFLgKVnFFUQtkeyhbX8dUlyFCyjxkcdJIlOONZH5MmI6R5rOPMWPE1qcKxT2wO 4ykNiIRI9pIo1E8jShJCbSi+kWX8niZA1f8Au3XwpnBnAcq25FsTdXsirPHEeIr+tH7skv5Q l0mZ59RiIXwsssnkoyz5NIsQtssckiGldxxKJN44RcnOWJiPRqcinPbTRMsR+kR6Ill9UOI0 ltW1lll7Xvn0/lcoOD+LmeQsyt0s8WcuvwWcqL7s5b8bJRr5Vt0NfGijgV8XciBGq485KJXy slkolPk/zdkUIuhtsQh+s2NqaVuGFEYJHFSWWHCe2Jccc+xwVJK0J0chS65HIbLLLRaLL2TL 7vfPi8kX18JW1bjJMsvrPjalDPRHIKVn4vrsss72Wzxji1/g4kcNnigeHGPDEWE8Y8bPFY8T RxOB6KOVqPXyZKRLJ05ct4iPTZYhSEyUIzU1kxaqEr2lPipy5SF7/Et0X0vVsj2IZyLL25Uc qOVlCRfw1UaybyzxTfHIeKSOM0WT/wCSM4UfziLUSRj1cGRywOSLosuhSL3scIseNlbUcTif aWWI81ZlMTMkqjGYmOCYxi+1fdEXxnInkPvdbMiL0325Ee9khFDxqRkz8csU5CRqcajLZPlG Q12/4s5C9HGhbUdFpF2Ns7qIpHssW+qleQtbZIcWpIssVGTFGY+WJrxs8WNk9DjmL9NHo9RE 8DcYQjFLa+k9kyyx0xw3RLIxZLOQmavG+WHJcIzizUy/48edHliRy8ikPGmKBJVKMiL+D9ZZ l21Gl8Ob3jYkIckjyzPKzgvL9os8UZsjnLbHPiSJNjPy2RZ+OVFlku3XEcqHI5JnLpNbIXRY jJLhCTtlbXEnjxyPHRxkjyJO0ZsvFYI8d+z8jQiz0Xtfw9DimUhmS077hMTs9mTxoxRHGLjK ln/OJ7yqU5afmcMmIhKxbzMz7UqcZKS3l1LaKsx+kUpE4SxuE0xGph/FMdof3NRJJbLUHK9/ Y6EXbT6Pw5UpSH2xCoRF9077HUVmyPI/g3xlyoUrLH2pN45nITR7Qt2WJnW1lnIT2Q9pQU1O Di4xIIs+myvLDoslghMekiS0UzFHUxFfHDntqZ7T/hOLFtkMvsxz4yWJNeE8JnxuK2RB9cu4 vbNj4Sgma7zLFiyc431KVZYk1/GKc5L9Myym9HnxJFFHESEhdFjkN71shFWRJSWNZczyPeyy UVI8MkLkWzJm4rC3KaaOuP4v/DF/BPZbVY+nNclxcRTEyYmJnI5Cdi2npoTyRwTgJGojUoel tlmkpu3tpM9N5IksjM762QvSIPtGrklHDPrpp6SWCUIvjm00c0FHJCXFswyjBqYpGfCskfhY mUcOnHatvyRVkUTyLGSk5v4eWJ5YnliRkpFxJfyWfmpY+oJFH4RYtr2ZXXZ6OR1shC3lHkll p2WIu9uRz2TEJl7IlFSU1435EjJqCU2/hZgy8o5dTGDu9rIzORCQva9a7nnywi0otli+GTFD IvpaPFkRFSRm01jjKG9ilQpNne3FEltxFEhBGSaiP5eLGcMZ4sYoRiNuMuZqvcH0vfW90e/j RxOO1C2ve9tVj6x5uMrE+rOxyORDIQyCkJ72WTjzjNuEr2sssbPI0Y10WWcjHk75ULKeXlFS oSrZP4Xs2WJ7NJmXTNbpWKLI2j8OJRwsUZISM2sxwPPA8sTyxPJE5xOcTnE4nHdxTJ6dGoxZ EY/tiLve9rELeij8f4H2ajS01OUBZosWQsk090yM6I5RTORyLLNRp/NGSlCVljZZdkmRfXIs s5FkJcoCExPa97LLL+NmbDyKFESaPZUhylXtRRRnU5w/a2L9NZ+3j0Ez6HKfQ5T6HKfRZi9u aOSLOSLRmjxyp7WJ7dJX8ve9/C/hVmTSQmZdC6eGWMWTJEjqYXae9likxTIyExCNXplqMTlR yORyMemz5ieh1MIp0ct7LNPPeLF2JdUX8LLLORZZez48lV8SmkhtFbZJrGvqD6hH1KPqon1M D6vELPjZ5InOIlGBZY5pNOzyRr6zGPU48kYyixe679bdWWIRZZe/Is7OJ0dfKWOM1PRRZk0U h4p43DUSFlj8LEyL6TEyMlWrhHltBpPDnjeTSaaekLFIssshKpRnz3TI+/Z9xW1ikPIc725F 2Im6j0KKOJe62njUzwHgY8DFp0S07PCR059Mz6aRl1XEjqZMlqxapxHqMrcs85p7JtEM9Ecl ikmWWLZbreyyyzkWWX/gljjMzaBSNRhniMeRxI5LW1imRmzmTz9ZZciXvaEdNOOHVywPJw5/ CEXOS/SsPj/adXhOM4bpidl1s2Oqe1l0J2REZmcXXo5Cdbr0UV3tQkjiiiihvCRWnOOnHKJc pNYYslg/i9NKR9HnY8GRFyg8WVNY88J7dI9kfe1nLaiikUi0Wiyyyyyyy9r2njjNavQSxGGf cXtRQpDykpkpD/xehNmPVvCvNLVYeWbA1MUjkKRY8lLn253tdFkEIRll/wAsGMva9qEmXs3t yOY5s5SrnI5TFp5C00+TxRv6REcPEjjhF9I7JTUX/wAchNVUZCjCG3jieAeKcX/NPmk+ViZZ y2o4nEpne1Fbdll7X8NR+n4so8c8T3bJMb+Si2PTZIx4lfDHg0ih5dOxx0hqXhlHHlojOyy2 cizkcjkWR6Iysj2I1eThkxNZY8KPGz8/j+RFDdFtn8i2NtNSluon8onKR9VC1UhzjAnrUYMu TUShi4rgNKpfp+PLPHoceNeCCXjRwQ1RZZyTKoeJTXggRw0eJHjoaP5Cvajo/MlKQoKJViVF FI4n57RZYjJjjli9M4jGMkxsjGU3+1arj+16oegzRcdHmb/bsvLDpeChp9PEyaXTSF+n6Jmb 9N4t6HLX0uUjpsgtBglD9qTP2hn7dqInHU4xZJHNFl7cu45uTjgyyfjeOULHaitPmnqI42hQ nt7OJ0Uxo4o7RZ2dnsSZx6l0uhfpc2Y9Dixj0entabT4iPGOzVuf2qS4c7PRdHKJdtxt5E3C L8GNfymud+lyRRYyjicG3JpC2Tm9rSOqSUToXbfQrZwKW1nCyeCMxaTGS02NEdLCCWPEn+O6 bPRcRdkscm+LS9H5cky+ZQscTxxaUaHFM4lMqyWNE9JhkR0eGJ4aIxHigz8PEnPisahyOpk8 UajEUYxfvaTaEy9ns5RiWj+J6OSKO95D9fl/fMXvJ90Eh+/+34/Mj86gwfaZDKL0if3sZ+f/ AKG35Y/S+2Hr/pH2j8oe69L0/SPy9kZftt88f+xC2y+v+q/2rZfcP4sZL7mP7YfcSSv8w+/J 6X2z6UPth98vUPsl6j7P+z9az7tO2Y2xCF7tn//EACQRAAICAQQDAQEBAQEAAAAAAAABAhEQ AxIgITAxQRMiQDJR/9oACAEDAQE/Af8ANGNn5mwrz0bSjaVxrNlIorzIhpM20IaGh+NRKKI+ xoqySNo1zr/DB0x0KXw7TLTGOOYQcj8kjahxGswjZtGsyZH0PDHmis7GPTZsZXK+elG3hRsf CS+iVkFtVDZasZKI41jT9Yk8JfRrN4dPgo2fkR064UPTiyUNvCuFZ0ZJOhnpcKJf1/KIwUUM XQ5EVQyeNNViiuVYrME17zdey1i8UPTQ4NYojCxaaPzTPzR+Q9Iaoh2h5SNWe3pGhKpDKwyM qGjUXWI+R4i3941xocEzYzTSKLp2eyPaoaGrI/yMePg7vvEXavDYuxo9koWfkzTfx5aKzQ8t 5jNfeFYrFZeU7KG28bpIchuLI+xixKCfZ+cSCpYZJHe0jI3ViUe7Izf3L4schvG0URRQv+vI kvY1iiiiiiPYlhnt8JIvquFsbYpsTvDLLLJMoorKdCffkTo3F/8ApFr5iiij0LUNxKZCf03j kRl3iuFFFHovNjfK0WWKXlTHTN0oohqKWGsKOF2NIss79kZ3h5rFc6KKK40K0bjcX5Kp2hO8 Mcs08pDFOnTxRWWL3wv/AAWWbi+FlllidG8kyiuNY6F16N7N45G5m4svysXgh986F4GLnEef /8QAJREAAgICAgICAwADAAAAAAAAAAECEQMQICESMRMwQEFRBCJC/9oACAECAQE/Afxp5FE+ dizL9id/bZY5JHyo+RHyoU0y/o7LL+/JmSXR5WPoTIyoT+ueX+F2WS7LLEzzoWQTvlf4ORXE 7HH9nUlRTQmQyfpl6nkUPY/8iTPN/wBFkaIyveWddDkJ7SJexDEQa3Ze/kiLLEU4l8q55pUi hyoXDHLuhujJPzlYkU6IkZJMhkUtZr8tLTYt0UK0R3KaR8xLJ5cLFmkiGTy4XwveeLatCPbF uyH+q85E8jmxDYkSYjDV6yu3r0Xp6ssssjPc2m+t1Z4vVaTI5WLInqyU6Hlkz5Wj5mfMLMJ2 ZOpC2zDj8u2Z43Hghq9YX3qXGucfWpJL1wR5F8LI5Gj5EZJWWeyqHpSaJNy0teyNV1qSp1pI Ynesc/FnzxM0f+luy+cI3uWNr6L4LT6FvoUSmiXoQxDyTiuiOXIyTbferIsdeQ4iiUKfVDin 6+hEcdiVa8xzHJj9fZ2+FiZZY1XD1qtRY+xbaQkhxK0itUQiv2Wiy90P0P7KPH+DtbssQ4lH S9nUvR4lElq9Xqyyz3pbRfHsoocfutopMlCuHlepCK10SjXG9WLjRWq5WPso8SvsUrVMa1Ql u+LjfZW60iuFbvfXC+VFFca3WvERZZerLLOy3qitdFar7UP8pcUIZ+uS9j0j/8QANRAAAQIE AwcDAwQBBQEAAAAAAQARAhAhMRIgMAMiMkFRcYFAYZETIzNCUGKhBFJgkrHBov/aAAgBAQAG PwL9usuE/wC32W9vFUlvQgrdoqj1dirT6d1v7Q+FwxHyqYh5XHRVJK/UF9uMHumiDH909lSG VMlVig+PTsF9w+FSCFXlWAfCeGGqrTQDDe9lwH4VR6Sqp6tgq1TMqTByMiPTfyOfEOU7LDDV UTVTO5TyaKEFYobft5ikxCeE4SsJVU94cuMW0LN3W9H8Kzr8YXA3Zfbif2KY5/qG2a8iJiAG VFhD1yn9wcxTxgd5vDulcUK4pvB8ZvfLvFlQLFCAmIbKypNhmeXiYJy70LrFs/j9uxMqzZOB oOL6PUrFHMmK4tlfrlrTK8t6F1QLhTGALcPyuGRmW1Kq0uapFK3q2ndPFpPnqWTiyqnJW4HW /VMdmFu2MzDkoMmGGGmmyomR02lfNaVPV4eepXJUqm1IW8XlUtlpymSc9RO2pihNUxGaiurp wmevRMDJv2IxatU2beTCbFEZLzHo/cZaKpyOCmNF/wCp3VExlZUy00qmVlQq8qytkxDSpnvl YphC8PWfVOc1JVnT01IlYfKsQmCqqKo+ExV1dNo9dKKEzf09M/0tmK8z0VTJxzm6ZXTCs7Se dZdZ1AVPKpyT6LtSVJ9D1TRs3VWC4Fchbu3bwqbYFC8J9iuapoVVND6kCeyumErqkqejpk4F wqjMVfKxtoe0qiXfTJT5LqzLiXI+U0W73V0zOVycypK+S0qalZmDqJVCLIPl4mW9X3Gg40qp 7hVk6vIAqgCtLB0y0Ge2i5XtlYq6vKtQsMNf/E5uuibmr6FJ3z1TFUl7rHtNp4nZUiK+3tWK ba/IkQeIXmRoOIldXT5bK0nFirp4bBAhWTGkqlMEYgQnML9tGues3K9s1Ud7F3VQZmJV9PfJ XPjtF7LjxeJYtDBEaLdqrr3yVyQvJluB4T0TGFdIlhMJkxoZXWIcQ1rSsupTnLdXV1RUld0z 9500q6TR6D52K9pUzYeaww70X/Sc30IfpGkN5XzNHCtzaRDuuIFbyxQfCqG1KyaG+eysFYKi rJ110L6+ILCclFUaTJjnoczGbOmT6lk8FRkoJ1ycKwQxBcQXEuJXV1dXV8lardLKzoBleyt6 Vk4suqu0r6jw8QREVCNUZK62IXldXXMKhlSZggiEL81+QKu0HwuP+lxQr9K/SuXyuH+9BxbJ 0k87+g6LqqOFWqru91TNfLiHHDleCAt1KMUUFB758OS+udHhXCuFWK5qpZcS4ldNDCBNjEJF jZXRxxMOgGSuvfQqFRWW6SE0Svol0SJ78OIdHZYdodpg/jHZbTa7LbbSOKGrE53VMt9C+e8q 5Lq6urqpXVcJVAyurpquni2hHsFu4ou5W7DXqSnxrCTSdFVCqvKvqKhbq3gVemhTL+X6cTWi q6w0wm9HKP03w8nyiGG5Qxf5UI2n9J9jHBGvuQ4TlplvmAZOgfQ/jC/G/lfjCYbPYN7wrDDs tme0KeKHZ9oSmh2ez/t04gwKkFOrrl8y3omWEGqYzv6diHWPZB4P+k2W/oBFSI91FEIdlD7k 1Q+oxhOZk+h7I8xkvq81xBcgOrpvqxHsuM/CYR/0uIq65KsYT4YT4lWEHwqQgdguFcKpEQqE KoXTRtK6vp4tnuRrDGNXGzw9Rmx7T/Jf+MMKww7sP8g63dsYPF0PpxmJlXSfJRUhTBVErZrS qMtkwiTkyoqUC9064mWI7aMpsUTLiiV1zyM9U6uuarE655bzplvNsllhiX+rM0IJKfDD/wAl WADymMBTGHD3TU+U0W0obwovshEh9kDsVaMeV9o4wnEK/HEFXZlPjIi6Km0Pwvz/APytyKEr e2EXhVgiHjM0Afwt6Fu83AdHa7Rh5VNoniiyWZUrO+W0ua/X8Le2oHZfrPlfiHyqbIHvVUA8 Kydlw4lReyAeqqrppRCE15IHaX9ljxP0CtK7TtKyqUIRdPKwEqypKkq0yVEqhG6oKr8YPdMN mB7tJiadEyurqyfF4VMntNmGbhBVdknhB8rdPyFiihTwhu07FOCqgKgPhXKckqkrUnZUlUgF XddFQyor6QpoFBCZUOQ9pHMe+uZCubx6gI6BV1fL/8QAKRAAAwACAgICAgICAwEBAAAAAAER ITFBURBhcYGRoSCxMNHB4fBA8f/aAAgBAQABPyHwQlHBPEJ/KE/zQn84QhP4Qhpmf0NeWj6G 64Gv5TzP8E/+GEIQhCf4aE8oLKGmT+MIT/BCEIQhCE8QhPJCEIQg5SciJNF7CcFi9C7iAQfB Yb308o627Whx/wDRCDaqd9DXtvJnIk7HInpYKc+Yynxb9hH/AAGRLx9kaif3Ji1aHrBjHIEI Qn8XrSM9eUKVoTbaGj0NKRYmaGgcf55/hn8YOz45s0pe2KsTHwe/6MXHgT8NJIia9imKxz0H 4T/DPE/wzBW+EK3D0N63e2JuT8j5M/JsLeQl+wHhVArZYpNiaN1z5jIsGSwJydOgz2JYvlE8 zy/Qb9E6Dk14UUdhI0JSC6glCEJ/ghP8j8raMs2avRvZJehKqG7CeD5QMiZ2FoiY3J6gY0Tz CfxnmE8QhCFHEUD9noy4wPM6foVLZRF9iZlLKZ8TFvHoxX9jmRyzUkr9if7hfHRRarWOuTpG h9oS0c+OiEIQgggqfBl4JIIQrgbZSleMT/54QhNjOj2TQDXTGlXr0KiZRdcBUZaVwtCXl/kU gmNiSFm8rb9eBohCEIJLg7wJ7+Ac9+T8Mf8AcGMDf7AOciNEJ/G3Q0KSiFarHOxNbTUGWhgq OJnAlP8AsXs39jkZK5Zgq8IeDV7E1d9ngky2hBlkH/NCb8PYlWSYGmNp+J/9rE4uR7SlwhfL f5Ic0k2BvyJQQuPatCT/ANxsL+ij5E3jYe0aGvLIIRGk+4w3+SHvsTyI4NWpFWaezIomfY7N MuGP+DU8OTA4JeJdGh6jP0VG2s+hbP6LiCOy5YnH6CFQxoUIlTeKQz3D6gj5wJohPZA8iDh/ wbB9WPzmGKF8IEcf5Z4SXPjadcDThjghCf4cDo5opb0KKFEKM2TLQsiQ0aLUQmCL+xjExogm w27hjmyJjJ6jDl6TJzbfHRWuBnoYykjIT+Cn828/mg7S4yi9hsxeZkz/AN+GodSOrEI68GXT 9iVwE2E+BF2HoMWP7I42ujKJvRXaKIX3Wf4qXxmy8kehTkJO/wBiOwsfI2coNf8AYh8Sv2Pe Ynif474fmEIQnlKyRepLHlF9Y+DG2WzVdEjQikKaFL4Ykq87GhmXAqcmBXiVGG2cTGRrD5zz xeTJJJDHAl7EuPzOCWt+nBQivgyxcyvBPDOmyjcUGTiSz2OWh+xFDcIpLgVa0WSSPL7FFaHl Jspvn2aCjYvYb9+E/DjVcibrproaZbE4P5slFofEUtiPkG/lQv8A6citv6OQK0v0J9sZ9jTZ GNvoZyTGycaIQhCEIT/HCEJSN9jV0FR2WIReWx3/AEYroYqH8nPk1ELs+jF7/A0whYy8Fa/0 DNzejIfKIkQ1NbG847Yj7PkKITGvIfjk0kFbEQ6QfC7/AANltpP2KVq/BloQaNVc8DZpCxY/ KJnsXQyuheCCCuiFhhuzI+AXRmKpkIYIYWWbbWBO1sIs3uomMndkZaHoTTksv6M/AWEjSfBQ uDKiIaYsa+SEIQngkRhBEREJ4LxNk9EITxD7Q7vNGS3gVdy8EeBYeMeGNzxUmx4Jpdi9Bkgn A4lkYJNiTRdKwN7NcXwRhU0yQ5tgkrqRBLJA95MvQoZa9icN1fIswSn5KlW17hvMjJxk+EZV 2jCVML9GHoat7MVF9xp2j7G9v7OSi7CfvxmV6hKnmsVtbexwcnKF5UaXoSdwdTSny6wYWR7F zdYT2DYLAKdSfs2qpCrLRiy9ehM12ONRxoW9/pm8RP5QTPQ3hehL3Wex+S6fWz0hutNM4qCf RU2D+LaCyGkSPmEzJTkxteM+EMJSdE7BreNNoxtvpnwrRVkmRsdjJxJDK48NeCSRKmAhfZjg Q1rJLSGM2MbNQwk2Nr4G3yTHitj6IjMZ1x8ChvBgzz0dGjXAm9pC4U2xgbr3Pkb4YM3+xaMM WqXJG5sEFRN+FY1L4TEyBWvRitr7Rbv6q0NbLvgOVl74FyKY3s9ou3Ebv+Qm1foZ9u9iW8Jk SZmZdQRXWhO2K7YmL2OFj9CWVgOSeCCK/Mtm+NlibbBmBtEUaohrFRUzemYuCG9DJZM/9yen 8OCKeRgr0EoguKO9W9DZNi0jv0KeQuCXIs4tOLokUDqsdBtNgQV7E/QgahBYYpYy3cNLQVUE nZVcISxTgRYIbq2/YsOiMq9MmIN1VoLAuucCFbsYnMprgTZqsj9Eu3Bnwx2QnohlMCLoqRRU +l5qjGn9tlSSS9i6GJ3aNXYmwvU2OtR1nZn+UN7KZ64ETdoxZe//AJ2cYfyZs0dvG/yNEp+2 yOUIv/IXqYznCE5ikFk+AkpwF9mK5IgsDcsWeyDX6FwPuE0Um5GjJU4cZqEMZObR5Rv59CWq 0QzRjsTdoWXAybMdgdP9GGQWvCQ8E7CuqipEIQTafTHp7Fbli0cWCZg5YywjC7fSOjD2z3TJ cOHWROdDANMY21EtLxCymRSyh7ZkxcqOzjPYpYv2y1XsTS3t2LmkkhZ9HJuseRrIUUOZgzez HyM8FSWND6mLwjJ8nqN2Jc/Q1zbfmkKkf0GGGb0JkUb7LakJSds9BO7FpEdwbjXISPVqPp9l bWuRV6IbdWizX7P/AMU6chfJnTIum/0bxF8ZZn4GVErgSiNoQL4CkEozods0nT7FJapDLZLY oWHZIQ0pkTxsvsTeeFwJqOw1LhQPW0ZNilnh4iODMh4mQhBfs8aOwkQpSK7Iohnl9vRi2aEV ECxpJox0RcmOTznIykvwi3RfA4yDbZ0IERFcGiURpcGtpjPvHVHI3TioSdvHsi32KiMbDOBp xKw9FRsWlHyZKrfSEOP6F7gl2GYdEjpaaRCGBltbzoVdfhnqPkSLHPZDkiYT+1aDTbpsUsNe hNTwHMITiqwalb/2J23J2GrSzSGG/wAF6BXMyJOjfyNx4JRbJTB8Mjxf7MVZ/kolcjnCDZoZ djIqWUS6GVar2jhgRVaWDk5rkMvlwQsxsRi3oT2ISLossjZLEZIdC5HLb1yIajT8F8IILfov i0hEdsTatjljs3TlMUaELbOLofVdGC7laQnlXRW4WpOWhqt/Zv0JAF9VejFk7eju5IZLRhyM TozdGjQurOoqNfJcjyL8BdcFJTLNLAmhxTjJlgxl+OWdE4L+Qjw+H0O0mrVaFR4T9rAlZoh+ FRn7nWdjCcCXyIWE7F7fSFOz1gSm8M+j5c9GtkdwPKoxPjJtj6/s58Cyt+TBsTcMGLMQgjLa NVijlgJ0JeDN7IBr4vqcJRMUR3DMeRqeLG7bGwcDet+GezkgTP8AoUc+3gh4fAiVz7FoW6QI ksGqZ2NjUtzNwJSJ8lebKY45ZfQjNJmKpI0x4Xteh7V8SBTUpLCDor4ORb1PP0KiGOfGjFds lY5G6LlgqzhSjP4PYQvg3LX/AB9M9M9M2Cj1bezgNJ/A7CcPgRIVpNjL/wACSZf0K+hej8EL ojkNqipaMLMX5Pl9FKnKKJgbTbMj3Cx7ZlCXNPYwfBt+FZd8MSxTTXI1emmiViyDX38ENNMr o8rqEOWz+hOYGVZ2Nw/IT8IEwNi/gxIbRhiG/Y8lKKRfQE0f0hPm1tlIIOMSOVIRdjXJSkq2 QnuCwJlt+BTeQrQ1ExfJh7RHB+1hiV76TIX/ABsaohFIy90Yx/yLguCBiYGFYk/CgrBuzoh8 CXY//UYIOIZ0Xdlt1ujR9n2UokbT7OPwdqMHiJ17F8RtaFRHkuhglonwLhJ/gXsXAhvZITN5 yEsf8E5M8jdrY45EnMbEwjF7FkUT8KV/LHOtHqmYtolPtj4OqDhWqzkYvaG6eGMVTEN5KlcU TvJReFDGHTA0O+Rv2MMPwOiM7gnPF5jHqBWg+arE2ZXpDFbaLof7NPZg/wCBYjZaxMXB+HJd +bwJY0a6YzfwHI01h+MLvo/7gaTX0JrFJGENryK/Q5gl5eRWQvl0bMl6x6B6p6p6v5PV/I62 n4IX/SEsYok7tiWYvZtfeMq5dp4LoyhEb2Dep+jSUeTazsw/2J//AKRdEQrgWeTfrxdK0SQi IJPW0JMgiGhElZTHsXf6CWNNEIM06ZTX6Eq1HorcNlmKIauYP+4h2r7EM12fIS9iHHGr2LCe wn4u/DnyOgluC0ngy/uOhcygaP6Hi2RleGbuXRPYuEQnClHyE/jhibKUyFo0xN+zIUHHJCur CS5BSX9saeNCLjovc50Q5D2WftMQ2g8cKeG75Mv+wn9Psa+4/wDRBI+RGSX9DRyyez5T0jcw m1MHRROuLD5IWUkzqYvumg2RRPOBN7C0hfJMYNso9FRtCiKNROi+DkwaMjt6E2kU2j0005KM RbBIVkyEwLwJPZicRehMEfA3uDDqtJWPfoY0eGuz5DSjyFtb4CEtkivHxq7E2xsijG9t8D0h YyJbTeieA7BacYm5KcXwuHlSCTVGwhcFMHOD4CPRiaDtP5HXrAk2nBJPaM929DVcmLuHtHYX ckMv7SNEpfSHqCyB+DQ9URgPpsQlTqMql8xr4Y6rHRA1Q2I0001+zrmfZhhP9jiYT2JYuRcl Q5bPoSX/AIG956Gz/sXpBH4jY2+hMuBYaMuYhJyEl0UW6F/CQQbDDIwY/v0Ahjz2N7j5KuH4 uSOyeisXXZcnyWWkOJI8YKJrg/8AgyghbScvx5FYw/6LwiicoaeRikcgpK6Z+hOc+B0qdpsE tNw/QWPgaJCe0LXRmnBc8hTyLuGbKzuxuuF7O5faKuMV0U1dia0hE1jZ0apgeZhnT+o+v+Dp iPPfQi8Bvy76GvhfJ1/sex+TLW/wPh0IRBNaWzQc7bDKw3wtCbUnCQy4b8Na0YhuD7Iqw7OD Jlc/kayYsj5FvLEaFJDiURejQ2ddnU16MeRSWIphMpS+WvHaat9HChcjdZPoTm+ei4KY8jBZ +hSSKpmw4Ey7pWSIb0xyZtidLD0zfH6sfil8J6rIkTzxtJp/AbnxKxv8kyTedNnOGIziMZoR OBKHZzBHy0FwVG4s34L0SBDAKQYp00y580lFjQz2E85IMeRCU9D2PHhoXy8W13cvLFnXm4bD sniXCpnKIwk38jXoa4VBikr5aX/QprA95Be/udCQb+QRf2PJGfSUWIqG6TrOVgept9IzCyMv JvRQmwe8iczo7mRikkcjjsy7/JHZ0ui9RN4JReJjIr8EMaSPstucy5EOA+jxn8i7sctw1rod OPob2UM8/wCGCujgg9j5rRdbQ52S7D6J/iruRb1H4FjBbwzDbX5FoYWavydwT/8AMnR0zZkp Kfj1G02JfBnsy4n2JNCc9+CubKem77EHkTe4X02UeKV2xjnhkdU4COpfsUc6PV+A3tPrP+h1 E+6L+Vegt36wxKUuRVZDBouryZrgJSXb7HK2e4Y5opwNT89Rcz/oIrIaP/wG1+ZyNDmY4Mvw xZChL6f8iHcmu/C9qeD+58TqN6wTb5GHyKXKF6MPGO8lzsXAwUo69tVp/Rsy7WmLOjKxBueR 9o2PxCDDRjp8+ivCEEs5FT5SUqcoTU/qoc4Tm3+BjmEdprMJTYr5Jc/grkZyeyPHPkwU8C4i HSYYyF/GzksWZ5Q39rhkn0dCT9iNCmyKLLyaEOlgjab+Bw2NMGP0Q2q8DcwUWHkxuo9QXYBg 5XyNZPsTbSL6GRfQF0dfsJLgr2zeP7Iyp/DSJd8zbFsgSkkn/Bnl/ARMrGqG3AmGgN8jcFJv Dobo1D7TH3eiWE27yRo/yMWvwfBpnK3PkVZVLf7Pu2JNUh8Z0RHi+z9glXEsaHeUiG5Xli0y RYHkfPr0aZ0aDXsxov6a4OrT9kJykaGx4k6FN0cJDTVXppRYIHcjS4a6EP8AUSNPusB7usGj JuZ+zKTP0CLN6eo0Isg0txmfPzEV6Hyiqd4g8wpqy8vVD/trKXNfNS/0SX59xMWxpuk0ehos qSXnXQVG6gtdV2hGZY+AQ+5L4CZyKlY1oT12YTS/A24bfo0lfBDhUCXtQwRtoa1/kN9Nn0Ew v/wV8BRVf2PwMvRHJ8vi0pGz8+P6G6/M3+zKtX0ECSS6SCa34EY3HyFUejWRRwvRia5gPDyL NJ5GQpjNzkhVdZPgc22I55MJozbhHWwxkxDXzdjbsaaMBmuB9dBVI3gqjbR2QSzcDTKCfZG9 vA46jMoT34Q9m5jsh7bArSywVdT4MYUpPskGjc/AQtTEmN+yhvwbFUa27L3L3FhiAuMMaqLa WhLlD8DBwT3Cr0DfmHOmPwhezDBiZ+eTbMXpkmmPQpw9dDR48p+SWpiosq2+j/h0JHYo18c1 f2NolaXuNoafQZf2cylOEEsS8uGDD7Cbw2UdxynUU2v7y2wSet28i9Rc0JkmvY/oHxWYTViq VfJta7It1COhq5QTGUGh5PaGLb+wVCprTs4XSJ1J0fgf8CkvE4GR4eLo4hsxwG3DvI0jXzNE IZrwkNRlL483eR3v8WdWfFNu2Zh6EzjwczWYJPA80z4GpXefJwNb+DR/ArGcGsDFnlSiGzRq NjmPgVO+SuMjP6iJPCOWJidmgjkWzg5nAwTw/q8SMxFRtvNseRwIsor4MGYMrZwYoXjZvLwN 4LwFTc1Ysehq1vyMcvHDQzrI6bZ//9oADAMBAAIAAwAAABAQZ7NWX1w9c/nm9LbxMzUJoPEZ mRieVq1VmYHoMTOmgOZ89xAMWaGNO3k8QgibpbKZLqOKJeVwRaZMLo3DVcK95vjIOhddostj t9eeMB3CTPPNgxTwMePEV0K6AdEsPXrsXVwjvLPNZkKhWhW/jlscyekP7GhQTLhz0rfjrewP 2pde9VyYxxxSc99BV5QnxyxyfjMX03EtemAjYjmB2htpaGEJb7TiULi0knihXAO5rz5Ss/pA quxNhi90vIeevBKnJTSwEx8x/l5IQUao2oHbEL9JAzLxPAQGOqVvZtUY70TC5ytft/aRfpHR luSy0B94w/8ATvfn3L1VDgXLoAfSYaGI1wHrKvIEwc2HxsmekNXaookb2fTzyTa00yMOmid5 mbqVu3tTzaLVw8EG3n1O+pvo0LTX41eaMk2vNyJbMRBGwJI6BFD1I2lLTqQqAnsR0A7YHqI7 0bZJ6s2NuRyc4W7I4T5fl/QIUu1tpMT3ZgKjuLfj61yyXu2BnNa3WxPRmYMUl85HIHh4ije7 H1a5tuIGiW270Lg05hVaLRt5ix2Azc+KC7coLW4H6y1x/rPPekJFMnfX/r6SFVhAiS2OggbU ykEq1jHgOn/lZliIXuKjh5jWhSU+3denowPGkDfc/cBeiBAd/g/eiAjB89/jB8ei/e9Adjid i+jDg/8AgPIQ/fwf/8QAIxEBAQEAAwEAAgMAAwEAAAAAAQARECExQSBRMGFxgZHB8P/aAAgB AwEBPxDOMbP59/Bbj9y/jKPf5MsshNq3a45+CLGHLH208gfZPyTP5CCuEh7nxhrjKWhjDH+I L910mYMMV2YWEN7sLLONvZC7WZJ/OQrD4m3TPay9HkP023ZJwh1BO7D5Cnkg86NjBYcO71Je VvOpzL3DlDP6Xf2O+iH4afpKPbOc4J1+XYfqX4wbZfGSxsy64iwhNW91R7/o/wDvJ/JE8nG8 EYwMsWa4NTxtZWdy7ewnjJ7j63psiCQ+3zMnX9WWWcMsshNllsESHonu8ju7w1/33SrtdmyL rAN3bO28tkBbs6m4xY2WTMnhkDOrOsleGwnjdnBWdezvOEyIjyD8jZ1ZXaw8tUs14ZzYPpDg /b1ESBb+/JQ16vRD3dvIJJZYTjJJ3jL1GzjpaTa5s9+3SOuuc3lHdG6nPkSbhcyImPIwh9RI BNOB2xp0tl9Ro7Ac27LCxgPS7G2fpv1zD9iJLTub0QL7EGSTGS2yjOl0+Xjl/vDOGcMyAYZJ dj1Zv7lQvdieR9Er6XanUvEI92dXei/ogxOBYMK1fJkq63bfCA5dlhtgQlsyyz8tLb/d2dwD qHb/AI4yTjLf3GWz3JZZMchqVMYodJBx9gPOFl8yzCUJBly0YeSbJZBdDKO4nTAOpzJHzh0m q+WrX4F8W22LOGfx9skhrxn9H/sj1vCWczEexbHcmENWDcO3bg8lmzOrLPwBq0npLfZ4W223 U4OX9kBjHkL0xpCyy3UWWSMnKnkO1O/2T+4v6F40khBn2PjqIdQydx8I+r7dMLy9sWTi9beu pt4QbEixYuvpb+i39y7Yb5WH9s/YD9s/Drjq6s53AQ2ZZxvbwMaFnCNjd0i2urpmhIAsJ/u7 Re7TkwWWBdQv221iz7zln6tT7ahWrTa8bw1H7TVgbU6tfWBYHhbZBkhnMyxfJfTID21K+WRO iMM6nh4OR4ODz8B8jy+z4T7x6/w3zk9ngm+8ns+TeuTfOCJ5H2L48fIvXBm//8QAIhEBAQEA AwEBAQEAAwEBAAAAAQARECExQVFhIDBxgaGx/9oACAECAQE/EBttt/4d/wBbbbbAd38JXjIR pbbbzvG8LbLIsXqM/O34fA4byLbJtj8tHsr5C+w/8qgayzUN6uzxpCyPS0N43jbbbbbZcm3J v1H4tD2EMY7bsjXZH5CNONsvIW6W7H/OiBD9EQYO49C24d36FlBNjtiHXVvGvYzbwZxaPIJE 8BF4ebNkPAiP3dTh2yHCV9gPlv8Ap3bb/jp/2PomyQ+loewls/bCNbYHkn2GSdH7D7EHZTJj rZ1Bgy+RO6fYAsLsYvsl0cLwIvhN0tllhnjfa2A/2223htttgttvzRNkdLpLt5dY/wDyLaPl stOobTqLD/s4FeBhuEsW5w6RwYdMMtrokKOyfEhZ+2ICQ8he98VsiM7fQnGrat0P7be2OOwc Fidq+H/7PufIJeo7k2b+wh1GYfsnV1UYlgj8lWXcRkW207OT3axiySeSn2U93y7ty1I/y0Nm W39XjLGIu7sLt4rxoo43a8LNd+WAPE4mWvG6LQaSRwe4dk2NsSB/Bly2MR3vbrgtjqV/yDCz ZLru7HuDTZlty23gu3ZCsm0TuOpBODsI+2QN0tf6Re8+pdcOwYbdtx64JpAQs0t7Q93s+Qmx 0jYctXkhs3Z8gGHGfy6epHrLrNttsSZO2QRbIFt7bwwhQE7mXUH7ZBsdNntjUiMY7DWsshhJ XsF6ifJRwJgRBdw/Sx+2f3lDDMf4EdcsBeQ3/Uh9L+kPQ41Ih+Jb02DFcdWWl23gTp2OrV3M FtxwadGYNsFke5LCW2wKbZNXaT5JYWRGzbbaQ8BJHUh/5JQ4HJWIgZ2SdxJ1ZPwzjTy7hjuz OG3a6FjGFl4WH5YgtWN/7Yft/wBQ5bkeiTvVuUXZbw93cZd3csbbkEGDEasY4wW8KF/5YcGS iNnXgmQuxhB8sSLtEpfxatqSfDdHs5Lfjjfy22wsSL3AHs5e2cM6k2Im9ROjfySstfZ84f1b hTYfZ19JPyxBnsicL3b11GLb5DthyWRN8n29cz2b5HrfOHyfY4+f4b5w+z5fYnyfCeH3h8n/ AAPq+T8vt9m8r1F4v//EACcQAQACAgICAgIDAQEBAQAAAAEAESExQVFhcYGREKGxwdHh8CDx /9oACAEBAAE/ELMWEtBqiNsQivE0/AGVKxqAyvwpKlPX43KlSojEZUqJKdfkpeJXiVElSpbq ba/NUQlfgN4iH1yYXTu1kayj4ikqVGUxJSIdSpSpUrx+KlRLlP4VXEqVKlMRlSmpn8V+K/FS rlrlpaek0/BpAuVmP53NE+IOCmPXMt1ChlDnDMuCJ7ILY/hUqVK/+BVRIiypUplMYf8A4Ixm v43iS3U9IN0TzmHMrGcYx5/jvZVEQsfgfEQUOIFEUopebZ7zob+5aHxf/oRu7HrMonCJKlSp VSpWZUZXUyTDxK8fgnMolf8AwkpluoqCgDyJmREeT8CByx+K/jcTsjgfswVHlUf8lXI8hD9k vlvvjPi20T+CNVL2fzCVajR2/wBRS+wMWRUVLSk/FeJXicsExxCvMq2NsqbCEchNnJuFR2iC 6Ll30zaR3TGN/mpzKlSo/is6lRIRUqVKZU1+KuEUR3MSuiXdQslBjwNeRfuAcPgwsFydnEFs nVwFqyUJccsWwWMrSHJfwjET8KYn4qJiViGp7hCfhUTMZUqVX4qCF6wWssnsn+X/ACE6h5n7 HUKKqMBoTVduhcuRLai/uJ4wbBKS/cxAI6ho8pKS0O+JQHOjEqKDhijIWekJQ53wbuUoGTdz JmqrInmGy1+0WsfVEacSpUPCEqWnKNzjKVqnpjbwtS0qlcV0uUsBFFdEPhajwRG0MGtPye/4 plSpknxKX8GKlSvEqURPH4cypxqVKS4epbmg3S8piEC1pitJR3XK4zL6SqGz5iQ1o0/EURc+ YAUs+sQrsmRACMrvIgRYxUfX4NJUSVKlpTK/DCJ+B+D0iGFq0BCYnITI6i7j7LzKFMxghTbX 7lFX31MqVX63E5T5i0/QLVkCVq10VuNqFG0JCjgs5VLy7UTj4YrD+CWhVyWZYxGfAxde+p53 JWosD7E7tKEwM0fKbtF3H8FpaWYjhLjlh+I8H7h2CDl0TdTDmUHKc2/y+SKMXBWe7l4jMQPw hH8jmLfEruMt/wDhAjUqMS+ZTmUhlL4oMJaVV4hnIcF1F3eTteyM+N7wxH0PmebG1buFmp0F ijNwmmJDYLhn7h5hR1PDEdfnc5daqDPYlP8AYQJb4/sYoWnywoNobW2Eg5jYGIYNyBS9Oo2B VImSMI/Hz+DMuUluPK9xJRfN7l1a50RxBteFKxLVIMdQLRBe8xdZeBjaIEI6imnEBrKu6wl0 tODKB2DT2QrIJ9/UJbSOUL2XnwmIu3u9w6m8aOYZpNncRxAgqtKO2bR3K8fmjhir1LhqI3iX jcvtHxRTcbuydUMzEOo5RMfhPxUpmT8UyokzK7ldSmbleZiPiWsfxUqVKJRf4yQTFDmZa9pz 8wNmXzHHY9ywIhQNnmVAQBruFV52MEBOwy9keKUNu3xia+tsMI6BuviJhoU8MaEbHi+orUJh EgVqVn8EitWiYpybyHqVNF/SLg0KwuNvRjBxNMgPG5W4GrYBKO1AlLbABpXc2NyCoKjcpqVN KBldEQ6y0AS9/nzFC6TsrMpYq9dv7lVwDdcJem01fhNSN+IQAXp4iILXAdssWFrmmoB4latI peIVsgpFCjD3MLA0fcAAp7uKCsNrGhSqeJXsI3KRHqLZU5W5PXcdBKTiJnUplTwEUf5J5Q8R RvDLeIbEXCOEWNJBC2EzCZiRfMK6/FRPxUr8V+FBFkAcBKM2n+9iLiK/BhJUqpUrqVKIEyHR ALzDEQdGmUZUwFQYhaaiWN+DiMHEIcM/UDdy3N1C8rgMkcowALD/AAYCaI0kp4jFRfOBlu4e FJXGIZyQwACuCAYpjmWiwMCUq0xoeE5RWhbiDBZ+ZlYAd31MsSJAlKNb4ImTXuZOvXMRIG/c oZWXUuHMBWn3ERALbNQ6VQ2iCrWgO4rl3oBwyrIQKjOfOJR4jAuz5JUFUdphFVr4l7hP/ly9 Jb3H3H46qnIMz8g8DEqsEtmV9Fae5n6YfUrIESVKiEs/EDDGs9zc3UqjcEEbwjiN/EEyB2qX gr2FNd5A3OJJ5CGyPpGoXxFESKieZVs5mvws2w/GbgotuoLlTCRt+G2PwpKgSgA3FGAADUKn E4S7+Jpf+XiNsQg08RNz9ZeNwcOHGINY++4m8W4uCwXEPvDKWdRkMQswMJwo7ZTHovqVX3FT EA6LGOCuyGXt0uX0czE33Ayv6Im5B4YCArtUUXPV8f6YDYTSaHwR4yclH7lAcFG3hFxMzKVV i/cpRzfMEXZ9wJO7SnH8RAcHTdf1uWU5aX/SADTzFiCqHtTAlFjb+kKJpNQMGjIZlOqFxymd 9fMv1h6g3nC9QnoxbbUs0kZ216YPFD8wvLAzMqqwimIsIJzQwZ7iTN5lRVCnmVWmXDVX+o4s VBGlQmtVgUxVrtY1LQK1Whj2iMcq+RFAAN5Fx9wasvWxcUsQTgdRGCP3kkBwL8OIUs3rTHSB OGFGbalYmAqPT8lVKlSokDxKiQJU9PyMUsIAlr6GKtP9RaoSgs5fAhsFUaUwALVoggCUx1P3 AORfEuqR2vjqGV2MpyiTCKXUP11xCRmY+iAyFrzWIlgg11hgXs6gX1QrR+oC0fNlv7mOOdqS gZMZzLmLP2EHvwHgJRoU9ZmdWgMq4gbKdeTLXKbhWCiiuWWalHXMDTz1LDWvTeooCK8sKdLC bhAtjogd1hYLqojQyyncwBkiRRnPB7jZ0g9GINlTMH/qlV3OyUTNANv3A7L6zBVNs0Zx5ZVk PKVQgrJn5jRx8JH8APUocxRsA8zvLgyjVfGouwKdQvjSLmD2IV+4HmGmaYGbhHFxrmFYUlYS 44JQk0sMIw9ssK0uW0EbCusxr5IIbmDZC6ccPUpYxw8MZxiw1LpqH4jG0iDIQOmYszwSvcGx YXLDcEllyuKluprKQK1AHN8Sblp2ZP8AkMVVLb4gI11fEqhS+WEAu/ECuIKKqpxguoRzUENm 4gcZ9S9g9cxYi1HmLGaZYxBrVRgpyWCZiJgt34IHBseY1Jt7qprIxk8Sy+/ZA0M2SwBLewij g9xSg+RXMMvCiK2jJqBdgwvUbQNmM1KMmJl6LFcsrF0cpKfUVC7lXMDcjVuH3BA9e1D6lhpq OLlgu8s4lDNvBkgWaX1LFp8wHczlIrlYngGA3kuoJxJu5RgEJuoAv/pBUwg+IANH6SmgvIyw oJ6h1RaCmKv3DqeTyOo6opNkuUXiUPiV044hSwGw/wCwajBYq/qIcJfzHbGOGiEqC3QfsYqA 6lW/XXqJNqiza/fJC0A5Zw/ERuAqZKuVEK8NVU0Qhzhj2wYklvmvqMLBbIyERUPVq9XFf9kN KRxHLE/8biec88RhGpUqZuUvMziQBV8QwQ8WWPUE7XEsMF6UzIvdEppQ+4f/AF0vjQeSbYjP gO6jnQMFaBDGSKqr8hFhNDhrcoAADs6hZyPsmXQQVu/qVi2KskoFlhL9EG8lGe5YrUO5WbWL ect3KDKssNkpt4ZbtgQi2V9SoquVmZcrALXcOOSU3uYikxjEVVYfcR3unkmCMFWqghDLZUNq ZN8S03sFlsyltyyPE9xFcIVgmZhTmuZbq7eSOsY5dJDEo2gczaE3gRx7Y7LXQrFeooLcFJyx BWHNxKtquykmCT+rIRVdZeIrYTffMrhq2LdxbAJ4hFYrxcwhFTvgiBB5LAiFga3huoBsl2Ms C1HfiXaofMEUmfE43iLkgbwVKYkDnUzqRhYdjF8l1Bu+7dE/Rl9zudj6GZ8p5V81cBwhptag WCOAuNBUci/5MTpbP6YIS3mkMFEzYLU/5L8LS7w+4lRvdXN14zC8MV1SvCNksRartiRoK85j pY31Bea8LKsITp1LFPO/xDLfRuMqTPTAVkgVxLDcQdygvCoEVecLClBS4u5Q1zUEhAmXriYC 23XUaLb+MQPwg1xcqBoNdxVS1cAoeQgueyFeCEV8ZhIBHTKUoj/SI5Y/iCrgxBb4l9VUvw+I BgXLz/NzOGF5e5QA1MXEvA2b9RhwNKJXgB35h4N3aOCO2Jecu5ZWtLU4IqFQCrMEEDB5I6lg FcbgjqGCLOe480g1n/UNIDYwWKDwIVNbDzGXW9M7TGfEuzAc6hmZZpSPOwksF6Jm816gDsgB RuvEYDNt24qUNEp4U1EQmTu7gqB5JbYKlUGoUoHrINzZwgUNyoGHIeGO71pdxormiXUoi2mT B8wAUxa0j0MDMujZFycu/wD9gWAPCwDiDETPRF8iEoBuo/GTqDEsUk3UwfMUg+BqGFkfJCFQ TsigJ8IibTQgIdqsAFJ5gAKRuwKJmEfUfCCII4Lv4xChjMiz9n9IO1PC7P2Sr1BevoLS3onJ lfuI2/QIiWJe9JdZQ77ilNra5gvRfNXCwbb3UKt29zgPlhOiHhklFt6KyTDiJ0Y4U4I7aOcH MUbAPdG5UisdF5gDsUCebDkh09z2h6SE2h6vccQXO3UHMwULypWScrGS0vhm4Pdqt55l8bdR hCA0kbPAZKgAUL4bgISEjUF4mwDPmCcQUaNRlRiuo04NneYZB7YmUjazudIOIUQo7RWNF/uB obLtBlWA5nP3MEzcqOYBFDGqqZ4SLsEfJ+o4xXsOJjOmVZezzCUseUIE2Z0bmggLLiEyitUX aaZULES7OYmX413EA9R4YkcRCkmyOY6C9mAAfGWOy03XHpjYxCjuQ8oOqgJKHItM5AF5lhBo urCVWKK5KtjCWxjDqzSmGAo5ho4RhQ52RAdOxLuEgw5U3FQ/IqKXnXUVTDHEXIusHliE2lsu bQiMRr/aIm5Z1f8AIQDOyP8AEUOuUh+mCMDuB9OpkQeUMU7DqprJkJg8D1NtB5IFII1mNw0C Hc0bA39kq7QeYiKQdjRKlg64auWUSoZzqICYNHR7gFBw4Df1LXYDpX+p2B1Ute6YZMOZirFQ aKV5TFML1zFe3mJjqKU1rG4IKFrSOYwMlGFgxs9ahKUejN/KhgOHzLwpRaIDkzMgHGg9xKEB yeIfMJ0zF4cHUxQyPcQADUqq4ekmR8+5dAVgte4CQXleZ1g8RdD1LeiWiuK5iobNxDqYdu2A Es5OvwZ3zHSizIjnGYIm/wCIK0P5hCARzlZoCxDIzzyRUUnYz7VGHpDeIEZLgUFKbwy8IHCy iA8BLnIlycCJD44Msk+i/UoIfuEqtsWCKcvTLu/mUWApsdQyFt8XbCcADhDDi+ZGTGFsrjKE rJe3t2RiWPkVjbsA0QA7VyZwMEiLTk3AF8aqOkjDJBRgA2jEaiwXbKLzNlkEtq8YblQUjs4h LMXvE280rzL7XYNRXX4VNGwhqDa2b9QsgXokWBsP0QJN+y4cZEbMHmHOESvm9x8x2Lef1MKk Ap3GCwWUqj47iIol97nPDg5JY4ZypuLaLsbyqOVk0Sxklmq3DJsDHFSwGy2g1+plbsebqoXg oO719QFBcdBdwrzVDOseGXHn+JUI09MWMG+I+WnqJVZVcTSgMGyMqJ0nDuXknusPqWS1NLKL SowLBNlAKK6XiVVpwseALebl4o8NMdWZ7pIy4rswsDbErLB8ahTGFUJzLx/JazvzD736YQUI 8MO+jbPE2BDzFbbPPE4BiLTb5hsN9xWXPbGAza6JD9vYhHofqNdo+IigU7UaOU+oNtmHxKOq MZuEI2W5/uNO82YiGkG2BMK5E5nEAPZENBWJn+0yFnMSIoDlBsXJhcxT1FJ7lwXDgM3LTV4i u1RhvcabWWf1HlH8AejMBUt8zxI1DRXUFSl6IoFHmiWMFPA7g5dj3LTA1mhb+pcL0FLiF5sX zFOTgMNwcnHhmQtvsEIlC/D+4saho2EGJq3glwd4QigPtySyHgoVZKtOorMyn8cpQTU4MrxA rPWKnw1KCC7GMyz9SlgphuouiDQ+6HmS6AbA+YYWdFLQeZUpm12YhIZHghTjDjiBmiF8sVXt VXc2Dyc4wxbxacEIi6tNZjcq92Rt2rDYzKLKwhxFpFPFWSogRthw6rz4lXI+RmMU7qoK1mfV 8QLZDpIwCTrzCuGtLxN2DmsShErHe4eS69sEaC9ytBKxeyO5V9ykArsiNGuqubBMQsBlVx8y +RNtV3y+YzUlvCfDEKiBjVT7JSB0aeIhTk4uKFlqWqF0O4SoZvFzLyg1XqAwLw3Vv8iemuEv 8uZbOHrCKGZbytqVM2nzKBFYmAbpSVIDwmLnCVXJuIIE8pQwwES+II+GIrAHpg5foU3Z0jqC sGxZAYX2ht8xhB7uj6lyII5sZhmml0wUCj9RBcA6ZjEliPqxUhs6g4yh4ilYY2BhEQJVFERA G3NXGqjldpxEBaXe+JcYQ+pj4+IL4Xt1AFNWdGGaBl+pjRQKcV/EYuhpTcGik+LjwZDB17jx qfqO5Xcr/wCOc/68s0wbRgiwe7ohUqHJAFnapBXqFvUUihFOM26mnDFgbmjZ2QbbMXBhubBf fMRlgTzv4jANKfJAoT84jYIOuDBZqfyYuJY6vEVIAJg7iiyO6rEuUAU5gxphSXTGNqU2FYYb GzuLaomAQPMsDEQUKZ6GPGauZL9U6TIwqJ6qC7lIao6dpUsQ2mpjAgmaTZELWulQc0rZpLgg 35fiEFZpziV3kgp/2PK78QaqUdMaAVCJW9n8TGKDtqWMRW0gLovqJF5fcQ0MbO7JZq2oDucI ckRB5zfue/EWb/tMqPFeY3NB8wOF7YT6WCCUo1iCFQyDiI9ABzLVHSW77IKYJkFV+JQCW84i 5bsiOqzWmNkpKie1+4WJYPZhhMqNmAfZGIzqCfOGBJSNZCzGo9N1FaZrwB9Rz4ElDKN9pRhw +YYAXvJCQlDpauZOjbeoLBqr2kPdnLNIF4NQUr4Cf3MKgjflKDbj7YgEhXJLVpY6ZchTtueQ lF6RA4ShzKdxHIfQijm+m2FVCJ2sWUGlf+JW0nFsHpBART5qXZgXfX1Ed8rtUrpa4zeZRAW2 FP1CtI1xGOyeG7Y9tPrMJCKMamszfa6gPMdMCqLjaggwfq4tZUPiJyw93KVhTmEF15K3iWjC +GMenpgCinqI2sMVQQ+0TvHUKONdRpm/iPVU8KxFRsZnB4JgUrPPBKVibwMsQEPDde5UoPJi WYRVbLfPUQ5TpzCBqOa5GKh2PLiogQ47zPQNVzEQov8AcqHT5Zy3UONzm6MPTDPs03hj2a+2 CnKZim4z58QDT9EcFv6iO2cqzZAotlbt2wh/2OWKfcrybly8+5QGt6vhgoXSc3K4czGMMYtt VogWU3AGJU31NXSAngVu9QbUB1l+p1DxUDb0dxWAmiCeICQewSo6o8QFqspFMI8cNhZDoVyc E2oJsSYtHfmHiVttqVSxrGIF6QdowRmQaQvEJuMHXMebNqoNQxLtXJKWBB6wx/C5ZihbxSv0 Tdq+b3FPL2xt/snS/wAwZ/vls3/4aIrSSDcr64PDfJmf4xEN6bIorVwanzBH20xSW7CcoVUI U/7DwOh18soBYHNSzAparcElc92qXNg1zBZbIncs1vzc3NH3Eg6cSsL27IocnyQcRd6YnLjG o06+4IwtXzLGvZUGg0EMAuWvOKgk3N9kXj0Nwgqt1VsOVFrmFPKYYAKidqyHUVm7dzILBo0x fQ8xABSPmBWJasi7avJSPbQ7f8h9GQ0jUMg4cKiSli0fHM7xmLHMHECy4PTEbtQNTEtr3KC7 lGbuNmbepeF4gHpKyoolaMwL38wLc+0vNNxbNq5vUvEbM1MUF5ZoaqATiDm9yg8li27lrQ+z MWhlnNdS/LBpirnOrhXnMANwR/qVBp9upR5i7E+YIr6meNkVXEKKouF+FYP/ADMbsYeY+ime yqidqZi9PqFMD1fM5pDleJvBXgWWhEvO2UaW5vMZNAO4OEwzYeJpLu7/AN0MBA5HAAYGl/6g vuwj/ETwEdkAWvsf+Qaw9f8Asnjf+PMCs+axFWuOxhZDXu1QAyryDCkyzzKNqg5loxXuHQOy ULe2rgASDYG5uEMNN3EbTSQ4p4cygqrwmagwSkd4olScfeog0L+4kBarqHCZ+pgLNeeZnani eRflNS8Et8pqBMGfEEl0JFeHEoGiC0ixc6fqCou6VNBseZYAU+EGLnjTL8q+Ci6C3rM/gWH3 KtnjN3AODfMtSuOYglwK3mzATcvruNkB23c7Yb7xGN39INi/JNdN11HXcVpJyiElFIKpiay4 zS4zQx6iXtAu9Lv4lrXzeh9xhh+5ywFbg7g3niUJuWt39S0UcspcQpiUUAHjMuhO2P8AxFfS PKlSwXX3NuLs4uYBt5hVpRfcvyfMtdspC2OiYl79Qs9PmDwLfUxhlAbTHcseJn4EQg1s05l4 y83cQhhKwVlgFlXWIOMBsdwGZeBDVQcZjDgTnuWpLrBc21DqLLQPcBL+WyJ/tYgefMViUAVO nZKVeurGH9sz/wDcg3hkIcGL/iKXKeeJ0xYJCRuwbPuClHhbB8sKRN2D/QE7cnxeV18S1MML ge5QtberyQjaARMIxoHKvKAJqboF/smpCKxS3jqAxagucTmkQyKTkYmHQdnMEUBrmGNO0R4Y A2fZAKBneNThUIX1JVyPi5TgICUGJ0MSl7zBTRUFjS5zGrw8xhfSYIoWthmVYjlNo+wq4eA2 7Ufcuql9Mbu1X1DuhZkeuYZpK1v/AGGCy1JSm95t1K1OEEQuzMxsUqku0K15i12xbG4bH6Mv xWkkeNPlKqB1tMmGl/MWtSpyWTC5DVtn8Qi8sQt/qeGJb6LuiHUAZB1LRLh0KLg6u15Z6UFZ zNassyuIzTQPH+zcPtApv9Jfmj3EN2PZE8/CAO2TuFA7tNVUCi68vESzRrjuZwxL8poReQ3E WrF5GvqF2+ixVsx6q4aM/NR2g8DYxGbnlMA+Um1BT3csigUYsnMEeGROJlmdnVSqo8WlEqTq 6SXErO1KZXqafqIOQJyTnQCLxX87h6AvbA8vMIkjRaB6Cojo5gGUJ2qEofEJ1phPuWa8iypX N3LzdFkMN6qpkf8AIiLlq2II0A4EsY4aluAmICtT1Y/MsMqXQQchU04qOJZTGDZuVouPbOEi t3Lti69Q7TNfURVBwlrAX84hd1yhiuniXKW743KFDT+5/wC2XstHUy3Z7lF3cAwhb1BGzEAY c0N81qNqT5QdyCuspbkOBMQEFj/eByK+COef4gwlswSL83AA201BzKaLgKJcZriWhyMw90s2 IC+IM3WXsBqr6THbHomoJq2ePMuRo3SE6QUi5xB85j1upc2QeFWxmtKUemRff6jYxziPoV+5 wqkxp8VxA2DyMfFX33EwyniVzZyypLgJrg0QRvZd5LxGgOeIkXaOrl8Fi8uJeRRTaaltWk8Q wVt4NV8RRLZdbl/NnFSxy92SkqRzYx2eVdXqFwrGSNKC25U4lEwMlvP3BWS2+WJFJ9srF/bA c19XFka/cLSIfMGK7vmL5rURdJ81Lb28xQ2+ricLSxzHsfUva/Jv2OYAF1MHnDEYtWoR+VuZ B3AIfhb8s4qU/btcR8yq0z4B+jASjkf7iphQmkeR2ZWEkQ6C/YliCcw/VxdkDnGIonlmj+Vr 6lEI4DX5hmVUu0/2FLNNFUSwG6rSZmwr0bv7jbWqvEatnyuoMsZHmAWX74hQWC9jMq0PVsel XieI+5ViD2glUeHqKZVd3CCgtRdJR4ltrnqD21On9Qd3eZyXFKiPEicwVaT5ixnDCfrSAju8 pl/6nmACbvHcSjOXEW8/1OwrYh0iDxeoGnMJmBcy7YQtovzuJZF+Jmw3ExMma+ZaxvczElSp hGyskqyWASkQiCi70wM0IBb4As0+ZcruCD/3EyDBO4pVU+NVMoIZ2MMGVXAFsUUQekQG84Ly QUlUP/SKKq3vslpvHlUKqCOmCO274h8gP1DYLR8z9IhiQBVr1HMLixRXiUWaU0CqjirisDlq WrL8iDrbOyDUV8s20QuKt6nEtyviBrHqlTI2vRZAAD7tmnZ5qY7aPczPiqAWu+3SXFF8GNzV Hr/sZC10qrBD28N34GmdZU5Q+bi8PEYP5l1i0rmGPI27i3F7o4o+PgsZh5ICq3ogQcc8j3BL WdAICoOAf6R9KYNNvdRSxHsuWlYj3pldncAD8TkxgbMwifME/mYAIabLz6YllyyUYitNOMlV AlQLLoCU1ruCosDyNyi8g+LuAgWehFVefuFOwlCr7mGnFxUHQydLhhqe5cRCXjxEtd106llK bPcHOrliMsvmBZoviDwr5YAtQ+IFpcX8yhlbYbfz/iYLBq74X+prMnzLSyL7I6w09P8AsQza HRAvNj1GpMDqX+JmcETGvwEuDPqUEovLDto21b0vD4ZVt1FGH8TiwXIh2EWo+fgqtf8AuYpl iDSHjJHsZWnID++Y+5bL2DF+abr1cRDGtPiXGqcVND41AnGu0XylI60r4ltDHiFlrjuKcXYQ 6z8RAGeAsCRjWQMQwApvuFqrSM3JogpX3K7aL33CjIHKFj6iM0bC8wDto51dzVctvEuoFDvV RKL3kalulnm4AFw9OJUul0hFfwbhwUHFXBHX2Xc2C+HX1Ewc6Q/yNcJXlcwwDngMfc//AEJQ ZfJE/mA0HYGLyvW1o9x0QOq/uXSE1kr8t/1PcdakbbSKo/iNoC8Bj7lZ3ZSk9LgPiYHxsEWf UoDc8D/EsiXhqh9w3FWLakbBv2HEbsQ6FqJLF+buCVeQN1AUoZTGYsweXDPtmEA1p/EYF8wo GPISxUFsNg9QOXUnVD+4c2FfI+pwryhM2i44QY8lcUTKFoAlYG6MSrmtgu5TG36SzLHjMlQq BTJv9wiIDTP3DII242+ILVOA4WCUxeRjasjmnESfUxjkpO5VC5OHuAE2MWZqU9i7RSuyFIUN IIDuuYnGyYR/7FXRfc5lMMviXEbrQZjs1oTbD5zChC/1+5tMPND3TiZqCBkJ4TcNI3AQVxNF 7L+40pHBHxu9xWmtCj/F0fEPwtZPsw1+pZrd0Lh81DQ+eD6B79x6mUBUfW4DWw0qXPlRak+L nBisiOppWLCHvMDQVMDB/cpOyBT+CY+5Zurln7tBujtLWmNEgLoL5mQCWy2V+sypPAtaoImh eboSXF8LgNshdNnpjmrByUYPDLQUGNizAyk4jjEyzex3MYsy/wCy0WK9SgCq8tGCErXaoFqY PQQxsOTTNlt4vMcE7qnEyZI4EZi8FfJFdg28H+QolC9LUFrTPMWiU+CAybsEd1Q1fMXXZvyi oFyhnzggSG1SKL4pLMR22f5izVeFafeCOoC0QfBEPy5YVhetBCPVBkQUeIMAZCv7mAWumkuZ RbtXGyAZxAlE8UkQtq+jJ8SgwWSiwloiwGF3UFCAHAp2YzBmVpg+WuWLCM9mVPeYtlUFuZbY PBWrlkoIc3bGcL5FqMFbOrf4mFhFa/8AbmS+xu8+oQLwQSErotgQoo7HB9xFgtvMVG5jZSXN HBr+ImLRqrjYwBV3KIFLuixiuJHJVXqJRUO5SSY1WWB85yWwHWQ7gNlHgRDsC+7zEltNKiOo e7z8yzMGMc/DNqQKsBBOqiVP1BhVsx3i7hngW2fO4roc+68SxS6OHwllTQpBFgCkVKVckK8a oVJiKcFtRHVHJQD2Soj4ZP3M3ZhBRI1FoMEsmXemSYLa/R+I3gQbVxLNaDKlGUBoM3Wxh9H+ EJpxPEqFu00pmDZQHxmIAM6oVcwm9hEE/ZLYu8qhfAIQa2vJj6YarJlsvTUso+lNo/uPFiWR V+yEIopTbUJClsqyJCctU0Jba/bT/UVLOUYIo08FI/crA66o14jkM4YviOWm2JMao4Jsgj5e 3EcDgtDNt3TgzNKB1f8AURbg7K3N6KLLfdorX1LWG3tGJVvsdy0MDFnMFsEe5goryy/uN8gA sAY6ic54mQvPuVDRdbqJADiyaQQRLOmJU26C2oKhR4RoCr1EIS3ysAcGniBCkYrcTvmSvMAA l55hBADHEIDozHdmZm2a37iQ0pM9kNLmoQBB4ZiCYfErVspzHd57lj3lG/hEUtXEFut3DLXf c28TEzuzaX5gKSvUS2W29w1sXbPMIOg3U2HFwo7bOYlu25yjvACgEAtrYTZALsGAKQLmI9QF iC1zACAB1Ebq2O4epDWxl1AuxbGEp4uA4nMX6TEJgqWACKpTJM/a/KZo5HRhgAHgIftgFAam mkNm8zHXUV5xNsxBFlwFekzLZzGgGh4IlMsAWDMZq85mKBqKCqc1mZ+Mu2MgUwwan3wVmJQK 8TFYm7rFwFV7Mziw6NRIqXUuCV7WEBiNTLvude4kqOOoBSg5gqkykv4S6LfKijaZNsAuQb35 gEgD1KRaurlh3dz/2Q== ------=_NextPart_000_001__16659973_14467,92 Content-Type: image/gif; name="textoarriba.gif" Content-Transfer-Encoding: base64 Content-ID: <166599787786@textoarriba.gif> R0lGODlhVwEdAOYAAP////X29+Hm7tbe6NDX38fU5tvKurvK3NS8qcS7tdW4mqe72ILA/6m3 ydCqjbywpZaszZuqvHax7I6kzKuanrGagoSgyW+k3IubsXubxYKVtmaZzKGJdm+VxHaTumuQ u2OSwXaLq2KMvJR+cVuKvmuEp1qEul2DrJF1X1GDumZ7m1J7tVJ8rl51qVJ3ol50lE9zrZJl PoZmUkpzoktsnGlidU9rjFVpg0hrlJBeGXlaQkphfkJijkJegjpbfzdRdf4BAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACH5BAQUAP8ALAAAAABXAR0AAAf/gCAig4SDIIeIh4WFiSAd j5AZkpOTFhYTEJkQExOWlBmQiCSjo4uLjp+QqogipKMmsLGys7S1tSm4ubqxurm0vcDBwsPD K8bHxr3IK7rLysvQ0dLT1NXSMNjZ2tvc3TAt4OEhpoaNiuTmqurrkpac7/CcnqCP5vaHHRmX 8BafoKyuArqyRbAgL2LACiJcyLChw2fWIkqcOM2bRYvhMrYoQaHDPXPkRNhbRzJSu33vNL2b Ry9RSX2YNMnsZKlfPUICScU6FOuCBAkgDBLU5ROoCWBFg8LiWfDQw6cNJyywQMyZMIpYs17c is3CggwawYV4gKAfvQUA0gY44DEkoQ4W/xCxo6fOX02UKuXdnfTop9+fNWPKHCzvn6Ccr2Bt YMBgAywJjJUW9XuBhCxXwCA3DqYZBK7Fm3HRAr0BqulhAwAssIoLGokOELPKjsh1a+oFYUMk MGDgroUDAAIISCvALaHhcfGp4rvc3yeU8fjd1cyYceDB2DV5aotzIKzqEnB1ZsGCevXGK4R2 hmZiPAvwzmLBP3a6forbrFNAGw67WuzZ1NRmEXksaHObRiWQhQACellQAAACdDBBWhCcYGE5 iQgQYSMlzeVcO/EQBo95jGWgwYmcZIfdSvQMkpNmG5CnGQkuuECdeQSyQNCM2iTDIwwwwpCj LjASWBQJT3WQVv8wBwVzW47kDaOhCdAwBOBE3HyQ1kVhHdjCCy+oMBYCDzzQ4IMCePABAQAc 0IKFJ2DIiikd1lnXSSnN9A51GXjgQQklhICiYCpmZ8kjLrpyQYws2MiYCTTQoJkEM4BQHQk0 zECeLTPO4KmmLKQwY6QzbEDCp55GiQsJixbo6XrILGRBWlWKNosut8HwKQzJXFWrlVdaw00G W3oTVgupNaDCsmJSQEGZDtBkCXACfFBCAwAMAKYLJ0BwwAKJZDBBBoV4u0A95mRwAAQZsHtI u6C0a8EjkixQwAHRdTJpCSqAGaagGhAqosCbcHKBRyAMRN6rjLGAAw4XMCYBDjxUBwL/DzjM wGstmkHKwqc6dvzwyJGSygIJnuWy8AySMkYClKEOQwJaAGRgAgsikCvCArmAMNUH88JymwcN nJAprz7POy8ucH2wAoFeQSAMCHFlAO4yECwAATIfZHDIast07XTOIiBj9QIiwGACBGl50MKn UZMXjgdTpUaAsxxw4OzeFZglCXADAIpBWmCq8CBxHySe2gFwHg4hIYlYEIBabQ6yuAiXD+K4 AL5ZMqkKNtwg+r8Bc1LdBJNaUp1Kk8LYnsuRRswACzzwIPsFtVcngg+yk7ACaBc85jKMoGqW Qu2yO/ywpRKL+igNzJ9XqcTGXCoLzWllMENqBUzO9OTBqWZM/2rDBdcCDTB0AP7kYD+JDXDE RUO+WmWPn1a2x3A/OTT45fr+/QuAAfYA4IFIwQ9C4dDA+gBwNw6MYAR540AFJvgJwJ3ABRog 3Asi0CYPsE9xqrEQ2w7wgclBwASMQFNqQniC25jAhWtrk/pU8xwSXWAHO7CBCkrgAX1Y4Dzn kZ3EPAfEyLyOAZCCWMOQx5gL9MAE1cHBD2R3s9uJp4gMqFF5ltiD5C3vPBJYgfFwEL0ozkBi OmqeLn6TlgW4gAYrLAAEyEMt+C2APKkJAM0ikLE6thGPqtHVhFYzHAhkI3/BgZ8hYcC2AkgO ABbARhwXecgn+c8DwVnAVGbgAfg1gP8GPBgcboYzgRqxSUNpudsDVxmDGKAABRXM1gVDoEE2 RSAEwCmAhW5joQdZ4AS5hNNxVGMC9gFyAS1UDXkeNAER5DJxH+hhBmyIQxu84ATRlASJsCiB EIQAPNR5mciUOLsedBGLF/jBFBlzglI1UUYSAw0DQJApzdCOdw17mGYuAIINACmfLADBPklQ O82sgHkXgNmsADADirHpALsqJAvY56nF4eChGJMoRbenGk89yAMwAA5EPcWrFSwOBourKCRh 8KAFqPQAukKVkHJ1m0hhSwAsKxkmAVC7HgAnBDRAywHANDkCGGByBqjAKiGIghw41TcWfAEt AWADGwynARH/eNAALsjLE1yVjQOoEbfilJZfJitSllRNjYYzFcCBA1A9tOEPchgnVezzBJ+T nQR2WJ0L9rVlDDjBw5JnTiFWJ53qTB4NSFMjzYjgnAzAHQ7sWdh8nrFhn7Jn7WzHGBf44LOg IQFoPuYpF5CHWAAAJQ/Y9MmStY2jDXhYsnjAQQL0gAevTZZsAdDaQnYyWyPTmEk7ii0C1O61 xd1tA3JaMkl2dLY8WKgFIlW7qfLAnMO5JXAIUNW0GOABwzGAAyE4wQlyIAYpygSaQqCCDFLV Bve7n7ZekKwaxTctA3gYDcZaVhZAl7UuOCsN7psta+4wmpOywQ7U2YMyDqIzLgAN/whscIIm Urg6b9SMCzg7OyaWE7ISEMEJeKDOxHaWB6TRZ2d9QIIm+oDDLOgBPjv8HsZEimLJ26zsPKtO FzBmA7IbWcY0hVqK+YC1m8VB22hgy9ohubafXXKTV8vbhxHYuLU72m1mUNwoAyAEOCiuk6u8 WYypdAFMBkAENrtCDGy2BGmR8Q+uvIMbpCUBFBhOAlYpQQcggDcOGAyaNBACbM03LQdogKIx UNVkgQnRim4Ao6vKX0gGmLfmZO1FeXvcNkVaA1UNEw8T7AN1+sDBInAsGRnzWB9HtgeuZsBg bTxjF1Q2i7e+QKlLbOIs8oB5F+OwZ0XQxB/U+ta0q7Gse/+6Y3NCdgYl9kETf+xsHmSKBUXm wZHVXOa2bToCn21ybY2dlhBQGdzbbkCnE43VEHy2dhqraZd9UG4esI0A4eZ0mXlw5m9/1gc4 WKG7fQBnAHx2zm2KgMJDsIMapOUBHEhNAl5JXrLwxgCChhChRbqstGDgBTbwpugc/QKPgykE JRCdDSptAWSpOdNVtqU5y/0w9ppz5dicVA+iTYM4DcJCmjmBDYjNABH8AAfFjjUOeqAZKTYb sraGrK553WtbA/vWJzh1sdeJa6jzINY0kPGxbw1tU+Po32bGdlpA2YMpdxrMtsx3BHowboSX 4Nxyf3vtSvCCf2cMpaqhQd3Tcnf/KG977tXmN2zPbWqAk++zBTcnvQFQAnMuq+FpocAI2JQA GcgAgs9SwJ8xLpP1hmByEVjWVV8wOAKIjrVgWn3rRXeDF5SghG0qQXZxyFobyLwHyQo5A29+ Tbwe9gL8fPF+xeqowPaA6CY4erF7UJ0NKJ3rKvjs02+36xJDdgM9AE3WZyyB5hud61F/evV9 QINja3/Fpi5j93uQMbWndsxr3mwhcYD6fNsWWw2gTtnVA6inTlOWGnMHZwRgbMoHeAVAA8AR gD8gc9iCbnGHdlqmGozHgDwwVZAXZ+aEgD2ggJgHAA+AApNzgihAXg4gerwRDw+yFpMjAP6C LQHQALb0/3q8BSY2iINqNjq29wHDsRZp0QA4BBw3WG7mxEE3yCYYcHMUZnxApGvWxnzNF2NE Z3RIF1nqtE2yxnXtN3bcx2v0B0VAJAFiZ1hRVHW3FnXyFFm19m879m8+oGyIZWr1h1o04FD6 VjtIiC1qZoBFODkYoE5/mBYRIIiIx4QR4IQciD4r1ACTowHqxEGBMxx9d3hoZ23/k4Rfpk70 FQHb9YEA4GyM6IQ1UANsEgAJcGcU12cKcHH8cEDZ0i+FUz4QQnvJ0i8qgIsCQHui9gFsExxX hUMqAD7Dd3MrlC3OhnNSGEQvhgNWSFlZ+AM0sHXX2ERBBobGtn0u5n04sF+GNf8xpiY78rQB JeaNXcd06zeH71dO71Yxj0KG9bdQe0hl6rZZ7iUcgTiBEIJfO/cDU8WPieiPiGcDyzgAjfd3 eQSQDLaM6KaJ7/Z3KzBDqVRiKnA/AZB9BAeCPYCQ8vUDNTACFKAWqfEAnocCElQBorcge4EJ nMB3/lI4ihYBwLiLzFKTtFd7B/YBE3AAIZAsOLQDKhABkjaU1WSUGDCUVXVgj/ABF+QCS2dO 0sh8cEIxVelsNaJt7yZiAPcw6jQy/7Z819UDy4cDdFiFm7IBIJB1PFcjsCYCUlRiWWlOy+ds txUnLPBZZCl2pkU7XGltTcdr1kYeImABH9BQOBAoqoX/MThANC2wLAFpeziAAU/YeCUQAYUT kL9HfwqnAWnJkKphAXMXbbQVASVAh7bHldEoXCsgAhAgad3nA4UWAWznAzvAL3hpAwq3lA03 AiqpghzgeTKwghXQggqQnP6QODIZamHCLDNJX7zFLND5AsDYk1CZTEZYTVWlYLvZnUz5L37y J6ATkD5Af2JFIDXCdnjZnu7ZfY33Wea0b2WGl9KYIw0lZ6Z2W5sFn8bWnvRZZnTono5JMbWD AzWGhqYJKrDwMXv4MGUWjiXDmvF4XXT4Yj1Fh263WWI3kfGmGkvHaxV6ofR5NMagK0Zmmo5Z lgS6WUOZiihAnDowoykJi8mp/wD+oCb8MpPLAij8YosqgJPUaYv+cnvQBJVCyZ3d2YwrJ5Xd aU08JE3WomA7cJ7oOVZwUiMQGqABak7RhpcHKmRCVmY0sCk3I5UUeltCpp//eaBJtqVhyqL8 mWQlY6CL9WMkZmr8piMN6iliql+oUjtpyaGbSKj5lo/0WW3XdhtoKaL7VqhJlioEwjIUGo0Q CqZc+qLAKQM0SpwqOUEOgJzO8Sc7+pyB4k0oxyyL86M9+qOFY6RPWQLJQnvWBCY48KTMN5Mb IU19wi9VxZ1jVQhR+aB/WqwUA6ZiWjLKemMjY1qy0CgGSpVD1lByijHLeq3KaqD0GY6foqxU pG0Mhv8DJdWgpHWtqEKpEQqnb6quSMalYepcC9Coempt95iuQqYxOYKiLGqtN2avf0qlojMC MuBUOTCjOhADEXScoTqqpOqjITCefoJygHIAA4CazOKjGHt7ftIniUOxHzc61GmVcHICywIn vNqry+IvwVoIJhCVVviyzEes+gWzNJuesPAK5PFGJGOFMpsxMHuuMYutJIUNqPITFwBKGLgx sHCi3oCfMpspfhpcqEKsC0AAGrBvEqqswkWxGWBkEwm1zEUq56opywADPQu22Jq23fkCDxQD BOtUCFteoioJ6nCkD7uxfRKxqOpNgLJDpyqxRipNT2ktRLpDe+ujg3CkPpr/OJTgJyUwshci Ah/ACrAAuZYLuY3CfDCzuZtLCzmruVACupw7ui87uvg5lfSnKcpguvh5rtmAKlASU92qrQ8z tiVlDNQ6n+G4DbvSDdGgKyUztLJbs1ZYOA7USjkQAyNwnDc6enRLEtGEt5MAsRALuHdLvSf7 CI7bt4GCvR4ACRALTfkwvX7yAabQCIQgC4tAEJArFASRvrGQI55LIO47v527tNBArVnmAukh CxMBM8eQI8sQuyxDMhqzDcuAro6JDQE8ugGSDbELwZwbFstCARwQnAmwIM3LGx/SwXZhCSeC qtLrwZJAaKh6IjXhwXOhCkeaOOhrHDBcCIiBGJch/xC04B2xEBCzQMP1+6w6W7tRohC+0MO2 ULbMha8BopjcygJYMQvUAMDGACWWKzjPsiBWfMULQsIn0TmdE8IP2w4efBcnMsbuIC0pzBx2 og4fARIxTA6IsQiuEBIzPMd0PMcFsTKSmgJEvMcFcaK7oiq5ULayS7bVIBRXcrmBQgEJkME3 2pILwsEkzMWSnLfSdMYfLMYonC978bxpvA5rzMZtnCgCEcrdUcelAMemrMM3qxPkqkV8agI4 zMd7fAwSHDOBLMiHFCtMEgvBsgyXewKJfMUKEKotiMUvUQmSzMWUoMzIHBj5osksQQlp/Mlr TMqtQArWLMN17Bap/MYsSySuZopCkqsOgyDLPRzFQ3LL0SDAvSwbvxwoGMDIyUnMyNm8gQAA Ow== ------=_NextPart_000_001__16659973_14467,92 Content-Type: image/gif; name="bajo.gif" Content-Transfer-Encoding: base64 Content-ID: <166599781457@bajo.gif> R0lGODlhCgOtAMQAAP///+jo6MzMzLe3t3659KSkpJmZmUql/1iU0XaAinJycmZmZlRUVEJC QjMzMwAAAP4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAQUAP8ALAAAAAAKA60AAAX/4COOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWG h4iJiouMjY6PkJGSk5SVllcOlykNmX8OnJo2oKFfDgwMDaR9AwspAQCpNQ6deAkAA1yxD58+ AwAJqjK2uLK0wUIIBwcIx3q+rScAsDUG0rp2w1oOrwEGDAABvb/NL9k01dPkQMnL6ne+ANAl 1jXSAApTCcBD5ij6Tq8MwIsnbp87Ff1k2MMn5R8Ph2rYMTtIZ6C8EfRoJHzSQBqRjSQ6AnCS gGGDBNd2//gySPEEyHK3pojkMXONxJZzBhIkkTFNTSEvRfyMsxKnv5hqhuJQeubmiVkljJGA qoJqValGb/gyIEDaxZ4PGHQFIIDBCgYDDOwagKuAtAJrwZkVgVZtAm4MSYiVVlZv2ge+FCQY yzZk1wBwE7BasWCsgItBB0srPKLB4cSLHRR2CwCuZrklLIPD3EozrrtI9Tqeu0I0YsDjRjTm exFFgVcDUpkmwRZridlk5e3m7NlXANZ1H6AOkDfs38CyHde+feuaa9IuEu4lyxpF8uFv4x4f kXx5c7qr/aoNLPkWMaGXlWcujPp9e8oigD9uoX867pQlUJfbWu8BNoBvIjjVgP8yCDjg1ALK HHCNgxE6UOEIFCpjoYYksKOMLrvVl5ULRY3FWk+c2dMZQjGJNNZkr9jTyTAphjdCjTYqR9ZY n6kom4o7xmYbkCuKEJROI+UHpABdAeOiigPEKA0tCyzZ5AMi1SgACTgWmUKVKjIpZJdwpaBT OEOBZQKZQvEFpZQAzHgLjmXqKGacIrApwpk/hnllC/3oeRQuT9oTpYpyDkAnl0TWacudPdrT pz1iOvlWmHsCeWOjKwjKJwp8ppnOCU4xwGCEDHrI4S6ottrJhq2uCiuqsWSJ6YgrFPXAYZ1k VE0AKKElDUslZCMSMTECs01stoCzQAMLxDjXr8HCs0//swMwkIkDCljz6mSooCakCb8q0ICw 9xiZWlTdwvLtLeEmi+VkIsi77D4OgHuSvC5mwlks1J5rbQr5wrvvsCKUK7A052EIzrlligrg CAqji8+x9SJ8r7rOQistx9l2UjE8+OQbAMQOGywusSmYEzC6LI9gLL0P2PvKtdIE8Gy00kwL TrUI6wjvtu2OUnC2B4/T7wP/7lK0yOCYa3EKIzO8y8MM1GmCySjPm6QIanbIIF2oqrqMhxOh rWonaqPKNoewtkmWv2HjypuQ3GRCT8HXGNdyi1OqG06mOA8+Am5Xjwrb4LYYLjejBRYc89UB GNO4ugWG5tGmkSMskpyG6+pW/+dK97Q3WH4PSbqy4FgODgomGyMx7K2TcPnngo+g6+UkIK6j 47Hb/nrwkE8VNAvZ8H2348UCjufvujP7eu8xKR8949NXtnme60rutS4Z/UR87k/VLvPw5hOc vtc8KV5CqREKFWHaY8P6NtwXPuDhtgzOkqFZIgGf++x2N4Msq3L06NaWjDdAzLHPgYRTl1pI AKYHKDAq9NjIUF7RHaaNiwTtIlLggvLAjHXQLZb6Wj90xcEAle5rD0ggWTDYwJoB4ITjCKEI EUQc7cGwbhYUoYx+skLpTbBPEBSBDolENy/ZEIeTM0E2LsjAiemIUNsrIs6OqKSRUDFlqdDg 9p7owv8Utq9W21sikHyjRkR50Ikn6OHjMFJD/Y0tLHd8QP5M1Q4+TkQEF/IjCQIZq/mVMIZ1 tJuuRHDADK4LbDWcmQpTs7sPzgQkjszc7IQ3uWYJMRMk3OT5zJhEXanJFqSEZBgfiUgrnnIc ntxhChTADQCOEYixZCIRKSk9YtUkIblcoxJrqcrmRbF5p2ElLp13vvdU0pceweQ0xPhD96Hy kOHLohADJ8VtPo+WoJklMUVpAvi1A5CrEqQgR0DIc6LzAJngYyGZQU4CFjAqUkoFmGQ3RmSW UItJVFI49hmSzVGTelz04OS6xTx/omCDAEgoCv/Jy30EpIzYnAZBfeiKD07/lKEaeV09RwDS h2rTmdLLXJWwV6CSroB3F2XUMYWHi43O0SXMLGVKf/M6mz7woIeLKEY3+ROXtsCof2toN9F0 yzqa8497HNuCVjVVeGIpQrW60FT/qLlq6sKKWVkkhmIUi1cI4FVd0Zo/d4lSnO0kYxadGyPT GtBDuqVyKZtcwbTmAIOEcox3pYX32Bq9fQQ2rxktq1x3Qdch4ZWRGsvRLmbaia5wwis33Zpk +3pTgArtIjcL6F6nwpLKTuOwkBWSABKAIHOYFa1wpClF28ox0MbmtXMtElC599jEpbKVNx0t hqIoXEaWVgSWJRhy3YXZQ5bzjuvUYzrviKoFQCh//2Vb2zvnkowGJXa5Sg3rBxn5ilh8YzLw WOCgZltYjt0iAQbgBnkMld5mdpWBnUnAXcdLsZwZQDFB+ysMC5bf/abSswQugH7B8cIz0oW+ fKmKPRRs4IT5F8D83UUAuoGOTHUDNWotATo+PDDCRlBo741v9jYy4v8ObBsc3lyCFxzaB4Cp k0g5r3si/DcsTpK2KB4AfOX7YPTy+Ir3TVmBGfzbbMKwxRiOIpRfvGEDdPgpVb6ycf77ihCL 7ZzRjeo5r1vITlQ1Vp0gc9kySw+RJJIiYp3KycgDp8x108f2PfEwzmQMBtRZtgWFoY2BtIA4 uxBIRxQwT1VU6Abr1CBgsv9Ho5s8Kj9DiQWR9soiu5TQErxoJ8uiFAs43dmKYo7PeWYUokfw aXlkOh66gkeP6XxpFuH50adWUW/D8udUZ3bQjC4KUftJahUUe1eMTkGryXurFDyVndN1p6qq Sgt5Nih/Nm7VHzdpVnsyEqxYkgoD9IGgqYxiFLtANy8cWGghe4fcUUF3ZbDigAIoalvgFoq9 02KMT5Q73FuzdwHwPW8MqTsl9b53ugteGQCNm7UuSPjAFx6SfRvg30Ziy4QEMoCGPdTishPs we3bbmL5+wQNAHmxNB4VgRMckl7+trjhvYKTA1zmBic5Wyb3cKnYPCT0djnFby4U62Al5Wy5 eAv/kM7vlQ8IISzHEMc9HhWr7KLfVrf6Lk7BSKv4jyrYFsoppCLvBljH21ogIdr/oHYk+LQh rFw7TQx5VWXIfQ5tv7se8m4EX9g5CnzX+wzalkfBtyHwhqcD4ofgi3wzYfGJb8Gs6B55NhR6 ppWnw+UZsfnM76ABCAj9AjDu+dKb/vSoT73qV8/61rv+9bCPvexnT/va2/72uM+97nfP+977 /vfAD77wh0/84hv/+MhPvvKXn3yzO//50I++9KdP/epb//rYz772t8/97nv/++APv/jHT/7y m//86E+/+tfP/va7//3wj7/850//+tv//vjPv/73z//++///ABiAAjiA/9hnAOYCfwZYfQlI gN6nD8+3gPYHgerngAwYfRLIffpVgd53CqiggR74gQ1wgdAngiAYggdYgvDHJM7XLblhdp0R fy/YeNH3guIng/yngs4Xg7DwfDZ4fT2YfTS4fjg4fT+4f0HIfQrUAD9YhNbHhNGXABKyfgqg DCjxfsmgfVf4fVCIgujnhC5YANV3hFwohlwohALgfAJwMjkIhvD3ggXAhtBHht33hk94hvU3 hB0BhnT4fHQ4GNe3h9snh+aHh9EHiOHnh+T3goiofW5hdoaYcnCYfY84fVuofqZShfCXAAhg fQuwiSfhiQ0Yhfy3iPE3ic8niF9YhmtofaSoiv/dh4NZ04Gp2IaROIO1aH6NeId2OIvUl4vp h4rkR4jr54vi54Y7yIjHOH+VmH7L2H/NCH7PmH/EyH/ACIwaaI3T6IrbN4QquFIvuBd2mIYC AIdp2GU3Yxln+ILlqDPQwmBg2I3ggBh5+HzgaHbr+CzOxzMo0Y03AyZnWI+WsWGdcY4rJY/6 +HzriAoqqI4bdhzzqIJ7MRiPwRftuGHvGADjCJFd0YIHmY/ueC5dsYv2KJDUsY/pWADfYABK qIYjuWGoUJDv+I8bCX0RuRcc2Y8UaZP0GFEr+XwwmYf+WJHy6Hz1GGnoCJK/oJFk0ZLsGJHw aJHSV4mhlwyaeABSswz/BxAsEVKF3QV9oeeVy2B2U5mVyWAuY1mVZrmJWQl6oXcAqPCVoGeV pkKVfsSWYhmWbJkMqMAAZfl8UtmWHdiX0JeQATmOAHmQAHmPQfmTRBmSTImPZoeYM4mUEomU duiNYPiTmOmT57iQkXiPR/mNjtkAAZAbApAbOomQDamQGImSk7mZnomU6SWb2ph93HiGrRmD HfcLopEAspiGjZOEsQmcL5ibMYmObgGGR8gW3bKPwHKEGKkAz6KC0bkAwoIKzMmbxMkcS8kk yUmaAiCdqolCofmOncGb6niGUSKdTHKdyKmOvyAWZ+id9wCe4ul8xqmEu4mJARmc3XmSpJkb /9WBhudpkt+pgvR5givJnuNYn9Xpngn6fKXZES1ojw2qnCjpCwp5oTy4n8IynerJHI2hnvvZ nzEoogjKoU8YhaKnDBCyiaEHhSgRo2vZopBpl85Ho8/Sogfwomx5XT76lTWKABAyozBKpHyJ ADLKl25plzr6o0NqnX7JokQapbKIhoihnfGZnShRnfrZnCaaoTf0npHIpWEqoeEJom5hLus5 ol/Km/lJn2CYn/iZpuWpmrZwnLoJpmnYEQZan1hKnk0in2sKngcKoOupABr6ngpam9N3m/P4 grfQLceJkPN5qXcam5Kqpxg6jzm4m5x6ig4ZmqOai5Oankepqco5qv9oCKDDCaCoSoMqaKqd ioOq2hGsmoqSCqqWmqqYeqJVcqO3GquduoqRuqodSKueanZREqyn2KnGqKuReKp6uIOxGZq8 eqt3Kod/6aRqiRJrGa7gWqX8CZdmJ67emq5fua7fapdDuiBViK7diq5COq5XehJUCq/6Kn2v 6oK8Khf+Sql3qqxHSK13moOjuqmeupD/Cq0Ou6y42oHXaqEPCau8ikpjqrCtWrHSeqzbyoYE e4uOOpi7OKz2oJKEmKK+yrEKS6wem4Mne7Bm1zgbehIAa6oxq7K3SrO96rK3eq2zuoMKa6uw CoY8u4qSGrMbq7MA+igsSbEtG6oFy4YKy7P/IeuXZPG0HhutL+uCMZuLQJuOOVu0UFus0Net 7Kqv6BquW/l85qq2RqquR5qu71q38QquKDGveOuuKDGFCHCleruv0devbsaTPKsiKAugVwuz 0pC4EHu4DxuaMRu1WxuJPDuxmQqrMfsNfdq1mduxQ0u2KSe0Zjuy/FqyZPuCCZiymKqyLhu6 lfusJiizM1sdODgMo5uKq9u6oou7G+uzZBu2ueuxRPuyvgu6YCiBTHun51WhZUu8ojuLGou7 i2t2zRuHD1u985iAYAugd7q7L6utZ5uvabu2e7uWCXCjWXiue5u27ju39cq38gu3+CqW7Wq3 Zue3U2q/9Hu6HLu9/weIu6prLrGpvQNMuzYroJEbmwlIuZSLtabpvc97qwv4H55LuA4stSBL uhBruoPJHAognx0xkXNaFtopkiuLoCfDk5pKwkeJkd9QujB8whBbsxB5lLk4wya5sjMMhjWL pd/gnB2BsvGAnsfpkiKcwyZcqdRpwsFylDnowjrcqzq7wiopGjeKxXC6xC/sxBJ6HH7mxTWr xEE8mPEAfT08j2QMnV7cvaQJxk1cxrGJxHFMg6yKtvD7t0N6iWxpKgo6hZgYeqayo3kst/Ib v+x6CoKMvuSrx4Ssr28JivV7yH/LANalmnJsh1Ncs1NcwDuYxnWayTXcxWVMx7jpxcFRnP9c nMqRaMNW3LMXOcTgWcZKyJuzbMsjKcq3jBKsHJCyjMRrzJ8ejJALoYLGoYg588NLi6meVLM6 2GVHecyl2ywOibljAaKicca5SM02jKnSnM3Cmsw22zPZnLHH2SxccYa5+M3Fiy326BU8+JHc TMXMbA8dGCWDa8+1DM0q6M5YG1H+fM3D6888qLX7rLDr/JHON89ujM79LM6x6dDq+ZG0tL+G 3F01ipUocV1/C5ZrydH8+77pSmaRrK9fOYVkqdGT/JUgfcjKALj5upYoDYWSPBbVbIfzLNA5 rbg7+M0LDdESDM7j3IISPc4O+c1IrdDvfMbNDMvjPKbzbLMdSND/S33TtTug39zU6LzNkzHM 07cAChDW0NKBIRzC1nuCUuqTL7nWkWnWY90Abl3WbA3XDGDWbk2UaI0Kd30ubi2ldd2BlozX +cjWaS3XfH2vTJLW0NLXlkzWcw3Wbx3Y+fvXb13Zkn3Y0WfYfB19UtrZHQjWsjih0Gedim3Y sJjFbW29kEnZ57LaqB2g0mfYZn3Zmi3Yqh2Zn20uaV3Xg03XqV3YlJ0W9AjYe1ncuH0Kh72W 53KvRCmLyG29xo3c0m3cy03ckW3dYz3d0L3d253Wis3dyL3b1G2h3u3cJ8jam43bvk3b6H3W vb3X6H3Zi23Zf8zaml3bmN3W9yqlfX3X/7xNlDcq3+T92c59o5oN2vkoNa7t1QyugcLY4KN9 xtz34OrnrI6aq94XlsoN4elH4Rz+gR7+4RUustEXi/lI4h+4AChefiEO4fFVfSYemZX6fi/O fSrOfr65geMHhXg5gDduff/F3GYo4uv346O94trX4kQeaSicfSnZiJEmst1ygo2Ykjt5xdlX JeZSDfCXjd9n5aMt5GUI5pwo5vkLqLnbLVh+LjyJft8ticmIfnFOfmTO5msOgl5e0DAMf29O 5HZ+5Y6Iy9Ln5Xlu42bu53A9J8Ls5I/RiGreFcw95c5X5Y9Bj5W+Wtgn6YV+fpu+fWKB2pg+ sp9uGYu+fZIe6P8gGeCXXurz1+mk3n1+ln6j3pivjX+hbn2bfhcKxgr0aG+NmjUdZ72+nr9W 5g2RSYLsd+vUp+ztN+qYPurf4LyDPufDG4ys7uenHn6Ofg/ZvoJo7urWeObm4urkR+7hF+5j iOTWl+3gru7u1+7dpxiIbovYt+nxZQCoHSUbdqP6zo79/iz/zqzsKH/hju5yXosLcOfTvvDl Z/AN3u2RSRbgYBzYKfHtqADbHtb3oOVcrkC8CeX12ThaPhaKCgu0/HyaDgtVMpkRP5kiL9Xd Ei4Mw6wMVrsDbxw2n8U4r+X7nM3m0iy6LfGlCbC+YFnSV/Qqfw9cPs4KWiVbcdVB/wz/Qk/x Iz/zQO+Tt8CTHA8LHo8SIP/zznIPJF/LluX0ybjzSp+MZq+SZm+zN1/zW2/zY//yztd4tCxk bq/zD8P07bgSNxTzPC/yId8xR2/xHqkAXL7yA/rTJ0P3OD/3hF/3Nc/3C12aWRwtbNEN+Via UYLvnK/5lo+PmB/hT5/3fZ+MjWP6im+aM4/0cm/1kY/1pX/1Zq/4Q38cVb/xg1+fq0/z5WX6 XI3mNk/2Sf/0Y+/6bf+ED/Pyvd/zfG/2tlDXY4r8WY9+DKXslOoLb8jtv1BeU77t+p7oGM/1 t7BhaX4PMVwSup8b0V8NkV6f214ARn/m8p/0d3GGVaJfJ/MN/2LR+N1v/yAQCE0CJEmzmGLT kiaqAEp5psDQMAAjBI2sMAAUCjNZIgBwMZFK4Myo4/maxMBv1/vJBovgsHicqXLaqiuIhSqk 3bV7tiskZIoyNLnsLly1WNRS2hUXzoJK0kjNk53UXAIeIosfjwFPSwCD5AilzVmhF2JBocKj 3SbToJ5V2x6RgGDLI+rfTQ5q59Nn6kDAAANTksGCr1/AsK8wcY5IAnBDr8Fzi9oPKp/L7MpI EKxtni4RJM5NYio14dQWlBcYkZHCKbndbvfS4hKqI9VPtriTq1HW5q1w5eWcNnP2Xnjix+6Q iVHgDPY5Z/GiRRnNWNlptCROKyi+gP95ZCMFpCV0ChoQmZJAAKdUdhqAlDIoZEqbvgTksKRg CM2PS3IONdGCKBNLKNgoddHSJ9COY0LaTHXSFc4ZQG9KgYqVjdR4M1gWaOCVVU2sV5kKmtly 7UwXTU3GosvGrNCgekumbPE0r7+XMYvqlWsU78+vDXbmsNPXMWCrke2WNHw071yyeAu3WHuW l4hpBo4tk0va12hkXrCMZMA6wEqVXfPGvWw7rd+ynmP95Yy2aOK7YcNqhhy85G69s4NbVq5W 0FvaY8/1Rcr38Nm4jJ3fxejde1xLU8PCDdSdsnncd1suhrVU5lj1svPaHOA+KID83Ne6Nro2 mxKAlBJgbvj/6TdcenW5UB5V+enHlVAOCjfeVJoZISGE6DVo13q6SRebLARWNt9dazH4n4WT tXeYAiOgqAOBFx44nX1GVYacgp1NVtKIhfFHYIq+mehgjgaM9l5qpR112gBJFqNDLyeg9qRd DDJh04nQechdgS9mKONXCIq1UkseSYjjfvQReaUgWXb5oUVYfuhIjGvGVSMKVn635zlxMRAP WFO5WRuPCXLoVlnQ5DcNK3uZ9yVgJVwixQJbDhkiD1729+dYmwZZaaBjeqmjoxuCCmkKZc0k JqJ6nUpioRveOFZ0paayaY+xplkqirVW1cIQl9BkqYKbUqrqdJKS9Cia57wY669y/xbmqa91 XfqqXMQYYAwyiZJwGh3gmmYkk6iCxCap6lXL2bp9GgrqqhSOWZx58Bp66VrYSqsuseehy11l xuaDbGzKAjwdnwlDYcAdHE1VwnHmERpRQL2UWoI0rULBCQMFTKNCWRbnah7EFk/RT8k/+ORN yrLIsEDLTHD6Racva9aymCULYkAOl0WcgBQxo5OAxTiPxSqtZQmdh8gUQyHEDyBhzCmZSmul WDYvI/ErEk2v1PLKrgB9DwDS3KxVP4PEJMDXaN/6stGx7dCPHVPX7bZZPb/A3NDyvSBNzDOf /VPaiLGMdwsLDFDAaBWlIEKUDAwACeQBUM6T5TQoHgDMU/962/UPcQdTNgNx29SSzn8Dgzre PKtStNvxjklcmTOYDtzhhOu19NSpg16g79O53kLvsT86s+gnE3+1vwp/J0N+MYVKT36MSIzw Yvkhq32p/c2QtCyHGeG4ovkJyPWjSgDgOJXqo7ADAE9kvz4U5MxPPvSNjWE/e+5PL0f1BCGA 98BPfupLlP8GYT5MLFB2YtLM/N5Tv8MccIJboof6WlVArNWvZxVUoI2mo74+bJCBLfEeBEd4 q8OwxAUqVKAHG4iwJ2EwPzN54QD9ET8FVbBHKFRh/gp0P5kF0IQS3EIAvAUsLPxiNDnoxUig wUTJsaYsVAwNCJcCROz9MD99qMz/CYuIwv55sQU5RMcCIzih2VWodivxX0lKOESdpBFTPCgi 9A4Txh1254ww0s8WQxJENdbmSSWsjfO+86d4MOpPOliJI3WwAE08UpKVlFnDHklJS0byTwyI ZCmW94xNMuELo4Qk+RxJylC6YJJNmIYmVvkx/DEqcRWJ5CHSMA1WqhKScpskCYtVKUH8iZbw gcQrXabMXl6SlUCoJRIcV0yXbZKSnSwFKEcJzEuWUpqZVMUtQfTMbGzzkd4kyS5r+YJRFs6Z rTQmN1NwSmpGcpxTuFU5sxZOS2LyGc7MJTXSiZB8ulMWBRCnLE4ADAaYrXTOSOhDSzeMbCjU CsjUpTLf/+bPeW6Sl+X0pD3tuQOLwvOalWTmOOvJS1TKgqDaxKhGJUnJaMI0liSUW7FYuVJ+ AjSgGU0cLLdZz0QStahG9YMSvwMTPjHsIk09KlTlgtCofmcAevtXwhBJVfBgjzpT3dNTt6rV rZrlqy6MCdGKagOwmjUYVyUrXKEa1kQCjU9jjatT2+qHq94Vr37dU18xkta/ErawUd2KFaT3 HRZ6hz3naAliDWsRyObIr479V2QvEli8bpayCrtsVDe7wkzsCbSpAEBMJlfUpZY2qRb5pGTh Ojd1KooJprUramvLBMSK9q+3vRUwotLV2J4js1TtLXBfGz/aAquyxH3unl7SGf/X/kqRerWt a7uU3XNIN65v2W4qulvU226yCHsaqmTR+1jdgHe9VJWuer1jBOaeFrxzaKVRWbvY9kIXrvO9 iHmdwl8AtympAY5nMBTrXf5217zxJW6DB5zIeoq3qP8NLycO3N8Ny9e5pLLsdn9LYLyKOE4e bi2HiVvii6yYT9VN2ET5VOIW70m/jZVwio0aYxnjWDJUfTFcVwzkHA/Zr0VmKvkWdOIcR3UH 2zJZ4gikAiwUQAW5XSoxTGDlfMQviTpwTw9y2wAfCMBbU/byZcNcgrIsNcyc8AEWIJJbN6cC zlcwCp1voAQ2j+DMbGaNnEeQZxeQ2WOw4ERL/PxlE7T/GRY9gzPnFs2JLEsQ0gs9tBlFUGUC hfnRgNYzmvnMEgeNg8p6TnSXy0LpUqa6ldEbs6YVXQyeSDrKjJ3yCTGNXVArsRick8EndW1p i+Dairom9AhaAuk+KJrQWLgzChS97FrDuszNzrS1Wz1sLO9Q1a1GCKa3PGZBu6fRYl62lckt 5nNsW9OdTly3x62ZTr96qbO+xbdv5ehMY+HS5451qtMt73vzGtZ75rSwAS3wQfObtIVWNL2v rO5Se5nJRC2G/TDBtj7AxAgeGwIw7L1xydGv45CFjeIGgIQxm2AaJi/LZXtxB2WPwKor98Ga SR5clTMW5/GTQc15jgJN03zc/x6Hdc5BDg2hMwHMNjcKzY8u8wUs1eQr8XnImC6Cb8LaCCh4 OgrAvHWOl3ksWDd6S4pehDW8vD1Hb/vYm152b+mc5c5oexWMAvb2cJ3oWV+5gNGuRB/sAGg/ 2DssvG4Rvy8d8GZM9p/XLPimW+7nEn975f9uFDC3ndAtx3sSNz8CxneeF0InOdmleIelIj7z dd87u0Mf9s+X/Y1zl/fJ46H0qv9A9Ednd+27rnemc37udec9S8J+e5/DJretT/olYJ9pxRdf 6rBJTMhrjvLSW1xhvVAB+ZZboFrhnrSFSTvME4WDIMh71+jftWaWuv6ik3/+gx9B1ZPN8/TH H/L9D/8SS+yf3PmFAL7f++Ee/8kfzBWg+SGbZthf+4nfA4qaASYgx5TNBGagATbg+CmRTbDW +9XAJUCgBAZe2gmgCfKfYZSAfeQABCrgZPEfBDog/cng/ckbDNZgALIfCKrg43UgAgZhBU6W AH6g/+GeAMLg6aBgnflfD2ogBaqgETLECPqg+0XhDhZdBk6hCK6OBeKg/vGg/y0h+9GgqEHh h8FgBnaf85QAGlACab0fF4rf6digXzjIttgYGgbe/xFJHo4hdODhAObfqOXHtrxfDmLh6Qii AxYiBg4heySiEApiCXBgDgoia1WiF/ahHWqhJWwiJPKfJl7hvzxhGKGBH77/AAcaICMC4WWp wKFBHSYeYX09YCsGoSReFiFK4iUaYgRaoSliYS5aoVMI4hRGYrLNIgCmIvD9HxrqIHtM4Q6g IjECYS9iYDAWRpuhVj8gIv59oyP+4TLeIgxmYzQK0BEeIBsmDPy81Qu4IP9N4Tuenx1qRlPp 4RDyoQ7eIyAWyFztov81lTdmoBJqSVkNoD1WzR7yov89RcFknBCWBT9SAjxyIhqy1pOE4hqy ICkq2Q+uoRL0jEMuz1UN4VzlYzEGyyZO5G2ZpDiVY0MCIzgyZAZO5Bp+5EBCYz3WYlMdY6LA IEtuSUJaBEy64hceoDyGJBC6l04eZDYmJf98ISGO/2RB+uNLOiGi1aNPLuU6JgwsJFn2tcd9 SaO86YQA3Fe/ucZZil4qhIY6LkYm3JfIFV4QmiVdOiAhuiUKoBbIDNxaKqIg6CVCCmZLuGVZ pOVcsmVhruX7tF+m0aVgslZYRqb/Geb/yQDDqOV98eVi3ldYntV9eWT7WaaiaBFj6oBjsoQA 9KVgBh5pep5GaBxdfiUFTQNnHuZpOhtLiGNn6uJMjt5fBiFlyqZvEuefzWayrWZvItA0COYU IiZwIicAtmYDEh5biiXUKeef7SZcfpI8DoFphmYDRmYmGMVwYqdQshZ4GicY+qV0kl9rPuZ1 WmZaPmdckiYHdqVFQJnn0f/PEOyZNuJfGdVHvEmKAUiKwynWf76lgRYdgoYl+T3oIIKjhC6o qFloXQqChDaihFIWgBroUknKo/mfhMIC/fQnaZXom5WRiP6ghw6kiV4NgGIohpoo+WCoaKpn vK3T8oifje5WgVYPo7xoUqXEk5Sog5BE4WDohvboJcAgjv4gIdYoiQpp+0XplcabiSaoosxo vClA4UjoHJZNiFppVb6A+IFp05kpJ7Rol7LOoqCpAchjCTwDhqopJdjPlgKDijYXgNKpsFBp e/ZphFopin4mkxrimPLMlxaOfi6eO4JUQIXSJrmSpMoSK33BT7mSTIBUQWlqKHFqPbkSpXrT Obj/EqrOky6F6kaxakqZaipwKjfplKRqqqg6DqmqqiY1oayO6ikFVSuh06QKK6nGQ2yUAq0m 60IV1DO5U6Wmk0dhUtaoE7LqKkxVKz7JU9YEK6c2Safu1KlmqrA2K6OkqraSq7aC67mia7Cu avZxKqdiK7p6q7S2FFAlzkqIKojkKj9xE70+HrwCq7vi68ew1LmS0rxui8w4Dkz06r5C60JV xK2+kquaKzfxKympV8M+g6zKq6Y+K74OKzQo7KMS24mWLMqmbH/pocq2rMXlp8vCFcvyCcz2 lyUqWIrVbCPGbI3hbFzpbMmOBs8OLdFC1cwWLVF1zMf02IZhC0LEldMe/1XUyqzPKpLzTG0r MS1qImT30ddHIi1RVi1Zee2jyirYni3allLHMBZCYGDaOlltHJnF7QPJXoRrJFEBiO2IbZXc QpXZjq3b+oazLNme/K3KGi7aIm7aLi7jNu5R7YA76luSyawE/VUP0AyI9C2RLcHlKhVM1JHC aK6LEW7Jdu6H7a3jpq7qri7rtq5RLUDdphiNiRXCiC6H2a7FJpLtfsfupuyR9a7rBq/wDi/x +pWkPGToxA+zoZb9VOLywoIvLJcKtM3hMe8NQO9/8qkNXS85mGjbdNUQeIMqju/x+ukNiMV9 2ET5ugBQ3OXyJG+kwSJETm9KyO9bLej5dmmP5v8r8/aM8/KC9b7p/r4v/QpC+BowH6likh0w AA+EAvTFf7LavqEp8lKw+U6vACuK+OKvBetv8X4wCIewCGPELiQECyzENRBBGMAD9dABQDzN CgPQOqAwOeyCKoQDHTzCLtSCVECRXtiwKH2iP9BBCudtXRSKEY/OKtxNQ8zwK3CZOdww2axC Cf/D9awCPpTDJAyN/CyPDZRELQxCEldxDjsED9tOQUwEQ4TDOoTxCL8xHMfx6p5FdcwJYYCE mPQFg4RFdjzKX/ANd9SxzwDFXJAHZjBPYNiYIPsNtFjLh8xFH2eFkKiJXtBxW9wLJSOFR/5K IZtHZpCIJQ9yUSwFmuD/C3AQMtvKsSqvMiu3LJj4iB0fDBuJSpt8iCGfiR97CIakC2DIiYT0 h4CU8powgQgw1r48x29wCC+zATAbCDK/iCk7c2EI865Ey2Q0cxwBCYm8si/rBzZjcjWvSTO3 MjmXszlvbqrAMq9QMtKEhCwbcjqD0ZboCyWr86ngiqBQstOq5L+4SYb0iJUITDyD8yZT8rFM MzhHc0HfihJQjU14yjYPjD0nCj5vSDQf9B+R7TlvNEd3NF25TfHoDhgbzyzfDeAwT86QdB3u DX+mTvGctO480vpIBdTsDuKgg2KFtNegz9gos+F8BfKoNNnE9PIER9iwdPJmjNOkzlHzDiJn /81MO41MO85I645O98PMGEfuoHKLDLXJzIzSerRYjzVZe4f/dBH9VEYgiYn3HJK8EFIuGxER 8VFbqw9cE4RYcA8dsa372tEQ9cj8EMyvuHVex1AIufMLhQ9dF5EaobUViRFjJ/YUJDAaGfb2 8FX6LBBaAwJel5BnR7YMkcP4lDVpl/ZYO5Ok7pQsLZMvXRJI2dRJtbZPnVRFOBOzwvaupvYs sXY1UbU61SlC0OoygWUmqRJYClVs9JRIGWxIkVNvrzY1mZNz35JLDRTCpoA34Spx9ytqC7ct ZRRuh3d1f3e/mrZ5nzd6l/bRpjd7t7d7nzPW+lV8vzcJH5RRpfJ8O/9PWMdxftM3XvX3hHmM YQF4IhF4yc6u3QbuBwOvUdGtf4dP7GZa5bLjVzF4RgxXCFt41yr42TqZ7pKu8yCXh3/4FER4 g4P4gWut5BKXHxVWiw/ucznCavLJi/NsjUfVjWfDjLtXXGk4fFzX8PZtjjOZ6ULXkBPahL/W jocuimcVhiP5l03unsj45B456iItgndflt93e/m48/TulrNhmO8Xl+OVl9+EHPftmLtui635 6HLWkwvRid8YUZ257Hob9oofAwvw9NrvALtanpMWA/u591qwnxs6DtTFnpvR9v5vBjt6BAOp A0Nw/IRX/FDKWJQvoTf69nowvA2Bwmp6osv/b/QKuvUeuqjvW6GnevxkL6KrOqdjT5/3L8ux TvyOOvOWenAFMAdDeqVLOgFvjFGUAdmAb6UXsPkCOjkguwXXKbApcLJ/OgYSO7Tz+Qz0RSWu uvJGO6uBui2Qza0HuvZGmgJn+rajeqdHOnele6V7L7UzsLbTCB9h8J6ru59qaKfDm7hrMJcN gUdor9nZ0KxPMAf7GL23+/bW+6+zbwKvb8zWjhC8wxhgcRrTtDcAMQxLvFgs8RN/Qz10/Mcf BBfXRSRswxpDMQu4MUOczxQfkTiAxMcnMR7sMAxYgUCoQxXwgTuIwcZbzxg7BA2bAdCrsMbH vDfMvEPcRNBrgsnr/zzR8/wLZzEt1HwnRFvT48Aa8AHGn3FIqPxCxJFDiMJAmIPXpwMfTD3H h4Q24BvZUz183PzZX33E8zwqmAIZyP3Fm7HbE1Eb1zweOP0qIH3fp33U730WY/zOs3DFGwIS hNE6/P0YJHEWwzgTW73+UPxaeTEbv6HLuhE8Xwo8f4ZKfD4y2yNKe/Lpi5OX9MalIMUn4wUp o37l6jFWRPJKW3LlXkfErISYuIntG2Qk83Hq3/5Thwrx20rvG/Qdj3IqQHIsz4Towz4os20j I8ZWbIfrU//1rARS+D5vSOQhJ7mGbAYeT0X2q4R1oL5Rp7IoS3+BzMR//DFQuMlsVO5uAP9y 8iN/l7U/vdAyl/gYCCiAYgBJgwJFUwCsW54o2r5NqQzuzPf+DwwKgaqGSHE81pauWnLEBEh5 TyS06VLuii1p9vryGkc8Zo+LtZlrjICJ135rG3EZbee8iucNtLhOBdY1dTRmdWg2N/ilUNO3 smhYFcnnNzUzuQWZVlilmLbmAjgDmAhWGEnqdjI3ijL3KdYwIPBm5mqYp6AGymiWsmmDi3lK Znr4aZPLKegluvoTOVqEmvYYNnV8Cz0TKvs6kmnTKSVwJ0sd3qzcozsdzMZ9x/s9ZH+PT7Ti uX6cvLCCGLJ1lYIBXGbjYKFu1mag4QXRURwGcNww4DOR4bw5CsH/XKtxkI5FgWY67uLXiFnK hPs8PjQpzqSjlwHBIdIEkdzAlaEgigRAURVQbYxY9piIcaRNXSUDJpBC8VfGpUV7Mm34UKLS QCurjVN302eyfwGnlnERMmO6Xb9o5lz3M2hEtDUlgT02phZbusDs8mx41lDcj9bM9gyZL7Hi IWurPM3h4rEOvzUkB+DqeMTkgg0sI/S8EIXkHQ5XeMZRq7Pmy3RELIDjWkQCia5nPDXAQBdo l6ZXo7gI4DW4BAMu7z4J9sjoz745H8+c47Jz3wKnRxeMcjnqyNSBC//teneB4oI9ww4um3Zw kl9mc79OBwBr896JEZdO5vSI1Om5475G/19tBgxgH3mFPAeWZ7cBp8BxlXUnIIGiQbjeWqpB 1peCmjGyXGvrobDdheRVl+CG2JkAgDnmNQZGhwNqVEh9RXRYH4j7vTfiYjru2BdKDEjhRnzy McKHG2+QeMiPQyJ0TQNGsuLRk4KRAiRpfTkpxWtKBonleiIAICE4YKJgZEtjCqVCUVJy1iWU Z4p55Jpk+Fglk3Ku1OSdVbTJZBF8IjlTQEa+plMVW4pSZ5eEShHmGGcO6qiFf4opYZmONlqk FIJKYUcAYUL6JaZeQLmLokJyaWkcLvgJKqMoCGDHl3KQYSpKpqpaSKt4ynkmrDzwKqGFh14p 5bBHGOsqlUtO6v/XsXXq1MIuUl4jzrAN+LqROmcWgeybp+4wLY/iJqYARRe1hi4dCzCgZQIA ibLLuexiIhd46J6r7rzyClcuvfbO+0pQ+MKx7ncB+/tbwQg3sIDBKDRMigLfQXxUufqWaoTA 8fIrV78POyybwR7jK2+8pbJ7sboI73twyyWnm/G/HC/878Ytx5zuyyQrnO93HjPsMNBUaAzw wDjzQHFrEzvMstJDI13vz0kPJ5zRP6NctcQRU/Sz1FVbGbK9K5sM89UWYzyyzTdT/KMPXvs7 MNY3j+wuGyfzPHXCAB9dc84Kk2xyUF2bS7a+dSNKcLpJj4x30HLfPG7kkrcTnCOTX47/eeaa Sx7a5p5/Dnroom/e+ei2iYqx6YoRp3oL76puuuuVNQp77abHEUDQtu/Ou+el9w588MLz/vvt UdM6/A8M1Bs67ronv6PzdDAPffXWX4+95EZnz333nxuQurjngp85+T6Y78P296Dvffvuvw9/ /PLDPxns9c//vp9D3M9YXZLrzwMARk6A+CugAQ+IwAQqsB3+01ECzIGPAjTQBw/ERwWBd8Hh ETAaE/zBBsW1wQ/uSIQLLKEJT4jCFHbPcpNjoRBcaDsY9o6EOqLhYkLYwRHmUIU87KEPf+g+ AQRgiBQRogAKwIBaQDCJJhCAOZgooQXIAw5KZFg56FALO/jA/4nXGmLuGLaKBVxRjENcgRCH 2LAxyicAZvSilqpoxTJ20Q0FgAYTIXjG3IkxRVjkI5UMMAvW/AaOeTQYEx9ojiKQkY3XWKQZ E/nIPuIxAEcszbUgGUdGOrKLlXzYkFZwxyu9aogqgAYXi1DIOHKrFrQDoitfCctYhk6ILThB FhkwgAHIJpAS46ITo+UkAWjNB7mUDS6BwsvnXbKLT1kBJSV2zCIeEZUBaGY0L9mCNjZzFrp8 wy+p+ZQAiMAcxfRmNVVwzXJq0VN9aJQ6mQnA4vQSk99cASqnGcl7cnOXt7TkKZ2JT2yi0gRy oWQ29/kGAAoxnONcJjiLYNB7AlOWFP+tqEUveo9/LrOdIrBnQDRaBPlQLwXdDEaTguBLTIp0 HtfQ50Namk97lhSmy0wpR11qUjB1lAfFEaPBdIrTAH5UpR6laVBPOVMuCtWhRQ1pUZVqyZDO VKHmsKlGQdrUomJ0q1zt6iuvCkFnANJPWFVNAEYqVmXQ0KYzWmmgrqHRtwY1rU6taVUT6QVA xnULeeXBU4R4hr5q1JJMNWpWC3tKwULQn0Q17Eajas++UtWuiG1sXW3o1cxqdrPtA2tfyEfW xqqmldcg31uFwFanjEmuMVXrUxsL2tdStgjk2+tnU6ck2tF2F4O9UlkvK9ug1naxffntYaHa l7rGlgdWvSv/XC17WM5Kd7rUxZ4Qf2RLCFISu046axLNsd03SJNMBRUAdx1BRAYkQAZnnUFq 6bBM9Jo3qPL9UWvDe4LwRtKm+C1sfY/k3g/NoL+97e7yAAsAQOq3pfNtYx/0Ct75ZvcMDk5w MO17YX0GUABiBCh3J2vVy1gYpByGqIQ7o8XqqnjFLP5cLVaq1KesVMYG4KKMJfRiQglSNW7d AY35qIAdvzfHytABHf27AyMHVcbtVfJ+ncvk8b40yj3IkW2AJOW60FjGyHTyNbzM5fFSGbkA 8gJFvOxlMoMZyyelrI3NXNg1b4u4La6zne+sGCeu62FyMdoCdrFnlYEnKAMAJGxI/zExQJ/Z 0HxmGNcIJzCfXYQie+7X3srVr0prbGiZprSnxebomO1NfU4i7cA03YM/P2xw/fJYufz056AE +tTM81isH5YADGes026bNKh/Fuo9B/rWoXa1rwUdajwre9nMZi6dL9feHUX7oj7dHWZrmEhG N3vb3O629ch8uZHmQ9yxNMCOYXftxXSBtN5ut7vfDbpAwzty8q4dsOeN73zre9/87re//w3w gAt84AQvOByWR24LagkBCPgNwoPAAIbDQeKd0Z27xl0Abd+DAQYoQPiil3HMJeDjINd4EEbu 14sPQb253njIO0PyFKI8frkxuekalnCD65xHDDiAzw+Qc/8hJMDndDhAw3v+84Yrz+hwYPrQ D0BBouNjAZ3MR42xNS6q73B14N6R1u+BSEwIwOY9UIAT9WyPr4f9h2uH39d3h/ady31ySGd4 0IOwAKb3/Og+R4DPdbf3pjc870pHGtMb4PeEvz0fBeDw5BYfObOTfTGQD4Lku7F1LAqAFptP eyUv/0PQu73qQ2i8MhcTdx+YvoWOn3u+kQ4EhOdavQKbvcDMpXei+/0Ey5te0RHAtsP3XjQy 6H3ED8B748tl8Q2iXvPpQIuWN4xiz6fDegXX8hm8Xb3TT/W6Zq9yI2R/cePvPilGjn1KdxJi bLu+0F5R/gVk/xWdp7p5gSZ/5r3/nWLTn3/1td8w2cd9/Nd9A+gw/Sdr5ld9OAd+PiOA7kd+ CZh/v+EuBDg16pVpr5E3CPgx1PeADxQQ7Fc114dLsJJ+bhN/8/cqjseBJZh9C9h9HAh/5hJ9 d+d6yoZ063UUP2d0fgd1DcCDfCeERQd0f0d4gYd0ffd7S4h4Prc8TOeDQLd7Q1d4b3d199cN ZwcQZ+cum+crV3hmaAeG2ldJ3/VLSOOFR8R5FAGGb9d4ekZ10UcKZwdIb8hhX6d1b8d5DdNJ dsiHnKdtILiCf+hEGoeHlRSHhQgiZ7d8Zzd2mneGiZhrjlgX9qeIksgCWpiIauhEUaGFswCH faiJaQhI/2aIiF5oB2ZoAHlIepb4iJjohyUYiUekh3rmh5mYejfAiJuocaEIiLjoeG2Iiry4 iJ14izcIb0n4g6TQd80IdITnd0OIhEH4e9OIfEQ3jYNndFrCdHnXjT0IdGS4AlSXADWGMVpX Y+BDC6tofxUIK+Zodh53YOUoTOJoBEfUeJVYiPt4h+8oTIeYcWPXjt/xQAOQa+gokKdYAF8X j+UCkOkYh/noV53kixKJhuN4igMgkeRojmRokFwUjxvpRO4Skq24eWE3kAi5ivx4dXwYkOBz RA6pkBC5eRJZkhgJKwR5kuxCiyb5keaQkkeUjjfJMD25DzF5EevIky9JhvTYS/8aSXqX9Ic2 qZRJ5JRBCZUY6ZQ5MHY2iIx2loMn4INP2HC6B3RDl2u5J40+p4PVqJZACHXZ2BnI9xuHl3go wIMX2RmbJ4eikZOVtHpvV5DR90AyMJhYp3Z/qY+RZHqH2YWmoZiVZ3abp16RqZCJKQOYyYoL SXqCKJWbiYsuWZQYyZmQmUuIWUk2ppij6ZePqZdcJJiWyZgcVphaV5gPU0m1aZSaqZBl50QD sJSQ93Ww2Um6WQDGOZqYmYWvgZx+eZqPWXmhWJo04HiOuX9GuZfPmYmn95XLBnsowHAIQJZw 2YTqhXxyaY2CJ5fY+JZoWZdKd5dNeHi4CZnHGX7IGZj/xXlE6yV/2AKC/GmPzUmf8UWb++mO kAmdUbmXY2ecAKmcrNmg2Cl25vVdwVlJHYdEAJmcuWmgE5OaKrKasema9kicTiGbBNqfj3mb ECqbvEmaFFSIoEmiQKmfKhqi2Lmi27mXI7qX9umS0dmP06mj/3mg9JmYPqqj3eludQd8gkee ifd0VLiE6cmM18h31xiXb+mNCGeX4SifBsOQY9cIaLOfj5ifASF5Y2p2A7AuaepxAXqSJjmb fyamHhemx5mQDWQAIBiPD7SSGPmRR8mmS3mPePqnkPddp0malaehoOmm5+hEa5qdghibgYqG wlR/ndSneYqimwqTg3qnfgqa/wVJqQq6pz1pqWSIqQTydp5KqhkpiGu6Z6vnqWIHPnYqoe4V pG7oeI96ndP5qDoah0rKbcqoRYFnlk+YdFOae8sInj+Hez/He28Jl0AXeOVZl87KmrKIhdDH iMLaSdx6YHomrvZoiouJouL6deoalZMpTOwaEJzneGYomvBaeVfIphvqP42KneWKm1wIib0Z sPoIsNsnr4TKRaYnrvS6rgcLmufKmlRwdrsgr2DqiCdgsIwIsaCIdvSqo/7qrZ0oo7r6o6Ko JQ67fv16sEPadcR6ZwhHPcrne9b3cDM7fMOXcn3GLt9xs7VXfLenffOpNxSogtZXfkNLtLV3 Mu6HaP+ydpD1gjJC037SF67uF7Vlp3IsZy6zxrTWtzE+u7XLU2+4JoDrcrVNmy/5crVae5Ez xzBPm7a4drajOXNny7ZRK4JJS4Ffq7coc7X5t2dzC38jWLS2eTd9xrSAC7bnVypJw7ZwYLVm O7YQ47fDxrORG2liu7jvx30u67m243fcqUCVl1mk63UKekKm+7mra3BS50Oqy1WwqxiyO7qo y7q3i7u5q7u7y7u967u/C7zBK7zDS7zFa7zHi7zJq7zLy7zN67zPC73Ri7swS73Va73Xi73Z q73by73d673fC77b+0rhS77la77ni77pW7MopL7t677vC7/pK3AIN31IMH3/94u/+au/+8u/ /eu//wvAASzAA0zA90u9KSS2DYMEC8zADezADwzBESzBE0zBFWzBF4zBEIy/MKtA9KvAElPA ISzCI0zCJWzC+XvA+7azGczCLezCLwzDMezC08fBJbTCMozDOazDO9zCBry+83PDPCzEQ0zE RbzANPzD78YuSLBe68XAJwzFUSzFU0zCNYxAS9zETWzEW8zFXQzCKIyzNPdnDaLFR0zFZ4zG aUzFVrykZLyn7hLGLpvCB3QR5bin0PSVbPw+dVyO/BnHl5MACEAAg0wATcpsc9xuF2EAi1y0 0hs8irzI9wY6LEeQKZY59wtwkLynXvkbdgd2g4wA/01MyIXnyN2jyBIkuqITyJxMvKeMRLCT AIQ8yBRRyJ+zALJMAKlcrCSAyj5AcbFHyKIryEUbcbUMnqRcyskjfxLEyp4zyJbsvMv8yqpz y8B3ywRAy8iMOdW8AIKMzfwmzdQTywQgdLkcdLFcfBBYzCcwzslcPaesy6LjybxbYyBSL/Us GrRzys08LrEcNMa8ObdsmAQAzW3ccYAXyuUsugxA0OApy4L8GoNMBwntzuUDQf8xA/jcGY0i f3s6BPLWZxrYZ4iWbPCVMD4QuMvjfl1rtJp7frMH0iz9tvP3uNPDtkwrey0n09rXtTWd0xSx 0z3gAA5QO41nRfVi1NSZav99bDvjzDyFXNMtrX0jfdIo3dAMc9VSDbk0rdI63cimQ9Sig88Y vYingzRMHXuy1tWdTNDy1sRyEcsOjbGEDNTfPHwFc3Gdm3JaUi8AGsZv3QOATXzzh9ftMjHs ktfhR0FdK9iOJn+GHQRD3VVGLUZIvVhJjWtkDQTGzNAzANWcTc4o8NlK19mijcz+3AC4jMu2 8dC5LBqtLRzeDMozINuhXdtKp9qyLNq5LdG+rNuI99C7zdtDINmwg9ntcNl01tH8HDnebMip jctBcdum/RuhndrajNW8N8sOPcq0HdzQPdy7U9ygQ9nIlIXnzdOa3QO1HMuy3XC1rSXRTd0C zdr/oX3LEd1w4zzKhGwHrV14/l3dsixrsqzdAt4ZuCzb7Izg/G3VDM7QBq7foMzgPzDeGHXc ZZDcEbPI9iDIFAHRB+7h3/zhsRziIc6c3+xXrj3LDy6Wrs3i3TzI8d3W3vwaw9wwzwzc7hLX ggx843wCK47jHw7kDf3hPGDjO17I8ofjQ97ipzfUYR06OtBxQJlkCdZ4IpAbxFXHk6fK3Q3d NU7kSe7jwG3iIP4D10zXDt3jQS7mS47NLA7c8Yw5Tx46F47emajhXM7eUP3gE93WdPDMMP7m rt3h2mfM933dB57fQA6fbW7MPK7ktfzgATjkDRPKL+7N6rXng77oi87p/0cR492ca4Ge6e19 4J9O4RUuS1Je3ijA6sI0FIvFx/bA0OI526Bt67WM6w/ecADN2vjt0K8N5nBN6Ch+4OvyzKKM zb6e6J5Nzo8e2qgN7cK+3sjs6xI97ccuBHQeOiJAB0bt7d6e5Waq5WQcPNf84/ZN0LXOAxJd 67ze7PIHoGhOyte+7PX+7I1O7bbD7Zrz6lbk6lYO61keMW252Yse29Hu2nHO2u6i4qSMzq9N 3ahN34nO7p59dNf+3oWs7Otl7Az/2h6vgVe95yMvA8xe6N5NkARN8SSP3Q3Q77Ik7uD+Bd+u iJg96xxO0IWcy8Y+zDx/y3Lx8xD98dSe7agtyP9IU+xKf+O5XfEPk9XA3exJr+1Hv/BQr0VP L/VW7+SqvjlJTfN4HgZKXfAFLTp9putKJ9BaT/VD3/PSzeACHeNYb+Q9r0VJz/Xi7fWcIwph P/M3L+vmHgQlH+zaLvWG7vDArvLUnegtf/KDF/USx/Ybr9qBbN2Fj/WOP/GuXfEof/mHn/mc 7/JAEPOxBPbm4O1gfwk4P8b3gO7wbujrPtuxP+oATXtVr+/aPsy/nuO/Xs3p4+t97uxTr/CK T/WoTXsXH+Dtnu+Fj9qRvfeZc/pjIPZdwBZa3vqga+xpj/XCv9tQL/u2T8PZ/eDm0tu77f3Q Tfz7Xjulz3pKnfoQ1AX/ZK8uSCAEhH/4z1/kx07f2w3otg0CBNM0BNIkxNIsREKaDUMQJHzO tR0jqm33VkAfKbUwslw3lK/1Kp1Qr+CPWlQhncufzeHlgsPiMblsPpsLApK6oQA02nEAQBFf 2xgLxcjcG1kNARIJNgTSnCDFGOpk0SQc0ay0uET69CAsLFBhHp10bvos9lytjDaK8ph4MmaG mkaRMgmJeTmg4YYZwN25we2yCQjLPOVp9uUmh6VUUi1qgQb+MdKCaaXErr62ajpnlyqHg9mK l8m1vfXO1amT6PGNxSAxgidVMi9hW5rQIMs3KYECQxsmEtFiUIKEzR4kBJAeWZqV5Mm/SQH/ /4lIuOnhPRoStQgMQ64cyZImSQDrlS6lmmEMisk4diZBlE1gaJKwyQUniygDXyj6JpERDX5C ehS1UhTRjqUGl1IUGvQpuEcDiz4tGpXqUJEjT45hACBAAnRwxJJV80ZByjx6kIFFg5RpSJBz Axap6TOM3YB3i/3dImte3DO2bhVGyctsA5bC1rz8oWcBXC4VuRJmVrQPp6Kh+rGA9fFilByP Fpl2sUgzaCZaXW8evdXRbNCsgS4VIXsLl8OJfwPPM7bsmnRoia9t644B8zPIKrvLE+Y5lz56 clq3Xu1IAubbE3RPgYx7ZfDdbZBHn92dEMrL2Uu3YX48+PHrY47xHf+8up3m12X0NwIfzVVH 4H5h1aeegjklWF18Y7iHHXoNTniehDJod2B+XwB3HGMeCpAcL24ZyIV7/2EIn2TgVZPDCChq As6JtEQYYRHn2SjFCIsQAwlcL0GSB4vGLDhjkff1SAuQStLYR44k6KehlCQxECB+AKY4YGXM lTillK155KWYZkQ5ZjlcQmemmmsGV2ZiVab4H5zNaVlgl8AxY6FkPcBkEp/1sGmmm4ESehKa hSaGFFJpIrrfYYg1iguXkVJaKRmDWorhnb+ZhoBDNHn2Zm57ZVrYo6WimqqGm3jKqKoknfqq rLNGGiutYn6WVJ+F0eTQrSXZ+quwwxKb2KOiHBabrLLiHAvpss9Ci0az0crarLXXYputttty 262334L7LbVdhFuuueeim666Xym7rrvvwhuvu+NWK6+99+J7L70/5Nuvv/9eOy7AAxNcMLL7 qmqwwgvPi7BXDEMc8bEONyCxxRcHTLHGG3PcsccfgxyyyCOTXLLJJ6Ocssors9yyyy/DHLPM M9Ncs80345yzzjvz3LPPPwMdtNBDE110ySEAADs= ------=_NextPart_000_001__16659973_14467,92 Content-Type: image/gif; name="ww.gif" Content-Transfer-Encoding: base64 Content-ID: <1665997820445@ww.gif> R0lGODlhtAASAIAAAP//////zCH5BAUUAAAALAAAAAC0ABIAAAI7hI+py+0Po5y02ouz3rz7 D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1AIAOw== ------=_NextPart_000_001__16659973_14467,92-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 23:21:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bsdconspiracy.net (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 8C01337B400 for ; Thu, 11 Jan 2001 23:20:58 -0800 (PST) Received: from zaphod.softweyr.com ([204.68.178.35] helo=softweyr.com ident=wes) by bsdconspiracy.net with esmtp (Exim 3.14 #1) id 14GySm-0001Hi-00; Fri, 12 Jan 2001 00:17:28 -0700 Message-ID: <3A5EB0C2.F895825B@softweyr.com> Date: Fri, 12 Jan 2001 00:22:42 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Cc: Brooks Davis Subject: Re: Setting default hostname to localhost References: <20010110213538.A668@cae88-102-101.sc.rr.com> <20010111102525.B28915@Odin.AC.HMC.Edu> <20010111151829.B76759@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Thu, Jan 11, 2001 at 10:25:25AM -0800, Brooks Davis wrote: > > I submitted one possiable solution to this problem in PR:conf/18583 > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18583 > > Have you submitted this back to the ISC? > > > Other solutions include just letting DHCP smash the hostname all the > > time or having a variable like dhcp_override_hostname in rc.conf. While > > The ISC's dhclient mailing list would be the right place to discuss this > and find a good fix. > > > I understand the concern that we don't want to maintain out own dhcp > > version, dhclient-script isn't on the vendor branch anyway. > > So? Do you not understand the maintance headache this creates? Add a FreeBSD-supplied dhclient-exit-hooks script. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 11 23:39:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail8.sc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by hub.freebsd.org (Postfix) with ESMTP id 9583637B6A8 for ; Thu, 11 Jan 2001 23:38:54 -0800 (PST) Received: from sc.rr.com ([24.88.102.101]) by mail8.sc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Fri, 12 Jan 2001 02:37:05 -0500 Received: (from dmaddox@localhost) by sc.rr.com (8.11.1/8.11.1) id f0C7dYc05190; Fri, 12 Jan 2001 02:39:34 -0500 (EST) (envelope-from dmaddox) Date: Fri, 12 Jan 2001 02:39:33 -0500 From: "Donald J . Maddox" To: Wes Peters Cc: freebsd-hackers@FreeBSD.ORG, Brooks Davis Subject: Re: Setting default hostname to localhost Message-ID: <20010112023933.A5120@cae88-102-101.sc.rr.com> Reply-To: dmaddox@sc.rr.com Mail-Followup-To: Wes Peters , freebsd-hackers@FreeBSD.ORG, Brooks Davis References: <20010110213538.A668@cae88-102-101.sc.rr.com> <20010111102525.B28915@Odin.AC.HMC.Edu> <20010111151829.B76759@dragon.nuxi.com> <3A5EB0C2.F895825B@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5EB0C2.F895825B@softweyr.com>; from wes@softweyr.com on Fri, Jan 12, 2001 at 12:22:42AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 12, 2001 at 12:22:42AM -0700, Wes Peters wrote: > David O'Brien wrote: > > So? Do you not understand the maintance headache this creates? > > Add a FreeBSD-supplied dhclient-exit-hooks script. As long as it will source a dhclient-exit-hooks.local :) Some of us already have dhclient-exit-hooks in use. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 2:13:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 8CCE237B6A1 for ; Fri, 12 Jan 2001 02:13:26 -0800 (PST) Received: by smtp.nettoll.com; Fri, 12 Jan 2001 11:09:38 +0100 (MET) Message-ID: <3A5ED8C9.3050309@wanadoo.fr> Date: Fri, 12 Jan 2001 11:13:29 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis References: <20010111163903.E6FF737B400@hub.freebsd.org> <3A5DE59F.6060602@enition.com> <3A5E090B.40601@enition.com> <20010111114318.C7240@fw.wintelcom.net> Content-Type: multipart/alternative; boundary="------------000601080407040901070709" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --------------000601080407040901070709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thank you for your answer, OK, let's make it a bit clearer ! I use a private scheme to interact with the 'ipintr' isr. The two following routines are expected to be called either by our modified version of 'ip_input' at network SWI level or at user level. int my_global_ipl=0; void my_enter() { int s=splnet(); /* We do not expect this routine to be reentrant, thus the following sanity check. */ ASSERT(my_global_ipl==0); my_global_ipl=s; } void my_exit() { int s=my_global_ipl; my_global_ipl=0; splx(s); } The crashes I got are always due to the assertion failure occuring in the 'ipintr' isr. This *seems* to indicate that 'my_enter' is called at the network SWI level after another execution flow has called 'my_enter' itself and has *NOT* called 'my_exit' yet ! This actually seems strange due to the 'splnet', and the only explanation I have found is that the first execution flow has fallen asleep somewhere in the kernel (while this is not expected, of course !). Now, if you've read my first mail, I was actually asking for help onhow to dump the stack of an interrupted process with GDB when the kernelcrash occurs in the context of an isr. Actually, I would like to know how I could dump the stack of *any* process at the time of the crash. This way, I would be able to see where my user-land daemon was lying in the kernel when the interrupt occurs. Anyway, without this information, I am reduced to add some traps on the track of the execution of my process within my kernel code. This brought me to surround calls to MALLOC with counters as follows: somewhere_else() { ... my_enter(); /* handle competition with network isr (especially ipintr) */ ... some_counter++; MALLOC(buf,cast,size,M_DEVBUF,M_NOWAIT); some_other_counter++; ... my_exit(); ... } Then, all crashes I got show the following equation at the time of crash: ( some_counter - some_other_counter == 1 ) which *seems* to indicate that that my process has been somehow preempted during the call to MALLOC. My belief is that the FreeBSD kernel is (currently) a monolithic non-preemptive non-threaded UNIX kernel, thus implying that : * system-scope scheduling is still done at process level (no kernel thread yet) * any process executing in the kernel cannot be preempted for execution by another process unless it either returns to user code or falls explicitely asleep. * the only interlocking that must be done is with interrupts (when relevant), using the 'spl' management routine set. Is that correct ? Well, I am obviously tracking a bug in my own code, but I would greatly appreciate to get help either on my GDB usage question or through technical hints on where I should look at to progress in my investigation. Thank you very much for your attention, Rgds, Xavier Alfred Perlstein wrote: > * Xavier Galleri [010111 11:27] wrote: > >> Hi everybody, >> >> I have reached a point where I am wondering if a call to 'malloc' with >> the M_NOWAIT flag is not falling asleep ! > > > M_NOWAIT shouldn't sleep. > >> In fact, I suspect that the interrupted context is somewhere during a >> call to 'malloc' (I increment a counter just before calling malloc and >> increment another just after and the difference is one !) while I have >> called 'splnet' beforehand, thus normally preventing competing with any >> network isr. I assume that this shouldnever occur unless the code is >> somewhere calling 'sleep' and provoke acontext switch. > > > if you add 1 to a variable the difference is expected to be one. > >> Is there anybody who can help on this ? > > > I'm not sure, you need to be more specific/clear. > --------------000601080407040901070709 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thank you for your answer,

OK, let's make it a bit clearer !

I use a private scheme to interact with the 'ipintr' isr. The two following routines are expected to be called either by our modified version of 'ip_input' at network SWI level or at user level.

int my_global_ipl=0;
void my_enter() {
  int s=splnet();
  /* We do not expect this routine to be reentrant, thus the following sanity check. */
  ASSERT(my_global_ipl==0);
  my_global_ipl=s;
}
void my_exit() {
  int s=my_global_ipl;
  my_global_ipl=0;
  splx(s);
}

The crashes I got are always due to the assertion failure occuring in the 'ipintr' isr. This *seems* to indicate that 'my_enter' is called at the network SWI level after another execution flow has called 'my_enter' itself and has *NOT* called 'my_exit' yet ! This actually seems strange due to the 'splnet', and the only explanation I have found is that the first execution flow has fallen asleep somewhere in the kernel (while this is not expected, of course !).

Now, if you've read my first mail, I was actually asking for help onhow to dump the stack of an interrupted process with GDB when the kernelcrash occurs in the context of an isr. Actually, I would like to know how I could dump the stack of *any* process at the time of the crash. This way, I would be able to see where my user-land daemon was lying in the kernel when the interrupt occurs.

Anyway, without this information, I am reduced to add some traps on the track of the execution of my process within my kernel code. This brought me to surround calls to MALLOC with counters as follows:

somewhere_else() {
  ...
  my_enter();    /* handle competition with network isr (especially ipintr) */
  ...
  some_counter++;
  MALLOC(buf,cast,size,M_DEVBUF,M_NOWAIT);
  some_other_counter++;
  ...
  my_exit();
  ...
}

Then, all crashes I got show the following equation at the time of crash:
( some_counter - some_other_counter == 1 )
which *seems* to indicate that that my process has been somehow preempted during the call to MALLOC.

My belief is that the FreeBSD kernel is (currently) a monolithic non-preemptive non-threaded UNIX kernel, thus implying that :
  • system-scope scheduling is still done at process level (no kernel thread yet)
  • any process executing in the kernel cannot be preempted for execution by another process unless it either returns to user code or falls explicitely asleep.
  • the only interlocking that must be done is with interrupts (when relevant), using the 'spl' management routine set.
Is that correct ?

Well, I am obviously tracking a bug in my own code, but I would greatly appreciate to get help either on my GDB usage question or through technical hints on where I should look at to progress in my investigation.

Thank you very much for your attention,

Rgds,

Xavier

Alfred Perlstein wrote:
* Xavier Galleri <xgalleri@enition.com> [010111 11:27] wrote:
Hi everybody,

I have reached a point where I am wondering if a call to 'malloc' with 
the M_NOWAIT flag is not falling asleep !

M_NOWAIT shouldn't sleep.

In fact, I suspect that the interrupted context is somewhere during a 
call to 'malloc' (I increment a counter just before calling malloc and 
increment another just after and the difference is one !) while I have 
called 'splnet' beforehand, thus normally preventing competing with any 
network isr. I assume that this shouldnever occur unless the code is 
somewhere calling 'sleep' and provoke acontext switch.

if you add 1 to a variable the difference is expected to be one.

Is there anybody who can help on this ?

I'm not sure, you need to be more specific/clear.


--------------000601080407040901070709-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 2:15:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id B4A0137B401 for ; Fri, 12 Jan 2001 02:14:44 -0800 (PST) Received: by smtp.nettoll.com; Fri, 12 Jan 2001 11:11:08 +0100 (MET) Message-ID: <3A5ED923.3010207@enition.com> Date: Fri, 12 Jan 2001 11:14:59 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis References: <20010111163903.E6FF737B400@hub.freebsd.org> <3A5DE59F.6060602@enition.com> <3A5E090B.40601@enition.com> <20010111114318.C7240@fw.wintelcom.net> Content-Type: multipart/alternative; boundary="------------070905060907020201090406" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --------------070905060907020201090406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thank you for your answer, OK, let's make it a bit clearer ! I use a private scheme to interact with the 'ipintr' isr. The two following routines are expected to be called either by our modified version of 'ip_input' at network SWI level or at user level. int my_global_ipl=0; void my_enter() { int s=splnet(); /* We do not expect this routine to be reentrant, thus the following sanity check. */ ASSERT(my_global_ipl==0); my_global_ipl=s; } void my_exit() { int s=my_global_ipl; my_global_ipl=0; splx(s); } The crashes I got are always due to the assertion failure occuring in the 'ipintr' isr. This *seems* to indicate that 'my_enter' is called at the network SWI level after another execution flow has called 'my_enter' itself and has *NOT* called 'my_exit' yet ! This actually seems strange due to the 'splnet', and the only explanation I have found is that the first execution flow has fallen asleep somewhere in the kernel (while this is not expected, of course !). Now, if you've read my first mail, I was actually asking for help onhow to dump the stack of an interrupted process with GDB when the kernelcrash occurs in the context of an isr. Actually, I would like to know how I could dump the stack of *any* process at the time of the crash. This way, I would be able to see where my user-land daemon was lying in the kernel when the interrupt occurs. Anyway, without this information, I am reduced to add some traps on the track of the execution of my process within my kernel code. This brought me to surround calls to MALLOC with counters as follows: somewhere_else() { ... my_enter(); /* handle competition with network isr (especially ipintr) */ ... some_counter++; MALLOC(buf,cast,size,M_DEVBUF,M_NOWAIT); some_other_counter++; ... my_exit(); ... } Then, all crashes I got show the following equation at the time of crash: ( some_counter - some_other_counter == 1 ) which *seems* to indicate that that my process has been somehow preempted during the call to MALLOC. My belief is that the FreeBSD kernel is (currently) a monolithic non-preemptive non-threaded UNIX kernel, thus implying that : * system-scope scheduling is still done at process level (no kernel thread yet) * any process executing in the kernel cannot be preempted for execution by another process unless it either returns to user code or falls explicitely asleep. * the only interlocking that must be done is with interrupts (when relevant), using the 'spl' management routine set. Is that correct ? Well, I am obviously tracking a bug in my own code, but I would greatly appreciate to get help either on my GDB usage question or through technical hints on where I should look at to progress in my investigation. Thank you very much for your attention, Rgds, Xavier Alfred Perlstein wrote: > * Xavier Galleri [010111 11:27] wrote: > >> Hi everybody, >> >> I have reached a point where I am wondering if a call to 'malloc' with >> the M_NOWAIT flag is not falling asleep ! > > > M_NOWAIT shouldn't sleep. > >> In fact, I suspect that the interrupted context is somewhere during a >> call to 'malloc' (I increment a counter just before calling malloc and >> increment another just after and the difference is one !) while I have >> called 'splnet' beforehand, thus normally preventing competing with any >> network isr. I assume that this shouldnever occur unless the code is >> somewhere calling 'sleep' and provoke acontext switch. > > > if you add 1 to a variable the difference is expected to be one. > >> Is there anybody who can help on this ? > > > I'm not sure, you need to be more specific/clear. > --------------070905060907020201090406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thank you for your answer,

OK, let's make it a bit clearer !

I use a private scheme to interact with the 'ipintr' isr. The two following routines are expected to be called either by our modified version of 'ip_input' at network SWI level or at user level.

int my_global_ipl=0;
void my_enter() {
  int s=splnet();
  /* We do not expect this routine to be reentrant, thus the following sanity check. */
  ASSERT(my_global_ipl==0);
  my_global_ipl=s;
}
void my_exit() {
  int s=my_global_ipl;
  my_global_ipl=0;
  splx(s);
}

The crashes I got are always due to the assertion failure occuring in the 'ipintr' isr. This *seems* to indicate that 'my_enter' is called at the network SWI level after another execution flow has called 'my_enter' itself and has *NOT* called 'my_exit' yet ! This actually seems strange due to the 'splnet', and the only explanation I have found is that the first execution flow has fallen asleep somewhere in the kernel (while this is not expected, of course !).

Now, if you've read my first mail, I was actually asking for help onhow to dump the stack of an interrupted process with GDB when the kernelcrash occurs in the context of an isr. Actually, I would like to know how I could dump the stack of *any* process at the time of the crash. This way, I would be able to see where my user-land daemon was lying in the kernel when the interrupt occurs.

Anyway, without this information, I am reduced to add some traps on the track of the execution of my process within my kernel code. This brought me to surround calls to MALLOC with counters as follows:

somewhere_else() {
  ...
  my_enter();    /* handle competition with network isr (especially ipintr) */
  ...
  some_counter++;
  MALLOC(buf,cast,size,M_DEVBUF,M_NOWAIT);
  some_other_counter++;
  ...
  my_exit();
  ...
}

Then, all crashes I got show the following equation at the time of crash:
( some_counter - some_other_counter == 1 )
which *seems* to indicate that that my process has been somehow preempted during the call to MALLOC.

My belief is that the FreeBSD kernel is (currently) a monolithic non-preemptive non-threaded UNIX kernel, thus implying that :
  • system-scope scheduling is still done at process level (no kernel thread yet)
  • any process executing in the kernel cannot be preempted for execution by another process unless it either returns to user code or falls explicitely asleep.
  • the only interlocking that must be done is with interrupts (when relevant), using the 'spl' management routine set.
Is that correct ?

Well, I am obviously tracking a bug in my own code, but I would greatly appreciate to get help either on my GDB usage question or through technical hints on where I should look at to progress in my investigation.

Thank you very much for your attention,

Rgds,

Xavier

Alfred Perlstein wrote:
* Xavier Galleri <xgalleri@enition.com> [010111 11:27] wrote:
Hi everybody,

I have reached a point where I am wondering if a call to 'malloc' with 
the M_NOWAIT flag is not falling asleep !

M_NOWAIT shouldn't sleep.

In fact, I suspect that the interrupted context is somewhere during a 
call to 'malloc' (I increment a counter just before calling malloc and 
increment another just after and the difference is one !) while I have 
called 'splnet' beforehand, thus normally preventing competing with any 
network isr. I assume that this shouldnever occur unless the code is 
somewhere calling 'sleep' and provoke acontext switch.

if you add 1 to a variable the difference is expected to be one.

Is there anybody who can help on this ?

I'm not sure, you need to be more specific/clear.



--------------070905060907020201090406-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 3:14:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by hub.freebsd.org (Postfix) with ESMTP id B589737B400 for ; Fri, 12 Jan 2001 03:13:52 -0800 (PST) Received: from localhost (s340-modem1099.dial.xs4all.nl [194.109.164.75]) by smtp8.xs4all.nl (8.9.3/8.9.3) with SMTP id MAA03144; Fri, 12 Jan 2001 12:13:48 +0100 (CET) Message-ID: <3A5EE6B1.41C67EA6@xs4all.nl> Date: Fri, 12 Jan 2001 11:12:49 +0000 From: "W.H.Scholten" Organization: . X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 4.1-RELEASE i386) MIME-Version: 1.0 To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff References: <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > 1. a pppd patch which sends the pppd messages to stderr. > > not sure about this one, I would open a PR about it. I'm not sure either :) Maybe everyone else uses gui frontend which reads pppd's syslog messages or starts pppd as root? > Ok, I may be misreading this, but this doesn't fix it really: > > mkdir /tmp/a/b/c/d/e/f/s > > perhaps if you called "stat" in a loop to on each patch component > until it failed you'd be able to trim off the directory paths > one by one. I don't think it's useful for mkdir to check which exact part of the path of the parent directory does exist. The fix just makes mkdir say the parent directory doesn't exist (instead of the previously wierd "the dir you wanted me to create doesn't exist" type of error message :). Regards, Wouter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 3:36:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay3.sion.com (unknown [200.43.36.250]) by hub.freebsd.org (Postfix) with ESMTP id 1254937B400; Fri, 12 Jan 2001 03:32:39 -0800 (PST) Received: from localhost (ol184-58.fibertel.com.ar [24.232.58.184]) by relay3.sion.com (8.9.3/8.9.3) with ESMTP id IAA30717; Fri, 12 Jan 2001 08:23:27 -0300 Message-Id: <200101121123.IAA30717@relay3.sion.com> X-Sender: info@globbalcomm.com From: "info@globbalcomm.com" To: "Paq1-1" Date: Fri, 12 Jan 2001 08:23:18 -0300 Subject: Image Communications Inc.. MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_001__32392454_30198,03" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a Multipart MIME message. ------=_NextPart_000_001__32392454_30198,03 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002__32392454_30198,03" ------=_NextPart_001_002__32392454_30198,03 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_001_002__32392454_30198,03 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iIzAwMDAwMCIgbGVm dG1hcmdpbj0iMCIgdG9wbWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0 PSIwIj4NCjxkaXYgaWQ9IkxheWVyMSIgc3R5bGU9InBvc2l0aW9uOmFic29sdXRlOyBsZWZ0 OjBweDsgdG9wOjBweDsgd2lkdGg6MjIwcHg7IGhlaWdodDo4MnB4OyB6LWluZGV4OjEiPjxp bWcgc3JjPSJjaWQ6MzIzOTI0NTkyMjcyMEBhbHRvLmpwZyIgd2lkdGg9Ijc3OCIgaGVpZ2h0 PSIyMDUiPjwvZGl2Pg0KPGRpdiBpZD0iTGF5ZXIyIiBzdHlsZT0icG9zaXRpb246YWJzb2x1 dGU7IGxlZnQ6OHB4OyB0b3A6MTlweDsgd2lkdGg6MjU2cHg7IGhlaWdodDoyMHB4OyB6LWlu ZGV4OjIiPjxpbWcgc3JjPSJjaWQ6MzIzOTI0NTkyNTcxOEB0ZXh0b2FycmliYS5naWYiIHdp ZHRoPSIzNDMiIGhlaWdodD0iMjkiPjwvZGl2Pg0KPGRpdiBpZD0iTGF5ZXIzIiBzdHlsZT0i cG9zaXRpb246YWJzb2x1dGU7IGxlZnQ6MHB4OyB0b3A6MjA3cHg7IHdpZHRoOjIzMHB4OyBo ZWlnaHQ6MzNweDsgei1pbmRleDozIj48aW1nIHNyYz0iY2lkOjMyMzkyNDYzODQ0MEBiYWpv LmdpZiIgd2lkdGg9Ijc3OCIgaGVpZ2h0PSIxNzMiPjwvZGl2Pg0KPGRpdiBpZD0iTGF5ZXI0 IiBzdHlsZT0icG9zaXRpb246YWJzb2x1dGU7IGxlZnQ6NTQ1cHg7IHRvcDozNDhweDsgd2lk dGg6MTc2cHg7IGhlaWdodDoyNXB4OyB6LWluZGV4OjQiPjxpbWcgc3JjPSJjaWQ6MzIzOTI0 NjMxMjUxOUB3dy5naWYiIHdpZHRoPSIxODAiIGhlaWdodD0iMjkiIHVzZW1hcD0iI01hcCIg Ym9yZGVyPSIwIj48bWFwIG5hbWU9Ik1hcCI+PGFyZWEgc2hhcGU9InJlY3QiIGNvb3Jkcz0i NiwyLDE3MiwyMyIgaHJlZj0ibWFpbHRvOmxlb25hcmRvQGltYWdlY29tbS5jb20iPjxhcmVh IHNoYXBlPSJyZWN0IiBjb29yZHM9IjE0LDcsMTUsMTkiIGhyZWY9IiMiPjxhcmVhIHNoYXBl PSJyZWN0IiBjb29yZHM9Ijg4LDI0LDg5LDM4IiBocmVmPSIjIj48L21hcD48L2Rpdj4NCjxk aXYgaWQ9IkxheWVyNSIgc3R5bGU9InBvc2l0aW9uOmFic29sdXRlOyBsZWZ0OjMwOHB4OyB0 b3A6MzQ4cHg7IHdpZHRoOjE1NHB4OyBoZWlnaHQ6MXB4OyB6LWluZGV4OjUiPjxpbWcgc3Jj PSJjaWQ6MzIzOTI0NjMxMjUxOUB3dy5naWYiIHdpZHRoPSIxODAiIGhlaWdodD0iMjkiIHVz ZW1hcD0iI01hcDIiIGJvcmRlcj0iMCI+PG1hcCBuYW1lPSJNYXAyIj48YXJlYSBzaGFwZT0i cmVjdCIgY29vcmRzPSI1LDMsMTc1LDI0IiBocmVmPSJodHRwOi8vd3d3LmltYWdlY29tbS5j b20vaW1hZ2UyLmh0bWwiPjwvbWFwPjwvZGl2Pg0KPGRpdiBpZD0iTGF5ZXI2IiBzdHlsZT0i cG9zaXRpb246YWJzb2x1dGU7IGxlZnQ6NjdweDsgdG9wOjM0OXB4OyB3aWR0aDoxNTZweDsg aGVpZ2h0OjE3cHg7IHotaW5kZXg6NiI+PGltZyBzcmM9ImNpZDozMjM5MjQ2MzEyNTE5QHd3 LmdpZiIgd2lkdGg9IjE4MCIgaGVpZ2h0PSIzMCIgdXNlbWFwPSIjTWFwMyIgYm9yZGVyPSIw Ij48bWFwIG5hbWU9Ik1hcDMiPjxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9IjcsNCwxNzYs MjUiIGhyZWY9Imh0dHA6Ly93d3cuaW1hZ2Vjb21tLmNvbSI+PC9tYXA+PC9kaXY+DQo8aW1n IHNyYz0iY2lkOjMyMzkyNDYzMTI1MTlAd3cuZ2lmIiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjE4 Ij48aW1nIHNyYz0iY2lkOjMyMzkyNDYzMTI1MTlAd3cuZ2lmIiB3aWR0aD0iMTgwIiBoZWln aHQ9IjE4Ij48aW1nIHNyYz0iY2lkOjMyMzkyNDYzMTI1MTlAd3cuZ2lmIiB3aWR0aD0iMTgw IiBoZWlnaHQ9IjE4Ij48aW1nIHNyYz0ibWFpbC5naWYiIHdpZHRoPSIxODAiIGhlaWdodD0i MTgiPiANCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_001_002__32392454_30198,03-- ------=_NextPart_000_001__32392454_30198,03 Content-Type: image/jpeg; name="alto.jpg" Content-Transfer-Encoding: base64 Content-ID: <3239245922720@alto.jpg> /9j/4AAQSkZJRgABAQEA3ADcAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wgAR CADSAwoDASIAAhEBAxEB/8QAGgAAAgMBAQAAAAAAAAAAAAAAAgMAAQQFBv/EABkBAAMBAQEA AAAAAAAAAAAAAAABAgMEBf/aAAwDAQACEAMQAAABqPX28i4cAKdQKjREEKMGyoBhUFS4OpcF VFQVJAqijAo4AQqCqODCHQDCgDRwAhwa4ygCHSYUcGEb2s74J+qPLTx4+w51Lz9bcu2a4VUV RQBhUFS4FVdjGXAqioJV2AwqTqXAGXE6lxFSzTXGigLLWnhne15vy09NmDhT0Jp+brucqkiF VKqumXVwJLgu6vSusE04GqaqwYSYmSnMDK0yBC9lBjpq6mpdMlXAqXAqXQVRQKoqCoUAYVBV FAGXAqXAqrodS2Klada+bfoaOft5tio8gayyuBnH7A6R5EdebtwGilSMuDGXYDLgDCgxhUFU VIqXBjLiKl2qvpaH8ujdON2NvXZtY8/WxBk2cnXnr0WZ81Zlq5G6a38xme55ifUu1jxtdXmb SFFKKksXftUrBgywqmLABaTWcyjAFgCqSMqSglXBVLgVLgVVxlSQJV0EkgSXQSSgkkCqKAMK h1syMz06WnDs83tRn6uQbspbhczbMyOgeXRpHM5PrOb048Knr6MlwqYMPdnpl1Vo5N70RiBx 9G6Xlw7vH68Uy6tVJETo5etz62tNcXRtdh1OXmg2tFCVzy9o7Irmc7bgLLG/IGjdlfN9TTi2 Xhm876rmbxxqOt5GXGvQrdFkgdS2k2NUmkopcs2xeRe6hYa1ruUU0LgZcZUugkkCpcCiGwYS aTICjQQoAUwRDCjYwogYVBNuTqYbjoIuLpuDyw1PByZmF3BSrEdVdLHwvUcfaOWLS6MwI9Hm 9yOgOlFKdwbjVvz7M7apda58IfT8frw58KtY6cWvzusaXeW+ndl1vJrQbcXgDPN9R/Oe5esz pUDo1iY8087jjWPZlbL4WLoYOzMZcqe6dWZSRWduWEi7mbNNdGZm5WZAKegs5j0RLApWm9M+ dXQy9XOmFNcwhQQwrGFNIERlAFHBBCsYU0gTDpoIdAT8x8vTs18zo8nSnMzRLJwlpBVLENxY MJCk2cqlbwbkMw1ZoQyXowNa1g6DWsRw2rWm/bg2KNXF6/C68M1FOrDdTw4Orn20cdtmvnvc b7xPE6hukImtDrVAdaSA7VTNBIIT4sqnFxfUZNV56mDtHbgm8w5e1fJ0wkTO9HE6amYelx1O fRn57an1Ig5bjAgY1DAeWdloUbb1y503p3xyxkuVxhAm3ti1vAufdin85GolvDMOurjGrq1S 5g6k65kdJ4uvY/O+KZKtzd1Gqzly1WjGpusCLB2zY/M7h6imeh625NRL2Idc35/0oMzu5z5r RwO/y+nDn3J14dnM1Xm9mZZrjUtOXUk0xa5OwY5pblMkGpZioQczLYbjyvqTNZtMsY1xcHQw defZtZvLn10svL0wgmdvWDmua1ucG5ugTXGDu01g1kU0wlsArAkMsLBpKYFodLjJeoOjIMu3 l8/Rpdyt2WnQ5u57nj71gO09PzRXdPh9VLaBHpllx9BKpOzn6s71mDLzkJFLnczRjjToXD9H gCjlLLCV5npCYsitOwdV5ATcLT6XqDlaxyqt3Mbm0hVdTJ04DpwhlpoQdcvULQJGjVkuo1nj YTqTCazieZVYAJWgs2hJ7UG51GptyYzj6QgJXXl3KGTOC9ePm3e7A3PTTzmc4TdIEq0EhyDM LEdgTKaAgw0EDbSxNlgEvWWZzlkh3OenItcs9mTHbe7G1zzOpSytyRc4yo6Jj5XQ0mLg9MQV bOd0+e5c7HpTdl0ZHPHxPQtnd7zXWeXQpyXnjw6ss709L4vY7NorPZow7dM+Y6hm8OT0/AbZ zu41HLvNc2E19bTLgr9XjHxIRY6rsrET0G5curFlDQkoLODhgxyxydjgrHlb5HmuurGpca2y 5jUYtibE5759+HuzOY9qH56mQMQdjYiMIDJUcidCF2FzTLBoW4DaYxJ1LFlBck65S16bsL5e iBCTvMkfTZznC6DcTbnSWc6nRSja59bfOZ67uYsFpY0FBQFk9yuCdZ9Ak3nsy0LDra+HuU9b dwdd54HNaVejM0l5pOpbVW0nP0KHlfZpc/m+jErzc24ctbNRg9y2uKXsBrnVoJVnY7Q0NZOb vjqDOPRlorPGn0mM7csuXUbqwvJrtPzU9NxlQPQeWrmKtNlgaCJZg01nUlCJyu7sdS7RDowh VGFazSvg9+U/JP7XMmzZxbF2caNKqjC5rS/n2112cZ5PUPn6KnZka+p8av1vi6bgUCblq0PP NrvILo1jKdnrWLlvV4fQT6JqkabnY3kPJZNOJJIaSo0+0206Jtj7VbTMWkg864zy1jbKolWb Wc2sCsrcVxyj6d1HPV1IHHnXazhj6GwSfIxp+gDiKF6KvMQfdTwaDsP4OuNOxeXTFldEnDAw M1tERCTRjBC7AU32mBpPMTWksptaLUTRyrBXO61D8zy/cIT8np3+fpdecDrRemCM6atfKMXZ 08rS46/j+rxNFygMNMG9DmdOX1PL9XnDBue6lwBSDMPTDQ4Tx2tyCz01uw6KnTFtc1dLaMcg zWlmQg2lg1C0XSbnOQyaaxB1LCAmiMIAZ9w1GAOlQuerpwOKXaprkj17DzES5twVQ06HaEZ8 PesPNJ9KDXltvoSDkbdhReNmkU1FSprQWMw0kggdFEFjcCEETYecmtB5yDTaCpNpJIZSzGSm QXkcHvuTpHMMDy6ahChl501J5aVeawOrxGFAGM0jxRgiCFYCV9dOdTnKiw3Yco+4znty26De ZYugrCLNoZonsHK8evZj1kacW3jaRotL5BKUxhUImXdtMipUlQpDVWawKltTtbBDivx9PSMu HuqT5Hc0tBEMZfJ17BCiaYJjaBdioCrGQ3ytYZDcxCV6VjzFqGWo5KRC6AlkYiSG0mziYVZA uMsazKBn53ZgecX6LKr4Wb0janx09jsrPy9erWHlD9RJrz/Q6a2KHRSWXndu2eVT6ww8n0O2 9Hma9XVz45Pt4n4pvrVzflg76lXFX6YmvNdDq6UcrRCQ/wA922tY3GtGss76mCwAgsJpFOpi FtQmVA6QWVGKzbwY+SVCwkliUg2LkRm0SD045Ba88jGSQMZSD01I1m0yS6CRGpcjC4ck33Rk cmUjSnSMipEW+RgMkClSBWiRDBkahSAuSDTmkT5eqTPTsXJplMckssUjOhcgE+Sps5GhuRlh IClSRVMkZj2SSDgkBmmQdLkaauSXokmk0qRPSuRzfmZHWXqSZ3sOQiDJa//EACwQAAICAQQC AQMEAgMBAAAAAAABAhEDBBASIRMxIBQyQQUVIkAwMyNCUEX/2gAIAQEAAQUCorev/KUWzxyK /wDSdbVt7OJx/vUV81G3i0+OAui2SjGanooSMmnnjK/tKLOLKKIaeczHosR9Jph6LCx6Cn9H iPosDJ/p7J45Qf8Aga+NnRxHA4lHjPGyv72LDzcMeOJ0UXv7NRpqVf1knJ49IQxYkroux4sc h6XGNtPyMjKxM/CmhNFmsjzXhyDi1872qytrLOQpl3tyOZ0yVf24xcn9Mknk8Sx5oyF6M3Uo yFLZ9rJHjP8AqJGHGsUeQixPfU4+SXuLF2ZNQkRk7gyWeMBTcnH00pLVafx/JM5bUcRordfC /wC5i6UJ2dNT0sJFzg4WajmpQkJ2LbUYGNfOOGchaVCwYkLFiPp8EjJoBxp/LT4iUxTE1shb SSlGELax96qXEo5pE80riiDISLNV/o/ycTj/AODFkMTQoiRnxu4ZSMrMmGEjwZCMJRFtm01j VfBK3HjjHkbIPZFqJHJZqcEskpQcX8MUOcrUU5FikI9sTJSUYwQjV/7WUT6yREu4dJDUchn0 dFfDgjgU0WWXvZ0Nf0FR0cSv8mGBfaYmOaTcYWvnmwrIpRp7R62jGxR6SM2ZYYx5TcSJqYxl jfwwKscmNiYvaZHZEsvLIrORKMZn0+M8UB4sbHpYihQl2+oY5CZqVWbe92rOO1i7FFFQP4M8 cDxHikcWv7SFLgKVnFFUQtkeyhbX8dUlyFCyjxkcdJIlOONZH5MmI6R5rOPMWPE1qcKxT2wO 4ykNiIRI9pIo1E8jShJCbSi+kWX8niZA1f8Au3XwpnBnAcq25FsTdXsirPHEeIr+tH7skv5Q l0mZ59RiIXwsssnkoyz5NIsQtssckiGldxxKJN44RcnOWJiPRqcinPbTRMsR+kR6Ill9UOI0 ltW1lll7Xvn0/lcoOD+LmeQsyt0s8WcuvwWcqL7s5b8bJRr5Vt0NfGijgV8XciBGq485KJXy slkolPk/zdkUIuhtsQh+s2NqaVuGFEYJHFSWWHCe2Jccc+xwVJK0J0chS65HIbLLLRaLL2TL 7vfPi8kX18JW1bjJMsvrPjalDPRHIKVn4vrsss72Wzxji1/g4kcNnigeHGPDEWE8Y8bPFY8T RxOB6KOVqPXyZKRLJ05ct4iPTZYhSEyUIzU1kxaqEr2lPipy5SF7/Et0X0vVsj2IZyLL25Uc qOVlCRfw1UaybyzxTfHIeKSOM0WT/wCSM4UfziLUSRj1cGRywOSLosuhSL3scIseNlbUcTif aWWI81ZlMTMkqjGYmOCYxi+1fdEXxnInkPvdbMiL0325Ee9khFDxqRkz8csU5CRqcajLZPlG Q12/4s5C9HGhbUdFpF2Ns7qIpHssW+qleQtbZIcWpIssVGTFGY+WJrxs8WNk9DjmL9NHo9RE 8DcYQjFLa+k9kyyx0xw3RLIxZLOQmavG+WHJcIzizUy/48edHliRy8ikPGmKBJVKMiL+D9ZZ l21Gl8Ob3jYkIckjyzPKzgvL9os8UZsjnLbHPiSJNjPy2RZ+OVFlku3XEcqHI5JnLpNbIXRY jJLhCTtlbXEnjxyPHRxkjyJO0ZsvFYI8d+z8jQiz0Xtfw9DimUhmS077hMTs9mTxoxRHGLjK ln/OJ7yqU5afmcMmIhKxbzMz7UqcZKS3l1LaKsx+kUpE4SxuE0xGph/FMdof3NRJJbLUHK9/ Y6EXbT6Pw5UpSH2xCoRF9077HUVmyPI/g3xlyoUrLH2pN45nITR7Qt2WJnW1lnIT2Q9pQU1O Di4xIIs+myvLDoslghMekiS0UzFHUxFfHDntqZ7T/hOLFtkMvsxz4yWJNeE8JnxuK2RB9cu4 vbNj4Sgma7zLFiyc431KVZYk1/GKc5L9Myym9HnxJFFHESEhdFjkN71shFWRJSWNZczyPeyy UVI8MkLkWzJm4rC3KaaOuP4v/DF/BPZbVY+nNclxcRTEyYmJnI5Cdi2npoTyRwTgJGojUoel tlmkpu3tpM9N5IksjM762QvSIPtGrklHDPrpp6SWCUIvjm00c0FHJCXFswyjBqYpGfCskfhY mUcOnHatvyRVkUTyLGSk5v4eWJ5YnliRkpFxJfyWfmpY+oJFH4RYtr2ZXXZ6OR1shC3lHkll p2WIu9uRz2TEJl7IlFSU1435EjJqCU2/hZgy8o5dTGDu9rIzORCQva9a7nnywi0otli+GTFD IvpaPFkRFSRm01jjKG9ilQpNne3FEltxFEhBGSaiP5eLGcMZ4sYoRiNuMuZqvcH0vfW90e/j RxOO1C2ve9tVj6x5uMrE+rOxyORDIQyCkJ72WTjzjNuEr2sssbPI0Y10WWcjHk75ULKeXlFS oSrZP4Xs2WJ7NJmXTNbpWKLI2j8OJRwsUZISM2sxwPPA8sTyxPJE5xOcTnE4nHdxTJ6dGoxZ EY/tiLve9rELeij8f4H2ajS01OUBZosWQsk090yM6I5RTORyLLNRp/NGSlCVljZZdkmRfXIs s5FkJcoCExPa97LLL+NmbDyKFESaPZUhylXtRRRnU5w/a2L9NZ+3j0Ez6HKfQ5T6HKfRZi9u aOSLOSLRmjxyp7WJ7dJX8ve9/C/hVmTSQmZdC6eGWMWTJEjqYXae9likxTIyExCNXplqMTlR yORyMemz5ieh1MIp0ct7LNPPeLF2JdUX8LLLORZZez48lV8SmkhtFbZJrGvqD6hH1KPqon1M D6vELPjZ5InOIlGBZY5pNOzyRr6zGPU48kYyixe679bdWWIRZZe/Is7OJ0dfKWOM1PRRZk0U h4p43DUSFlj8LEyL6TEyMlWrhHltBpPDnjeTSaaekLFIssshKpRnz3TI+/Z9xW1ikPIc725F 2Im6j0KKOJe62njUzwHgY8DFp0S07PCR059Mz6aRl1XEjqZMlqxapxHqMrcs85p7JtEM9Ecl ikmWWLZbreyyyzkWWX/gljjMzaBSNRhniMeRxI5LW1imRmzmTz9ZZciXvaEdNOOHVywPJw5/ CEXOS/SsPj/adXhOM4bpidl1s2Oqe1l0J2REZmcXXo5Cdbr0UV3tQkjiiiihvCRWnOOnHKJc pNYYslg/i9NKR9HnY8GRFyg8WVNY88J7dI9kfe1nLaiikUi0Wiyyyyyyy9r2njjNavQSxGGf cXtRQpDykpkpD/xehNmPVvCvNLVYeWbA1MUjkKRY8lLn253tdFkEIRll/wAsGMva9qEmXs3t yOY5s5SrnI5TFp5C00+TxRv6REcPEjjhF9I7JTUX/wAchNVUZCjCG3jieAeKcX/NPmk+ViZZ y2o4nEpne1Fbdll7X8NR+n4so8c8T3bJMb+Si2PTZIx4lfDHg0ih5dOxx0hqXhlHHlojOyy2 cizkcjkWR6Iysj2I1eThkxNZY8KPGz8/j+RFDdFtn8i2NtNSluon8onKR9VC1UhzjAnrUYMu TUShi4rgNKpfp+PLPHoceNeCCXjRwQ1RZZyTKoeJTXggRw0eJHjoaP5Cvajo/MlKQoKJViVF FI4n57RZYjJjjli9M4jGMkxsjGU3+1arj+16oegzRcdHmb/bsvLDpeChp9PEyaXTSF+n6Jmb 9N4t6HLX0uUjpsgtBglD9qTP2hn7dqInHU4xZJHNFl7cu45uTjgyyfjeOULHaitPmnqI42hQ nt7OJ0Uxo4o7RZ2dnsSZx6l0uhfpc2Y9Dixj0entabT4iPGOzVuf2qS4c7PRdHKJdtxt5E3C L8GNfymud+lyRRYyjicG3JpC2Tm9rSOqSUToXbfQrZwKW1nCyeCMxaTGS02NEdLCCWPEn+O6 bPRcRdkscm+LS9H5cky+ZQscTxxaUaHFM4lMqyWNE9JhkR0eGJ4aIxHigz8PEnPisahyOpk8 UajEUYxfvaTaEy9ns5RiWj+J6OSKO95D9fl/fMXvJ90Eh+/+34/Mj86gwfaZDKL0if3sZ+f/ AKG35Y/S+2Hr/pH2j8oe69L0/SPy9kZftt88f+xC2y+v+q/2rZfcP4sZL7mP7YfcSSv8w+/J 6X2z6UPth98vUPsl6j7P+z9az7tO2Y2xCF7tn//EACQRAAICAQQDAQEBAQEAAAAAAAABAhEQ AxIgITAxQRMiQDJR/9oACAEDAQE/Af8ANGNn5mwrz0bSjaVxrNlIorzIhpM20IaGh+NRKKI+ xoqySNo1zr/DB0x0KXw7TLTGOOYQcj8kjahxGswjZtGsyZH0PDHmis7GPTZsZXK+elG3hRsf CS+iVkFtVDZasZKI41jT9Yk8JfRrN4dPgo2fkR064UPTiyUNvCuFZ0ZJOhnpcKJf1/KIwUUM XQ5EVQyeNNViiuVYrME17zdey1i8UPTQ4NYojCxaaPzTPzR+Q9Iaoh2h5SNWe3pGhKpDKwyM qGjUXWI+R4i3941xocEzYzTSKLp2eyPaoaGrI/yMePg7vvEXavDYuxo9koWfkzTfx5aKzQ8t 5jNfeFYrFZeU7KG28bpIchuLI+xixKCfZ+cSCpYZJHe0jI3ViUe7Izf3L4schvG0URRQv+vI kvY1iiiiiiPYlhnt8JIvquFsbYpsTvDLLLJMoorKdCffkTo3F/8ApFr5iiij0LUNxKZCf03j kRl3iuFFFHovNjfK0WWKXlTHTN0oohqKWGsKOF2NIss79kZ3h5rFc6KKK40K0bjcX5Kp2hO8 Mcs08pDFOnTxRWWL3wv/AAWWbi+FlllidG8kyiuNY6F16N7N45G5m4svysXgh986F4GLnEef /8QAJREAAgICAgICAwADAAAAAAAAAAECEQMQICESMRMwQEFRBCJC/9oACAECAQE/Afxp5FE+ dizL9id/bZY5JHyo+RHyoU0y/o7LL+/JmSXR5WPoTIyoT+ueX+F2WS7LLEzzoWQTvlf4ORXE 7HH9nUlRTQmQyfpl6nkUPY/8iTPN/wBFkaIyveWddDkJ7SJexDEQa3Ze/kiLLEU4l8q55pUi hyoXDHLuhujJPzlYkU6IkZJMhkUtZr8tLTYt0UK0R3KaR8xLJ5cLFmkiGTy4XwveeLatCPbF uyH+q85E8jmxDYkSYjDV6yu3r0Xp6ssssjPc2m+t1Z4vVaTI5WLInqyU6Hlkz5Wj5mfMLMJ2 ZOpC2zDj8u2Z43Hghq9YX3qXGucfWpJL1wR5F8LI5Gj5EZJWWeyqHpSaJNy0teyNV1qSp1pI Ynesc/FnzxM0f+luy+cI3uWNr6L4LT6FvoUSmiXoQxDyTiuiOXIyTbferIsdeQ4iiUKfVDin 6+hEcdiVa8xzHJj9fZ2+FiZZY1XD1qtRY+xbaQkhxK0itUQiv2Wiy90P0P7KPH+DtbssQ4lH S9nUvR4lElq9Xqyyz3pbRfHsoocfutopMlCuHlepCK10SjXG9WLjRWq5WPso8SvsUrVMa1Ql u+LjfZW60iuFbvfXC+VFFca3WvERZZerLLOy3qitdFar7UP8pcUIZ+uS9j0j/8QANRAAAQIE AwcDAwQBBQEAAAAAAQARAhAhMRIgMAMiMkFRcYFAYZETIzNCUGKhBFJgkrHBov/aAAgBAQAG PwL9usuE/wC32W9vFUlvQgrdoqj1dirT6d1v7Q+FwxHyqYh5XHRVJK/UF9uMHumiDH909lSG VMlVig+PTsF9w+FSCFXlWAfCeGGqrTQDDe9lwH4VR6Sqp6tgq1TMqTByMiPTfyOfEOU7LDDV UTVTO5TyaKEFYobft5ikxCeE4SsJVU94cuMW0LN3W9H8Kzr8YXA3Zfbif2KY5/qG2a8iJiAG VFhD1yn9wcxTxgd5vDulcUK4pvB8ZvfLvFlQLFCAmIbKypNhmeXiYJy70LrFs/j9uxMqzZOB oOL6PUrFHMmK4tlfrlrTK8t6F1QLhTGALcPyuGRmW1Kq0uapFK3q2ndPFpPnqWTiyqnJW4HW /VMdmFu2MzDkoMmGGGmmyomR02lfNaVPV4eepXJUqm1IW8XlUtlpymSc9RO2pihNUxGaiurp wmevRMDJv2IxatU2beTCbFEZLzHo/cZaKpyOCmNF/wCp3VExlZUy00qmVlQq8qytkxDSpnvl YphC8PWfVOc1JVnT01IlYfKsQmCqqKo+ExV1dNo9dKKEzf09M/0tmK8z0VTJxzm6ZXTCs7Se dZdZ1AVPKpyT6LtSVJ9D1TRs3VWC4Fchbu3bwqbYFC8J9iuapoVVND6kCeyumErqkqejpk4F wqjMVfKxtoe0qiXfTJT5LqzLiXI+U0W73V0zOVycypK+S0qalZmDqJVCLIPl4mW9X3Gg40qp 7hVk6vIAqgCtLB0y0Ge2i5XtlYq6vKtQsMNf/E5uuibmr6FJ3z1TFUl7rHtNp4nZUiK+3tWK ba/IkQeIXmRoOIldXT5bK0nFirp4bBAhWTGkqlMEYgQnML9tGues3K9s1Ud7F3VQZmJV9PfJ XPjtF7LjxeJYtDBEaLdqrr3yVyQvJluB4T0TGFdIlhMJkxoZXWIcQ1rSsupTnLdXV1RUld0z 9500q6TR6D52K9pUzYeaww70X/Sc30IfpGkN5XzNHCtzaRDuuIFbyxQfCqG1KyaG+eysFYKi rJ110L6+ILCclFUaTJjnoczGbOmT6lk8FRkoJ1ycKwQxBcQXEuJXV1dXV8lardLKzoBleyt6 Vk4suqu0r6jw8QREVCNUZK62IXldXXMKhlSZggiEL81+QKu0HwuP+lxQr9K/SuXyuH+9BxbJ 0k87+g6LqqOFWqru91TNfLiHHDleCAt1KMUUFB758OS+udHhXCuFWK5qpZcS4ldNDCBNjEJF jZXRxxMOgGSuvfQqFRWW6SE0Svol0SJ78OIdHZYdodpg/jHZbTa7LbbSOKGrE53VMt9C+e8q 5Lq6urqpXVcJVAyurpquni2hHsFu4ou5W7DXqSnxrCTSdFVCqvKvqKhbq3gVemhTL+X6cTWi q6w0wm9HKP03w8nyiGG5Qxf5UI2n9J9jHBGvuQ4TlplvmAZOgfQ/jC/G/lfjCYbPYN7wrDDs tme0KeKHZ9oSmh2ez/t04gwKkFOrrl8y3omWEGqYzv6diHWPZB4P+k2W/oBFSI91FEIdlD7k 1Q+oxhOZk+h7I8xkvq81xBcgOrpvqxHsuM/CYR/0uIq65KsYT4YT4lWEHwqQgdguFcKpEQqE KoXTRtK6vp4tnuRrDGNXGzw9Rmx7T/Jf+MMKww7sP8g63dsYPF0PpxmJlXSfJRUhTBVErZrS qMtkwiTkyoqUC9064mWI7aMpsUTLiiV1zyM9U6uuarE655bzplvNsllhiX+rM0IJKfDD/wAl WADymMBTGHD3TU+U0W0obwovshEh9kDsVaMeV9o4wnEK/HEFXZlPjIi6Km0Pwvz/APytyKEr e2EXhVgiHjM0Afwt6Fu83AdHa7Rh5VNoniiyWZUrO+W0ua/X8Le2oHZfrPlfiHyqbIHvVUA8 Kydlw4lReyAeqqrppRCE15IHaX9ljxP0CtK7TtKyqUIRdPKwEqypKkq0yVEqhG6oKr8YPdMN mB7tJiadEyurqyfF4VMntNmGbhBVdknhB8rdPyFiihTwhu07FOCqgKgPhXKckqkrUnZUlUgF XddFQyor6QpoFBCZUOQ9pHMe+uZCubx6gI6BV1fL/8QAKRAAAwACAgICAgICAwEBAAAAAAER ITFBURBhcYGRoSCxMNHB4fBA8f/aAAgBAQABPyHwQlHBPEJ/KE/zQn84QhP4Qhpmf0NeWj6G 64Gv5TzP8E/+GEIQhCf4aE8oLKGmT+MIT/BCEIQhCE8QhPJCEIQg5SciJNF7CcFi9C7iAQfB Yb308o627Whx/wDRCDaqd9DXtvJnIk7HInpYKc+Yynxb9hH/AAGRLx9kaif3Ji1aHrBjHIEI Qn8XrSM9eUKVoTbaGj0NKRYmaGgcf55/hn8YOz45s0pe2KsTHwe/6MXHgT8NJIia9imKxz0H 4T/DPE/wzBW+EK3D0N63e2JuT8j5M/JsLeQl+wHhVArZYpNiaN1z5jIsGSwJydOgz2JYvlE8 zy/Qb9E6Dk14UUdhI0JSC6glCEJ/ghP8j8raMs2avRvZJehKqG7CeD5QMiZ2FoiY3J6gY0Tz CfxnmE8QhCFHEUD9noy4wPM6foVLZRF9iZlLKZ8TFvHoxX9jmRyzUkr9if7hfHRRarWOuTpG h9oS0c+OiEIQgggqfBl4JIIQrgbZSleMT/54QhNjOj2TQDXTGlXr0KiZRdcBUZaVwtCXl/kU gmNiSFm8rb9eBohCEIJLg7wJ7+Ac9+T8Mf8AcGMDf7AOciNEJ/G3Q0KSiFarHOxNbTUGWhgq OJnAlP8AsXs39jkZK5Zgq8IeDV7E1d9ngky2hBlkH/NCb8PYlWSYGmNp+J/9rE4uR7SlwhfL f5Ic0k2BvyJQQuPatCT/ANxsL+ij5E3jYe0aGvLIIRGk+4w3+SHvsTyI4NWpFWaezIomfY7N MuGP+DU8OTA4JeJdGh6jP0VG2s+hbP6LiCOy5YnH6CFQxoUIlTeKQz3D6gj5wJohPZA8iDh/ wbB9WPzmGKF8IEcf5Z4SXPjadcDThjghCf4cDo5opb0KKFEKM2TLQsiQ0aLUQmCL+xjExogm w27hjmyJjJ6jDl6TJzbfHRWuBnoYykjIT+Cn828/mg7S4yi9hsxeZkz/AN+GodSOrEI68GXT 9iVwE2E+BF2HoMWP7I42ujKJvRXaKIX3Wf4qXxmy8kehTkJO/wBiOwsfI2coNf8AYh8Sv2Pe Ynif474fmEIQnlKyRepLHlF9Y+DG2WzVdEjQikKaFL4Ykq87GhmXAqcmBXiVGG2cTGRrD5zz xeTJJJDHAl7EuPzOCWt+nBQivgyxcyvBPDOmyjcUGTiSz2OWh+xFDcIpLgVa0WSSPL7FFaHl Jspvn2aCjYvYb9+E/DjVcibrproaZbE4P5slFofEUtiPkG/lQv8A6citv6OQK0v0J9sZ9jTZ GNvoZyTGycaIQhCEIT/HCEJSN9jV0FR2WIReWx3/AEYroYqH8nPk1ELs+jF7/A0whYy8Fa/0 DNzejIfKIkQ1NbG847Yj7PkKITGvIfjk0kFbEQ6QfC7/AANltpP2KVq/BloQaNVc8DZpCxY/ KJnsXQyuheCCCuiFhhuzI+AXRmKpkIYIYWWbbWBO1sIs3uomMndkZaHoTTksv6M/AWEjSfBQ uDKiIaYsa+SEIQngkRhBEREJ4LxNk9EITxD7Q7vNGS3gVdy8EeBYeMeGNzxUmx4Jpdi9Bkgn A4lkYJNiTRdKwN7NcXwRhU0yQ5tgkrqRBLJA95MvQoZa9icN1fIswSn5KlW17hvMjJxk+EZV 2jCVML9GHoat7MVF9xp2j7G9v7OSi7CfvxmV6hKnmsVtbexwcnKF5UaXoSdwdTSny6wYWR7F zdYT2DYLAKdSfs2qpCrLRiy9ehM12ONRxoW9/pm8RP5QTPQ3hehL3Wex+S6fWz0hutNM4qCf RU2D+LaCyGkSPmEzJTkxteM+EMJSdE7BreNNoxtvpnwrRVkmRsdjJxJDK48NeCSRKmAhfZjg Q1rJLSGM2MbNQwk2Nr4G3yTHitj6IjMZ1x8ChvBgzz0dGjXAm9pC4U2xgbr3Pkb4YM3+xaMM WqXJG5sEFRN+FY1L4TEyBWvRitr7Rbv6q0NbLvgOVl74FyKY3s9ou3Ebv+Qm1foZ9u9iW8Jk SZmZdQRXWhO2K7YmL2OFj9CWVgOSeCCK/Mtm+NlibbBmBtEUaohrFRUzemYuCG9DJZM/9yen 8OCKeRgr0EoguKO9W9DZNi0jv0KeQuCXIs4tOLokUDqsdBtNgQV7E/QgahBYYpYy3cNLQVUE nZVcISxTgRYIbq2/YsOiMq9MmIN1VoLAuucCFbsYnMprgTZqsj9Eu3Bnwx2QnohlMCLoqRRU +l5qjGn9tlSSS9i6GJ3aNXYmwvU2OtR1nZn+UN7KZ64ETdoxZe//AJ2cYfyZs0dvG/yNEp+2 yOUIv/IXqYznCE5ikFk+AkpwF9mK5IgsDcsWeyDX6FwPuE0Um5GjJU4cZqEMZObR5Rv59CWq 0QzRjsTdoWXAybMdgdP9GGQWvCQ8E7CuqipEIQTafTHp7Fbli0cWCZg5YywjC7fSOjD2z3TJ cOHWROdDANMY21EtLxCymRSyh7ZkxcqOzjPYpYv2y1XsTS3t2LmkkhZ9HJuseRrIUUOZgzez HyM8FSWND6mLwjJ8nqN2Jc/Q1zbfmkKkf0GGGb0JkUb7LakJSds9BO7FpEdwbjXISPVqPp9l bWuRV6IbdWizX7P/AMU6chfJnTIum/0bxF8ZZn4GVErgSiNoQL4CkEozods0nT7FJapDLZLY oWHZIQ0pkTxsvsTeeFwJqOw1LhQPW0ZNilnh4iODMh4mQhBfs8aOwkQpSK7Iohnl9vRi2aEV ECxpJox0RcmOTznIykvwi3RfA4yDbZ0IERFcGiURpcGtpjPvHVHI3TioSdvHsi32KiMbDOBp xKw9FRsWlHyZKrfSEOP6F7gl2GYdEjpaaRCGBltbzoVdfhnqPkSLHPZDkiYT+1aDTbpsUsNe hNTwHMITiqwalb/2J23J2GrSzSGG/wAF6BXMyJOjfyNx4JRbJTB8Mjxf7MVZ/kolcjnCDZoZ djIqWUS6GVar2jhgRVaWDk5rkMvlwQsxsRi3oT2ISLossjZLEZIdC5HLb1yIajT8F8IILfov i0hEdsTatjljs3TlMUaELbOLofVdGC7laQnlXRW4WpOWhqt/Zv0JAF9VejFk7eju5IZLRhyM TozdGjQurOoqNfJcjyL8BdcFJTLNLAmhxTjJlgxl+OWdE4L+Qjw+H0O0mrVaFR4T9rAlZoh+ FRn7nWdjCcCXyIWE7F7fSFOz1gSm8M+j5c9GtkdwPKoxPjJtj6/s58Cyt+TBsTcMGLMQgjLa NVijlgJ0JeDN7IBr4vqcJRMUR3DMeRqeLG7bGwcDet+GezkgTP8AoUc+3gh4fAiVz7FoW6QI ksGqZ2NjUtzNwJSJ8lebKY45ZfQjNJmKpI0x4Xteh7V8SBTUpLCDor4ORb1PP0KiGOfGjFds lY5G6LlgqzhSjP4PYQvg3LX/AB9M9M9M2Cj1bezgNJ/A7CcPgRIVpNjL/wACSZf0K+hej8EL ojkNqipaMLMX5Pl9FKnKKJgbTbMj3Cx7ZlCXNPYwfBt+FZd8MSxTTXI1emmiViyDX38ENNMr o8rqEOWz+hOYGVZ2Nw/IT8IEwNi/gxIbRhiG/Y8lKKRfQE0f0hPm1tlIIOMSOVIRdjXJSkq2 QnuCwJlt+BTeQrQ1ExfJh7RHB+1hiV76TIX/ABsaohFIy90Yx/yLguCBiYGFYk/CgrBuzoh8 CXY//UYIOIZ0Xdlt1ujR9n2UokbT7OPwdqMHiJ17F8RtaFRHkuhglonwLhJ/gXsXAhvZITN5 yEsf8E5M8jdrY45EnMbEwjF7FkUT8KV/LHOtHqmYtolPtj4OqDhWqzkYvaG6eGMVTEN5KlcU TvJReFDGHTA0O+Rv2MMPwOiM7gnPF5jHqBWg+arE2ZXpDFbaLof7NPZg/wCBYjZaxMXB+HJd +bwJY0a6YzfwHI01h+MLvo/7gaTX0JrFJGENryK/Q5gl5eRWQvl0bMl6x6B6p6p6v5PV/I62 n4IX/SEsYok7tiWYvZtfeMq5dp4LoyhEb2Dep+jSUeTazsw/2J//AKRdEQrgWeTfrxdK0SQi IJPW0JMgiGhElZTHsXf6CWNNEIM06ZTX6Eq1HorcNlmKIauYP+4h2r7EM12fIS9iHHGr2LCe wn4u/DnyOgluC0ngy/uOhcygaP6Hi2RleGbuXRPYuEQnClHyE/jhibKUyFo0xN+zIUHHJCur CS5BSX9saeNCLjovc50Q5D2WftMQ2g8cKeG75Mv+wn9Psa+4/wDRBI+RGSX9DRyyez5T0jcw m1MHRROuLD5IWUkzqYvumg2RRPOBN7C0hfJMYNso9FRtCiKNROi+DkwaMjt6E2kU2j0005KM RbBIVkyEwLwJPZicRehMEfA3uDDqtJWPfoY0eGuz5DSjyFtb4CEtkivHxq7E2xsijG9t8D0h YyJbTeieA7BacYm5KcXwuHlSCTVGwhcFMHOD4CPRiaDtP5HXrAk2nBJPaM929DVcmLuHtHYX ckMv7SNEpfSHqCyB+DQ9URgPpsQlTqMql8xr4Y6rHRA1Q2I0001+zrmfZhhP9jiYT2JYuRcl Q5bPoSX/AIG956Gz/sXpBH4jY2+hMuBYaMuYhJyEl0UW6F/CQQbDDIwY/v0Ahjz2N7j5KuH4 uSOyeisXXZcnyWWkOJI8YKJrg/8AgyghbScvx5FYw/6LwiicoaeRikcgpK6Z+hOc+B0qdpsE tNw/QWPgaJCe0LXRmnBc8hTyLuGbKzuxuuF7O5faKuMV0U1dia0hE1jZ0apgeZhnT+o+v+Dp iPPfQi8Bvy76GvhfJ1/sex+TLW/wPh0IRBNaWzQc7bDKw3wtCbUnCQy4b8Na0YhuD7Iqw7OD Jlc/kayYsj5FvLEaFJDiURejQ2ddnU16MeRSWIphMpS+WvHaat9HChcjdZPoTm+ei4KY8jBZ +hSSKpmw4Ey7pWSIb0xyZtidLD0zfH6sfil8J6rIkTzxtJp/AbnxKxv8kyTedNnOGIziMZoR OBKHZzBHy0FwVG4s34L0SBDAKQYp00y580lFjQz2E85IMeRCU9D2PHhoXy8W13cvLFnXm4bD sniXCpnKIwk38jXoa4VBikr5aX/QprA95Be/udCQb+QRf2PJGfSUWIqG6TrOVgept9IzCyMv JvRQmwe8iczo7mRikkcjjsy7/JHZ0ui9RN4JReJjIr8EMaSPstucy5EOA+jxn8i7sctw1rod OPob2UM8/wCGCujgg9j5rRdbQ52S7D6J/iruRb1H4FjBbwzDbX5FoYWavydwT/8AMnR0zZkp Kfj1G02JfBnsy4n2JNCc9+CubKem77EHkTe4X02UeKV2xjnhkdU4COpfsUc6PV+A3tPrP+h1 E+6L+Vegt36wxKUuRVZDBouryZrgJSXb7HK2e4Y5opwNT89Rcz/oIrIaP/wG1+ZyNDmY4Mvw xZChL6f8iHcmu/C9qeD+58TqN6wTb5GHyKXKF6MPGO8lzsXAwUo69tVp/Rsy7WmLOjKxBueR 9o2PxCDDRjp8+ivCEEs5FT5SUqcoTU/qoc4Tm3+BjmEdprMJTYr5Jc/grkZyeyPHPkwU8C4i HSYYyF/GzksWZ5Q39rhkn0dCT9iNCmyKLLyaEOlgjab+Bw2NMGP0Q2q8DcwUWHkxuo9QXYBg 5XyNZPsTbSL6GRfQF0dfsJLgr2zeP7Iyp/DSJd8zbFsgSkkn/Bnl/ARMrGqG3AmGgN8jcFJv Dobo1D7TH3eiWE27yRo/yMWvwfBpnK3PkVZVLf7Pu2JNUh8Z0RHi+z9glXEsaHeUiG5Xli0y RYHkfPr0aZ0aDXsxov6a4OrT9kJykaGx4k6FN0cJDTVXppRYIHcjS4a6EP8AUSNPusB7usGj JuZ+zKTP0CLN6eo0Isg0txmfPzEV6Hyiqd4g8wpqy8vVD/trKXNfNS/0SX59xMWxpuk0ehos qSXnXQVG6gtdV2hGZY+AQ+5L4CZyKlY1oT12YTS/A24bfo0lfBDhUCXtQwRtoa1/kN9Nn0Ew v/wV8BRVf2PwMvRHJ8vi0pGz8+P6G6/M3+zKtX0ECSS6SCa34EY3HyFUejWRRwvRia5gPDyL NJ5GQpjNzkhVdZPgc22I55MJozbhHWwxkxDXzdjbsaaMBmuB9dBVI3gqjbR2QSzcDTKCfZG9 vA46jMoT34Q9m5jsh7bArSywVdT4MYUpPskGjc/AQtTEmN+yhvwbFUa27L3L3FhiAuMMaqLa WhLlD8DBwT3Cr0DfmHOmPwhezDBiZ+eTbMXpkmmPQpw9dDR48p+SWpiosq2+j/h0JHYo18c1 f2NolaXuNoafQZf2cylOEEsS8uGDD7Cbw2UdxynUU2v7y2wSet28i9Rc0JkmvY/oHxWYTViq VfJta7It1COhq5QTGUGh5PaGLb+wVCprTs4XSJ1J0fgf8CkvE4GR4eLo4hsxwG3DvI0jXzNE IZrwkNRlL483eR3v8WdWfFNu2Zh6EzjwczWYJPA80z4GpXefJwNb+DR/ArGcGsDFnlSiGzRq NjmPgVO+SuMjP6iJPCOWJidmgjkWzg5nAwTw/q8SMxFRtvNseRwIsor4MGYMrZwYoXjZvLwN 4LwFTc1Ysehq1vyMcvHDQzrI6bZ//9oADAMBAAIAAwAAABAQZ7NWX1w9c/nm9LbxMzUJoPEZ mRieVq1VmYHoMTOmgOZ89xAMWaGNO3k8QgibpbKZLqOKJeVwRaZMLo3DVcK95vjIOhddostj t9eeMB3CTPPNgxTwMePEV0K6AdEsPXrsXVwjvLPNZkKhWhW/jlscyekP7GhQTLhz0rfjrewP 2pde9VyYxxxSc99BV5QnxyxyfjMX03EtemAjYjmB2htpaGEJb7TiULi0knihXAO5rz5Ss/pA quxNhi90vIeevBKnJTSwEx8x/l5IQUao2oHbEL9JAzLxPAQGOqVvZtUY70TC5ytft/aRfpHR luSy0B94w/8ATvfn3L1VDgXLoAfSYaGI1wHrKvIEwc2HxsmekNXaookb2fTzyTa00yMOmid5 mbqVu3tTzaLVw8EG3n1O+pvo0LTX41eaMk2vNyJbMRBGwJI6BFD1I2lLTqQqAnsR0A7YHqI7 0bZJ6s2NuRyc4W7I4T5fl/QIUu1tpMT3ZgKjuLfj61yyXu2BnNa3WxPRmYMUl85HIHh4ije7 H1a5tuIGiW270Lg05hVaLRt5ix2Azc+KC7coLW4H6y1x/rPPekJFMnfX/r6SFVhAiS2OggbU ykEq1jHgOn/lZliIXuKjh5jWhSU+3denowPGkDfc/cBeiBAd/g/eiAjB89/jB8ei/e9Adjid i+jDg/8AgPIQ/fwf/8QAIxEBAQEAAwEAAgMAAwEAAAAAAQARECExQSBRMGFxgZHB8P/aAAgB AwEBPxDOMbP59/Bbj9y/jKPf5MsshNq3a45+CLGHLH208gfZPyTP5CCuEh7nxhrjKWhjDH+I L910mYMMV2YWEN7sLLONvZC7WZJ/OQrD4m3TPay9HkP023ZJwh1BO7D5Cnkg86NjBYcO71Je VvOpzL3DlDP6Xf2O+iH4afpKPbOc4J1+XYfqX4wbZfGSxsy64iwhNW91R7/o/wDvJ/JE8nG8 EYwMsWa4NTxtZWdy7ewnjJ7j63psiCQ+3zMnX9WWWcMsshNllsESHonu8ju7w1/33SrtdmyL rAN3bO28tkBbs6m4xY2WTMnhkDOrOsleGwnjdnBWdezvOEyIjyD8jZ1ZXaw8tUs14ZzYPpDg /b1ESBb+/JQ16vRD3dvIJJZYTjJJ3jL1GzjpaTa5s9+3SOuuc3lHdG6nPkSbhcyImPIwh9RI BNOB2xp0tl9Ro7Ac27LCxgPS7G2fpv1zD9iJLTub0QL7EGSTGS2yjOl0+Xjl/vDOGcMyAYZJ dj1Zv7lQvdieR9Er6XanUvEI92dXei/ogxOBYMK1fJkq63bfCA5dlhtgQlsyyz8tLb/d2dwD qHb/AI4yTjLf3GWz3JZZMchqVMYodJBx9gPOFl8yzCUJBly0YeSbJZBdDKO4nTAOpzJHzh0m q+WrX4F8W22LOGfx9skhrxn9H/sj1vCWczEexbHcmENWDcO3bg8lmzOrLPwBq0npLfZ4W223 U4OX9kBjHkL0xpCyy3UWWSMnKnkO1O/2T+4v6F40khBn2PjqIdQydx8I+r7dMLy9sWTi9beu pt4QbEixYuvpb+i39y7Yb5WH9s/YD9s/Drjq6s53AQ2ZZxvbwMaFnCNjd0i2urpmhIAsJ/u7 Re7TkwWWBdQv221iz7zln6tT7ahWrTa8bw1H7TVgbU6tfWBYHhbZBkhnMyxfJfTID21K+WRO iMM6nh4OR4ODz8B8jy+z4T7x6/w3zk9ngm+8ns+TeuTfOCJ5H2L48fIvXBm//8QAIhEBAQEA AwEBAQEAAwEBAAAAAQARECExQVFhIDBxgaGx/9oACAECAQE/EBttt/4d/wBbbbbAd38JXjIR pbbbzvG8LbLIsXqM/O34fA4byLbJtj8tHsr5C+w/8qgayzUN6uzxpCyPS0N43jbbbbbZcm3J v1H4tD2EMY7bsjXZH5CNONsvIW6W7H/OiBD9EQYO49C24d36FlBNjtiHXVvGvYzbwZxaPIJE 8BF4ebNkPAiP3dTh2yHCV9gPlv8Ap3bb/jp/2PomyQ+loewls/bCNbYHkn2GSdH7D7EHZTJj rZ1Bgy+RO6fYAsLsYvsl0cLwIvhN0tllhnjfa2A/2223htttgttvzRNkdLpLt5dY/wDyLaPl stOobTqLD/s4FeBhuEsW5w6RwYdMMtrokKOyfEhZ+2ICQ8he98VsiM7fQnGrat0P7be2OOwc Fidq+H/7PufIJeo7k2b+wh1GYfsnV1UYlgj8lWXcRkW207OT3axiySeSn2U93y7ty1I/y0Nm W39XjLGIu7sLt4rxoo43a8LNd+WAPE4mWvG6LQaSRwe4dk2NsSB/Bly2MR3vbrgtjqV/yDCz ZLru7HuDTZlty23gu3ZCsm0TuOpBODsI+2QN0tf6Re8+pdcOwYbdtx64JpAQs0t7Q93s+Qmx 0jYctXkhs3Z8gGHGfy6epHrLrNttsSZO2QRbIFt7bwwhQE7mXUH7ZBsdNntjUiMY7DWsshhJ XsF6ifJRwJgRBdw/Sx+2f3lDDMf4EdcsBeQ3/Uh9L+kPQ41Ih+Jb02DFcdWWl23gTp2OrV3M FtxwadGYNsFke5LCW2wKbZNXaT5JYWRGzbbaQ8BJHUh/5JQ4HJWIgZ2SdxJ1ZPwzjTy7hjuz OG3a6FjGFl4WH5YgtWN/7Yft/wBQ5bkeiTvVuUXZbw93cZd3csbbkEGDEasY4wW8KF/5YcGS iNnXgmQuxhB8sSLtEpfxatqSfDdHs5Lfjjfy22wsSL3AHs5e2cM6k2Im9ROjfySstfZ84f1b hTYfZ19JPyxBnsicL3b11GLb5DthyWRN8n29cz2b5HrfOHyfY4+f4b5w+z5fYnyfCeH3h8n/ AAPq+T8vt9m8r1F4v//EACcQAQACAgICAgIDAQEBAQAAAAEAESExQVFhcYGREKGxwdHh8CDx /9oACAEBAAE/ELMWEtBqiNsQivE0/AGVKxqAyvwpKlPX43KlSojEZUqJKdfkpeJXiVElSpbq ba/NUQlfgN4iH1yYXTu1kayj4ikqVGUxJSIdSpSpUrx+KlRLlP4VXEqVKlMRlSmpn8V+K/FS rlrlpaek0/BpAuVmP53NE+IOCmPXMt1ChlDnDMuCJ7ILY/hUqVK/+BVRIiypUplMYf8A4Ixm v43iS3U9IN0TzmHMrGcYx5/jvZVEQsfgfEQUOIFEUopebZ7zob+5aHxf/oRu7HrMonCJKlSp VSpWZUZXUyTDxK8fgnMolf8AwkpluoqCgDyJmREeT8CByx+K/jcTsjgfswVHlUf8lXI8hD9k vlvvjPi20T+CNVL2fzCVajR2/wBRS+wMWRUVLSk/FeJXicsExxCvMq2NsqbCEchNnJuFR2iC 6Ll30zaR3TGN/mpzKlSo/is6lRIRUqVKZU1+KuEUR3MSuiXdQslBjwNeRfuAcPgwsFydnEFs nVwFqyUJccsWwWMrSHJfwjET8KYn4qJiViGp7hCfhUTMZUqVX4qCF6wWssnsn+X/ACE6h5n7 HUKKqMBoTVduhcuRLai/uJ4wbBKS/cxAI6ho8pKS0O+JQHOjEqKDhijIWekJQ53wbuUoGTdz JmqrInmGy1+0WsfVEacSpUPCEqWnKNzjKVqnpjbwtS0qlcV0uUsBFFdEPhajwRG0MGtPye/4 plSpknxKX8GKlSvEqURPH4cypxqVKS4epbmg3S8piEC1pitJR3XK4zL6SqGz5iQ1o0/EURc+ YAUs+sQrsmRACMrvIgRYxUfX4NJUSVKlpTK/DCJ+B+D0iGFq0BCYnITI6i7j7LzKFMxghTbX 7lFX31MqVX63E5T5i0/QLVkCVq10VuNqFG0JCjgs5VLy7UTj4YrD+CWhVyWZYxGfAxde+p53 JWosD7E7tKEwM0fKbtF3H8FpaWYjhLjlh+I8H7h2CDl0TdTDmUHKc2/y+SKMXBWe7l4jMQPw hH8jmLfEruMt/wDhAjUqMS+ZTmUhlL4oMJaVV4hnIcF1F3eTteyM+N7wxH0PmebG1buFmp0F ijNwmmJDYLhn7h5hR1PDEdfnc5daqDPYlP8AYQJb4/sYoWnywoNobW2Eg5jYGIYNyBS9Oo2B VImSMI/Hz+DMuUluPK9xJRfN7l1a50RxBteFKxLVIMdQLRBe8xdZeBjaIEI6imnEBrKu6wl0 tODKB2DT2QrIJ9/UJbSOUL2XnwmIu3u9w6m8aOYZpNncRxAgqtKO2bR3K8fmjhir1LhqI3iX jcvtHxRTcbuydUMzEOo5RMfhPxUpmT8UyokzK7ldSmbleZiPiWsfxUqVKJRf4yQTFDmZa9pz 8wNmXzHHY9ywIhQNnmVAQBruFV52MEBOwy9keKUNu3xia+tsMI6BuviJhoU8MaEbHi+orUJh EgVqVn8EitWiYpybyHqVNF/SLg0KwuNvRjBxNMgPG5W4GrYBKO1AlLbABpXc2NyCoKjcpqVN KBldEQ6y0AS9/nzFC6TsrMpYq9dv7lVwDdcJem01fhNSN+IQAXp4iILXAdssWFrmmoB4latI peIVsgpFCjD3MLA0fcAAp7uKCsNrGhSqeJXsI3KRHqLZU5W5PXcdBKTiJnUplTwEUf5J5Q8R RvDLeIbEXCOEWNJBC2EzCZiRfMK6/FRPxUr8V+FBFkAcBKM2n+9iLiK/BhJUqpUrqVKIEyHR ALzDEQdGmUZUwFQYhaaiWN+DiMHEIcM/UDdy3N1C8rgMkcowALD/AAYCaI0kp4jFRfOBlu4e FJXGIZyQwACuCAYpjmWiwMCUq0xoeE5RWhbiDBZ+ZlYAd31MsSJAlKNb4ImTXuZOvXMRIG/c oZWXUuHMBWn3ERALbNQ6VQ2iCrWgO4rl3oBwyrIQKjOfOJR4jAuz5JUFUdphFVr4l7hP/ly9 Jb3H3H46qnIMz8g8DEqsEtmV9Fae5n6YfUrIESVKiEs/EDDGs9zc3UqjcEEbwjiN/EEyB2qX gr2FNd5A3OJJ5CGyPpGoXxFESKieZVs5mvws2w/GbgotuoLlTCRt+G2PwpKgSgA3FGAADUKn E4S7+Jpf+XiNsQg08RNz9ZeNwcOHGINY++4m8W4uCwXEPvDKWdRkMQswMJwo7ZTHovqVX3FT EA6LGOCuyGXt0uX0czE33Ayv6Im5B4YCArtUUXPV8f6YDYTSaHwR4yclH7lAcFG3hFxMzKVV i/cpRzfMEXZ9wJO7SnH8RAcHTdf1uWU5aX/SADTzFiCqHtTAlFjb+kKJpNQMGjIZlOqFxymd 9fMv1h6g3nC9QnoxbbUs0kZ216YPFD8wvLAzMqqwimIsIJzQwZ7iTN5lRVCnmVWmXDVX+o4s VBGlQmtVgUxVrtY1LQK1Whj2iMcq+RFAAN5Fx9wasvWxcUsQTgdRGCP3kkBwL8OIUs3rTHSB OGFGbalYmAqPT8lVKlSokDxKiQJU9PyMUsIAlr6GKtP9RaoSgs5fAhsFUaUwALVoggCUx1P3 AORfEuqR2vjqGV2MpyiTCKXUP11xCRmY+iAyFrzWIlgg11hgXs6gX1QrR+oC0fNlv7mOOdqS gZMZzLmLP2EHvwHgJRoU9ZmdWgMq4gbKdeTLXKbhWCiiuWWalHXMDTz1LDWvTeooCK8sKdLC bhAtjogd1hYLqojQyyncwBkiRRnPB7jZ0g9GINlTMH/qlV3OyUTNANv3A7L6zBVNs0Zx5ZVk PKVQgrJn5jRx8JH8APUocxRsA8zvLgyjVfGouwKdQvjSLmD2IV+4HmGmaYGbhHFxrmFYUlYS 44JQk0sMIw9ssK0uW0EbCusxr5IIbmDZC6ccPUpYxw8MZxiw1LpqH4jG0iDIQOmYszwSvcGx YXLDcEllyuKluprKQK1AHN8Sblp2ZP8AkMVVLb4gI11fEqhS+WEAu/ECuIKKqpxguoRzUENm 4gcZ9S9g9cxYi1HmLGaZYxBrVRgpyWCZiJgt34IHBseY1Jt7qprIxk8Sy+/ZA0M2SwBLewij g9xSg+RXMMvCiK2jJqBdgwvUbQNmM1KMmJl6LFcsrF0cpKfUVC7lXMDcjVuH3BA9e1D6lhpq OLlgu8s4lDNvBkgWaX1LFp8wHczlIrlYngGA3kuoJxJu5RgEJuoAv/pBUwg+IANH6SmgvIyw oJ6h1RaCmKv3DqeTyOo6opNkuUXiUPiV044hSwGw/wCwajBYq/qIcJfzHbGOGiEqC3QfsYqA 6lW/XXqJNqiza/fJC0A5Zw/ERuAqZKuVEK8NVU0Qhzhj2wYklvmvqMLBbIyERUPVq9XFf9kN KRxHLE/8biec88RhGpUqZuUvMziQBV8QwQ8WWPUE7XEsMF6UzIvdEppQ+4f/AF0vjQeSbYjP gO6jnQMFaBDGSKqr8hFhNDhrcoAADs6hZyPsmXQQVu/qVi2KskoFlhL9EG8lGe5YrUO5WbWL ect3KDKssNkpt4ZbtgQi2V9SoquVmZcrALXcOOSU3uYikxjEVVYfcR3unkmCMFWqghDLZUNq ZN8S03sFlsyltyyPE9xFcIVgmZhTmuZbq7eSOsY5dJDEo2gczaE3gRx7Y7LXQrFeooLcFJyx BWHNxKtquykmCT+rIRVdZeIrYTffMrhq2LdxbAJ4hFYrxcwhFTvgiBB5LAiFga3huoBsl2Ms C1HfiXaofMEUmfE43iLkgbwVKYkDnUzqRhYdjF8l1Bu+7dE/Rl9zudj6GZ8p5V81cBwhptag WCOAuNBUci/5MTpbP6YIS3mkMFEzYLU/5L8LS7w+4lRvdXN14zC8MV1SvCNksRartiRoK85j pY31Bea8LKsITp1LFPO/xDLfRuMqTPTAVkgVxLDcQdygvCoEVecLClBS4u5Q1zUEhAmXriYC 23XUaLb+MQPwg1xcqBoNdxVS1cAoeQgueyFeCEV8ZhIBHTKUoj/SI5Y/iCrgxBb4l9VUvw+I BgXLz/NzOGF5e5QA1MXEvA2b9RhwNKJXgB35h4N3aOCO2Jecu5ZWtLU4IqFQCrMEEDB5I6lg FcbgjqGCLOe480g1n/UNIDYwWKDwIVNbDzGXW9M7TGfEuzAc6hmZZpSPOwksF6Jm816gDsgB RuvEYDNt24qUNEp4U1EQmTu7gqB5JbYKlUGoUoHrINzZwgUNyoGHIeGO71pdxormiXUoi2mT B8wAUxa0j0MDMujZFycu/wD9gWAPCwDiDETPRF8iEoBuo/GTqDEsUk3UwfMUg+BqGFkfJCFQ TsigJ8IibTQgIdqsAFJ5gAKRuwKJmEfUfCCII4Lv4xChjMiz9n9IO1PC7P2Sr1BevoLS3onJ lfuI2/QIiWJe9JdZQ77ilNra5gvRfNXCwbb3UKt29zgPlhOiHhklFt6KyTDiJ0Y4U4I7aOcH MUbAPdG5UisdF5gDsUCebDkh09z2h6SE2h6vccQXO3UHMwULypWScrGS0vhm4Pdqt55l8bdR hCA0kbPAZKgAUL4bgISEjUF4mwDPmCcQUaNRlRiuo04NneYZB7YmUjazudIOIUQo7RWNF/uB obLtBlWA5nP3MEzcqOYBFDGqqZ4SLsEfJ+o4xXsOJjOmVZezzCUseUIE2Z0bmggLLiEyitUX aaZULES7OYmX413EA9R4YkcRCkmyOY6C9mAAfGWOy03XHpjYxCjuQ8oOqgJKHItM5AF5lhBo urCVWKK5KtjCWxjDqzSmGAo5ho4RhQ52RAdOxLuEgw5U3FQ/IqKXnXUVTDHEXIusHliE2lsu bQiMRr/aIm5Z1f8AIQDOyP8AEUOuUh+mCMDuB9OpkQeUMU7DqprJkJg8D1NtB5IFII1mNw0C Hc0bA39kq7QeYiKQdjRKlg64auWUSoZzqICYNHR7gFBw4Df1LXYDpX+p2B1Ute6YZMOZirFQ aKV5TFML1zFe3mJjqKU1rG4IKFrSOYwMlGFgxs9ahKUejN/KhgOHzLwpRaIDkzMgHGg9xKEB yeIfMJ0zF4cHUxQyPcQADUqq4ekmR8+5dAVgte4CQXleZ1g8RdD1LeiWiuK5iobNxDqYdu2A Es5OvwZ3zHSizIjnGYIm/wCIK0P5hCARzlZoCxDIzzyRUUnYz7VGHpDeIEZLgUFKbwy8IHCy iA8BLnIlycCJD44Msk+i/UoIfuEqtsWCKcvTLu/mUWApsdQyFt8XbCcADhDDi+ZGTGFsrjKE rJe3t2RiWPkVjbsA0QA7VyZwMEiLTk3AF8aqOkjDJBRgA2jEaiwXbKLzNlkEtq8YblQUjs4h LMXvE280rzL7XYNRXX4VNGwhqDa2b9QsgXokWBsP0QJN+y4cZEbMHmHOESvm9x8x2Lef1MKk Ap3GCwWUqj47iIol97nPDg5JY4ZypuLaLsbyqOVk0Sxklmq3DJsDHFSwGy2g1+plbsebqoXg oO719QFBcdBdwrzVDOseGXHn+JUI09MWMG+I+WnqJVZVcTSgMGyMqJ0nDuXknusPqWS1NLKL SowLBNlAKK6XiVVpwseALebl4o8NMdWZ7pIy4rswsDbErLB8ahTGFUJzLx/JazvzD736YQUI 8MO+jbPE2BDzFbbPPE4BiLTb5hsN9xWXPbGAza6JD9vYhHofqNdo+IigU7UaOU+oNtmHxKOq MZuEI2W5/uNO82YiGkG2BMK5E5nEAPZENBWJn+0yFnMSIoDlBsXJhcxT1FJ7lwXDgM3LTV4i u1RhvcabWWf1HlH8AejMBUt8zxI1DRXUFSl6IoFHmiWMFPA7g5dj3LTA1mhb+pcL0FLiF5sX zFOTgMNwcnHhmQtvsEIlC/D+4saho2EGJq3glwd4QigPtySyHgoVZKtOorMyn8cpQTU4MrxA rPWKnw1KCC7GMyz9SlgphuouiDQ+6HmS6AbA+YYWdFLQeZUpm12YhIZHghTjDjiBmiF8sVXt VXc2Dyc4wxbxacEIi6tNZjcq92Rt2rDYzKLKwhxFpFPFWSogRthw6rz4lXI+RmMU7qoK1mfV 8QLZDpIwCTrzCuGtLxN2DmsShErHe4eS69sEaC9ytBKxeyO5V9ykArsiNGuqubBMQsBlVx8y +RNtV3y+YzUlvCfDEKiBjVT7JSB0aeIhTk4uKFlqWqF0O4SoZvFzLyg1XqAwLw3Vv8iemuEv 8uZbOHrCKGZbytqVM2nzKBFYmAbpSVIDwmLnCVXJuIIE8pQwwES+II+GIrAHpg5foU3Z0jqC sGxZAYX2ht8xhB7uj6lyII5sZhmml0wUCj9RBcA6ZjEliPqxUhs6g4yh4ilYY2BhEQJVFERA G3NXGqjldpxEBaXe+JcYQ+pj4+IL4Xt1AFNWdGGaBl+pjRQKcV/EYuhpTcGik+LjwZDB17jx qfqO5Xcr/wCOc/68s0wbRgiwe7ohUqHJAFnapBXqFvUUihFOM26mnDFgbmjZ2QbbMXBhubBf fMRlgTzv4jANKfJAoT84jYIOuDBZqfyYuJY6vEVIAJg7iiyO6rEuUAU5gxphSXTGNqU2FYYb GzuLaomAQPMsDEQUKZ6GPGauZL9U6TIwqJ6qC7lIao6dpUsQ2mpjAgmaTZELWulQc0rZpLgg 35fiEFZpziV3kgp/2PK78QaqUdMaAVCJW9n8TGKDtqWMRW0gLovqJF5fcQ0MbO7JZq2oDucI ckRB5zfue/EWb/tMqPFeY3NB8wOF7YT6WCCUo1iCFQyDiI9ABzLVHSW77IKYJkFV+JQCW84i 5bsiOqzWmNkpKie1+4WJYPZhhMqNmAfZGIzqCfOGBJSNZCzGo9N1FaZrwB9Rz4ElDKN9pRhw +YYAXvJCQlDpauZOjbeoLBqr2kPdnLNIF4NQUr4Cf3MKgjflKDbj7YgEhXJLVpY6ZchTtueQ lF6RA4ShzKdxHIfQijm+m2FVCJ2sWUGlf+JW0nFsHpBART5qXZgXfX1Ed8rtUrpa4zeZRAW2 FP1CtI1xGOyeG7Y9tPrMJCKMamszfa6gPMdMCqLjaggwfq4tZUPiJyw93KVhTmEF15K3iWjC +GMenpgCinqI2sMVQQ+0TvHUKONdRpm/iPVU8KxFRsZnB4JgUrPPBKVibwMsQEPDde5UoPJi WYRVbLfPUQ5TpzCBqOa5GKh2PLiogQ47zPQNVzEQov8AcqHT5Zy3UONzm6MPTDPs03hj2a+2 CnKZim4z58QDT9EcFv6iO2cqzZAotlbt2wh/2OWKfcrybly8+5QGt6vhgoXSc3K4czGMMYtt VogWU3AGJU31NXSAngVu9QbUB1l+p1DxUDb0dxWAmiCeICQewSo6o8QFqspFMI8cNhZDoVyc E2oJsSYtHfmHiVttqVSxrGIF6QdowRmQaQvEJuMHXMebNqoNQxLtXJKWBB6wx/C5ZihbxSv0 Tdq+b3FPL2xt/snS/wAwZ/vls3/4aIrSSDcr64PDfJmf4xEN6bIorVwanzBH20xSW7CcoVUI U/7DwOh18soBYHNSzAparcElc92qXNg1zBZbIncs1vzc3NH3Eg6cSsL27IocnyQcRd6YnLjG o06+4IwtXzLGvZUGg0EMAuWvOKgk3N9kXj0Nwgqt1VsOVFrmFPKYYAKidqyHUVm7dzILBo0x fQ8xABSPmBWJasi7avJSPbQ7f8h9GQ0jUMg4cKiSli0fHM7xmLHMHECy4PTEbtQNTEtr3KC7 lGbuNmbepeF4gHpKyoolaMwL38wLc+0vNNxbNq5vUvEbM1MUF5ZoaqATiDm9yg8li27lrQ+z MWhlnNdS/LBpirnOrhXnMANwR/qVBp9upR5i7E+YIr6meNkVXEKKouF+FYP/ADMbsYeY+ime yqidqZi9PqFMD1fM5pDleJvBXgWWhEvO2UaW5vMZNAO4OEwzYeJpLu7/AN0MBA5HAAYGl/6g vuwj/ETwEdkAWvsf+Qaw9f8Asnjf+PMCs+axFWuOxhZDXu1QAyryDCkyzzKNqg5loxXuHQOy ULe2rgASDYG5uEMNN3EbTSQ4p4cygqrwmagwSkd4olScfeog0L+4kBarqHCZ+pgLNeeZnani eRflNS8Et8pqBMGfEEl0JFeHEoGiC0ixc6fqCou6VNBseZYAU+EGLnjTL8q+Ci6C3rM/gWH3 KtnjN3AODfMtSuOYglwK3mzATcvruNkB23c7Yb7xGN39INi/JNdN11HXcVpJyiElFIKpiay4 zS4zQx6iXtAu9Lv4lrXzeh9xhh+5ywFbg7g3niUJuWt39S0UcspcQpiUUAHjMuhO2P8AxFfS PKlSwXX3NuLs4uYBt5hVpRfcvyfMtdspC2OiYl79Qs9PmDwLfUxhlAbTHcseJn4EQg1s05l4 y83cQhhKwVlgFlXWIOMBsdwGZeBDVQcZjDgTnuWpLrBc21DqLLQPcBL+WyJ/tYgefMViUAVO nZKVeurGH9sz/wDcg3hkIcGL/iKXKeeJ0xYJCRuwbPuClHhbB8sKRN2D/QE7cnxeV18S1MML ge5QtberyQjaARMIxoHKvKAJqboF/smpCKxS3jqAxagucTmkQyKTkYmHQdnMEUBrmGNO0R4Y A2fZAKBneNThUIX1JVyPi5TgICUGJ0MSl7zBTRUFjS5zGrw8xhfSYIoWthmVYjlNo+wq4eA2 7Ufcuql9Mbu1X1DuhZkeuYZpK1v/AGGCy1JSm95t1K1OEEQuzMxsUqku0K15i12xbG4bH6Mv xWkkeNPlKqB1tMmGl/MWtSpyWTC5DVtn8Qi8sQt/qeGJb6LuiHUAZB1LRLh0KLg6u15Z6UFZ zNassyuIzTQPH+zcPtApv9Jfmj3EN2PZE8/CAO2TuFA7tNVUCi68vESzRrjuZwxL8poReQ3E WrF5GvqF2+ixVsx6q4aM/NR2g8DYxGbnlMA+Um1BT3csigUYsnMEeGROJlmdnVSqo8WlEqTq 6SXErO1KZXqafqIOQJyTnQCLxX87h6AvbA8vMIkjRaB6Cojo5gGUJ2qEofEJ1phPuWa8iypX N3LzdFkMN6qpkf8AIiLlq2II0A4EsY4aluAmICtT1Y/MsMqXQQchU04qOJZTGDZuVouPbOEi t3Lti69Q7TNfURVBwlrAX84hd1yhiuniXKW743KFDT+5/wC2XstHUy3Z7lF3cAwhb1BGzEAY c0N81qNqT5QdyCuspbkOBMQEFj/eByK+COef4gwlswSL83AA201BzKaLgKJcZriWhyMw90s2 IC+IM3WXsBqr6THbHomoJq2ePMuRo3SE6QUi5xB85j1upc2QeFWxmtKUemRff6jYxziPoV+5 wqkxp8VxA2DyMfFX33EwyniVzZyypLgJrg0QRvZd5LxGgOeIkXaOrl8Fi8uJeRRTaaltWk8Q wVt4NV8RRLZdbl/NnFSxy92SkqRzYx2eVdXqFwrGSNKC25U4lEwMlvP3BWS2+WJFJ9srF/bA c19XFka/cLSIfMGK7vmL5rURdJ81Lb28xQ2+ricLSxzHsfUva/Jv2OYAF1MHnDEYtWoR+VuZ B3AIfhb8s4qU/btcR8yq0z4B+jASjkf7iphQmkeR2ZWEkQ6C/YliCcw/VxdkDnGIonlmj+Vr 6lEI4DX5hmVUu0/2FLNNFUSwG6rSZmwr0bv7jbWqvEatnyuoMsZHmAWX74hQWC9jMq0PVsel XieI+5ViD2glUeHqKZVd3CCgtRdJR4ltrnqD21On9Qd3eZyXFKiPEicwVaT5ixnDCfrSAju8 pl/6nmACbvHcSjOXEW8/1OwrYh0iDxeoGnMJmBcy7YQtovzuJZF+Jmw3ExMma+ZaxvczElSp hGyskqyWASkQiCi70wM0IBb4As0+ZcruCD/3EyDBO4pVU+NVMoIZ2MMGVXAFsUUQekQG84Ly QUlUP/SKKq3vslpvHlUKqCOmCO274h8gP1DYLR8z9IhiQBVr1HMLixRXiUWaU0CqjirisDlq WrL8iDrbOyDUV8s20QuKt6nEtyviBrHqlTI2vRZAAD7tmnZ5qY7aPczPiqAWu+3SXFF8GNzV Hr/sZC10qrBD28N34GmdZU5Q+bi8PEYP5l1i0rmGPI27i3F7o4o+PgsZh5ICq3ogQcc8j3BL WdAICoOAf6R9KYNNvdRSxHsuWlYj3pldncAD8TkxgbMwifME/mYAIabLz6YllyyUYitNOMlV AlQLLoCU1ruCosDyNyi8g+LuAgWehFVefuFOwlCr7mGnFxUHQydLhhqe5cRCXjxEtd106llK bPcHOrliMsvmBZoviDwr5YAtQ+IFpcX8yhlbYbfz/iYLBq74X+prMnzLSyL7I6w09P8AsQza HRAvNj1GpMDqX+JmcETGvwEuDPqUEovLDto21b0vD4ZVt1FGH8TiwXIh2EWo+fgqtf8AuYpl iDSHjJHsZWnID++Y+5bL2DF+abr1cRDGtPiXGqcVND41AnGu0XylI60r4ltDHiFlrjuKcXYQ 6z8RAGeAsCRjWQMQwApvuFqrSM3JogpX3K7aL33CjIHKFj6iM0bC8wDto51dzVctvEuoFDvV RKL3kalulnm4AFw9OJUul0hFfwbhwUHFXBHX2Xc2C+HX1Ewc6Q/yNcJXlcwwDngMfc//AEJQ ZfJE/mA0HYGLyvW1o9x0QOq/uXSE1kr8t/1PcdakbbSKo/iNoC8Bj7lZ3ZSk9LgPiYHxsEWf UoDc8D/EsiXhqh9w3FWLakbBv2HEbsQ6FqJLF+buCVeQN1AUoZTGYsweXDPtmEA1p/EYF8wo GPISxUFsNg9QOXUnVD+4c2FfI+pwryhM2i44QY8lcUTKFoAlYG6MSrmtgu5TG36SzLHjMlQq BTJv9wiIDTP3DII242+ILVOA4WCUxeRjasjmnESfUxjkpO5VC5OHuAE2MWZqU9i7RSuyFIUN IIDuuYnGyYR/7FXRfc5lMMviXEbrQZjs1oTbD5zChC/1+5tMPND3TiZqCBkJ4TcNI3AQVxNF 7L+40pHBHxu9xWmtCj/F0fEPwtZPsw1+pZrd0Lh81DQ+eD6B79x6mUBUfW4DWw0qXPlRak+L nBisiOppWLCHvMDQVMDB/cpOyBT+CY+5Zurln7tBujtLWmNEgLoL5mQCWy2V+sypPAtaoImh eboSXF8LgNshdNnpjmrByUYPDLQUGNizAyk4jjEyzex3MYsy/wCy0WK9SgCq8tGCErXaoFqY PQQxsOTTNlt4vMcE7qnEyZI4EZi8FfJFdg28H+QolC9LUFrTPMWiU+CAybsEd1Q1fMXXZvyi oFyhnzggSG1SKL4pLMR22f5izVeFafeCOoC0QfBEPy5YVhetBCPVBkQUeIMAZCv7mAWumkuZ RbtXGyAZxAlE8UkQtq+jJ8SgwWSiwloiwGF3UFCAHAp2YzBmVpg+WuWLCM9mVPeYtlUFuZbY PBWrlkoIc3bGcL5FqMFbOrf4mFhFa/8AbmS+xu8+oQLwQSErotgQoo7HB9xFgtvMVG5jZSXN HBr+ImLRqrjYwBV3KIFLuixiuJHJVXqJRUO5SSY1WWB85yWwHWQ7gNlHgRDsC+7zEltNKiOo e7z8yzMGMc/DNqQKsBBOqiVP1BhVsx3i7hngW2fO4roc+68SxS6OHwllTQpBFgCkVKVckK8a oVJiKcFtRHVHJQD2Soj4ZP3M3ZhBRI1FoMEsmXemSYLa/R+I3gQbVxLNaDKlGUBoM3Wxh9H+ EJpxPEqFu00pmDZQHxmIAM6oVcwm9hEE/ZLYu8qhfAIQa2vJj6YarJlsvTUso+lNo/uPFiWR V+yEIopTbUJClsqyJCctU0Jba/bT/UVLOUYIo08FI/crA66o14jkM4YviOWm2JMao4Jsgj5e 3EcDgtDNt3TgzNKB1f8AURbg7K3N6KLLfdorX1LWG3tGJVvsdy0MDFnMFsEe5goryy/uN8gA sAY6ic54mQvPuVDRdbqJADiyaQQRLOmJU26C2oKhR4RoCr1EIS3ysAcGniBCkYrcTvmSvMAA l55hBADHEIDozHdmZm2a37iQ0pM9kNLmoQBB4ZiCYfErVspzHd57lj3lG/hEUtXEFut3DLXf c28TEzuzaX5gKSvUS2W29w1sXbPMIOg3U2HFwo7bOYlu25yjvACgEAtrYTZALsGAKQLmI9QF iC1zACAB1Ebq2O4epDWxl1AuxbGEp4uA4nMX6TEJgqWACKpTJM/a/KZo5HRhgAHgIftgFAam mkNm8zHXUV5xNsxBFlwFekzLZzGgGh4IlMsAWDMZq85mKBqKCqc1mZ+Mu2MgUwwan3wVmJQK 8TFYm7rFwFV7Mziw6NRIqXUuCV7WEBiNTLvude4kqOOoBSg5gqkykv4S6LfKijaZNsAuQb35 gEgD1KRaurlh3dz/2Q== ------=_NextPart_000_001__32392454_30198,03 Content-Type: image/gif; name="textoarriba.gif" Content-Transfer-Encoding: base64 Content-ID: <3239245925718@textoarriba.gif> R0lGODlhVwEdAOYAAP////X29+Hm7tbe6NDX38fU5tvKurvK3NS8qcS7tdW4mqe72ILA/6m3 ydCqjbywpZaszZuqvHax7I6kzKuanrGagoSgyW+k3IubsXubxYKVtmaZzKGJdm+VxHaTumuQ u2OSwXaLq2KMvJR+cVuKvmuEp1qEul2DrJF1X1GDumZ7m1J7tVJ8rl51qVJ3ol50lE9zrZJl PoZmUkpzoktsnGlidU9rjFVpg0hrlJBeGXlaQkphfkJijkJegjpbfzdRdf4BAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACH5BAQUAP8ALAAAAABXAR0AAAf/gCAig4SDIIeIh4WFiSAd j5AZkpOTFhYTEJkQExOWlBmQiCSjo4uLjp+QqogipKMmsLGys7S1tSm4ubqxurm0vcDBwsPD K8bHxr3IK7rLysvQ0dLT1NXSMNjZ2tvc3TAt4OEhpoaNiuTmqurrkpac7/CcnqCP5vaHHRmX 8BafoKyuArqyRbAgL2LACiJcyLChw2fWIkqcOM2bRYvhMrYoQaHDPXPkRNhbRzJSu33vNL2b Ry9RSX2YNMnsZKlfPUICScU6FOuCBAkgDBLU5ROoCWBFg8LiWfDQw6cNJyywQMyZMIpYs17c is3CggwawYV4gKAfvQUA0gY44DEkoQ4W/xCxo6fOX02UKuXdnfTop9+fNWPKHCzvn6Ccr2Bt YMBgAywJjJUW9XuBhCxXwCA3DqYZBK7Fm3HRAr0BqulhAwAssIoLGokOELPKjsh1a+oFYUMk MGDgroUDAAIISCvALaHhcfGp4rvc3yeU8fjd1cyYceDB2DV5aotzIKzqEnB1ZsGCevXGK4R2 hmZiPAvwzmLBP3a6forbrFNAGw67WuzZ1NRmEXksaHObRiWQhQACellQAAACdDBBWhCcYGE5 iQgQYSMlzeVcO/EQBo95jGWgwYmcZIfdSvQMkpNmG5CnGQkuuECdeQSyQNCM2iTDIwwwwpCj LjASWBQJT3WQVv8wBwVzW47kDaOhCdAwBOBE3HyQ1kVhHdjCCy+oMBYCDzzQ4IMCePABAQAc 0IKFJ2DIiikd1lnXSSnN9A51GXjgQQklhICiYCpmZ8kjLrpyQYws2MiYCTTQoJkEM4BQHQk0 zECeLTPO4KmmLKQwY6QzbEDCp55GiQsJixbo6XrILGRBWlWKNosut8HwKQzJXFWrlVdaw00G W3oTVgupNaDCsmJSQEGZDtBkCXACfFBCAwAMAKYLJ0BwwAKJZDBBBoV4u0A95mRwAAQZsHtI u6C0a8EjkixQwAHRdTJpCSqAGaagGhAqosCbcHKBRyAMRN6rjLGAAw4XMCYBDjxUBwL/DzjM wGstmkHKwqc6dvzwyJGSygIJnuWy8AySMkYClKEOQwJaAGRgAgsikCvCArmAMNUH88JymwcN nJAprz7POy8ucH2wAoFeQSAMCHFlAO4yECwAATIfZHDIast07XTOIiBj9QIiwGACBGl50MKn UZMXjgdTpUaAsxxw4OzeFZglCXADAIpBWmCq8CBxHySe2gFwHg4hIYlYEIBabQ6yuAiXD+K4 AL5ZMqkKNtwg+r8Bc1LdBJNaUp1Kk8LYnsuRRswACzzwIPsFtVcngg+yk7ACaBc85jKMoGqW Qu2yO/ywpRKL+igNzJ9XqcTGXCoLzWllMENqBUzO9OTBqWZM/2rDBdcCDTB0AP7kYD+JDXDE RUO+WmWPn1a2x3A/OTT45fr+/QuAAfYA4IFIwQ9C4dDA+gBwNw6MYAR540AFJvgJwJ3ABRog 3Asi0CYPsE9xqrEQ2w7wgclBwASMQFNqQniC25jAhWtrk/pU8xwSXWAHO7CBCkrgAX1Y4Dzn kZ3EPAfEyLyOAZCCWMOQx5gL9MAE1cHBD2R3s9uJp4gMqFF5ltiD5C3vPBJYgfFwEL0ozkBi OmqeLn6TlgW4gAYrLAAEyEMt+C2APKkJAM0ikLE6thGPqtHVhFYzHAhkI3/BgZ8hYcC2AkgO ABbARhwXecgn+c8DwVnAVGbgAfg1gP8GPBgcboYzgRqxSUNpudsDVxmDGKAABRXM1gVDoEE2 RSAEwCmAhW5joQdZ4AS5hNNxVGMC9gFyAS1UDXkeNAER5DJxH+hhBmyIQxu84ATRlASJsCiB EIQAPNR5mciUOLsedBGLF/jBFBlzglI1UUYSAw0DQJApzdCOdw17mGYuAIINACmfLADBPklQ O82sgHkXgNmsADADirHpALsqJAvY56nF4eChGJMoRbenGk89yAMwAA5EPcWrFSwOBourKCRh 8KAFqPQAukKVkHJ1m0hhSwAsKxkmAVC7HgAnBDRAywHANDkCGGByBqjAKiGIghw41TcWfAEt AWADGwynARH/eNAALsjLE1yVjQOoEbfilJZfJitSllRNjYYzFcCBA1A9tOEPchgnVezzBJ+T nQR2WJ0L9rVlDDjBw5JnTiFWJ53qTB4NSFMjzYjgnAzAHQ7sWdh8nrFhn7Jn7WzHGBf44LOg IQFoPuYpF5CHWAAAJQ/Y9MmStY2jDXhYsnjAQQL0gAevTZZsAdDaQnYyWyPTmEk7ii0C1O61 xd1tA3JaMkl2dLY8WKgFIlW7qfLAnMO5JXAIUNW0GOABwzGAAyE4wQlyIAYpygSaQqCCDFLV Bve7n7ZekKwaxTctA3gYDcZaVhZAl7UuOCsN7psta+4wmpOywQ7U2YMyDqIzLgAN/whscIIm Urg6b9SMCzg7OyaWE7ISEMEJeKDOxHaWB6TRZ2d9QIIm+oDDLOgBPjv8HsZEimLJ26zsPKtO FzBmA7IbWcY0hVqK+YC1m8VB22hgy9ohubafXXKTV8vbhxHYuLU72m1mUNwoAyAEOCiuk6u8 WYypdAFMBkAENrtCDGy2BGmR8Q+uvIMbpCUBFBhOAlYpQQcggDcOGAyaNBACbM03LQdogKIx UNVkgQnRim4Ao6vKX0gGmLfmZO1FeXvcNkVaA1UNEw8T7AN1+sDBInAsGRnzWB9HtgeuZsBg bTxjF1Q2i7e+QKlLbOIs8oB5F+OwZ0XQxB/U+ta0q7Gse/+6Y3NCdgYl9kETf+xsHmSKBUXm wZHVXOa2bToCn21ybY2dlhBQGdzbbkCnE43VEHy2dhqraZd9UG4esI0A4eZ0mXlw5m9/1gc4 WKG7fQBnAHx2zm2KgMJDsIMapOUBHEhNAl5JXrLwxgCChhChRbqstGDgBTbwpugc/QKPgykE JRCdDSptAWSpOdNVtqU5y/0w9ppz5dicVA+iTYM4DcJCmjmBDYjNABH8AAfFjjUOeqAZKTYb sraGrK553WtbA/vWJzh1sdeJa6jzINY0kPGxbw1tU+Po32bGdlpA2YMpdxrMtsx3BHowboSX 4Nxyf3vtSvCCf2cMpaqhQd3Tcnf/KG977tXmN2zPbWqAk++zBTcnvQFQAnMuq+FpocAI2JQA GcgAgs9SwJ8xLpP1hmByEVjWVV8wOAKIjrVgWn3rRXeDF5SghG0qQXZxyFobyLwHyQo5A29+ Tbwe9gL8fPF+xeqowPaA6CY4erF7UJ0NKJ3rKvjs02+36xJDdgM9AE3WZyyB5hud61F/evV9 QINja3/Fpi5j93uQMbWndsxr3mwhcYD6fNsWWw2gTtnVA6inTlOWGnMHZwRgbMoHeAVAA8AR gD8gc9iCbnGHdlqmGozHgDwwVZAXZ+aEgD2ggJgHAA+AApNzgihAXg4gerwRDw+yFpMjAP6C LQHQALb0/3q8BSY2iINqNjq29wHDsRZp0QA4BBw3WG7mxEE3yCYYcHMUZnxApGvWxnzNF2NE Z3RIF1nqtE2yxnXtN3bcx2v0B0VAJAFiZ1hRVHW3FnXyFFm19m879m8+oGyIZWr1h1o04FD6 VjtIiC1qZoBFODkYoE5/mBYRIIiIx4QR4IQciD4r1ACTowHqxEGBMxx9d3hoZ23/k4Rfpk70 FQHb9YEA4GyM6IQ1UANsEgAJcGcU12cKcHH8cEDZ0i+FUz4QQnvJ0i8qgIsCQHui9gFsExxX hUMqAD7Dd3MrlC3OhnNSGEQvhgNWSFlZ+AM0sHXX2ERBBobGtn0u5n04sF+GNf8xpiY78rQB JeaNXcd06zeH71dO71Yxj0KG9bdQe0hl6rZZ7iUcgTiBEIJfO/cDU8WPieiPiGcDyzgAjfd3 eQSQDLaM6KaJ7/Z3KzBDqVRiKnA/AZB9BAeCPYCQ8vUDNTACFKAWqfEAnocCElQBorcge4EJ nMB3/lI4ihYBwLiLzFKTtFd7B/YBE3AAIZAsOLQDKhABkjaU1WSUGDCUVXVgj/ABF+QCS2dO 0sh8cEIxVelsNaJt7yZiAPcw6jQy/7Z819UDy4cDdFiFm7IBIJB1PFcjsCYCUlRiWWlOy+ds txUnLPBZZCl2pkU7XGltTcdr1kYeImABH9BQOBAoqoX/MThANC2wLAFpeziAAU/YeCUQAYUT kL9HfwqnAWnJkKphAXMXbbQVASVAh7bHldEoXCsgAhAgad3nA4UWAWznAzvAL3hpAwq3lA03 AiqpghzgeTKwghXQggqQnP6QODIZamHCLDNJX7zFLND5AsDYk1CZTEZYTVWlYLvZnUz5L37y J6ATkD5Af2JFIDXCdnjZnu7ZfY33Wea0b2WGl9KYIw0lZ6Z2W5sFn8bWnvRZZnTono5JMbWD AzWGhqYJKrDwMXv4MGUWjiXDmvF4XXT4Yj1Fh263WWI3kfGmGkvHaxV6ofR5NMagK0Zmmo5Z lgS6WUOZiihAnDowoykJi8mp/wD+oCb8MpPLAij8YosqgJPUaYv+cnvQBJVCyZ3d2YwrJ5Xd aU08JE3WomA7cJ7oOVZwUiMQGqABak7RhpcHKmRCVmY0sCk3I5UUeltCpp//eaBJtqVhyqL8 mWQlY6CL9WMkZmr8piMN6iliql+oUjtpyaGbSKj5lo/0WW3XdhtoKaL7VqhJlioEwjIUGo0Q CqZc+qLAKQM0SpwqOUEOgJzO8Sc7+pyB4k0oxyyL86M9+qOFY6RPWQLJQnvWBCY48KTMN5Mb IU19wi9VxZ1jVQhR+aB/WqwUA6ZiWjLKemMjY1qy0CgGSpVD1lByijHLeq3KaqD0GY6foqxU pG0Mhv8DJdWgpHWtqEKpEQqnb6quSMalYepcC9Coempt95iuQqYxOYKiLGqtN2avf0qlojMC MuBUOTCjOhADEXScoTqqpOqjITCefoJygHIAA4CazOKjGHt7ftIniUOxHzc61GmVcHICywIn vNqry+IvwVoIJhCVVviyzEes+gWzNJuesPAK5PFGJGOFMpsxMHuuMYutJIUNqPITFwBKGLgx sHCi3oCfMpspfhpcqEKsC0AAGrBvEqqswkWxGWBkEwm1zEUq56opywADPQu22Jq23fkCDxQD BOtUCFteoioJ6nCkD7uxfRKxqOpNgLJDpyqxRipNT2ktRLpDe+ujg3CkPpr/OJTgJyUwshci Ah/ACrAAuZYLuY3CfDCzuZtLCzmruVACupw7ui87uvg5lfSnKcpguvh5rtmAKlASU92qrQ8z tiVlDNQ6n+G4DbvSDdGgKyUztLJbs1ZYOA7USjkQAyNwnDc6enRLEtGEt5MAsRALuHdLvSf7 CI7bt4GCvR4ACRALTfkwvX7yAabQCIQgC4tAEJArFASRvrGQI55LIO47v527tNBArVnmAukh CxMBM8eQI8sQuyxDMhqzDcuAro6JDQE8ugGSDbELwZwbFstCARwQnAmwIM3LGx/SwXZhCSeC qtLrwZJAaKh6IjXhwXOhCkeaOOhrHDBcCIiBGJch/xC04B2xEBCzQMP1+6w6W7tRohC+0MO2 ULbMha8BopjcygJYMQvUAMDGACWWKzjPsiBWfMULQsIn0TmdE8IP2w4efBcnMsbuIC0pzBx2 og4fARIxTA6IsQiuEBIzPMd0PMcFsTKSmgJEvMcFcaK7oiq5ULayS7bVIBRXcrmBQgEJkME3 2pILwsEkzMWSnLfSdMYfLMYonC978bxpvA5rzMZtnCgCEcrdUcelAMemrMM3qxPkqkV8agI4 zMd7fAwSHDOBLMiHFCtMEgvBsgyXewKJfMUKEKotiMUvUQmSzMWUoMzIHBj5osksQQlp/Mlr TMqtQArWLMN17Bap/MYsSySuZopCkqsOgyDLPRzFQ3LL0SDAvSwbvxwoGMDIyUnMyNm8gQAA Ow== ------=_NextPart_000_001__32392454_30198,03 Content-Type: image/gif; name="bajo.gif" Content-Transfer-Encoding: base64 Content-ID: <323924638440@bajo.gif> R0lGODlhCgOtAMQAAP///+jo6MzMzLe3t3659KSkpJmZmUql/1iU0XaAinJycmZmZlRUVEJC QjMzMwAAAP4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAQUAP8ALAAAAAAKA60AAAX/4COOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWG h4iJiouMjY6PkJGSk5SVllcOlykNmX8OnJo2oKFfDgwMDaR9AwspAQCpNQ6deAkAA1yxD58+ AwAJqjK2uLK0wUIIBwcIx3q+rScAsDUG0rp2w1oOrwEGDAABvb/NL9k01dPkQMnL6ne+ANAl 1jXSAApTCcBD5ij6Tq8MwIsnbp87Ff1k2MMn5R8Ph2rYMTtIZ6C8EfRoJHzSQBqRjSQ6AnCS gGGDBNd2//gySPEEyHK3pojkMXONxJZzBhIkkTFNTSEvRfyMsxKnv5hqhuJQeubmiVkljJGA qoJqValGb/gyIEDaxZ4PGHQFIIDBCgYDDOwagKuAtAJrwZkVgVZtAm4MSYiVVlZv2ge+FCQY yzZk1wBwE7BasWCsgItBB0srPKLB4cSLHRR2CwCuZrklLIPD3EozrrtI9Tqeu0I0YsDjRjTm exFFgVcDUpkmwRZridlk5e3m7NlXANZ1H6AOkDfs38CyHde+feuaa9IuEu4lyxpF8uFv4x4f kXx5c7qr/aoNLPkWMaGXlWcujPp9e8oigD9uoX867pQlUJfbWu8BNoBvIjjVgP8yCDjg1ALK HHCNgxE6UOEIFCpjoYYksKOMLrvVl5ULRY3FWk+c2dMZQjGJNNZkr9jTyTAphjdCjTYqR9ZY n6kom4o7xmYbkCuKEJROI+UHpABdAeOiigPEKA0tCyzZ5AMi1SgACTgWmUKVKjIpZJdwpaBT OEOBZQKZQvEFpZQAzHgLjmXqKGacIrApwpk/hnllC/3oeRQuT9oTpYpyDkAnl0TWacudPdrT pz1iOvlWmHsCeWOjKwjKJwp8ppnOCU4xwGCEDHrI4S6ottrJhq2uCiuqsWSJ6YgrFPXAYZ1k VE0AKKElDUslZCMSMTECs01stoCzQAMLxDjXr8HCs0//swMwkIkDCljz6mSooCakCb8q0ICw 9xiZWlTdwvLtLeEmi+VkIsi77D4OgHuSvC5mwlks1J5rbQr5wrvvsCKUK7A052EIzrlligrg CAqji8+x9SJ8r7rOQistx9l2UjE8+OQbAMQOGywusSmYEzC6LI9gLL0P2PvKtdIE8Gy00kwL TrUI6wjvtu2OUnC2B4/T7wP/7lK0yOCYa3EKIzO8y8MM1GmCySjPm6QIanbIIF2oqrqMhxOh rWonaqPKNoewtkmWv2HjypuQ3GRCT8HXGNdyi1OqG06mOA8+Am5Xjwrb4LYYLjejBRYc89UB GNO4ugWG5tGmkSMskpyG6+pW/+dK97Q3WH4PSbqy4FgODgomGyMx7K2TcPnngo+g6+UkIK6j 47Hb/nrwkE8VNAvZ8H2348UCjufvujP7eu8xKR8949NXtnme60rutS4Z/UR87k/VLvPw5hOc vtc8KV5CqREKFWHaY8P6NtwXPuDhtgzOkqFZIgGf++x2N4Msq3L06NaWjDdAzLHPgYRTl1pI AKYHKDAq9NjIUF7RHaaNiwTtIlLggvLAjHXQLZb6Wj90xcEAle5rD0ggWTDYwJoB4ITjCKEI EUQc7cGwbhYUoYx+skLpTbBPEBSBDolENy/ZEIeTM0E2LsjAiemIUNsrIs6OqKSRUDFlqdDg 9p7owv8Utq9W21sikHyjRkR50Ikn6OHjMFJD/Y0tLHd8QP5M1Q4+TkQEF/IjCQIZq/mVMIZ1 tJuuRHDADK4LbDWcmQpTs7sPzgQkjszc7IQ3uWYJMRMk3OT5zJhEXanJFqSEZBgfiUgrnnIc ntxhChTADQCOEYixZCIRKSk9YtUkIblcoxJrqcrmRbF5p2ElLp13vvdU0pceweQ0xPhD96Hy kOHLohADJ8VtPo+WoJklMUVpAvi1A5CrEqQgR0DIc6LzAJngYyGZQU4CFjAqUkoFmGQ3RmSW UItJVFI49hmSzVGTelz04OS6xTx/omCDAEgoCv/Jy30EpIzYnAZBfeiKD07/lKEaeV09RwDS h2rTmdLLXJWwV6CSroB3F2XUMYWHi43O0SXMLGVKf/M6mz7woIeLKEY3+ROXtsCof2toN9F0 yzqa8497HNuCVjVVeGIpQrW60FT/qLlq6sKKWVkkhmIUi1cI4FVd0Zo/d4lSnO0kYxadGyPT GtBDuqVyKZtcwbTmAIOEcox3pYX32Bq9fQQ2rxktq1x3Qdch4ZWRGsvRLmbaia5wwis33Zpk +3pTgArtIjcL6F6nwpLKTuOwkBWSABKAIHOYFa1wpClF28ox0MbmtXMtElC599jEpbKVNx0t hqIoXEaWVgSWJRhy3YXZQ5bzjuvUYzrviKoFQCh//2Vb2zvnkowGJXa5Sg3rBxn5ilh8YzLw WOCgZltYjt0iAQbgBnkMld5mdpWBnUnAXcdLsZwZQDFB+ysMC5bf/abSswQugH7B8cIz0oW+ fKmKPRRs4IT5F8D83UUAuoGOTHUDNWotATo+PDDCRlBo741v9jYy4v8ObBsc3lyCFxzaB4Cp k0g5r3si/DcsTpK2KB4AfOX7YPTy+Ir3TVmBGfzbbMKwxRiOIpRfvGEDdPgpVb6ycf77ihCL 7ZzRjeo5r1vITlQ1Vp0gc9kySw+RJJIiYp3KycgDp8x108f2PfEwzmQMBtRZtgWFoY2BtIA4 uxBIRxQwT1VU6Abr1CBgsv9Ho5s8Kj9DiQWR9soiu5TQErxoJ8uiFAs43dmKYo7PeWYUokfw aXlkOh66gkeP6XxpFuH50adWUW/D8udUZ3bQjC4KUftJahUUe1eMTkGryXurFDyVndN1p6qq Sgt5Nih/Nm7VHzdpVnsyEqxYkgoD9IGgqYxiFLtANy8cWGghe4fcUUF3ZbDigAIoalvgFoq9 02KMT5Q73FuzdwHwPW8MqTsl9b53ugteGQCNm7UuSPjAFx6SfRvg30Ziy4QEMoCGPdTishPs we3bbmL5+wQNAHmxNB4VgRMckl7+trjhvYKTA1zmBic5Wyb3cKnYPCT0djnFby4U62Al5Wy5 eAv/kM7vlQ8IISzHEMc9HhWr7KLfVrf6Lk7BSKv4jyrYFsoppCLvBljH21ogIdr/oHYk+LQh rFw7TQx5VWXIfQ5tv7se8m4EX9g5CnzX+wzalkfBtyHwhqcD4ofgi3wzYfGJb8Gs6B55NhR6 ppWnw+UZsfnM76ABCAj9AjDu+dKb/vSoT73qV8/61rv+9bCPvexnT/va2/72uM+97nfP+977 /vfAD77wh0/84hv/+MhPvvKXn3yzO//50I++9KdP/epb//rYz772t8/97nv/++APv/jHT/7y m//86E+/+tfP/va7//3wj7/850//+tv//vjPv/73z//++///ABiAAjiA/9hnAOYCfwZYfQlI gN6nD8+3gPYHgerngAwYfRLIffpVgd53CqiggR74gQ1wgdAngiAYggdYgvDHJM7XLblhdp0R fy/YeNH3guIng/yngs4Xg7DwfDZ4fT2YfTS4fjg4fT+4f0HIfQrUAD9YhNbHhNGXABKyfgqg DCjxfsmgfVf4fVCIgujnhC5YANV3hFwohlwohALgfAJwMjkIhvD3ggXAhtBHht33hk94hvU3 hB0BhnT4fHQ4GNe3h9snh+aHh9EHiOHnh+T3goiofW5hdoaYcnCYfY84fVuofqZShfCXAAhg fQuwiSfhiQ0Yhfy3iPE3ic8niF9YhmtofaSoiv/dh4NZ04Gp2IaROIO1aH6NeId2OIvUl4vp h4rkR4jr54vi54Y7yIjHOH+VmH7L2H/NCH7PmH/EyH/ACIwaaI3T6IrbN4QquFIvuBd2mIYC AIdp2GU3Yxln+ILlqDPQwmBg2I3ggBh5+HzgaHbr+CzOxzMo0Y03AyZnWI+WsWGdcY4rJY/6 +HzriAoqqI4bdhzzqIJ7MRiPwRftuGHvGADjCJFd0YIHmY/ueC5dsYv2KJDUsY/pWADfYABK qIYjuWGoUJDv+I8bCX0RuRcc2Y8UaZP0GFEr+XwwmYf+WJHy6Hz1GGnoCJK/oJFk0ZLsGJHw aJHSV4mhlwyaeABSswz/BxAsEVKF3QV9oeeVy2B2U5mVyWAuY1mVZrmJWQl6oXcAqPCVoGeV pkKVfsSWYhmWbJkMqMAAZfl8UtmWHdiX0JeQATmOAHmQAHmPQfmTRBmSTImPZoeYM4mUEomU duiNYPiTmOmT57iQkXiPR/mNjtkAAZAbApAbOomQDamQGImSk7mZnomU6SWb2ph93HiGrRmD HfcLopEAspiGjZOEsQmcL5ibMYmObgGGR8gW3bKPwHKEGKkAz6KC0bkAwoIKzMmbxMkcS8kk yUmaAiCdqolCofmOncGb6niGUSKdTHKdyKmOvyAWZ+id9wCe4ul8xqmEu4mJARmc3XmSpJkb /9WBhudpkt+pgvR5givJnuNYn9Xpngn6fKXZES1ojw2qnCjpCwp5oTy4n8IynerJHI2hnvvZ nzEoogjKoU8YhaKnDBCyiaEHhSgRo2vZopBpl85Ho8/Sogfwomx5XT76lTWKABAyozBKpHyJ ADLKl25plzr6o0NqnX7JokQapbKIhoihnfGZnShRnfrZnCaaoTf0npHIpWEqoeEJom5hLus5 ol/Km/lJn2CYn/iZpuWpmrZwnLoJpmnYEQZan1hKnk0in2sKngcKoOupABr6ngpam9N3m/P4 grfQLceJkPN5qXcam5Kqpxg6jzm4m5x6ig4ZmqOai5Oankepqco5qv9oCKDDCaCoSoMqaKqd ioOq2hGsmoqSCqqWmqqYeqJVcqO3GquduoqRuqodSKueanZREqyn2KnGqKuReKp6uIOxGZq8 eqt3Kod/6aRqiRJrGa7gWqX8CZdmJ67emq5fua7fapdDuiBViK7diq5COq5XehJUCq/6Kn2v 6oK8Khf+Sql3qqxHSK13moOjuqmeupD/Cq0Ou6y42oHXaqEPCau8ikpjqrCtWrHSeqzbyoYE e4uOOpi7OKz2oJKEmKK+yrEKS6wem4Mne7Bm1zgbehIAa6oxq7K3SrO96rK3eq2zuoMKa6uw CoY8u4qSGrMbq7MA+igsSbEtG6oFy4YKy7P/IeuXZPG0HhutL+uCMZuLQJuOOVu0UFus0Net 7Kqv6BquW/l85qq2RqquR5qu71q38QquKDGveOuuKDGFCHCleruv0devbsaTPKsiKAugVwuz 0pC4EHu4DxuaMRu1WxuJPDuxmQqrMfsNfdq1mduxQ0u2KSe0Zjuy/FqyZPuCCZiymKqyLhu6 lfusJiizM1sdODgMo5uKq9u6oou7G+uzZBu2ueuxRPuyvgu6YCiBTHun51WhZUu8ojuLGou7 i2t2zRuHD1u985iAYAugd7q7L6utZ5uvabu2e7uWCXCjWXiue5u27ju39cq38gu3+CqW7Wq3 Zue3U2q/9Hu6HLu9/weIu6prLrGpvQNMuzYroJEbmwlIuZSLtabpvc97qwv4H55LuA4stSBL uhBruoPJHAognx0xkXNaFtopkiuLoCfDk5pKwkeJkd9QujB8whBbsxB5lLk4wya5sjMMhjWL pd/gnB2BsvGAnsfpkiKcwyZcqdRpwsFylDnowjrcqzq7wiopGjeKxXC6xC/sxBJ6HH7mxTWr xEE8mPEAfT08j2QMnV7cvaQJxk1cxrGJxHFMg6yKtvD7t0N6iWxpKgo6hZgYeqayo3kst/Ib v+x6CoKMvuSrx4Ssr28JivV7yH/LANalmnJsh1Ncs1NcwDuYxnWayTXcxWVMx7jpxcFRnP9c nMqRaMNW3LMXOcTgWcZKyJuzbMsjKcq3jBKsHJCyjMRrzJ8ejJALoYLGoYg588NLi6meVLM6 2GVHecyl2ywOibljAaKicca5SM02jKnSnM3Cmsw22zPZnLHH2SxccYa5+M3Fiy326BU8+JHc TMXMbA8dGCWDa8+1DM0q6M5YG1H+fM3D6888qLX7rLDr/JHON89ujM79LM6x6dDq+ZG0tL+G 3F01ipUocV1/C5ZrydH8+77pSmaRrK9fOYVkqdGT/JUgfcjKALj5upYoDYWSPBbVbIfzLNA5 rbg7+M0LDdESDM7j3IISPc4O+c1IrdDvfMbNDMvjPKbzbLMdSND/S33TtTug39zU6LzNkzHM 07cAChDW0NKBIRzC1nuCUuqTL7nWkWnWY90Abl3WbA3XDGDWbk2UaI0Kd30ubi2ldd2BlozX +cjWaS3XfH2vTJLW0NLXlkzWcw3Wbx3Y+fvXb13Zkn3Y0WfYfB19UtrZHQjWsjih0Gedim3Y sJjFbW29kEnZ57LaqB2g0mfYZn3Zmi3Yqh2Zn20uaV3Xg03XqV3YlJ0W9AjYe1ncuH0Kh72W 53KvRCmLyG29xo3c0m3cy03ckW3dYz3d0L3d253Wis3dyL3b1G2h3u3cJ8jam43bvk3b6H3W vb3X6H3Zi23Zf8zaml3bmN3W9yqlfX3X/7xNlDcq3+T92c59o5oN2vkoNa7t1QyugcLY4KN9 xtz34OrnrI6aq94XlsoN4elH4Rz+gR7+4RUustEXi/lI4h+4AChefiEO4fFVfSYemZX6fi/O fSrOfr65geMHhXg5gDduff/F3GYo4uv346O94trX4kQeaSicfSnZiJEmst1ygo2Ykjt5xdlX JeZSDfCXjd9n5aMt5GUI5pwo5vkLqLnbLVh+LjyJft8ticmIfnFOfmTO5msOgl5e0DAMf29O 5HZ+5Y6Iy9Ln5Xlu42bu53A9J8Ls5I/RiGreFcw95c5X5Y9Bj5W+Wtgn6YV+fpu+fWKB2pg+ sp9uGYu+fZIe6P8gGeCXXurz1+mk3n1+ln6j3pivjX+hbn2bfhcKxgr0aG+NmjUdZ72+nr9W 5g2RSYLsd+vUp+ztN+qYPurf4LyDPufDG4ys7uenHn6Ofg/ZvoJo7urWeObm4urkR+7hF+5j iOTWl+3gru7u1+7dpxiIbovYt+nxZQCoHSUbdqP6zo79/iz/zqzsKH/hju5yXosLcOfTvvDl Z/AN3u2RSRbgYBzYKfHtqADbHtb3oOVcrkC8CeX12ThaPhaKCgu0/HyaDgtVMpkRP5kiL9Xd Ei4Mw6wMVrsDbxw2n8U4r+X7nM3m0iy6LfGlCbC+YFnSV/Qqfw9cPs4KWiVbcdVB/wz/Qk/x Iz/zQO+Tt8CTHA8LHo8SIP/zznIPJF/LluX0ybjzSp+MZq+SZm+zN1/zW2/zY//yztd4tCxk bq/zD8P07bgSNxTzPC/yId8xR2/xHqkAXL7yA/rTJ0P3OD/3hF/3Nc/3C12aWRwtbNEN+Via UYLvnK/5lo+PmB/hT5/3fZ+MjWP6im+aM4/0cm/1kY/1pX/1Zq/4Q38cVb/xg1+fq0/z5WX6 XI3mNk/2Sf/0Y+/6bf+ED/Pyvd/zfG/2tlDXY4r8WY9+DKXslOoLb8jtv1BeU77t+p7oGM/1 t7BhaX4PMVwSup8b0V8NkV6f214ARn/m8p/0d3GGVaJfJ/MN/2LR+N1v/yAQCE0CJEmzmGLT kiaqAEp5psDQMAAjBI2sMAAUCjNZIgBwMZFK4Myo4/maxMBv1/vJBovgsHicqXLaqiuIhSqk 3bV7tiskZIoyNLnsLly1WNRS2hUXzoJK0kjNk53UXAIeIosfjwFPSwCD5AilzVmhF2JBocKj 3SbToJ5V2x6RgGDLI+rfTQ5q59Nn6kDAAANTksGCr1/AsK8wcY5IAnBDr8Fzi9oPKp/L7MpI EKxtni4RJM5NYio14dQWlBcYkZHCKbndbvfS4hKqI9VPtriTq1HW5q1w5eWcNnP2Xnjix+6Q iVHgDPY5Z/GiRRnNWNlptCROKyi+gP95ZCMFpCV0ChoQmZJAAKdUdhqAlDIoZEqbvgTksKRg CM2PS3IONdGCKBNLKNgoddHSJ9COY0LaTHXSFc4ZQG9KgYqVjdR4M1gWaOCVVU2sV5kKmtly 7UwXTU3GosvGrNCgekumbPE0r7+XMYvqlWsU78+vDXbmsNPXMWCrke2WNHw071yyeAu3WHuW l4hpBo4tk0va12hkXrCMZMA6wEqVXfPGvWw7rd+ynmP95Yy2aOK7YcNqhhy85G69s4NbVq5W 0FvaY8/1Rcr38Nm4jJ3fxejde1xLU8PCDdSdsnncd1suhrVU5lj1svPaHOA+KID83Ne6Nro2 mxKAlBJgbvj/6TdcenW5UB5V+enHlVAOCjfeVJoZISGE6DVo13q6SRebLARWNt9dazH4n4WT tXeYAiOgqAOBFx44nX1GVYacgp1NVtKIhfFHYIq+mehgjgaM9l5qpR112gBJFqNDLyeg9qRd DDJh04nQechdgS9mKONXCIq1UkseSYjjfvQReaUgWXb5oUVYfuhIjGvGVSMKVn635zlxMRAP WFO5WRuPCXLoVlnQ5DcNK3uZ9yVgJVwixQJbDhkiD1729+dYmwZZaaBjeqmjoxuCCmkKZc0k JqJ6nUpioRveOFZ0paayaY+xplkqirVW1cIQl9BkqYKbUqrqdJKS9Cia57wY669y/xbmqa91 XfqqXMQYYAwyiZJwGh3gmmYkk6iCxCap6lXL2bp9GgrqqhSOWZx58Bp66VrYSqsuseehy11l xuaDbGzKAjwdnwlDYcAdHE1VwnHmERpRQL2UWoI0rULBCQMFTKNCWRbnah7EFk/RT8k/+ORN yrLIsEDLTHD6Racva9aymCULYkAOl0WcgBQxo5OAxTiPxSqtZQmdh8gUQyHEDyBhzCmZSmul WDYvI/ErEk2v1PLKrgB9DwDS3KxVP4PEJMDXaN/6stGx7dCPHVPX7bZZPb/A3NDyvSBNzDOf /VPaiLGMdwsLDFDAaBWlIEKUDAwACeQBUM6T5TQoHgDMU/962/UPcQdTNgNx29SSzn8Dgzre PKtStNvxjklcmTOYDtzhhOu19NSpg16g79O53kLvsT86s+gnE3+1vwp/J0N+MYVKT36MSIzw Yvkhq32p/c2QtCyHGeG4ovkJyPWjSgDgOJXqo7ADAE9kvz4U5MxPPvSNjWE/e+5PL0f1BCGA 98BPfupLlP8GYT5MLFB2YtLM/N5Tv8MccIJboof6WlVArNWvZxVUoI2mo74+bJCBLfEeBEd4 q8OwxAUqVKAHG4iwJ2EwPzN54QD9ET8FVbBHKFRh/gp0P5kF0IQS3EIAvAUsLPxiNDnoxUig wUTJsaYsVAwNCJcCROz9MD99qMz/CYuIwv55sQU5RMcCIzih2VWodivxX0lKOESdpBFTPCgi 9A4Txh1254ww0s8WQxJENdbmSSWsjfO+86d4MOpPOliJI3WwAE08UpKVlFnDHklJS0byTwyI ZCmW94xNMuELo4Qk+RxJylC6YJJNmIYmVvkx/DEqcRWJ5CHSMA1WqhKScpskCYtVKUH8iZbw gcQrXabMXl6SlUCoJRIcV0yXbZKSnSwFKEcJzEuWUpqZVMUtQfTMbGzzkd4kyS5r+YJRFs6Z rTQmN1NwSmpGcpxTuFU5sxZOS2LyGc7MJTXSiZB8ulMWBRCnLE4ADAaYrXTOSOhDSzeMbCjU CsjUpTLf/+bPeW6Sl+X0pD3tuQOLwvOalWTmOOvJS1TKgqDaxKhGJUnJaMI0liSUW7FYuVJ+ AjSgGU0cLLdZz0QStahG9YMSvwMTPjHsIk09KlTlgtCofmcAevtXwhBJVfBgjzpT3dNTt6rV rZrlqy6MCdGKagOwmjUYVyUrXKEa1kQCjU9jjatT2+qHq94Vr37dU18xkta/ErawUd2KFaT3 HRZ6hz3naAliDWsRyObIr479V2QvEli8bpayCrtsVDe7wkzsCbSpAEBMJlfUpZY2qRb5pGTh Ojd1KooJprUramvLBMSK9q+3vRUwotLV2J4js1TtLXBfGz/aAquyxH3unl7SGf/X/kqRerWt a7uU3XNIN65v2W4qulvU226yCHsaqmTR+1jdgHe9VJWuer1jBOaeFrxzaKVRWbvY9kIXrvO9 iHmdwl8AtympAY5nMBTrXf5217zxJW6DB5zIeoq3qP8NLycO3N8Ny9e5pLLsdn9LYLyKOE4e bi2HiVvii6yYT9VN2ET5VOIW70m/jZVwio0aYxnjWDJUfTFcVwzkHA/Zr0VmKvkWdOIcR3UH 2zJZ4gikAiwUQAW5XSoxTGDlfMQviTpwTw9y2wAfCMBbU/byZcNcgrIsNcyc8AEWIJJbN6cC zlcwCp1voAQ2j+DMbGaNnEeQZxeQ2WOw4ERL/PxlE7T/GRY9gzPnFs2JLEsQ0gs9tBlFUGUC hfnRgNYzmvnMEgeNg8p6TnSXy0LpUqa6ldEbs6YVXQyeSDrKjJ3yCTGNXVArsRick8EndW1p i+Dairom9AhaAuk+KJrQWLgzChS97FrDuszNzrS1Wz1sLO9Q1a1GCKa3PGZBu6fRYl62lckt 5nNsW9OdTly3x62ZTr96qbO+xbdv5ehMY+HS5451qtMt73vzGtZ75rSwAS3wQfObtIVWNL2v rO5Se5nJRC2G/TDBtj7AxAgeGwIw7L1xydGv45CFjeIGgIQxm2AaJi/LZXtxB2WPwKor98Ga SR5clTMW5/GTQc15jgJN03zc/x6Hdc5BDg2hMwHMNjcKzY8u8wUs1eQr8XnImC6Cb8LaCCh4 OgrAvHWOl3ksWDd6S4pehDW8vD1Hb/vYm152b+mc5c5oexWMAvb2cJ3oWV+5gNGuRB/sAGg/ 2DssvG4Rvy8d8GZM9p/XLPimW+7nEn975f9uFDC3ndAtx3sSNz8CxneeF0InOdmleIelIj7z dd87u0Mf9s+X/Y1zl/fJ46H0qv9A9Ednd+27rnemc37udec9S8J+e5/DJretT/olYJ9pxRdf 6rBJTMhrjvLSW1xhvVAB+ZZboFrhnrSFSTvME4WDIMh71+jftWaWuv6ik3/+gx9B1ZPN8/TH H/L9D/8SS+yf3PmFAL7f++Ee/8kfzBWg+SGbZthf+4nfA4qaASYgx5TNBGagATbg+CmRTbDW +9XAJUCgBAZe2gmgCfKfYZSAfeQABCrgZPEfBDog/cng/ckbDNZgALIfCKrg43UgAgZhBU6W AH6g/+GeAMLg6aBgnflfD2ogBaqgETLECPqg+0XhDhZdBk6hCK6OBeKg/vGg/y0h+9GgqEHh h8FgBnaf85QAGlACab0fF4rf6digXzjIttgYGgbe/xFJHo4hdODhAObfqOXHtrxfDmLh6Qii AxYiBg4heySiEApiCXBgDgoia1WiF/ahHWqhJWwiJPKfJl7hvzxhGKGBH77/AAcaICMC4WWp wKFBHSYeYX09YCsGoSReFiFK4iUaYgRaoSliYS5aoVMI4hRGYrLNIgCmIvD9HxrqIHtM4Q6g IjECYS9iYDAWRpuhVj8gIv59oyP+4TLeIgxmYzQK0BEeIBsmDPy81Qu4IP9N4Tuenx1qRlPp 4RDyoQ7eIyAWyFztov81lTdmoBJqSVkNoD1WzR7yov89RcFknBCWBT9SAjxyIhqy1pOE4hqy ICkq2Q+uoRL0jEMuz1UN4VzlYzEGyyZO5G2ZpDiVY0MCIzgyZAZO5Bp+5EBCYz3WYlMdY6LA IEtuSUJaBEy64hceoDyGJBC6l04eZDYmJf98ISGO/2RB+uNLOiGi1aNPLuU6JgwsJFn2tcd9 SaO86YQA3Fe/ucZZil4qhIY6LkYm3JfIFV4QmiVdOiAhuiUKoBbIDNxaKqIg6CVCCmZLuGVZ pOVcsmVhruX7tF+m0aVgslZYRqb/Geb/yQDDqOV98eVi3ldYntV9eWT7WaaiaBFj6oBjsoQA 9KVgBh5pep5GaBxdfiUFTQNnHuZpOhtLiGNn6uJMjt5fBiFlyqZvEuefzWayrWZvItA0COYU IiZwIicAtmYDEh5biiXUKeef7SZcfpI8DoFphmYDRmYmGMVwYqdQshZ4GicY+qV0kl9rPuZ1 WmZaPmdckiYHdqVFQJnn0f/PEOyZNuJfGdVHvEmKAUiKwynWf76lgRYdgoYl+T3oIIKjhC6o qFloXQqChDaihFIWgBroUknKo/mfhMIC/fQnaZXom5WRiP6ghw6kiV4NgGIohpoo+WCoaKpn vK3T8oifje5WgVYPo7xoUqXEk5Sog5BE4WDohvboJcAgjv4gIdYoiQpp+0XplcabiSaoosxo vClA4UjoHJZNiFppVb6A+IFp05kpJ7Rol7LOoqCpAchjCTwDhqopJdjPlgKDijYXgNKpsFBp e/ZphFopin4mkxrimPLMlxaOfi6eO4JUQIXSJrmSpMoSK33BT7mSTIBUQWlqKHFqPbkSpXrT Obj/EqrOky6F6kaxakqZaipwKjfplKRqqqg6DqmqqiY1oayO6ikFVSuh06QKK6nGQ2yUAq0m 60IV1DO5U6Wmk0dhUtaoE7LqKkxVKz7JU9YEK6c2Safu1KlmqrA2K6OkqraSq7aC67mia7Cu avZxKqdiK7p6q7S2FFAlzkqIKojkKj9xE70+HrwCq7vi68ew1LmS0rxui8w4Dkz06r5C60JV xK2+kquaKzfxKympV8M+g6zKq6Y+K74OKzQo7KMS24mWLMqmbH/pocq2rMXlp8vCFcvyCcz2 lyUqWIrVbCPGbI3hbFzpbMmOBs8OLdFC1cwWLVF1zMf02IZhC0LEldMe/1XUyqzPKpLzTG0r MS1qImT30ddHIi1RVi1Zee2jyirYni3allLHMBZCYGDaOlltHJnF7QPJXoRrJFEBiO2IbZXc QpXZjq3b+oazLNme/K3KGi7aIm7aLi7jNu5R7YA76luSyawE/VUP0AyI9C2RLcHlKhVM1JHC aK6LEW7Jdu6H7a3jpq7qri7rtq5RLUDdphiNiRXCiC6H2a7FJpLtfsfupuyR9a7rBq/wDi/x +pWkPGToxA+zoZb9VOLywoIvLJcKtM3hMe8NQO9/8qkNXS85mGjbdNUQeIMqju/x+ukNiMV9 2ET5ugBQ3OXyJG+kwSJETm9KyO9bLej5dmmP5v8r8/aM8/KC9b7p/r4v/QpC+BowH6likh0w AA+EAvTFf7LavqEp8lKw+U6vACuK+OKvBetv8X4wCIewCGPELiQECyzENRBBGMAD9dABQDzN CgPQOqAwOeyCKoQDHTzCLtSCVECRXtiwKH2iP9BBCudtXRSKEY/OKtxNQ8zwK3CZOdww2axC Cf/D9awCPpTDJAyN/CyPDZRELQxCEldxDjsED9tOQUwEQ4TDOoTxCL8xHMfx6p5FdcwJYYCE mPQFg4RFdjzKX/ANd9SxzwDFXJAHZjBPYNiYIPsNtFjLh8xFH2eFkKiJXtBxW9wLJSOFR/5K IZtHZpCIJQ9yUSwFmuD/C3AQMtvKsSqvMiu3LJj4iB0fDBuJSpt8iCGfiR97CIakC2DIiYT0 h4CU8powgQgw1r48x29wCC+zATAbCDK/iCk7c2EI865Ey2Q0cxwBCYm8si/rBzZjcjWvSTO3 MjmXszlvbqrAMq9QMtKEhCwbcjqD0ZboCyWr86ngiqBQstOq5L+4SYb0iJUITDyD8yZT8rFM MzhHc0HfihJQjU14yjYPjD0nCj5vSDQf9B+R7TlvNEd3NF25TfHoDhgbzyzfDeAwT86QdB3u DX+mTvGctO480vpIBdTsDuKgg2KFtNegz9gos+F8BfKoNNnE9PIER9iwdPJmjNOkzlHzDiJn /81MO41MO85I645O98PMGEfuoHKLDLXJzIzSerRYjzVZe4f/dBH9VEYgiYn3HJK8EFIuGxER 8VFbqw9cE4RYcA8dsa372tEQ9cj8EMyvuHVex1AIufMLhQ9dF5EaobUViRFjJ/YUJDAaGfb2 8FX6LBBaAwJel5BnR7YMkcP4lDVpl/ZYO5Ok7pQsLZMvXRJI2dRJtbZPnVRFOBOzwvaupvYs sXY1UbU61SlC0OoygWUmqRJYClVs9JRIGWxIkVNvrzY1mZNz35JLDRTCpoA34Spx9ytqC7ct ZRRuh3d1f3e/mrZ5nzd6l/bRpjd7t7d7nzPW+lV8vzcJH5RRpfJ8O/9PWMdxftM3XvX3hHmM YQF4IhF4yc6u3QbuBwOvUdGtf4dP7GZa5bLjVzF4RgxXCFt41yr42TqZ7pKu8yCXh3/4FER4 g4P4gWut5BKXHxVWiw/ucznCavLJi/NsjUfVjWfDjLtXXGk4fFzX8PZtjjOZ6ULXkBPahL/W jocuimcVhiP5l03unsj45B456iItgndflt93e/m48/TulrNhmO8Xl+OVl9+EHPftmLtui635 6HLWkwvRid8YUZ257Hob9oofAwvw9NrvALtanpMWA/u591qwnxs6DtTFnpvR9v5vBjt6BAOp A0Nw/IRX/FDKWJQvoTf69nowvA2Bwmp6osv/b/QKuvUeuqjvW6GnevxkL6KrOqdjT5/3L8ux TvyOOvOWenAFMAdDeqVLOgFvjFGUAdmAb6UXsPkCOjkguwXXKbApcLJ/OgYSO7Tz+Qz0RSWu uvJGO6uBui2Qza0HuvZGmgJn+rajeqdHOnele6V7L7UzsLbTCB9h8J6ru59qaKfDm7hrMJcN gUdor9nZ0KxPMAf7GL23+/bW+6+zbwKvb8zWjhC8wxhgcRrTtDcAMQxLvFgs8RN/Qz10/Mcf BBfXRSRswxpDMQu4MUOczxQfkTiAxMcnMR7sMAxYgUCoQxXwgTuIwcZbzxg7BA2bAdCrsMbH vDfMvEPcRNBrgsnr/zzR8/wLZzEt1HwnRFvT48Aa8AHGn3FIqPxCxJFDiMJAmIPXpwMfTD3H h4Q24BvZUz183PzZX33E8zwqmAIZyP3Fm7HbE1Eb1zweOP0qIH3fp33U730WY/zOs3DFGwIS hNE6/P0YJHEWwzgTW73+UPxaeTEbv6HLuhE8Xwo8f4ZKfD4y2yNKe/Lpi5OX9MalIMUn4wUp o37l6jFWRPJKW3LlXkfErISYuIntG2Qk83Hq3/5Thwrx20rvG/Qdj3IqQHIsz4Towz4os20j I8ZWbIfrU//1rARS+D5vSOQhJ7mGbAYeT0X2q4R1oL5Rp7IoS3+BzMR//DFQuMlsVO5uAP9y 8iN/l7U/vdAyl/gYCCiAYgBJgwJFUwCsW54o2r5NqQzuzPf+DwwKgaqGSHE81pauWnLEBEh5 TyS06VLuii1p9vryGkc8Zo+LtZlrjICJ135rG3EZbee8iucNtLhOBdY1dTRmdWg2N/ilUNO3 smhYFcnnNzUzuQWZVlilmLbmAjgDmAhWGEnqdjI3ijL3KdYwIPBm5mqYp6AGymiWsmmDi3lK Znr4aZPLKegluvoTOVqEmvYYNnV8Cz0TKvs6kmnTKSVwJ0sd3qzcozsdzMZ9x/s9ZH+PT7Ti uX6cvLCCGLJ1lYIBXGbjYKFu1mag4QXRURwGcNww4DOR4bw5CsH/XKtxkI5FgWY67uLXiFnK hPs8PjQpzqSjlwHBIdIEkdzAlaEgigRAURVQbYxY9piIcaRNXSUDJpBC8VfGpUV7Mm34UKLS QCurjVN302eyfwGnlnERMmO6Xb9o5lz3M2hEtDUlgT02phZbusDs8mx41lDcj9bM9gyZL7Hi IWurPM3h4rEOvzUkB+DqeMTkgg0sI/S8EIXkHQ5XeMZRq7Pmy3RELIDjWkQCia5nPDXAQBdo l6ZXo7gI4DW4BAMu7z4J9sjoz745H8+c47Jz3wKnRxeMcjnqyNSBC//teneB4oI9ww4um3Zw kl9mc79OBwBr896JEZdO5vSI1Om5475G/19tBgxgH3mFPAeWZ7cBp8BxlXUnIIGiQbjeWqpB 1peCmjGyXGvrobDdheRVl+CG2JkAgDnmNQZGhwNqVEh9RXRYH4j7vTfiYjru2BdKDEjhRnzy McKHG2+QeMiPQyJ0TQNGsuLRk4KRAiRpfTkpxWtKBonleiIAICE4YKJgZEtjCqVCUVJy1iWU Z4p55Jpk+Fglk3Ku1OSdVbTJZBF8IjlTQEa+plMVW4pSZ5eEShHmGGcO6qiFf4opYZmONlqk FIJKYUcAYUL6JaZeQLmLokJyaWkcLvgJKqMoCGDHl3KQYSpKpqpaSKt4ynkmrDzwKqGFh14p 5bBHGOsqlUtO6v/XsXXq1MIuUl4jzrAN+LqROmcWgeybp+4wLY/iJqYARRe1hi4dCzCgZQIA ibLLuexiIhd46J6r7rzyClcuvfbO+0pQ+MKx7ncB+/tbwQg3sIDBKDRMigLfQXxUufqWaoTA 8fIrV78POyybwR7jK2+8pbJ7sboI73twyyWnm/G/HC/878Ytx5zuyyQrnO93HjPsMNBUaAzw wDjzQHFrEzvMstJDI13vz0kPJ5zRP6NctcQRU/Sz1FVbGbK9K5sM89UWYzyyzTdT/KMPXvs7 MNY3j+wuGyfzPHXCAB9dc84Kk2xyUF2bS7a+dSNKcLpJj4x30HLfPG7kkrcTnCOTX47/eeaa Sx7a5p5/Dnroom/e+ei2iYqx6YoRp3oL76puuuuVNQp77abHEUDQtu/Ou+el9w588MLz/vvt UdM6/A8M1Bs67ronv6PzdDAPffXWX4+95EZnz333nxuQurjngp85+T6Y78P296Dvffvuvw9/ /PLDPxns9c//vp9D3M9YXZLrzwMARk6A+CugAQ+IwAQqsB3+01ECzIGPAjTQBw/ERwWBd8Hh ETAaE/zBBsW1wQ/uSIQLLKEJT4jCFHbPcpNjoRBcaDsY9o6EOqLhYkLYwRHmUIU87KEPf+g+ AQRgiBQRogAKwIBaQDCJJhCAOZgooQXIAw5KZFg56FALO/jA/4nXGmLuGLaKBVxRjENcgRCH 2LAxyicAZvSilqpoxTJ20Q0FgAYTIXjG3IkxRVjkI5UMMAvW/AaOeTQYEx9ojiKQkY3XWKQZ E/nIPuIxAEcszbUgGUdGOrKLlXzYkFZwxyu9aogqgAYXi1DIOHKrFrQDoitfCctYhk6ILThB FhkwgAHIJpAS46ITo+UkAWjNB7mUDS6BwsvnXbKLT1kBJSV2zCIeEZUBaGY0L9mCNjZzFrp8 wy+p+ZQAiMAcxfRmNVVwzXJq0VN9aJQ6mQnA4vQSk99cASqnGcl7cnOXt7TkKZ2JT2yi0gRy oWQ29/kGAAoxnONcJjiLYNB7AlOWFP+tqEUveo9/LrOdIrBnQDRaBPlQLwXdDEaTguBLTIp0 HtfQ50Namk97lhSmy0wpR11qUjB1lAfFEaPBdIrTAH5UpR6laVBPOVMuCtWhRQ1pUZVqyZDO VKHmsKlGQdrUomJ0q1zt6iuvCkFnANJPWFVNAEYqVmXQ0KYzWmmgrqHRtwY1rU6taVUT6QVA xnULeeXBU4R4hr5q1JJMNWpWC3tKwULQn0Q17Eajas++UtWuiG1sXW3o1cxqdrPtA2tfyEfW xqqmldcg31uFwFanjEmuMVXrUxsL2tdStgjk2+tnU6ck2tF2F4O9UlkvK9ug1naxffntYaHa l7rGlgdWvSv/XC17WM5Kd7rUxZ4Qf2RLCFISu046axLNsd03SJNMBRUAdx1BRAYkQAZnnUFq 6bBM9Jo3qPL9UWvDe4LwRtKm+C1sfY/k3g/NoL+97e7yAAsAQOq3pfNtYx/0Ct75ZvcMDk5w MO17YX0GUABiBCh3J2vVy1gYpByGqIQ7o8XqqnjFLP5cLVaq1KesVMYG4KKMJfRiQglSNW7d AY35qIAdvzfHytABHf27AyMHVcbtVfJ+ncvk8b40yj3IkW2AJOW60FjGyHTyNbzM5fFSGbkA 8gJFvOxlMoMZyyelrI3NXNg1b4u4La6zne+sGCeu62FyMdoCdrFnlYEnKAMAJGxI/zExQJ/Z 0HxmGNcIJzCfXYQie+7X3srVr0prbGiZprSnxebomO1NfU4i7cA03YM/P2xw/fJYufz056AE +tTM81isH5YADGes026bNKh/Fuo9B/rWoXa1rwUdajwre9nMZi6dL9feHUX7oj7dHWZrmEhG N3vb3O629ch8uZHmQ9yxNMCOYXftxXSBtN5ut7vfDbpAwzty8q4dsOeN73zre9/87re//w3w gAt84AQvOByWR24LagkBCPgNwoPAAIbDQeKd0Z27xl0Abd+DAQYoQPiil3HMJeDjINd4EEbu 14sPQb253njIO0PyFKI8frkxuekalnCD65xHDDiAzw+Qc/8hJMDndDhAw3v+84Yrz+hwYPrQ D0BBouNjAZ3MR42xNS6q73B14N6R1u+BSEwIwOY9UIAT9WyPr4f9h2uH39d3h/ady31ySGd4 0IOwAKb3/Og+R4DPdbf3pjc870pHGtMb4PeEvz0fBeDw5BYfObOTfTGQD4Lku7F1LAqAFptP eyUv/0PQu73qQ2i8MhcTdx+YvoWOn3u+kQ4EhOdavQKbvcDMpXei+/0Ey5te0RHAtsP3XjQy 6H3ED8B748tl8Q2iXvPpQIuWN4xiz6fDegXX8hm8Xb3TT/W6Zq9yI2R/cePvPilGjn1KdxJi bLu+0F5R/gVk/xWdp7p5gSZ/5r3/nWLTn3/1td8w2cd9/Nd9A+gw/Sdr5ld9OAd+PiOA7kd+ CZh/v+EuBDg16pVpr5E3CPgx1PeADxQQ7Fc114dLsJJ+bhN/8/cqjseBJZh9C9h9HAh/5hJ9 d+d6yoZ063UUP2d0fgd1DcCDfCeERQd0f0d4gYd0ffd7S4h4Prc8TOeDQLd7Q1d4b3d199cN ZwcQZ+cum+crV3hmaAeG2ldJ3/VLSOOFR8R5FAGGb9d4ekZ10UcKZwdIb8hhX6d1b8d5DdNJ dsiHnKdtILiCf+hEGoeHlRSHhQgiZ7d8Zzd2mneGiZhrjlgX9qeIksgCWpiIauhEUaGFswCH faiJaQhI/2aIiF5oB2ZoAHlIepb4iJjohyUYiUekh3rmh5mYejfAiJuocaEIiLjoeG2Iiry4 iJ14izcIb0n4g6TQd80IdITnd0OIhEH4e9OIfEQ3jYNndFrCdHnXjT0IdGS4AlSXADWGMVpX Y+BDC6tofxUIK+Zodh53YOUoTOJoBEfUeJVYiPt4h+8oTIeYcWPXjt/xQAOQa+gokKdYAF8X j+UCkOkYh/noV53kixKJhuN4igMgkeRojmRokFwUjxvpRO4Skq24eWE3kAi5ivx4dXwYkOBz RA6pkBC5eRJZkhgJKwR5kuxCiyb5keaQkkeUjjfJMD25DzF5EevIky9JhvTYS/8aSXqX9Ic2 qZRJ5JRBCZUY6ZQ5MHY2iIx2loMn4INP2HC6B3RDl2u5J40+p4PVqJZACHXZ2BnI9xuHl3go wIMX2RmbJ4eikZOVtHpvV5DR90AyMJhYp3Z/qY+RZHqH2YWmoZiVZ3abp16RqZCJKQOYyYoL SXqCKJWbiYsuWZQYyZmQmUuIWUk2ppij6ZePqZdcJJiWyZgcVphaV5gPU0m1aZSaqZBl50QD sJSQ93Ww2Um6WQDGOZqYmYWvgZx+eZqPWXmhWJo04HiOuX9GuZfPmYmn95XLBnsowHAIQJZw 2YTqhXxyaY2CJ5fY+JZoWZdKd5dNeHi4CZnHGX7IGZj/xXlE6yV/2AKC/GmPzUmf8UWb++mO kAmdUbmXY2ecAKmcrNmg2Cl25vVdwVlJHYdEAJmcuWmgE5OaKrKasema9kicTiGbBNqfj3mb ECqbvEmaFFSIoEmiQKmfKhqi2Lmi27mXI7qX9umS0dmP06mj/3mg9JmYPqqj3eludQd8gkee ifd0VLiE6cmM18h31xiXb+mNCGeX4SifBsOQY9cIaLOfj5ifASF5Y2p2A7AuaepxAXqSJjmb fyamHhemx5mQDWQAIBiPD7SSGPmRR8mmS3mPePqnkPddp0malaehoOmm5+hEa5qdghibgYqG wlR/ndSneYqimwqTg3qnfgqa/wVJqQq6pz1pqWSIqQTydp5KqhkpiGu6Z6vnqWIHPnYqoe4V pG7oeI96ndP5qDoah0rKbcqoRYFnlk+YdFOae8sInj+Hez/He28Jl0AXeOVZl87KmrKIhdDH iMLaSdx6YHomrvZoiouJouL6deoalZMpTOwaEJzneGYomvBaeVfIphvqP42KneWKm1wIib0Z sPoIsNsnr4TKRaYnrvS6rgcLmufKmlRwdrsgr2DqiCdgsIwIsaCIdvSqo/7qrZ0oo7r6o6Ko JQ67fv16sEPadcR6ZwhHPcrne9b3cDM7fMOXcn3GLt9xs7VXfLenffOpNxSogtZXfkNLtLV3 Mu6HaP+ydpD1gjJC037SF67uF7Vlp3IsZy6zxrTWtzE+u7XLU2+4JoDrcrVNmy/5crVae5Ez xzBPm7a4drajOXNny7ZRK4JJS4Ffq7coc7X5t2dzC38jWLS2eTd9xrSAC7bnVypJw7ZwYLVm O7YQ47fDxrORG2liu7jvx30u67m243fcqUCVl1mk63UKekKm+7mra3BS50Oqy1WwqxiyO7qo y7q3i7u5q7u7y7u967u/C7zBK7zDS7zFa7zHi7zJq7zLy7zN67zPC73Ri7swS73Va73Xi73Z q73by73d673fC77b+0rhS77la77ni77pW7MopL7t677vC7/pK3AIN31IMH3/94u/+au/+8u/ /eu//wvAASzAA0zA90u9KSS2DYMEC8zADezADwzBESzBE0zBFWzBF4zBEIy/MKtA9KvAElPA ISzCI0zCJWzC+XvA+7azGczCLezCLwzDMezC08fBJbTCMozDOazDO9zCBry+83PDPCzEQ0zE RbzANPzD78YuSLBe68XAJwzFUSzFU0zCNYxAS9zETWzEW8zFXQzCKIyzNPdnDaLFR0zFZ4zG aUzFVrykZLyn7hLGLpvCB3QR5bin0PSVbPw+dVyO/BnHl5MACEAAg0wATcpsc9xuF2EAi1y0 0hs8irzI9wY6LEeQKZY59wtwkLynXvkbdgd2g4wA/01MyIXnyN2jyBIkuqITyJxMvKeMRLCT AIQ8yBRRyJ+zALJMAKlcrCSAyj5AcbFHyKIryEUbcbUMnqRcyskjfxLEyp4zyJbsvMv8yqpz y8B3ywRAy8iMOdW8AIKMzfwmzdQTywQgdLkcdLFcfBBYzCcwzslcPaesy6LjybxbYyBSL/Us GrRzys08LrEcNMa8ObdsmAQAzW3ccYAXyuUsugxA0OApy4L8GoNMBwntzuUDQf8xA/jcGY0i f3s6BPLWZxrYZ4iWbPCVMD4QuMvjfl1rtJp7frMH0iz9tvP3uNPDtkwrey0n09rXtTWd0xSx 0z3gAA5QO41nRfVi1NSZav99bDvjzDyFXNMtrX0jfdIo3dAMc9VSDbk0rdI63cimQ9Sig88Y vYingzRMHXuy1tWdTNDy1sRyEcsOjbGEDNTfPHwFc3Gdm3JaUi8AGsZv3QOATXzzh9ftMjHs ktfhR0FdK9iOJn+GHQRD3VVGLUZIvVhJjWtkDQTGzNAzANWcTc4o8NlK19mijcz+3AC4jMu2 8dC5LBqtLRzeDMozINuhXdtKp9qyLNq5LdG+rNuI99C7zdtDINmwg9ntcNl01tH8HDnebMip jctBcdum/RuhndrajNW8N8sOPcq0HdzQPdy7U9ygQ9nIlIXnzdOa3QO1HMuy3XC1rSXRTd0C zdr/oX3LEd1w4zzKhGwHrV14/l3dsixrsqzdAt4ZuCzb7Izg/G3VDM7QBq7foMzgPzDeGHXc ZZDcEbPI9iDIFAHRB+7h3/zhsRziIc6c3+xXrj3LDy6Wrs3i3TzI8d3W3vwaw9wwzwzc7hLX ggx843wCK47jHw7kDf3hPGDjO17I8ofjQ97ipzfUYR06OtBxQJlkCdZ4IpAbxFXHk6fK3Q3d NU7kSe7jwG3iIP4D10zXDt3jQS7mS47NLA7c8Yw5Tx46F47emajhXM7eUP3gE93WdPDMMP7m rt3h2mfM933dB57fQA6fbW7MPK7ktfzgATjkDRPKL+7N6rXng77oi87p/0cR492ca4Ge6e19 4J9O4RUuS1Je3ijA6sI0FIvFx/bA0OI526Bt67WM6w/ecADN2vjt0K8N5nBN6Ch+4OvyzKKM zb6e6J5Nzo8e2qgN7cK+3sjs6xI97ccuBHQeOiJAB0bt7d6e5Waq5WQcPNf84/ZN0LXOAxJd 67ze7PIHoGhOyte+7PX+7I1O7bbD7Zrz6lbk6lYO61keMW252Yse29Hu2nHO2u6i4qSMzq9N 3ahN34nO7p59dNf+3oWs7Otl7Az/2h6vgVe95yMvA8xe6N5NkARN8SSP3Q3Q77Ik7uD+Bd+u iJg96xxO0IWcy8Y+zDx/y3Lx8xD98dSe7agtyP9IU+xKf+O5XfEPk9XA3exJr+1Hv/BQr0VP L/VW7+SqvjlJTfN4HgZKXfAFLTp9putKJ9BaT/VD3/PSzeACHeNYb+Q9r0VJz/Xi7fWcIwph P/M3L+vmHgQlH+zaLvWG7vDArvLUnegtf/KDF/USx/Ybr9qBbN2Fj/WOP/GuXfEof/mHn/mc 7/JAEPOxBPbm4O1gfwk4P8b3gO7wbujrPtuxP+oATXtVr+/aPsy/nuO/Xs3p4+t97uxTr/CK T/WoTXsXH+Dtnu+Fj9qRvfeZc/pjIPZdwBZa3vqga+xpj/XCv9tQL/u2T8PZ/eDm0tu77f3Q Tfz7Xjulz3pKnfoQ1AX/ZK8uSCAEhH/4z1/kx07f2w3otg0CBNM0BNIkxNIsREKaDUMQJHzO tR0jqm33VkAfKbUwslw3lK/1Kp1Qr+CPWlQhncufzeHlgsPiMblsPpsLApK6oQA02nEAQBFf 2xgLxcjcG1kNARIJNgTSnCDFGOpk0SQc0ay0uET69CAsLFBhHp10bvos9lytjDaK8ph4MmaG mkaRMgmJeTmg4YYZwN25we2yCQjLPOVp9uUmh6VUUi1qgQb+MdKCaaXErr62ajpnlyqHg9mK l8m1vfXO1amT6PGNxSAxgidVMi9hW5rQIMs3KYECQxsmEtFiUIKEzR4kBJAeWZqV5Mm/SQH/ /4lIuOnhPRoStQgMQ64cyZImSQDrlS6lmmEMisk4diZBlE1gaJKwyQUniygDXyj6JpERDX5C ehS1UhTRjqUGl1IUGvQpuEcDiz4tGpXqUJEjT45hACBAAnRwxJJV80ZByjx6kIFFg5RpSJBz Axap6TOM3YB3i/3dImte3DO2bhVGyctsA5bC1rz8oWcBXC4VuRJmVrQPp6Kh+rGA9fFilByP Fpl2sUgzaCZaXW8evdXRbNCsgS4VIXsLl8OJfwPPM7bsmnRoia9t644B8zPIKrvLE+Y5lz56 clq3Xu1IAubbE3RPgYx7ZfDdbZBHn92dEMrL2Uu3YX48+PHrY47xHf+8up3m12X0NwIfzVVH 4H5h1aeegjklWF18Y7iHHXoNTniehDJod2B+XwB3HGMeCpAcL24ZyIV7/2EIn2TgVZPDCChq As6JtEQYYRHn2SjFCIsQAwlcL0GSB4vGLDhjkff1SAuQStLYR44k6KehlCQxECB+AKY4YGXM lTillK155KWYZkQ5ZjlcQmemmmsGV2ZiVab4H5zNaVlgl8AxY6FkPcBkEp/1sGmmm4ESehKa hSaGFFJpIrrfYYg1iguXkVJaKRmDWorhnb+ZhoBDNHn2Zm57ZVrYo6WimqqGm3jKqKoknfqq rLNGGiutYn6WVJ+F0eTQrSXZ+quwwxKb2KOiHBabrLLiHAvpss9Ci0az0crarLXXYputttty 262334L7LbVdhFuuueeim666Xym7rrvvwhuvu+NWK6+99+J7L70/5Nuvv/9eOy7AAxNcMLL7 qmqwwgvPi7BXDEMc8bEONyCxxRcHTLHGG3PcsccfgxyyyCOTXLLJJ6Ocssors9yyyy/DHLPM M9Ncs80345yzzjvz3LPPPwMdtNBDE110ySEAADs= ------=_NextPart_000_001__32392454_30198,03 Content-Type: image/gif; name="ww.gif" Content-Transfer-Encoding: base64 Content-ID: <3239246312519@ww.gif> R0lGODlhtAASAIAAAP//////zCH5BAUUAAAALAAAAAC0ABIAAAI7hI+py+0Po5y02ouz3rz7 D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1AIAOw== ------=_NextPart_000_001__32392454_30198,03-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 3:52:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by hub.freebsd.org (Postfix) with ESMTP id AF2EF37B400 for ; Fri, 12 Jan 2001 03:52:00 -0800 (PST) Received: from chocolate (1Cust30.tnt1.san-jose2.ca.da.uu.net [63.59.129.30]) by smtppop3pub.verizon.net with SMTP for ; id FAA95764143 Fri, 12 Jan 2001 05:47:29 -0600 (CST) Message-ID: <001201c07c8d$4276f8a0$1e813b3f@netscaler.com> Reply-To: "Soumen Biswas" From: "Soumen Biswas" To: Subject: how to write custom init Date: Fri, 12 Jan 2001 03:46:08 -0800 Organization: Netscaler Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi , What are the points to be observed while writing custom init I am currently doing something like : /* 1. never exit 2. open fd 0,1 & 2 3. link statically */ int main( int argc, char **argv ) { int fd ; char cmd[128] = {0}; fd = open( "/dev/console", O_RDWR ); dup(fd); dup(fd); while( 1 ) { printf( "comm>" ); fflush( stdout ); fgets( cmd, sizeof(cmd ), stdin ); if( memcmp( "init", cmd , 4 ) == 0 ) { close(0); close(1);close(2); execv("/init/sbin", argv ); } if( memcmp( "quit", cmd, 4) == 0 ) reboot( RB_AUTOBOOT ); } /* while */ /* should not reach here */ return 0 ; } Am I missing something ? Thanx & Regards soumen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 3:52:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from henny.webweaving.org (unknown [212.113.16.243]) by hub.freebsd.org (Postfix) with ESMTP id 2FE5037B402 for ; Fri, 12 Jan 2001 03:52:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id LAA03729; Fri, 12 Jan 2001 11:50:27 GMT (envelope-from n_hibma@calcaphon.com) Date: Fri, 12 Jan 2001 11:50:27 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: Jon Simola Cc: FreeBSD Hackers Mailing List Subject: Re: Broken-by-design USB device? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG First of all, you are not wasting my time (I _asked_ for the info, right?). More probably it is the other way around with you having to crash you machine all the time ... :-) Second the info your supplying is good quality. Thanks for that. I'll have a look after the weekend (I'll try and not be a sad person while on holiday) ... oh hell ... I have enough space on my laptop for a usr/src/sys tree of STABLE ... sigh, they'll hate me now... Thanks. Nick On Thu, 11 Jan 2001, Jon Simola wrote: > On Mon, 8 Jan 2001, Nick Hibma wrote: > > > Just as a note on the side, the fact that the attach of the generic > > driver fails (while setting config 0, which is a sort of a soft > > reset) could indicate that there is something fishy going on with > > respect to fetching the report descriptor. I seems to freeze. > > I'd still bet on the hardware being suspect. It's got all the prime labelling > of a quality product: "PS-PC USB Converter" "Full Colors" "Special Design, > Extra Stable & Highly Compatibility" > > > And now back to your scheduled 'panic' demolition: > > > > It still bombs in the middle of DEVOPMETH in: > > > > device_probe_t *m = (device_probe_t *) DEVOPMETH(dev, device_probe); > > > > which is > > > > #define DEVOPMETH(DEV, OP) \ > > ((DEVOPDESC(OP)->offset >= DEVOPS(DEV)->maxoffset) \ > > ? DEVOPDESC(OP)->deflt \ > > : DEVOPS(DEV)->methods[DEVOPDESC(OP)->offset]) > > > > while executing > > > > 56: 3b 02 cmp (%edx),%eax > > > > with edx == dev->ops and eax == device_probe_ops->offset (don't you hate > > i386 assembler syntax?) and edx apparently being 0. > > > > Which as far as I can see is impossible in the subr_bus.c code. So that > > leaves 'memory spamming' as the only option :-( Apart from that, I have > > no clue which driver tries to attach after the > > ugen driver is finished. Because that is the last driver that makes an > > attempt. > > > > Could you do the following: Boot the machine and when it panics type the > > following commands: > > > > show registers > > db> show registers > cs 0x8 > ds 0xc0a20010 > es 0xc0150010 await+0xe4 > fs 0xc0300010 > ss 0x10 > eax 0x9 > ecx 0xc0d32400 > edx 0 > ebx 0x6 > esp 0xc030b920 > ebp 0xc030b920 > esi 0xc0a227b0 > edi 0xc0d32400 > eip 0xc011d58a DEVICE_PROBE+0xe > efl 0x90282 > > > x/x $ecx,0x20 > > db> x/x $ecx,0x20 > 0xc0d32400: 0 0 0 0 > 0xc0d32410: 0 0 0 c0d2ac40 > 0xc0d32420: 0 c0a22040 0 0 > 0xc0d32430: 0 0 0 0 > 0xc0d32440: 0 0 0 0 > 0xc0d32450: 0 0 0 0 > 0xc0d32460: 0 0 0 0 > 0xc0d32470: 0 0 0 0 > > > x/c *($ecx+0x24),0x10 > > db> x/c *($ecx+0x24),0x10 > 0xc0a22040: uhid0\000\000\000\000\000\000\000\000\000\000\000 > > > which will print three things: the contents of all registers (show > > registers), then the 32 longs at address $ecx (x/x $ecx,20), basically > > the contents of the struct device in DEVICE_PROBE, in which the 6th > > element (at +0x14) should be zero. And then the string that is pointed > > to by the nameunit element in the struct device. This last one should > > give us a hint at which device is failing. > > > > Never mind if the last one gives you a page fault. nameunit might be > > zero. > > > > I really am at a loss what this could be :( > > If I'm following you, the info above will just prove that something is too > broken to figure out. If I can find another one of these things I'll just mail > it to you. Other than that, I'll stop wasting your time :) > > Thank you very much for the help. > > --- > Jon Simola | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 3:53:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from henny.webweaving.org (unknown [212.113.16.243]) by hub.freebsd.org (Postfix) with ESMTP id 264AD37B400 for ; Fri, 12 Jan 2001 03:53:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id KAA03680; Fri, 12 Jan 2001 10:41:29 GMT (envelope-from n_hibma@calcaphon.com) Date: Fri, 12 Jan 2001 10:41:29 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: j mckitrick Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: scsi and PS2 mode parallel port programming In-Reply-To: <20010111192445.A5805@dogma.freebsd-uk.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You've been speaking to Nicolas Souchu, right? He has written the current driver and seems to know a fair bit about this topic. Nick > | I'll put this on my pile of things to and dig through the CAM changes to > | find it. There weren't that many in the past year. > > I finally heard from the guy who noticed the change, and asked if he could > help localize it. > > | I don't know much about the PS2 mode nor the parallel port driver > | (allthough I've had my fingers in there, as you know). > > A parallel port in ECP mode should support PS2 without any problem, correct? > And if I recall, it worked under 3.x, so that *should* rule out a buggy BIOS > or hardware anomaly. I *hate* when problems only afflict my machine. > > > jcm > -- > o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o > | ~~~~~~~~~~~~ Jonathon McKitrick ~~~~~~~~~~~~~ | > | "I prefer the term 'Artificial Person' myself." | > o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o > -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 3:54:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id D8DC037B404 for ; Fri, 12 Jan 2001 03:54:35 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0CBsYZ14563; Fri, 12 Jan 2001 12:54:34 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Soumen Biswas" Cc: hackers@FreeBSD.ORG Subject: Re: how to write custom init In-Reply-To: Your message of "Fri, 12 Jan 2001 03:46:08 PST." <001201c07c8d$4276f8a0$1e813b3f@netscaler.com> Date: Fri, 12 Jan 2001 12:54:34 +0100 Message-ID: <14561.979300474@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You may want to check out sysinstalls initialization, it is used to run as /sbin/init when you boot from installation media Poul-Henning In message <001201c07c8d$4276f8a0$1e813b3f@netscaler.com>, "Soumen Biswas" writ es: >Hi , > >What are the points to be observed while writing custom init > >I am currently doing something like : >/* > 1. never exit > 2. open fd 0,1 & 2 > 3. link statically */ > >int main( int argc, char **argv ) >{ >int fd ; >char cmd[128] = {0}; > >fd = open( "/dev/console", O_RDWR ); >dup(fd); >dup(fd); > > while( 1 ) { > printf( "comm>" ); fflush( stdout ); > fgets( cmd, sizeof(cmd ), stdin ); > > if( memcmp( "init", cmd , 4 ) == 0 ) > { close(0); close(1);close(2); execv("/init/sbin", argv ); } > > if( memcmp( "quit", cmd, 4) == 0 ) reboot( RB_AUTOBOOT ); > } /* while */ > >/* should not reach here */ >return 0 ; >} > > >Am I missing something ? > >Thanx & Regards >soumen > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 6: 4: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from henny.webweaving.org (unknown [212.113.16.243]) by hub.freebsd.org (Postfix) with ESMTP id 3E92637B400 for ; Fri, 12 Jan 2001 06:03:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id MAA03889; Fri, 12 Jan 2001 12:18:14 GMT (envelope-from n_hibma@calcaphon.com) Date: Fri, 12 Jan 2001 12:18:14 +0000 (GMT) From: Nick Hibma X-Sender: n_hibma@henny.webweaving.org Reply-To: Nick Hibma To: Jon Simola Cc: FreeBSD Hackers Mailing List Subject: Re: Broken-by-design USB device? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh, and another thing: a kernel panicing is unacceptable, even with bad hardware (except possibly for hardware faults. There is not a lot you can do about those). We've found one non-trivial bug, and I have the feeling that we are looking at another one (possibly a stack or device list corruption bug), which I'm determined to find. If you could send me the make and model (basically all the numbers (including the FCC one) on the label on the device, that would be appreciated. I'll have a look around to see whether I can find another one. We have a PlayStation 2 Developer's Kit in the office, so I'm interested to see the controllers work. We develop a game for PlayStation 2 and Windows (but it runs on FreeBSD as well :-), so being able to use the gamepad converter on FreeBSD would be a laugh. Hm, is it one of these? http://www.psxshop.com/shownews.asp?NewsID=1870 http://www.allusb.com/products/P10227.html http://www.angelcd.com/angelcd/psxusbcon.html http://www.baysoftgames.com/baysoftgames/pssmartjoy2.html http://www.dcs.com.hk/misc/mc_joybox.htm http://www.goldenshop.com.hk/AI-trad/pc/pc_psxn64usb.htm http://www.smartjoy.com/ or was it a do-it-your-self adapater http://www.users.globalnet.co.uk/~snandhe/usbpads.htm There is quite a few of those it seems. Or I have loads of duplicates ... That could be as well :) Cheers, Nick > If I'm following you, the info above will just prove that something is too > broken to figure out. If I can find another one of these things I'll just mail > it to you. Other than that, I'll stop wasting your time :) > > Thank you very much for the help. > > --- > Jon Simola | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > -- Qube Software, Ltd. Private: n_hibma@qubesoft.com n_hibma@webweaving.org n_hibma@freebsd.org http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 6: 9:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.193.193.101]) by hub.freebsd.org (Postfix) with ESMTP id 510B337B400 for ; Fri, 12 Jan 2001 06:09:26 -0800 (PST) Received: from core.is.kiev.ua (p187.is.kiev.ua [62.244.5.187] (may be forged)) by sivka.carrier.kiev.ua (8/Kilkenny_is_better) with ESMTP id QDO06097; Fri, 12 Jan 2001 16:09:17 +0200 (EET) (envelope-from diman@asd-g.com) Received: from ergo.local ([10.203.1.10]) by core.is.kiev.ua (8.11.1/ASDG-2.3-NR) with ESMTP id f0CE9G027238; Fri, 12 Jan 2001 16:09:16 +0200 (EET) (envelope-from diman@asd-g.com) Date: Fri, 12 Jan 2001 16:09:10 +0200 (EET) From: diman X-Sender: diman@portal.none.ua To: Soumen Biswas Cc: hackers@FreeBSD.ORG Subject: Re: how to write custom init In-Reply-To: <001201c07c8d$4276f8a0$1e813b3f@netscaler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 12 Jan 2001, Soumen Biswas wrote: > Hi , > > What are the points to be observed while writing custom init > > I am currently doing something like : > /* > 1. never exit > 2. open fd 0,1 & 2 > 3. link statically */ > > int main( int argc, char **argv ) > { > int fd ; > char cmd[128] = {0}; > > fd = open( "/dev/console", O_RDWR ); > dup(fd); > dup(fd); > > while( 1 ) { > printf( "comm>" ); fflush( stdout ); > fgets( cmd, sizeof(cmd ), stdin ); > > if( memcmp( "init", cmd , 4 ) == 0 ) > { close(0); close(1);close(2); execv("/init/sbin", argv ); } Why /init/sbin ?? > > if( memcmp( "quit", cmd, 4) == 0 ) reboot( RB_AUTOBOOT ); > } /* while */ > > /* should not reach here */ > return 0 ; > } > > > Am I missing something ? > > Thanx & Regards > soumen > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 6:27: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by hub.freebsd.org (Postfix) with ESMTP id A070E37B401 for ; Fri, 12 Jan 2001 06:26:48 -0800 (PST) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [161.44.133.25]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA23071; Fri, 12 Jan 2001 09:26:47 -0500 (EST) Received: from bmcgover-pc.cisco.com (localhost [127.0.0.1]) by bmcgover-pc.cisco.com (8.11.1/8.11.1) with ESMTP id f0CEQll03035; Fri, 12 Jan 2001 09:26:47 -0500 (EST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <200101121426.f0CEQll03035@bmcgover-pc.cisco.com> To: Chris Peiffer Cc: hackers@freebsd.org Subject: Re: Question about 'open' files.... In-reply-to: Your message of "Thu, 11 Jan 2001 14:42:22 PST." <20010111144222.A31382@redlinenetworks.com> Date: Fri, 12 Jan 2001 09:26:47 -0500 From: "Brian J. McGovern" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, I finally found it. One of the function calls I pulled from a library someone else wrote used mkstemps(), and didn't bother to discard the descriptor when it was done. I had originally thought the problem to be in my code, but, it wasn't. I fixed the other code, and the problem was solved. -Brian > > Don't know if this is part of the error checking you glossed over, > but I recently had some extremely weird problems with file IO that went away > when I added the third mode argument that open() needs when it is passed the > O_CREAT flag. > > > On Thu, Jan 11, 2001 at 03:05:29PM -0500, Brian J. McGovern wrote: > > I'm doing some tests for Greg on vinum (trying to crash it), and I've run > > across a problem that is not particular to vinum. I'm hoping someone can > > explain it to me and/or tell me how to work around it. > > > > Using the code fragment (note: The code I'm using is actually more complex , > > and checks for errors in opening, writing, etc, but I'm keeping it basic > > for the discussion): > > > > for (counter = 0; counter < 20000; counter++) > > { > > x = open(filename,O_CREAT | O_WRONLY); > > write(x, buffer, size); > > close(x); > > } > > > > > > I will run anywhere between 1-5 instances of the code loop above. After th ere > > are about 2050 files on the disk (it _appears_ to be variations of 2048, p lus > > files already on the disk, . and .., etc.), the programs crash with "too m any > > open files". > > > > The problem, in my mind, is that the files are _closed_ (not open). I'm cu rious > if this is some type of accounting error on a per-login basis, or whether > > there is some type of garbage collection not happening. Typically, after a ll > > of the applications die with this error, if I immediately restart, they > > die pretty quickly. If I wait like 10+ seconds, they can run again, and > > generate the 2048+/- files again before dying, which leads me to believe i ts > > something to do with per-user accounting/garbage collection. > > > > I would be curious to understand this, and its impact, as this does not > > appear to be 'good' (tm) behavior, particularly if one wishes to run a pro gram > > that opens and closes a lot of small files. > > > > I welcome any thoughts. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 6:46:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.193.193.101]) by hub.freebsd.org (Postfix) with ESMTP id 6AC3037B400 for ; Fri, 12 Jan 2001 06:46:09 -0800 (PST) Received: from core.is.kiev.ua (p187.is.kiev.ua [62.244.5.187] (may be forged)) by sivka.carrier.kiev.ua (8/Kilkenny_is_better) with ESMTP id QRQ12440; Fri, 12 Jan 2001 16:45:48 +0200 (EET) (envelope-from diman@asd-g.com) Received: from ergo.local ([10.203.1.10]) by core.is.kiev.ua (8.11.1/ASDG-2.3-NR) with ESMTP id f0CEjl027391; Fri, 12 Jan 2001 16:45:48 +0200 (EET) (envelope-from diman@asd-g.com) Date: Fri, 12 Jan 2001 16:45:41 +0200 (EET) From: diman X-Sender: diman@portal.none.ua To: Xavier Galleri Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis In-Reply-To: <3A5ED923.3010207@enition.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 12 Jan 2001, Xavier Galleri wrote: > OK, let's make it a bit clearer ! ... [skiped] > > Now, if you've read my first mail, I was actually asking for help onhow > to dump the stack of an interrupted process with GDB when the > kernelcrash occurs in the context of an isr. Actually, I would like to > know how I could dump the stack of *any* process at the time of the > crash. This way, I would be able to see where my user-land daemon was > lying in the kernel when the interrupt occurs. To dump stack of *any* (all) process you may write a little kld wich will: 1) go through a process list, 2) get tf_eip, tf_esp, tf_ebp of a process 3) get p->p_vmspace 4) read process stack frames and all you need by manually written routine based on procfs_rwmem and old good 'pread' (which dosn't work now) Another way is to go through proc list and coredump all the processes for future manual analisys. I like such way. Can anybody point me to some difficults wich can appear while implementing this? > [skiped] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 6:55:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 5BAE037B400 for ; Fri, 12 Jan 2001 06:54:57 -0800 (PST) Received: by smtp.nettoll.com; Fri, 12 Jan 2001 15:51:21 +0100 (MET) Message-ID: <3A5F1ACF.6020909@enition.com> Date: Fri, 12 Jan 2001 15:55:11 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis References: Content-Type: multipart/alternative; boundary="------------000202050404040402080905" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --------------000202050404040402080905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thank you for your answer, It's difficult to believe that nothing more intuitive and immediate can be done to get the kernel stack of any process from a GDB session on a kernel crash dump. Does it mean that this is something that nobody ever need until now ? Also, is there a mean to ask GDB to dump the kernel stack of the 'curproc' that has been interrupted at the time of kernel panic ? Regards, Xavier diman wrote: > > On Fri, 12 Jan 2001, Xavier Galleri wrote: > >> OK, let's make it a bit clearer ! > > .... > [skiped] > >> Now, if you've read my first mail, I was actually asking for help onhow >> to dump the stack of an interrupted process with GDB when the >> kernelcrash occurs in the context of an isr. Actually, I would like to >> know how I could dump the stack of *any* process at the time of the >> crash. This way, I would be able to see where my user-land daemon was >> lying in the kernel when the interrupt occurs. > > > > To dump stack of *any* (all) process you may write a little kld > wich will: > > 1) go through a process list, > 2) get tf_eip, tf_esp, tf_ebp of a process > 3) get p->p_vmspace > 4) read process stack frames and all you need by manually > written routine based on procfs_rwmem and old good 'pread' > (which dosn't work now) > > Another way is to go through proc list and coredump all the > processes for future manual analisys. > > I like such way. > > Can anybody point me to some difficults wich can appear while > implementing this? > > [skiped] > > > > --------------000202050404040402080905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thank you for your answer,

It's difficult to believe that nothing more intuitive and immediate can be done to get the kernel stack of any process from a GDB session on a kernel crash dump. Does it mean that this is something that nobody ever need until now ?

Also, is there a mean to ask GDB to dump the kernel stack of the 'curproc' that has been interrupted at the time of kernel panic ?

Regards,

Xavier

diman wrote:

On Fri, 12 Jan 2001, Xavier Galleri wrote:

OK, let's make it a bit clearer !
....
[skiped]
Now, if you've read my first mail, I was actually asking for help onhow 
to dump the stack of an interrupted process with GDB when the 
kernelcrash occurs in the context of an isr. Actually, I would like to 
know how I could dump the stack of *any* process at the time of the 
crash. This way, I would be able to see where my user-land daemon was 
lying in the kernel when the interrupt occurs.


To dump stack of *any* (all) process you may write a little kld 
wich will:

1) go through a process list,
2) get tf_eip, tf_esp, tf_ebp of a process
3) get p->p_vmspace 
4) read process stack frames and all you need by manually
   written routine based on procfs_rwmem and old good 'pread'
   (which dosn't work now)

Another way is to go through proc list and coredump all the
processes for future manual analisys.

I like such way. 

Can anybody point me to some difficults wich can appear while
implementing this?

[skiped]





--------------000202050404040402080905-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 7:26:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by hub.freebsd.org (Postfix) with ESMTP id BD64F37B400 for ; Fri, 12 Jan 2001 07:26:39 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id KAA06009 for ; Fri, 12 Jan 2001 10:26:37 -0500 (EST) Received: from mailsrv2.mitre.org (mailsrv2.mitre.org [129.83.221.17]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id KAA17374 for ; Fri, 12 Jan 2001 10:26:36 -0500 (EST) Received: from mitre.org ([128.29.145.140]) by mailsrv2.mitre.org (Netscape Messaging Server 4.15) with ESMTP id G722WB00.1HQ; Fri, 12 Jan 2001 10:26:35 -0500 Message-ID: <3A5F219A.A1E1D06B@mitre.org> Date: Fri, 12 Jan 2001 10:24:10 -0500 From: "Andresen,Jason R." X-Mailer: Mozilla 4.75 [en]C-20000818M (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Willcox Cc: Alfred Perlstein , hackers list Subject: Re: FreeBSD boot manager, where is latest version? References: <20010111135851.A16078@luke.immure.com> <20010111120332.D7240@fw.wintelcom.net> <3A5E1A3E.5A17AF9E@mitre.org> <20010111160653.A16818@luke.immure.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bob Willcox wrote: > > Well, ob-bs didn't work either. I went to the referenced site for > XOSL and it certainly looked interesting...but was way more than I was > looking for at this time (I was happy with the default FreeBSD installed > boot manager before W98 trashed it and I certainly didn't want to create > partion for it...which seemed to be required). On the XOSL web site I > found a refernence to the "Ranish Partition Manager" which I wound up > installing and it worked for me. :-) Good to hear. BTW, xosl will also install on your Win98 partition, so you don't have to make a special partition just for it. -- _ _ _ ___ ____ ___ ______________________________________ / \/ \ | ||_ _|| _ \|___| | Jason Andresen -- jandrese@mitre.org / /\/\ \ | | | | | |/ /|_|_ | Views expressed may not reflect those /_/ \_\|_| |_| |_|\_\|___| | of the Mitre Corporation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 8:14:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 78C6B37B401 for ; Fri, 12 Jan 2001 08:14:25 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0CGEM924783; Fri, 12 Jan 2001 08:14:22 -0800 (PST) Date: Fri, 12 Jan 2001 08:14:22 -0800 From: Alfred Perlstein To: "W.H.Scholten" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff Message-ID: <20010112081422.U7240@fw.wintelcom.net> References: <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5EE6B1.41C67EA6@xs4all.nl>; from whs@xs4all.nl on Fri, Jan 12, 2001 at 11:12:49AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * W.H.Scholten [010112 03:13] wrote: > Alfred Perlstein wrote: > > > > 1. a pppd patch which sends the pppd messages to stderr. > > > > not sure about this one, I would open a PR about it. > > I'm not sure either :) Maybe everyone else uses gui frontend which reads > pppd's syslog messages or starts pppd as root? Open a PR, someone will get to it. :) > > > Ok, I may be misreading this, but this doesn't fix it really: > > > > mkdir /tmp/a/b/c/d/e/f/s > > > > perhaps if you called "stat" in a loop to on each patch component > > until it failed you'd be able to trim off the directory paths > > one by one. > > I don't think it's useful for mkdir to check which exact part of the > path of the parent directory does exist. The fix just makes mkdir say > the parent directory doesn't exist (instead of the previously wierd "the > dir you wanted me to create doesn't exist" type of error message :). Good point, I'll commit the patch shortly. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 9:28:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 848AF37B402; Fri, 12 Jan 2001 09:28:19 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0CHSHs81776; Fri, 12 Jan 2001 10:28:17 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101121728.f0CHSHs81776@harmony.village.org> To: Robert Watson Subject: Re: Setting default hostname to localhost Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 10 Jan 2001 21:23:13 EST." References: Date: Fri, 12 Jan 2001 10:28:17 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Robert Watson writes: : Unless there are some really good reasons : not to (which there may be), I'd like to commit changes to -CURRENT's : /etc/default/rc.conf to change the default hostname to "localhost". We have localhost.com as one of our domains here in the Village. So long as this change doesn't generate traffic to us in any way, shape, or form, I'd say go for it. Sniff your network for traffic to/from 204.144.255.150 to see if it does or not. There have been bugs in the past that would cause this to be the case. There have also been bugs in the past where machines (not necessarily FreeBSD machines) whose hostname was foo.com (for all values of foo) would try to use localhost.com as the loopback address. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 9:44: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 8817337B401; Fri, 12 Jan 2001 09:43:47 -0800 (PST) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.1+3.4W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id f0CHhek18470; Sat, 13 Jan 2001 02:43:40 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: current@freebsd.org, hackers@freebsd.org Subject: Re: CFR: Generalized power-management interface In-Reply-To: <20001231180216L.iwasaki@jp.FreeBSD.org> References: <20001231180216L.iwasaki@jp.FreeBSD.org> 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: <20010113024339Z.iwasaki@jp.FreeBSD.org> Date: Sat, 13 Jan 2001 02:43:39 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz http://people.freebsd.org/~iwasaki/acpi/wmpm-20010113.tar.gz Note that ioctl number for power device have been changed, so rebuilding your kernel and recompiling lib/libpower/ and usr.sbin/power/ are needed. Added API is; u_int power_get_pm_type(void); I'll get device major number for /dev/power and commit them within a few days if no objection. Thanks > I've created new common framework on generalized power-management > interface for userland utilities. > > http://people.freebsd.org/~iwasaki/acpi/power-20001229.tar.gz > > This provides some PM APIs to APM applications, such as wmapm, so that > these applications can be ported smoothly to use ACPI (power > management portion). Currently following APIs are implemented; > > int power_get_syspm_info(struct power_syspm_info *); > int power_get_batt_info(u_int, struct power_batt_info *); > int power_standby(void); > int power_suspend(void); > int power_hibernate(void); > > And PM event notification mechanism is suggested to be implemented so far. > > Sample application is included in usr.sbin/power/ which is very similar > to apm(8) but supports ACPI as well. > > usr.sbin/acpi/acpibatt/ is for displaying acpi_cmbat (ACPI Control > Method Battery), can be used to verify that generalized > power-management interface is working correctly. > Note that many ACPI BIOS give us unknown battery remaining time when > ac-line is plugged in. MIB 'hw.battery.full_charge_time' can be used to > specify the full charged remaining time of batteries in minutes, like > sysctl -w hw.battery.full_charge_time=60,60 > for multiple number of batteries, or > sysctl -w hw.battery.full_charge_time=120 > for a battery installed. > > To test them, /dev/power is required as a device control file. > > % ls -l /dev/power > crw-r--r-- 1 root wheel 210, 0 12/19 04:51 /dev/power > > I'll commit them at sometime early in coming century. > > Any comments would be appreciated. Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 9:55: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id 5DC1137B400 for ; Fri, 12 Jan 2001 09:54:47 -0800 (PST) Received: (qmail 1669 invoked by uid 3001); 12 Jan 2001 17:54:46 -0000 Received: from natto.numachi.com (198.175.254.216) by numachi.numachi.com with SMTP; 12 Jan 2001 17:54:46 -0000 Received: (qmail 94198 invoked by uid 1001); 12 Jan 2001 17:54:46 -0000 Date: Fri, 12 Jan 2001 12:54:46 -0500 From: Brian Reichert To: freebsd-hackers@freebsd.org Subject: wicontrol: password <-> hex digits Message-ID: <20010112125446.C93738@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to debug my interactions with a WAP. Could someone quickly explain the algorithm in wicontrol for converting a text key to a hex key, and vice-versa? Yes, I could go scrounge though the source, but I have my hands full... And, while I'm at it, how does 'wicontrol -i wi0' know when to dump out the keys in text vs hex? -- Brian 'you Bastard' Reichert 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 10: 2:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 9C15837B400 for ; Fri, 12 Jan 2001 10:02:18 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0CI1h133219; Fri, 12 Jan 2001 10:01:43 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <00a701c07c4c$61db61e0$edcf1f40@pdq.net> Date: Fri, 12 Jan 2001 10:02:23 -0800 (PST) From: John Baldwin To: Jason Smethers Subject: RE: Mutexs: checking for initialization Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12-Jan-01 Jason Smethers wrote: > I've got some kernel code that passes untrusted data containing mutic. > I'd like to be able to check if the mutic have been initialized and > return an error if they haven't. As of now I don't see a standard way > of checking for initialization. I'd like to do it this way to abstract > out the way things are locked, and in FreeBSD's case the mutex's > description. > > I known I can do this other ways, but it'd be nice if there was a > standard way to check for this. Just a thought, or else I'd have a > diff =O. Umm, well, you could write a function that walked the all_mtx list and checked if the mutex was in that list. However, I think that you are using the wrong tool for your problem here. :) I'm not sure validating mutexes is the way to validate all the data you are receiving. > Thanks > - Jason -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 10:11:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 8759037B402 for ; Fri, 12 Jan 2001 10:10:58 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0CI9q133471; Fri, 12 Jan 2001 10:09:52 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010113024339Z.iwasaki@jp.FreeBSD.org> Date: Fri, 12 Jan 2001 10:10:32 -0800 (PST) From: John Baldwin To: Mitsuru IWASAKI Subject: Re: CFR: Generalized power-management interface Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12-Jan-01 Mitsuru IWASAKI wrote: > Hi, > > I've update the patch based on some comments so far and added wmpm > (actually ACPI support for wmapm which is utility for WindowMaker) > ports files as a example. > > http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz > http://people.freebsd.org/~iwasaki/acpi/wmpm-20010113.tar.gz > > Note that ioctl number for power device have been changed, so rebuilding > your kernel and recompiling lib/libpower/ and usr.sbin/power/ are needed. > Added API is; > > u_int power_get_pm_type(void); > > I'll get device major number for /dev/power and commit them within a > few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( > Thanks -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 10:34:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 1451237B401 for ; Fri, 12 Jan 2001 10:34:29 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f0CIYLe32169; Fri, 12 Jan 2001 10:34:21 -0800 Date: Fri, 12 Jan 2001 10:34:21 -0800 From: Brooks Davis To: Brian Reichert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: wicontrol: password <-> hex digits Message-ID: <20010112103421.C20792@Odin.AC.HMC.Edu> References: <20010112125446.C93738@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010112125446.C93738@numachi.com>; from reichert@numachi.com on Fri, Jan 12, 2001 at 12:54:46PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 12, 2001 at 12:54:46PM -0500, Brian Reichert wrote: > I'm trying to debug my interactions with a WAP. Could someone > quickly explain the algorithm in wicontrol for converting a text > key to a hex key, and vice-versa? Yes, I could go scrounge though > the source, but I have my hands full... The hex version is just the literal ASCII string. IMNSHO it's a really bad idea to generate a key by converting an ASCII string as you limit your key space tremendously by doing so. If you really want to do this you can use: echo "password" | hexdump -C Just ignore the trailing 0x0a. My recommended key generation method is actually: dd count=13 bs=1 if=/dev/random of=/dev/stdout | hexdump -C > And, while I'm at it, how does 'wicontrol -i wi0' know when to dump > out the keys in text vs hex? It checks to see if all the characters are printable with isprint() and if they are it prints the string in ASCII, otherwise it prints it out in hex. I implemented this feature because it pretty much does what the user would expect, but it's pretty stupid because it encourages people to use ASCII keys. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 10:40:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 5373837B400; Fri, 12 Jan 2001 10:40:26 -0800 (PST) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.1+3.4W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id f0CIeOk31978; Sat, 13 Jan 2001 03:40:24 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: jhb@FreeBSD.org Cc: iwasaki@jp.FreeBSD.org, hackers@FreeBSD.org Subject: Re: CFR: Generalized power-management interface In-Reply-To: References: <20010113024339Z.iwasaki@jp.FreeBSD.org> 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: <20010113034023K.iwasaki@jp.FreeBSD.org> Date: Sat, 13 Jan 2001 03:40:23 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > > I'll get device major number for /dev/power and commit them within a > > few days if no objection. > > One thing that I was talking about with Mike Smith is that perhaps instead of > having a /dev/power just for power management stuff we should be a bit more > generic and have a /dev/health used for anything related to the machine's > "health"? This could include power management, thermal zones, etc. BTW, the I'm not sure if /dev/health is better but I think having common API for the machine's health is good thing. How about having /dev/power, /dev/thermal or whatever related with machine's health as abstracted layers, and creating API libraries for each subsystems like libpower, then providing libhealth as full-set API for the applications? > battery status doesn't work on my laptop unfortunately, but that is because I > have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Is that related with embedded controller too? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 10:44: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from garlic.cgf.net (adsl-209-76-108-196.dsl.snfc21.pacbell.net [209.76.108.196]) by hub.freebsd.org (Postfix) with ESMTP id 0D4C037B400 for ; Fri, 12 Jan 2001 10:43:46 -0800 (PST) Received: from cgf.net (garlic.themancini.net [192.168.26.7]) by garlic.cgf.net (8.9.3/8.9.3) with ESMTP id KAA19006 for ; Fri, 12 Jan 2001 10:45:10 -0800 (PST) (envelope-from tomb@cgf.net) Message-ID: <3A5EC113.B903E2AF@cgf.net> Date: Fri, 12 Jan 2001 00:32:19 -0800 From: tomb Reply-To: tomb@cgf.net X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Kernel time drifting -0.3% to -50% from H/W clock. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG HI, I sent a message about this to questions to no avail. So sorry if this is an inappropreate place but here is the problem. Dec 3 Upgared machine to FreeBSD 4.2 (i386) Dec 6 - Jan 2 away from machine. I logged in to find that the value of date was way out (-6 Days), at this point the machie was not running any type of time peering it was essentually stand-alone. I corrected the time manually using date. The next day I noticed the time was wrong again, and decided to run ntp to track the time on our master. It tried very hard to keep time but finally gave up and syslogged me that a manual time change would be necessary. This moring I find that the drift is -50% . I don't know much about how kernel time relates to bios time but I guess that there's a pashe locked loop in the software that is not getting feedback from the HW clock, but I'm just guessing. Can anybody explain what is happening? Thanks. Tom Brown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 11: 1:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D063737B401 for ; Fri, 12 Jan 2001 11:01:36 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0CJ0T134955; Fri, 12 Jan 2001 11:00:29 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010113034023K.iwasaki@jp.FreeBSD.org> Date: Fri, 12 Jan 2001 11:01:10 -0800 (PST) From: John Baldwin To: Mitsuru IWASAKI Subject: Re: CFR: Generalized power-management interface Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12-Jan-01 Mitsuru IWASAKI wrote: > Hi, > >> > I'll get device major number for /dev/power and commit them within a >> > few days if no objection. >> >> One thing that I was talking about with Mike Smith is that perhaps instead >> of >> having a /dev/power just for power management stuff we should be a bit more >> generic and have a /dev/health used for anything related to the machine's >> "health"? This could include power management, thermal zones, etc. BTW, >> the > > I'm not sure if /dev/health is better but I think having common API > for the machine's health is good thing. How about having /dev/power, > /dev/thermal or whatever related with machine's health as abstracted > layers, and creating API libraries for each subsystems like libpower, > then providing libhealth as full-set API for the applications? It was just an idea to think about is all. :) However you do it will probably be fine. I'm not really working on this code enough to make too many suggestions right now. :) >> battery status doesn't work on my laptop unfortunately, but that is because >> I >> have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. >> :( > > Is that related with embedded controller too? Yes. I need to figure out how ACPI_DEBUG works so I can dimp debugging info and find out where it hangs when I don't disable the SIO_ controller. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 11: 3:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id B423237B401 for ; Fri, 12 Jan 2001 11:03:28 -0800 (PST) Received: (qmail 2560 invoked by uid 3001); 12 Jan 2001 19:03:26 -0000 Received: from natto.numachi.com (198.175.254.216) by numachi.numachi.com with SMTP; 12 Jan 2001 19:03:26 -0000 Received: (qmail 94888 invoked by uid 1001); 12 Jan 2001 19:03:26 -0000 Date: Fri, 12 Jan 2001 14:03:26 -0500 From: Brian Reichert To: Brooks Davis Cc: Brian Reichert , freebsd-hackers@FreeBSD.ORG Subject: Re: wicontrol: password <-> hex digits Message-ID: <20010112140326.D93738@numachi.com> References: <20010112125446.C93738@numachi.com> <20010112103421.C20792@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010112103421.C20792@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Fri, Jan 12, 2001 at 10:34:21AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 12, 2001 at 10:34:21AM -0800, Brooks Davis wrote: > It checks to see if all the characters are printable with isprint() and > if they are it prints the string in ASCII, otherwise it prints it out in > hex. I implemented this feature because it pretty much does what the > user would expect, but it's pretty stupid because it encourages people > to use ASCII keys. Thanks for the answers, and the advice. My only comment WRT hex keys: there's a greater chance of transcription error, which can be a hassle in provisioning. But I certianly agree with you WRT the keyspace issues... > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. -- Brian 'you Bastard' Reichert 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 11: 5:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B6CD037B404; Fri, 12 Jan 2001 11:05:02 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA27974; Fri, 12 Jan 2001 11:05:03 -0800 Date: Fri, 12 Jan 2001 11:04:59 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: Mitsuru IWASAKI , hackers@FreeBSD.ORG Subject: Re: CFR: Generalized power-management interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If we're going to talk about 'health' for a machine and it's components, it should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). > > On 12-Jan-01 Mitsuru IWASAKI wrote: > > Hi, > > > >> > I'll get device major number for /dev/power and commit them within a > >> > few days if no objection. > >> > >> One thing that I was talking about with Mike Smith is that perhaps instead > >> of > >> having a /dev/power just for power management stuff we should be a bit more > >> generic and have a /dev/health used for anything related to the machine's > >> "health"? This could include power management, thermal zones, etc. BTW, > >> the > > > > I'm not sure if /dev/health is better but I think having common API > > for the machine's health is good thing. How about having /dev/power, > > /dev/thermal or whatever related with machine's health as abstracted > > layers, and creating API libraries for each subsystems like libpower, > > then providing libhealth as full-set API for the applications? > > It was just an idea to think about is all. :) However you do it will probably > be fine. I'm not really working on this code enough to make too many > suggestions right now. :) > > >> battery status doesn't work on my laptop unfortunately, but that is because > >> I > >> have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. > >> :( > > > > Is that related with embedded controller too? > > Yes. I need to figure out how ACPI_DEBUG works so I can dimp debugging info > and find out where it hangs when I don't disable the SIO_ controller. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 11:39:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail2.iadfw.net (mail2.iadfw.net [206.66.12.234]) by hub.freebsd.org (Postfix) with SMTP id 2D00C37B401; Fri, 12 Jan 2001 11:39:02 -0800 (PST) Received: from Jason from [64.31.207.237] by mail2.iadfw.net (/\##/\ Smail3.1.30.16 #30.27) with smtp for sender: id ; Fri, 12 Jan 2001 13:39:05 -0600 (CST) Message-ID: <006601c07cd0$1063ed80$edcf1f40@pdq.net> From: "Jason Smethers" To: "John Baldwin" Cc: References: Subject: Re: Mutexs: checking for initialization Date: Fri, 12 Jan 2001 13:44:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: "John Baldwin" > Umm, well, you could write a function that walked the all_mtx list and checked > if the mutex was in that list. However, I think that you are using the wrong > tool for your problem here. :) I'm not sure validating mutexes is the way to > validate all the data you are receiving. We'll, I'm not validating ALL the data with the mutic, just the mutic itself. Anyway, after sleep and a shower I come back and have a 'Duh' moment. What am I trying to do and what am I doing? If I can't trust the data being passed, how can I trust the memory it's in. Time to change the model to a one time memory copy hit. =) Thanks - Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 11:45:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 3B42A37B400; Fri, 12 Jan 2001 11:45:08 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id LAA91666; Fri, 12 Jan 2001 11:45:07 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id LAA01072; Fri, 12 Jan 2001 11:45:07 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101121945.LAA01072@curve.dellroad.org> Subject: Re: Setting default hostname to localhost In-Reply-To: <200101121728.f0CHSHs81776@harmony.village.org> "from Warner Losh at Jan 12, 2001 10:28:17 am" To: Warner Losh Date: Fri, 12 Jan 2001 11:45:07 -0800 (PST) Cc: Robert Watson , freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > : Unless there are some really good reasons > : not to (which there may be), I'd like to commit changes to -CURRENT's > : /etc/default/rc.conf to change the default hostname to "localhost". > > We have localhost.com as one of our domains here in the Village. So > long as this change doesn't generate traffic to us in any way, shape, > or form, I'd say go for it. Sniff your network for traffic to/from > 204.144.255.150 to see if it does or not. > > There have been bugs in the past that would cause this to be the > case. There have also been bugs in the past where machines (not > necessarily FreeBSD machines) whose hostname was foo.com (for all > values of foo) would try to use localhost.com as the loopback > address. There is an RFC that specifies a "private use" top level domain, analogous to 192.168.0.0/16, 10.0.0.0/8, etc. The domain is ".local" so any default ending in ".local" should not conflict. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 11:49:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 934FA37B400 for ; Fri, 12 Jan 2001 11:49:01 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f0CJmxH22807; Fri, 12 Jan 2001 13:48:59 -0600 (CST) (envelope-from dan) Date: Fri, 12 Jan 2001 13:48:58 -0600 From: Dan Nelson To: tomb Cc: hackers@FreeBSD.ORG Subject: Re: Kernel time drifting -0.3% to -50% from H/W clock. Message-ID: <20010112134858.A15232@dan.emsphone.com> References: <3A5EC113.B903E2AF@cgf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: <3A5EC113.B903E2AF@cgf.net>; from "tomb" on Fri Jan 12 00:32:19 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jan 12), tomb said: > The next day I noticed the time was wrong again, and decided to run > ntp to track the time on our master. It tried very hard to keep time > but finally gave up and syslogged me that a manual time change would > be necessary. > > This moring I find that the drift is -50% . > > I don't know much about how kernel time relates to bios time but I > guess that there's a pashe locked loop in the software that is not > getting feedback from the HW clock, but I'm just guessing. > > Can anybody explain what is happening? Try adding the following kernel options and rebuilding: options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION That should help some, if the clock the kernel decided to pick really drifts that badly. You can see which clock the kernel is using with "sysctl kern.timecounter.hardware", and view the current timing values for each clock with "sysctl machdep | grep freq". -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 11:56:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B099437B402; Fri, 12 Jan 2001 11:56:17 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0CJuEs82793; Fri, 12 Jan 2001 12:56:14 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101121956.f0CJuEs82793@harmony.village.org> To: Archie Cobbs Subject: Re: Setting default hostname to localhost Cc: Robert Watson , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 12 Jan 2001 11:45:07 PST." <200101121945.LAA01072@curve.dellroad.org> References: <200101121945.LAA01072@curve.dellroad.org> Date: Fri, 12 Jan 2001 12:56:14 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101121945.LAA01072@curve.dellroad.org> Archie Cobbs writes: : There is an RFC that specifies a "private use" top level domain, : analogous to 192.168.0.0/16, 10.0.0.0/8, etc. : : The domain is ".local" so any default ending in ".local" should : not conflict. RFC 2606 states: To safely satisfy these needs, four domain names are reserved as listed and described below. .test .example .invalid .localhost ".test" is recommended for use in testing of current or new DNS related code. ".example" is recommended for use in documentation or as examples. ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. But RFC 2964 and 2965 (which relate to http things) both say The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. So it looks like the more porper choice is 'host.invalid' rather than 'localhost'. I think that would, in the end, cause fewer problems. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 11:56:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.hiwaay.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 3D0D037B699 for ; Fri, 12 Jan 2001 11:56:21 -0800 (PST) Received: from bonsai.knology.net (user-24-214-88-8.knology.net [24.214.88.8]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id f0CJuBo06810; Fri, 12 Jan 2001 13:56:14 -0600 (CST) Received: (from steve@localhost) by bonsai.knology.net (8.11.1/8.11.1) id f0CJu5o26085; Fri, 12 Jan 2001 13:56:05 -0600 (CST) (envelope-from steve) Date: Fri, 12 Jan 2001 13:56:05 -0600 From: Steve Price To: Dan Nelson Cc: hackers@FreeBSD.ORG Subject: Re: synchronous IO Message-ID: <20010112135605.J36120@bonsai.knology.net> References: <20010111202855.Y36120@bonsai.knology.net> <20010111214449.A26983@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010111214449.A26983@dan.emsphone.com>; from dnelson@emsphone.com on Thu, Jan 11, 2001 at 09:44:49PM -0600 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 11, 2001 at 09:44:49PM -0600, Dan Nelson wrote: # I don't think you really mean synchronous IO; All you need is some # buffering. If the toggling you're talking about is direct wave # generation (i.e. you have to do something for each byte in the sample), # your time restrictions are probably tight enough that you'll want # multiple buffers, filled by one process and drained by another one. # You mmap() some shared buffer space, fork your process into two, and # send buffer status messages over a pipe connecting the two. Process 1: # read a block of data from input file, fill an empty buffer, send the # buffer address over the pipe, repeat. Process 2: read a full buffer, # toggle buffer through the serial port, send the address of the buffer # back over the pipe for reuse. This ensures that the only operations P2 # does apart from waveform generation are a select, two reads, and a # write every sizeof(buffer). You could even toss the pipe and use # another bit of shared memory to keep track of buffer usage. # # If, on the other hand, the toggling merely tells the controller to play # a sample that you have already stored in the device's memory, then you # presumably have looser timing requirements and can get away with having # one process drain and fill the buffers as appropriate. This is similar # to how the kernel's soundcard drivers work; most soundcards read system # memory directly and signal the kernel via interrupts when its buffers # are getting empty. Thanks for the info. I don't think I was very clear in my first explanation. I have an RF transmitter that I control via a serial port on a FreeBSD box. I also have a sound card in that same computer connected to the transmitter. I'm sending commands to the transmitter in a sequence that looks like this. DIGITAL_BURST (commands sent via serial port) AUDIO (.wav files being played by the computer) TEXT_ECHO (text to display on the radio) I use DTR and RTS to control a set of relays in the transmitter to select which source of data to broadcast to the radios. I set the bits appropriately and I send the digital burst via the serial port. I need to make sure all of these bits have made it to the controller before I reset the bits to tell the transmitter to start sending the WAV file I'm playing on the computer. In the same respect I need to know when all of the sound data is completely sent so that I can put the controller back in serial IO mode and transmit the text to display on the radio. I don't have control over the message format nor can I change anything inside the transmitter. I only have control over the software that runs on the computer. This is why I believe I need something like synchronous IO. How would I otherwise know when all the data from one phase has been transmitted and I can go on to the next step? Currently the code is riddled with a bunch of nanosleeps that do their best to estimate how long it takes to transmit the data. This is kludgy at best and not very accurate because it depends on the load of the box and a bunch of other factors. I end up having to pad the times a bunch to try and cover all the possible things that could cause my rough-order transmission times to be missed. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 12: 4:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (dhcp45-24.dis.org [216.240.45.24]) by hub.freebsd.org (Postfix) with ESMTP id 786DC37B401 for ; Fri, 12 Jan 2001 12:04:33 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f0CKIKQ00952; Fri, 12 Jan 2001 12:18:20 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200101122018.f0CKIKQ00952@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Steve Price Cc: Dan Nelson , hackers@FreeBSD.ORG Subject: Re: synchronous IO In-reply-to: Your message of "Fri, 12 Jan 2001 13:56:05 CST." <20010112135605.J36120@bonsai.knology.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Jan 2001 12:18:20 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Thanks for the info. I don't think I was very clear in my first > explanation. I have an RF transmitter that I control via a serial > port on a FreeBSD box. I also have a sound card in that same > computer connected to the transmitter. I'm sending commands to > the transmitter in a sequence that looks like this. > > DIGITAL_BURST (commands sent via serial port) > AUDIO (.wav files being played by the computer) > TEXT_ECHO (text to display on the radio) > > I use DTR and RTS to control a set of relays in the transmitter to > select which source of data to broadcast to the radios. I set the > bits appropriately and I send the digital burst via the serial port. > I need to make sure all of these bits have made it to the controller > before I reset the bits to tell the transmitter to start sending > the WAV file I'm playing on the computer. In the same respect I > need to know when all of the sound data is completely sent so that > I can put the controller back in serial IO mode and transmit the > text to display on the radio. You can ensure the serial output is drained with tcdrain(). There's is probably an interface for checking the status of the sound buffer. Looking in sys/soundcard.h, I would suggest calling SNDCTL_DSP_GETOSPACE while the card is idle to determine the total amount of output space, then poll while you're waiting for the sample play to end until it returns to the "empty" level. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 12:20:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.hiwaay.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 08F8B37B402; Fri, 12 Jan 2001 12:20:04 -0800 (PST) Received: from bonsai.knology.net (user-24-214-88-8.knology.net [24.214.88.8]) by mail.hiwaay.net (8.11.0/8.11.0) with ESMTP id f0CKK1o04058; Fri, 12 Jan 2001 14:20:01 -0600 (CST) Received: (from steve@localhost) by bonsai.knology.net (8.11.1/8.11.1) id f0CKK0S26468; Fri, 12 Jan 2001 14:20:00 -0600 (CST) (envelope-from steve) Date: Fri, 12 Jan 2001 14:20:00 -0600 From: Steve Price To: Mike Smith Cc: Dan Nelson , hackers@FreeBSD.ORG Subject: Re: synchronous IO Message-ID: <20010112142000.K36120@bonsai.knology.net> References: <20010112135605.J36120@bonsai.knology.net> <200101122018.f0CKIKQ00952@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101122018.f0CKIKQ00952@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Fri, Jan 12, 2001 at 12:18:20PM -0800 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 12, 2001 at 12:18:20PM -0800, Mike Smith wrote: # # You can ensure the serial output is drained with tcdrain(). There's is # probably an interface for checking the status of the sound buffer. Yes, this appears to have done the trick. # Looking in sys/soundcard.h, I would suggest calling SNDCTL_DSP_GETOSPACE # while the card is idle to determine the total amount of output space, # then poll while you're waiting for the sample play to end until it # returns to the "empty" level. I'll give this one a shot shortly. Thanks Mike. :) -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 16: 0:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tj2.demon.co.uk (tj2.demon.co.uk [158.152.29.119]) by hub.freebsd.org (Postfix) with SMTP id 6A66837B402 for ; Fri, 12 Jan 2001 16:00:38 -0800 (PST) Received: from tj2.demon.co.uk, ID 3A5F4C98-DCB9, Fri, 12 Jan 2001 18:27:36 UTC To: freebsd-hackers@freebsd.org From: 207.100@tj2.demon.co.uk X-Date: Fri, 12 Jan 2001 18:27:35 +0000 Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <3A5F4C98.DCB9@tj2.demon.co.uk> Date: Fri, 12 Jan 2001 18:27:36 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FWIW, I'm against changing cron. Ted Faber said it best: > If someone wants to change cron's behavior to make DST (and > other timezone shenanigans) behave intuitively, add a flag to > make cron work exclusively in UTC as someone else suggested. > It's simple to explain which means less user confusion, and > covers all the cases (even crossing the International Date > line with a mobile laptop) which reduces code bloat. Finally > it's conceptually simpler and more elegant. I think that's ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > worth something. -- Tim Jackson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 18:50:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by hub.freebsd.org (Postfix) with ESMTP id 5365037B69C for ; Fri, 12 Jan 2001 18:50:00 -0800 (PST) Received: from GLOBALLINK2001@aol.com by imo-d06.mx.aol.com (mail_out_v29.5.) id n.fe.e6691a (3863) for ; Fri, 12 Jan 2001 21:49:53 -0500 (EST) From: GLOBALLINK2001@aol.com Message-ID: Date: Fri, 12 Jan 2001 21:49:53 EST Subject: new documentaion To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 59 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello everyone, I have started a thread on freebsd-newbies & freebsd-advocacy. The main purpose of this thread is to create new and up to date documentation for freebsd, as well as extend the number of tutorials as a whole. I have decent number of contributers from the above mentioned lists and we are going to be going to work soon, organizing it all through E-mail etc... here is my reason for posting this: While i am sure me and the few people i have gathered will have no time writing up to date tutorials on topics such as UNIX basics, configuring ppp, setting up a cable modem, using some development tools etc, I know there will be some advanced subjects that we will need some assistance on from you guys. I know this is a busy bunch, and if you have things you are doing (for the project or otherwise) that are more important, disregard this message, I am simply looking for some people who are willing to write some tutorials whenever they have the time. If you would like to participate just send me an E-mail with the E-mail address you would like to discuss the docs with, and any other information you feel to be of relevence, Biggest thanks, Arthur To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 20:35:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id A073C37B401 for ; Fri, 12 Jan 2001 20:34:53 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id WAA15529 for freebsd-hackers@FreeBSD.ORG; Fri, 12 Jan 2001 22:39:49 -0600 (CST) Date: Fri, 12 Jan 2001 22:39:49 -0600 From: Robert Lipe To: freebsd-hackers@FreeBSD.ORG Subject: bus_alloc_resource and RF_SHARABLE Message-ID: <20010112223949.R8978@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Hackers. I'm on FreeBSD 4.1.1 and when I attempt multiple calls to bus_alloc_resource on a PCI device for the same BAR, I run afoul of code in resource_list_alloc: rle = resource_list_find(rl, type, *rid); if (!rle) return 0; /* no resource of that type/rid */ if (rle->res) panic("resource_list_alloc: resource entry is busy"); Even though I'm calling it with RF_SHARABLE, this code doesn't seem to take that into account. It finds the existing list and therefore panics. Am I doing something wrong or does this really work? Yes, I can rig things up such that there is only one bus_alloc_resource call per BAR but I'd rather not. Thanx, RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 22:23: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 1B37D37B401 for ; Fri, 12 Jan 2001 22:22:42 -0800 (PST) Received: from casablanca-23.budapest.interware.hu ([195.70.53.23] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14HK5I-0002Ne-00 for ; Sat, 13 Jan 2001 07:22:40 +0100 Message-ID: <3A5FF3C6.DD185302@elischer.org> Date: Fri, 12 Jan 2001 22:20:54 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: hackers@freebsd.org Subject: Off topic but worth it.. Things to Say When You're Losing a Technical Argument Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maybe we could declare a thread closed when these turn up? http://www.pigdog.org/auto/mr_bads_list/shortcolumn/1914.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 12 22:26:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id D6F4F37B402 for ; Fri, 12 Jan 2001 22:26:31 -0800 (PST) Received: (qmail 26669 invoked by uid 1000); 13 Jan 2001 06:26:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jan 2001 06:26:31 -0000 Date: Sat, 13 Jan 2001 00:26:31 -0600 (CST) From: Mike Silbersack To: Julian Elischer Cc: Subject: Re: Off topic but worth it.. Things to Say When You're Losing a Technical Argument In-Reply-To: <3A5FF3C6.DD185302@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 12 Jan 2001, Julian Elischer wrote: > Maybe we could declare a thread closed when these turn up? > > http://www.pigdog.org/auto/mr_bads_list/shortcolumn/1914.html I like your idea. Why don't you write up a white paper and we'll review it at the next staff meeting? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 0:47:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200]) by hub.freebsd.org (Postfix) with ESMTP id 7186937B400 for ; Sat, 13 Jan 2001 00:47:04 -0800 (PST) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id RAA03982; Sat, 13 Jan 2001 17:47:54 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200101130847.RAA03982@shidahara1.planet.sci.kobe-u.ac.jp> To: Mitsuru IWASAKI Cc: hackers@FreeBSD.ORG Subject: Re: CFR: Generalized power-management interface In-reply-to: Your message of "Sat, 13 Jan 2001 02:43:39 JST." <20010113024339Z.iwasaki@jp.FreeBSD.org> Date: Sat, 13 Jan 2001 17:47:54 +0900 From: Takanori Watanabe Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010113024339Z.iwasaki@jp.FreeBSD.org>, Mitsuru IWASAKI $B$5$s$$$o$/(B : >Hi, > >I've update the patch based on some comments so far and added wmpm >(actually ACPI support for wmapm which is utility for WindowMaker) >ports files as a example. > >http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz What about treating it as a part of ioctl in existing device, then make symbolic link to a generalzed name,instead of consuming new major number? Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 1:57:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp7.xs4all.nl (smtp7.xs4all.nl [194.109.127.133]) by hub.freebsd.org (Postfix) with ESMTP id D807037B401 for ; Sat, 13 Jan 2001 01:57:07 -0800 (PST) Received: from localhost (s340-modem1351.dial.xs4all.nl [194.109.165.71]) by smtp7.xs4all.nl (8.9.3/8.9.3) with SMTP id KAA29891; Sat, 13 Jan 2001 10:57:03 +0100 (CET) Message-ID: <3A6025F1.794BDF32@xs4all.nl> Date: Sat, 13 Jan 2001 09:54:57 +0000 From: "W.H.Scholten" Organization: . X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 4.1-RELEASE i386) MIME-Version: 1.0 To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff References: <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> <20010112081422.U7240@fw.wintelcom.net> Content-Type: multipart/mixed; boundary="------------1CFBAE3959E2B60015FB7483" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------1CFBAE3959E2B60015FB7483 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alfred Perlstein wrote: [ mkdir ] > I'll commit the patch shortly. Here's a better patch, it checks for multiple slashes, so mkdir /tmp/aa///bb//// will give: mkdir: /tmp/aa: No such file or directory Also, renamed the function to dirname as it does the same as dirname(1). Regards, Wouter --------------1CFBAE3959E2B60015FB7483 Content-Type: text/plain; charset=us-ascii; name="mkdir.diff3" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mkdir.diff3" diff -ruN /usr/src/bin/mkdir.orig/mkdir.c /usr/src/bin/mkdir/mkdir.c --- /usr/src/bin/mkdir.orig/mkdir.c Sat Sep 4 05:19:38 1999 +++ /usr/src/bin/mkdir/mkdir.c Sat Jan 13 10:45:07 2001 @@ -58,6 +58,8 @@ int build __P((char *, mode_t)); void usage __P((void)); +char *dirname __P((char *)); + int vflag; @@ -108,7 +110,10 @@ if (build(*argv, omode)) success = 0; } else if (mkdir(*argv, omode) < 0) { - warn("%s", *argv); + if (errno == ENOTDIR || errno == ENOENT) + warn("%s", dirname(*argv)); + else + warn("%s", *argv); success = 0; } else if (vflag) (void)printf("%s\n", *argv); @@ -129,6 +134,22 @@ } exit(exitval); } + + +char *dirname(char *path) { + char *slash; + + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; + + slash = strrchr(path, '/'); + if (slash) { + *slash = 0; + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; + } + + return path; +} + int build(path, omode) --------------1CFBAE3959E2B60015FB7483-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 6:16: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 1707037B402 for ; Sat, 13 Jan 2001 06:15:52 -0800 (PST) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.1+3.4W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id f0DEFnk86718; Sat, 13 Jan 2001 23:15:49 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: takawata@shidahara1.planet.sci.kobe-u.ac.jp Cc: iwasaki@jp.FreeBSD.org, hackers@FreeBSD.ORG Subject: Re: CFR: Generalized power-management interface In-Reply-To: <200101130847.RAA03982@shidahara1.planet.sci.kobe-u.ac.jp> References: <20010113024339Z.iwasaki@jp.FreeBSD.org> <200101130847.RAA03982@shidahara1.planet.sci.kobe-u.ac.jp> 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: <20010113231549X.iwasaki@jp.FreeBSD.org> Date: Sat, 13 Jan 2001 23:15:49 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >I've update the patch based on some comments so far and added wmpm > >(actually ACPI support for wmapm which is utility for WindowMaker) > >ports files as a example. > > > >http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz > > What about treating it as a part of ioctl in existing device, then > make symbolic link to a generalzed name,instead of consuming new > major number? Does `existing device' mean APM or ACPI? We don't know which power management system is enabled on the actual system, so it's impossible. We need one mandatory device for PM to be generalized. I think the opposite way is more reasonable. Or if your concern is shortage of major number, we could expand it in proper way. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 7: 0:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-r20.mx.aol.com (imo-r20.mx.aol.com [152.163.225.162]) by hub.freebsd.org (Postfix) with ESMTP id 48FC037B6A2 for ; Sat, 13 Jan 2001 07:00:33 -0800 (PST) Received: from GLOBALLINK2001@aol.com by imo-r20.mx.aol.com (mail_out_v29.5.) id n.ab.53527b9 (7381) for ; Sat, 13 Jan 2001 10:00:27 -0500 (EST) From: GLOBALLINK2001@aol.com Message-ID: Date: Sat, 13 Jan 2001 10:00:27 EST Subject: Re: new documentaion To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 59 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Thank you very much for your support, I will check into all the resources you suggested. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 7:24:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200]) by hub.freebsd.org (Postfix) with ESMTP id E2C6B37B699 for ; Sat, 13 Jan 2001 07:24:31 -0800 (PST) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id AAA05193; Sun, 14 Jan 2001 00:25:37 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200101131525.AAA05193@shidahara1.planet.sci.kobe-u.ac.jp> To: Mitsuru IWASAKI Cc: hackers@FreeBSD.ORG Subject: Re: CFR: Generalized power-management interface In-reply-to: Your message of "Sat, 13 Jan 2001 23:15:49 JST." <20010113231549X.iwasaki@jp.FreeBSD.org> Date: Sun, 14 Jan 2001 00:25:37 +0900 From: Takanori Watanabe Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010113231549X.iwasaki@jp.FreeBSD.org>, Mitsuru IWASAKI $B$5$s$$$o$/(B : >> >I've update the patch based on some comments so far and added wmpm >> >(actually ACPI support for wmapm which is utility for WindowMaker) >> >ports files as a example. >> > >> >http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz >> >> What about treating it as a part of ioctl in existing device, then >> make symbolic link to a generalzed name,instead of consuming new >> major number? > >Does `existing device' mean APM or ACPI? Yes . >We don't know which power management system is enabled on the actual >system, so it's impossible. We need one mandatory device for PM to be >generalized. I think the opposite way is more reasonable. Why? Is it bad to check whether the device is available or not in rc? Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 7:30:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 8A25237B69C for ; Sat, 13 Jan 2001 07:29:54 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0DFTps26367; Sat, 13 Jan 2001 08:29:52 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101131529.f0DFTps26367@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Lipe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: bus_alloc_resource and RF_SHARABLE In-Reply-To: Your message of "Fri, 12 Jan 2001 22:39:49 CST." <20010112223949.R8978@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Jan 2001 08:29:51 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I'm on FreeBSD 4.1.1 and when I attempt multiple calls to >bus_alloc_resource on a PCI device for the same BAR, I run afoul of code >in resource_list_alloc: > > rle = resource_list_find(rl, type, *rid); > > if (!rle) > return 0; /* no resource of that type/rid */ > if (rle->res) > panic("resource_list_alloc: resource entry is busy"); > > >Even though I'm calling it with RF_SHARABLE RF_SHARABLE requests to share a resource with another device, not within the same device. Further, RF_SHARABLE only applies to IRQs, not BARs. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 8: 5: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 1982537B401; Sat, 13 Jan 2001 08:04:44 -0800 (PST) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.1+3.4W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id f0DG4ek63945; Sun, 14 Jan 2001 01:04:40 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: mjacob@feral.com Cc: jhb@FreeBSD.ORG, iwasaki@jp.FreeBSD.org, hackers@FreeBSD.ORG Subject: Re: CFR: Generalized power-management interface In-Reply-To: References: 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: <20010114010440T.iwasaki@jp.FreeBSD.org> Date: Sun, 14 Jan 2001 01:04:40 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > If we're going to talk about 'health' for a machine and it's components, it > should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). Yes, but my understanding on SES/SAF-TE is very poor unfortunately :-) I think number of hackers who can cover all areas with enough knowledge and experience is quite limited, so I prefer dividing it into sub-areas sharing upper level framework to make things simple. Any volunteers for the design? something like; health ----+---- power ----+---- apm | | | +---- acpi | +---- thermal --+---- acpi | | : : Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 8:46:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id B5C9C37B401 for ; Sat, 13 Jan 2001 08:46:40 -0800 (PST) Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92]) by tasogare.imasy.or.jp (8.11.1+3.4W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id f0DGkYk86994; Sun, 14 Jan 2001 01:46:34 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: takawata@shidahara1.planet.sci.kobe-u.ac.jp Cc: iwasaki@jp.FreeBSD.org, hackers@FreeBSD.ORG Subject: Re: CFR: Generalized power-management interface In-Reply-To: <200101131525.AAA05193@shidahara1.planet.sci.kobe-u.ac.jp> References: <20010113231549X.iwasaki@jp.FreeBSD.org> <200101131525.AAA05193@shidahara1.planet.sci.kobe-u.ac.jp> 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: <20010114014634Y.iwasaki@jp.FreeBSD.org> Date: Sun, 14 Jan 2001 01:46:34 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >We don't know which power management system is enabled on the actual > >system, so it's impossible. We need one mandatory device for PM to be > >generalized. I think the opposite way is more reasonable. > > Why? Is it bad to check whether the device is available or not in rc? Ah, you mean we support the same ioctl interface directly in both apm and acpi for power management without passthru requests via generalized device, right? If ioctl is only the matter, I thinkg yes. But having own device file is still advantages when we start considering other cdevsw stuff such as open/close/read/write/poll/etc. I think the way you suggested may prevent generalized device interface improving and make existing-code to be more complicated. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 9: 7:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id B0A2437B401 for ; Sat, 13 Jan 2001 09:07:10 -0800 (PST) Received: (qmail 15392 invoked by uid 0); 13 Jan 2001 17:07:08 -0000 Received: from pd9508869.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.105) by mail.gmx.net (mp006-rz3) with SMTP; 13 Jan 2001 17:07:08 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id QAA05176; Sat, 13 Jan 2001 16:23:57 +0100 Date: Sat, 13 Jan 2001 16:23:57 +0100 From: Gerhard Sittig To: Doug Barton Cc: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010113162357.R253@speedy.gsinet> References: <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010110233907.L253@speedy.gsinet> <3A5D7762.DC8DE5D@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3A5D7762.DC8DE5D@FreeBSD.org>; from DougB@FreeBSD.org on Thu, Jan 11, 2001 at 01:05:38AM -0800 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 11, 2001 at 01:05 -0800, Doug Barton wrote: > Gerhard Sittig wrote: > > > > Looking at the echo returning so far > > Which represents a very small percentage of the people who need > to look at the change. A significant percentage (probably a > majority) of the people who are freebsd developers abandoned > -hackers long ago. How am I supposed to know? Especially after asking "how to? where to go?" without getting this kind of redirection? That's been part of what rises frustration when you don't know whether you're plain wrong or just unheard. But we had the OT discussion already and don't need to replay it here ... > > BTW: There's good news for those with a dislike regarding > > the change: > > You and your associates keep trying to cast this in personal > terms. Not to leave a false impression: I don't have any "associates" here. It just happened that there was no unisono rejection and some readers thought (like I did) teaching cron about DST would be a good idea. The always bubbling up threads and PRs may have led there. > It is not that I dislike your idea. I think your idea is > dangerous, and wrong for the project. There is a big > difference. OK, in the meantime I did what I didn't want to bother you with: setup another OpenBSD machine and have it run some test. It's just that toying with DST without artificially jumping the clock (and thus falsifying the test, see my other message) takes a few days for a single cycle. And we all have our day jobs. As well as other spare time projects. Some of us even have a real life. I hope to have come back to reasonable and technically based discussion with the summary I just sent out in the other reply. That's the kind of "redirection towards what will be a real solution" I hoped to get together with the refusal in case my first approach was wrong. It obviously took some laps to get there ... :) virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 9: 7:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id D8F1B37B402 for ; Sat, 13 Jan 2001 09:07:10 -0800 (PST) Received: (qmail 15429 invoked by uid 0); 13 Jan 2001 17:07:09 -0000 Received: from pd9508869.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.105) by mail.gmx.net (mp006-rz3) with SMTP; 13 Jan 2001 17:07:09 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id SAA05233; Sat, 13 Jan 2001 18:04:23 +0100 Date: Sat, 13 Jan 2001 18:04:23 +0100 From: Gerhard Sittig To: Darren Henderson Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010113180423.T253@speedy.gsinet> References: <20010110233907.L253@speedy.gsinet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from darren@bmv.state.me.us on Thu, Jan 11, 2001 at 01:19:49PM -0500 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 11, 2001 at 13:19 -0500, Darren Henderson wrote: > > On Wed, 10 Jan 2001, Gerhard Sittig wrote: > > > Looking at the echo returning so far I see _much_ more "yes" > > than "nope" answers. There's consent that *something* has to > > be done. > > Heh, if its votes you are looking for then you can add another > to your "nope" column for what its worth. The current behavior > is the expected behavior and should remain. If those votes help in estimating what the community opinion is: Yes, I want to get them! Wouldn't you like to know, too, how much of acceptance is there for the results of work you do in your spare time? We only have limited resources, and we aren't paid for contributing. Well, most of us. So there should at least be the motivation of "yes, it makes sense what I do here and it brings us some advantage". > I'd suggest moving the man 5 conrtab BUGS section content > (really doesn't belong there, its not really what I would call > a bug) up to the section discussing field contents so > admins/users are hit with it each time they look. Or perhaps > adding a note to the default crontab comments. I'd see this as > being more helpful. The above crontab(5) BUGS section BTW is the result of another "DST breaks cron / is broken by cron" PR back in April 1999. This PR conf/10947 has a rather lengthy discussion on wether it is a bug or an implementation detail and wheter it should be documented in the NOTES section. The problem with DST and cron doesn't seem to be so much that it isn't documented. But more that it doesn't spring to mind immediately to those admins affected. Especially when they didn't schedule the daily job themselves but merely drop in their own scripts to the collection alredy installed and having its execution time. Maybe the actual problem is the lack of an afterboot(7) manpage which could make admins really check the thousand things in a fresh installation they might even not be aware of. PR bin/3314 as of April 1997 BTW has a patch in it from Mark Thompson which basically looks like what OpenBSD incorporated in December 1997. It was then rejected. And it is what doesn't solve the DST issue as I stated in the summary message since its only criterion for the time passed by is the time(3) syscall. So we couldn't use it even when we were willing to teach cron about DST. These PRs is what I found after searching for closed PRs, too. But I couldn't imagine that such an eternal problem is not open. Next time I will know better. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 9: 8:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 973D037B400 for ; Sat, 13 Jan 2001 09:07:13 -0800 (PST) Received: (qmail 15504 invoked by uid 0); 13 Jan 2001 17:07:11 -0000 Received: from pd9508869.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.105) by mail.gmx.net (mp006-rz3) with SMTP; 13 Jan 2001 17:07:11 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id QAA05173; Sat, 13 Jan 2001 16:09:17 +0100 Date: Sat, 13 Jan 2001 16:09:17 +0100 From: Gerhard Sittig To: Greg Black Cc: Doug Barton , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20010113160917.Q253@speedy.gsinet> References: <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010110233907.L253@speedy.gsinet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from gjb@gbch.net on Thu, Jan 11, 2001 at 04:33:57PM +1000 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ for the impatient there's a summary at the bottom ("/summarize") ] On Thu, Jan 11, 2001 at 16:33 +1000, Greg Black wrote: > Gerhard Sittig wrote: > > > I take notice of your (and Greg Black's) reservation / being > > opposed, respect it and conclude that the change will have to > > - default to the current behaviour (something quite usual for > > expanding changes) > > We'd need some guarantees that the attempt to maintain current > behaviour was done correctly -- i.e., without introducing bugs > that broke things. The only way I could think of to make sure there won't be new bugs would be peer review. The reason why we're not yet at this stage is my personal failure to make any (visible) progress. There seems to be a catch22: I don't want to bother you with untested code, but I fail to successfully test what I have here as long as I'm alone fighting it. But that's OK with me as it "only" slows things down a bit. Compared to the time this topic has been discussed in over the last few years some more weeks don't count that much ... > > - be well documented (something absolutely clear to all of us, > > strictly speaking it's way out of imagination for us how > > somebody could contribute undocumented stuff ... :) > > One of the things that would need to be documented is what will > happen to the new algorithm in the situation where cron is > stopped and re-started during one of the time periods that gets > repeated. Oh, you bring up an absolutely new datapoint it seems! Since all the information vixie cron (in its original form as well as the OpenBSD variant) keeps its state in is held in memory (the time it went to sleep, the time it expects to wake up again, the time it is collecting jobs for -- usually somewhere between the time it went to sleep and the time it woke up at, catching up towards the current time) it wouldn't know that it does repeat an hour it just has passed few minutes ago in case there's been a restart in between. This lack of persistency is some (mis)behaviour the OpenBSD version has, too. And it isn't documented there, either. It looks like this point should be fed back to their project, too (to be solved by extending the documentation). A solution to make this state persistent would be to - have cron.c:set_time() read state from a file which - cron.c:cron_sleep() will write to before going to sleep. The file probably should live somewhere next to the crontab spool directory. But permanently writing state to disc to keep this kind of persistency is what we have learnt to be wrong from the latest /etc/rc and Yarrow thread on cvs-all ... And yes, now that you brought this up, I can see the (IMO first technical and valid) point against the proposed change. It turns out that specifying cronjobs' timings in UTC is the only real solution. Should any existing will to *somehow* solve the current situation better be spent on writing a frontend to _this_ approach (some vicron(8) command being a vipw(8) workalike, translating users' specifications in local time to a unified coordinate system; or a cron(8) command line option to interpret the crontab time specification in UTC) instead of shooting down the effort I'm trying to do now? It's not that I would insist in following a dead end's path. But I would like to learn _how_ to solve the problem and how to contribute if my current proposal turns out to just not work at all in forseable future or for some obvious(?) reason. This is BTW the reason why I asked some seven weeks back in cvs-all message <20001120193326.C27042@speedy.gsinet> *if* the OpenBSD approach would be a solution for us, if somebody is already to handle the DST topic, and if I should lend a hand / jump in on existing works. Just to find myself welcomed with a warm and heartly "Go away and do something more useful instead!" which might one of the reasons for this discussion being not wholly technical ... :> > > - yet be enabled easily for those interested in the change to > > work for them and free up some of their resources for more > > important tasks > > - maybe provide knobs (besides the on-off-switch) to customize > > behaviour in a more fine grained way > > In the beginning, something like CRON_DST_HACK="NO" in rc.conf > with a comment pointing to the explanation should cover both > these items. If more is needed later, then it can be added. I would have done some cron_flags setting in rc.conf(5) since this is already kind of missing in case you want to activate some -x command line parameters. :) Of course this would have its comment in /etc/defaults/rc.conf and its section in the rc.conf(5) manpage pointing to the fullblown discussion in the cron(8) manpage. > > BTW: There's good news for those with a dislike regarding > > the change: While testing I'm stuck again, so there will be > > some more delay. > > Previously we were told that this stuff had already been tested > for years under another OS and was therefore robust and > reliable. Now we learn that these claims are not correct. And > you wonder why people are reluctant to even consider these > changes ... "We were told UNIX had been around for some thirty years, is said to be functional / reliable / flexible / add whatever you use and love UNIX for. And now we learn it doesn't even work easily for those simple tasks as networking / printing / gaming / etc are?" Excuse me, please? Could it be that you got more from my messages than what I actually said? What I did was to extract a patch from a sibling *BSD project and try to port it to FreeBSD. When *I* fail there it doesn't mean that the other project's approach must be wrong. I don't question *BSD's networking capabilities just because I don't get LAN access with three different PCMCIA cards (3com, Xircom, D-Link) and several OSes (FreeBSD-STABLE, FreeBSD-CURRENT, NetBSD 1.5, OpenBSD 2.8). And I wouldn't dare to say "we never want to get to a state where this works" just because it doesn't at the moment. But I'm side tracking. And yes, there is a chance that the method has flaws in principle, see my summary below. But it could have been my fault as well. Well, since you "asked": the current status is that OpenBSD has had this extension since Dec '97: $ rlog /home/ocvs/src/usr.sbin/cron/cron.c,v [ ... ] revision 1.4 date: 1997/12/22 08:10:41; author: deraadt; state: Exp; lines: +156 -68 handle timing normally except when clock jumps between 1 and 3 hours. If it jumps, attempt as best as possible to gaurantee that jobs DO run, but only run ONCE; patch by thompson@.tgsoft.com [ ... ] date: 1995/10/18 08:47:30; author: deraadt; state: Exp; lines: +0 -0 initial import of NetBSD tree OpenBSD imported the NetBSD source, which didn't have the DST handling code at this time. Reading the NetBSD 1.5 cron(8) manpage doesn't give a hint that they introduced such a change any time later. BSD/OS is something I didn't check. FreeBSD obviously doesn't have special DST treatment. So of all the *BSD sibling projects OpenBSD seems to be the only one to have taken action in this respect (modulo my lack of information about BSD/OS). What I did so far is to extract the DST related parts of the cron trees' diff between FreeBSD and OpenBSD (the latter had much more changes not related to this topic). The patches applied cleanly, the source compiles and runs. cron now handles time _jumps_ in the documented way (like caused by manual intervention by means of date(8) - tested - or netdate(8) - not tested, but expected to result in the same time(3) change). Why I'm puzzled since my latest tests is: cron.c:main() has a structure like this (all time counters are held in minutes): ----------------------------------------------------------------- int main() { /* fork() to daemonize */ ... /* init */ load_database(&database); set_time(); run_reboot_jobs(&database); timeRunning = virtualTime = clockTime; /* endless main loop * clockTime: the "real" time from time(NULL) * timeRunning: when we last ran * virtualTime: what we expect the time to be */ while (TRUE) { load_database(&database); /* wait for the time to change */ do { cron_sleep(timeRunning + 1); set_time(); } while (clockTime == timeRunning); timeRunning = clockTime; /* calculate the difference between * the current time and the last time we ran at */ timeDiff = timeRunning - virtualTime; | /* the most common case | * here is where the new switch(wakeupKind) comes in | */ | virtualTime = timeRunning; | find_jobs(virtualTime, &database, TRUE, TRUE); job_runqueue(); } } void set_time() { clockTime = time(NULL) / 60; } void cron_sleep(int target) { sleep(time(NULL) - target); } ----------------------------------------------------------------- The marked section is the one which (after obtaining the patch from OpenBSD) would read like wakeupKind = f(timeDiff); switch (wakeupKind) { ... } Now for the problem: There's a repeated "sleep(); clockTime = time(NULL);" invocation. Then the difference between the minutes we last ran at and the current minutes count is calculated. In the most common case cron wakes up often enough to always find that only one minute has passed since. What surprises me is: DST changes won't make the time() result jump! At least that's what I get from reading "man 3 time" on several FreeBSD and OpenBSD (and Linux:) versions. localtime(3) is only used in find_jobs(). So the main loop doesn't know about DST changes. Of course localtime could get introduced in the main loop's calculation, too -- but it wouldn't be the original OpenBSD approach any longer. Hmmm, how could this ever have worked? Or how could this bug(?) have gone unnoticed for three years? More probable: Where is my error in these thoughts? What did I miss? That's where I had to setup another machine running OpenBSD to check and see if I could get the expected behaviour at all. And it looks like OpenBSD's cron(8) doesn't "handle DST" either -- although the manpage does suggest it. Can any OpenBSD user lingering around and following the thread comment on this? Does it work and I fail to see it? Did it never work and nobody noticed? Has it never be a concern? To summarize the current FreeBSD situation: DST is an ever popping up "problem" right now and there is not (cannot be?) a general solution easy enough to work for everyone and become accepted by all traditional admins. Then there's been my impression (not experience) that a sibling BSD project already has a solution and has had it for the past three years. Hence my try to port their approach over into FreeBSD. And (after fiddling with it for a while) their approach seems to not work for DST changes. Although it still could be incorporated to handle the edge cases where - cron(8) doesn't wake up often or fast enough to cope with its scheduled jobs (probably rare, but not impossible) - time jumps - back and forth - cannot be avoided easily: The "problem" with an NTP daemon is that it depends on network connectivity. Remember that not everyone has permanent connections, some dialup users could prefer to use chrony or cron'ed netdate(8) or wall clock "sync"ed date(8) invocations. I understand that having the clock jump is a Bad Idea(TM). Especially when it is jumping backward since this violates the model we have of time (*always* monotonously increasing, *maybe* or *usually* flowing continuously)! But I see an advantage in supporting delayed cron ticks as well as forward clock correction jumpwise. That's why I will file the PR with the current state next week. And I realize that the DST topic is anything but trivial, cannot be handled by my ported patch and actions can easily do harm when done incorrectly. The only solutions turn out to be - education by constantly repeating "don't do this on your behalf", "correct the possibly wrong defaults installed for you" as well as "always keep this in mind whenever things should change", maybe supported by some kind of afterboot(7) manpage - avoiding local time representation in job time specifications and thus completely eliminating DST influence, maybe supported by editing wrappers or database loading converters since humans might have problems getting used to calculate in "foreign" coordinate systems So we're back from DST being a "problem" to just an "issue" ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 9:25:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by hub.freebsd.org (Postfix) with ESMTP id 904FD37B400 for ; Sat, 13 Jan 2001 09:24:58 -0800 (PST) Received: from fwd02.sul.t-online.com by mailout05.sul.t-online.com with smtp id 14HUQD-0008Iu-01; Sat, 13 Jan 2001 18:24:57 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.158.39.108]) by fmrl02.sul.t-online.com with esmtp id 14HUQ4-1SkPh2C; Sat, 13 Jan 2001 18:24:48 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 79EBFAB0C for ; Sat, 13 Jan 2001 18:26:10 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 2547914A8F; Sat, 13 Jan 2001 18:24:45 +0100 (CET) Date: Sat, 13 Jan 2001 18:24:44 +0100 From: Alexander Langer To: hackers@freebsd.org Subject: sys/disklabel.h in C++ files Message-ID: <20010113182444.A1799@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I have a question: How do you include sys/disklabel.h in C++ files? alex:~ $ cat test.cc #include alex:~ $ cat test2.cc extern "C" { #include } alex:~ $ make test.o c++ -O -pipe -c test.cc In file included from test.cc:1: /usr/include/sys/disklabel.h:182: `lp' was not declared in this scope /usr/include/sys/disklabel.h:183: syntax error before `*' *** Error code 1 Stop in /usr/home/alex. alex:~ $ make test2.o c++ -O -pipe -c test2.cc In file included from test2.cc:2: /usr/include/sys/disklabel.h:182: `lp' was not declared in this scope /usr/include/sys/disklabel.h:183: syntax error before `*' /usr/include/sys/disklabel.h:188: `lp' was not declared in this scope /usr/include/sys/disklabel.h:189: `lp' was not declared in this scope /usr/include/sys/disklabel.h:189: `lp' was not declared in this scope /usr/include/sys/disklabel.h:190: syntax error before `while' *** Error code 1 Stop in /usr/home/alex. alex:~ $ Is there a gcc option? Or does this just not work? I mean, it worked before PHK made dkcksum() an __inline function. Thanks Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 10:17:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A88A837B6A1; Sat, 13 Jan 2001 10:17:14 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA32556; Sat, 13 Jan 2001 10:17:11 -0800 Date: Sat, 13 Jan 2001 10:17:11 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mitsuru IWASAKI Cc: jhb@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: CFR: Generalized power-management interface In-Reply-To: <20010114010440T.iwasaki@jp.FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 14 Jan 2001, Mitsuru IWASAKI wrote: > Hi, > > > If we're going to talk about 'health' for a machine and it's components, it > > should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). > > Yes, but my understanding on SES/SAF-TE is very poor unfortunately :-) > I think number of hackers who can cover all areas with enough knowledge and > experience is quite limited, so I prefer dividing it into sub-areas sharing > upper level framework to make things simple. > Any volunteers for the design? something like; > SAF-TE is nearly a proper subset of SES, and SES covers lots of things (not just environmental) health ----+---- power ----+---- apm | | | +---- acpi | | | +---- SES/SAF-TE | +---- thermal --+---- acpi | | | +---- SES/SAF-TE | | +---- object* --+---- SES/SAF-TE : : * An 'object' can be marked as having a fault condition An object might be a disk drive tray.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 14:18:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 321D937B404 for ; Sat, 13 Jan 2001 14:17:59 -0800 (PST) Received: (from uucp@localhost) by ns.internet.dk (8.11.1/8.11.1) with UUCP id f0DMHgb53733; Sat, 13 Jan 2001 23:17:42 +0100 (CET) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.11.1/8.11.0) with ESMTP id f0DMHQi49150; Sat, 13 Jan 2001 23:17:30 +0100 (CET) (envelope-from leifn@neland.dk) Date: Sat, 13 Jan 2001 23:17:26 +0100 (CET) From: Leif Neland To: Gerhard Sittig Cc: Greg Black , Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <20010113160917.Q253@speedy.gsinet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > One of the things that would need to be documented is what will > > happen to the new algorithm in the situation where cron is > > stopped and re-started during one of the time periods that gets > > repeated. > > Oh, you bring up an absolutely new datapoint it seems! Since all > the information vixie cron (in its original form as well as the > OpenBSD variant) keeps its state in is held in memory (the time > it went to sleep, the time it expects to wake up again, the time > it is collecting jobs for -- usually somewhere between the time > it went to sleep and the time it woke up at, catching up towards > the current time) it wouldn't know that it does repeat an hour it > just has passed few minutes ago in case there's been a restart in > between. > Oh no. If this "clock-slewing" was implemented, I'd expect killing and restarting cron be a way to forget everything which had happened. I.e. if I wanted to test a schedule, I might want to stop cron, reset time and start cron again. Cron usually doesn't die by itself. If it gets killed, it is usually for a reason. Don't complicate this proposed change with also having to add persistance over a kill and restart. Does anacron handle this DST issue better? Could it be added to ports if so, and a knob NO_CRON in make.conf? Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 14:25:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id CE93937B401 for ; Sat, 13 Jan 2001 14:24:41 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0DMNm159928 for ; Sat, 13 Jan 2001 14:23:48 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 13 Jan 2001 14:24:47 -0800 (PST) From: John Baldwin To: hackers@FreeBSD.org Subject: x85 memory barriers.. ewww Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, I wish I had a freebsd-{i386,ia32,x86} list to send this to, but I'm having some x86 asm problems. I'm trying to fix atomic_store_rel() and atomic_load_acq() to actually serve as memory barriers, instead of the current lame a = b versions we have now that don't enforce any type of barriers. Unfortunately, my newer versions of atomic_store_rel() that use a single 'xchg' instruction make things _worse_. The updated i386/include/atomic.h can be found at: http://people.freebsd.org/~jhb/patches/atomic.h. With the new atomic_store_rel(), I'm actually seeing caases in the mutex code (in release_lock_quick) where for some reason the actual write out to memory is a) being delayed, and b) not even being seen by the processor that sees it. As a result, a _UP_ system will spin on a spin mutex until the xchg in the atomic_store_rel_ptr() that did the release finally propagates. The machine finally panics during boot when it actually succeeeds in recursing on a mutex it had released because when it performs the atomic_cmpset() to acuiqre the mutex, the write from the xchg has not yet been performed. Thus it mistakenly thinkgs it has recursed on hte mutex and never fully releases it. Thus, interrupts stay disabled and the next mtx_enter() of a normal mutex panic's. This behavior makes absolutely no since, and I have seen it on both PPro's and PIII's. Suggestions, comments, welcome. The relevant part of atomic.h is this: #define ATOMIC_STORE_LOAD(TYPE, LOP, SOP) \ static __inline u_##TYPE \ atomic_load_acq_##TYPE(volatile u_##TYPE *p) \ { \ u_##TYPE res; \ \ __asm __volatile(MPLOCKED LOP \ : "=a" (res) /* 0 (result) */\ : "m" (*p) /* 1 */ \ : "memory"); \ \ return (res); \ } \ \ /* \ * The XCHG instruction asserts LOCK automagically. \ */ \ static __inline void \ atomic_store_rel_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\ { \ __asm __volatile(SOP \ : "=m" (*p) /* 0 */ \ : "r" (v) /* 1 */ \ : "memory"); \ } #endif /* defined(I386_CPU) */ #endif /* defined(KLD_MODULE) */ ATOMIC_STORE_LOAD(char, "cmpxchgb %b0,%1", "xchgb %b1,%0") ATOMIC_STORE_LOAD(short,"cmpxchgw %w0,%1", "xchgw %w1,%0") ATOMIC_STORE_LOAD(int, "cmpxchgl %0,%1", "xchgl %1,%0") ATOMIC_STORE_LOAD(long, "cmpxchgl %0,%1", "xchgl %1,%0") Actually, I am probably just screwing up the clobbers, thinking about this. Thanks to whoever points out the obvious brain-o. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 14:55:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 998E437B69E for ; Sat, 13 Jan 2001 14:54:55 -0800 (PST) Received: from FreeBSD.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id OAA54323; Sat, 13 Jan 2001 14:53:55 -0800 (PST) (envelope-from DougB@FreeBSD.org) Message-ID: <3A60DC82.5FFCA817@FreeBSD.org> Date: Sat, 13 Jan 2001 14:53:54 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Leif Neland Cc: Gerhard Sittig , Greg Black , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Could you guys remove my name from the Cc: list on this thread please? I've already made my position quite clear. Thanks, Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 18:44:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from vieo.com (vieo.com [216.30.79.131]) by hub.freebsd.org (Postfix) with ESMTP id 889BD37B401 for ; Sat, 13 Jan 2001 18:44:12 -0800 (PST) Received: (from johng@localhost) by vieo.com (8.11.2/8.11.2) id f0E2i3518278; Sat, 13 Jan 2001 20:44:03 -0600 (CST) (envelope-from johng) Date: Sat, 13 Jan 2001 20:44:03 -0600 (CST) From: John Gregor Message-Id: <200101140244.f0E2i3518278@vieo.com> To: Gerhard.Sittig@gmx.net, leifn@neland.dk Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Cc: DougB@gorean.org, freebsd-hackers@FreeBSD.ORG, gjb@gbch.net In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, this has gone on long enough that my normal inhibitions about driving down the signal-to-noise ratio of a technical list have long subsided. Folks, cron is a *LOW LEVEL SERVICE* much in the same vein as UDP. Neither one makes strong guarantees about ordering, duplication, or dropped events. Those are for higher layer services, iff they are needed. *BSD may very well have a need for a temporal equivalent to TCP where stronger guarantees are made, but it is not and should not be cron. That said, I can't help dinking with the design :-) What would happen if the definitions of the hour and minute fields were subtly changed to mean "elapsed wall-clock time since local midnight"? Then, the DST conversion is no longer ambiguous. "Two hours since local midnight" only happens once regardless. On days where the clocks change, most scripts would wind up running an hour ahead or behind their usual time, but hey, so are many of the people :-). There would also have to be an entry in the BUGS section noting that some days have 23 or 25 hours, which is accurate. -JohnG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 19:14:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1C3ED37B400 for ; Sat, 13 Jan 2001 19:14:35 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0E3EW617016; Sat, 13 Jan 2001 19:14:32 -0800 (PST) Date: Sat, 13 Jan 2001 19:14:32 -0800 From: Alfred Perlstein To: "W.H.Scholten" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff Message-ID: <20010113191432.G7240@fw.wintelcom.net> References: <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> <20010112081422.U7240@fw.wintelcom.net> <3A6025F1.794BDF32@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6025F1.794BDF32@xs4all.nl>; from whs@xs4all.nl on Sat, Jan 13, 2001 at 09:54:57AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * W.H.Scholten [010113 01:57] wrote: > Alfred Perlstein wrote: > > [ mkdir ] > > > I'll commit the patch shortly. > > Here's a better patch, it checks for multiple slashes, so mkdir > /tmp/aa///bb//// will give: > > mkdir: /tmp/aa: No such file or directory > > Also, renamed the function to dirname as it does the same as dirname(1). Actually, there already exists a function called dirname in libc, dirname(3). Here's what I'm going to commit: Index: mkdir.c =================================================================== RCS file: /home/ncvs/src/bin/mkdir/mkdir.c,v retrieving revision 1.19 diff -u -u -r1.19 mkdir.c --- mkdir.c 1999/09/04 03:19:38 1.19 +++ mkdir.c 2001/01/14 03:14:51 @@ -50,6 +50,7 @@ #include #include +#include #include #include #include @@ -108,7 +109,10 @@ if (build(*argv, omode)) success = 0; } else if (mkdir(*argv, omode) < 0) { - warn("%s", *argv); + if (errno == ENOTDIR || errno == ENOENT) + warn("%s", dirname(*argv)); + else + warn("%s", *argv); success = 0; } else if (vflag) (void)printf("%s\n", *argv); Does this look ok to you? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 19:55:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 75B7937B402 for ; Sat, 13 Jan 2001 19:55:25 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0E3tIs95857; Sat, 13 Jan 2001 20:55:18 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101140355.f0E3tIs95857@harmony.village.org> To: "W.H.Scholten" Subject: Re: pppd & mkdir diff Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 13 Jan 2001 09:54:57 GMT." <3A6025F1.794BDF32@xs4all.nl> References: <3A6025F1.794BDF32@xs4all.nl> <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> <20010112081422.U7240@fw.wintelcom.net> Date: Sat, 13 Jan 2001 20:55:18 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A6025F1.794BDF32@xs4all.nl> "W.H.Scholten" writes: : + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; Style(9) says write this like: while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; : + : + slash = strrchr(path, '/'); : + if (slash) { : + *slash = 0; this is not an integer, but rather a character. *slash = '\0'; please. : + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; Ditto. But why do this at all? 'mkdir /a/b/////d/e' is required by posix to create /a/b/d/e if /a/b/d exists. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 19:57:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4EEAE37B698 for ; Sat, 13 Jan 2001 19:56:55 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0E3uos95880; Sat, 13 Jan 2001 20:56:51 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101140356.f0E3uos95880@harmony.village.org> To: "Justin T. Gibbs" Subject: Re: bus_alloc_resource and RF_SHARABLE Cc: Robert Lipe , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 13 Jan 2001 08:29:51 MST." <200101131529.f0DFTps26367@aslan.scsiguy.com> References: <200101131529.f0DFTps26367@aslan.scsiguy.com> Date: Sat, 13 Jan 2001 20:56:50 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101131529.f0DFTps26367@aslan.scsiguy.com> "Justin T. Gibbs" writes: : RF_SHARABLE requests to share a resource with another device, not : within the same device. Further, RF_SHARABLE only applies to : IRQs, not BARs. Actaully, the underlying RF_SHARABLE is for any region of resource that can be multiplexed between different devices. However, in practice, only IRQs can be shared. And even then the device drive would only be working around bugs in the bridge drivers that don't enable sharing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 19:59:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 63F9437B400; Sat, 13 Jan 2001 19:58:54 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0E3wrs95918; Sat, 13 Jan 2001 20:58:53 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101140358.f0E3wrs95918@harmony.village.org> To: Alexander Langer Subject: Re: sys/disklabel.h in C++ files Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 13 Jan 2001 18:24:44 +0100." <20010113182444.A1799@cichlids.cichlids.com> References: <20010113182444.A1799@cichlids.cichlids.com> Date: Sat, 13 Jan 2001 20:58:53 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010113182444.A1799@cichlids.cichlids.com> Alexander Langer writes: : How do you include sys/disklabel.h in C++ files? You can't. It is broken :-(. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 21:17:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8D17C37B400; Sat, 13 Jan 2001 21:17:25 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0E5HOs08319; Sat, 13 Jan 2001 22:17:24 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101140517.f0E5HOs08319@harmony.village.org> Subject: Re: sys/disklabel.h in C++ files Cc: Alexander Langer , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 13 Jan 2001 20:58:53 MST." Date: Sat, 13 Jan 2001 22:17:24 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -------- Warner Losh writes: : In message <20010113182444.A1799@cichlids.cichlids.com> Alexander : Langer writes: : : How do you include sys/disklabel.h in C++ files? : : You can't. It is broken :-(. But I just fixed it. Looks like version 1.54 broke this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 21:25:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id C95F437B400 for ; Sat, 13 Jan 2001 21:25:15 -0800 (PST) Received: (qmail 50189 invoked by uid 1001); 14 Jan 2001 15:25:08 +1000 X-Posted-By: GJB-Post 2.08 05-Jan-2001 (FreeBSD) X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Sun, 14 Jan 2001 15:25:07 +1000 From: Greg Black To: freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010110233907.L253@speedy.gsinet> <20010113160917.Q253@speedy.gsinet> In-reply-to: <20010113160917.Q253@speedy.gsinet> of Sat, 13 Jan 2001 16:09:17 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gerhard Sittig wrote: > On Thu, Jan 11, 2001 at 16:33 +1000, Greg Black wrote: > > > BTW: There's good news for those with a dislike regarding > > > the change: While testing I'm stuck again, so there will be > > > some more delay. > > > > Previously we were told that this stuff had already been tested > > for years under another OS and was therefore robust and > > reliable. Now we learn that these claims are not correct. And > > you wonder why people are reluctant to even consider these > > changes ... > > "We were told UNIX had been around for some thirty years, is said > to be functional / reliable / flexible / add whatever you use and > love UNIX for. And now we learn it doesn't even work easily for > those simple tasks as networking / printing / gaming / etc are?" > > Excuse me, please? Could it be that you got more from my > messages than what I actually said? Please read more carefully. I said: "we were told that this stuff had already been tested for years [...]". I did not say who made this claim, although I assumed that those few people who are following this thread would have remembered who it was. The claim /was/ made. I suggested that it was invalid. I still think that. As for the implementation issues that you covered in detail, I have no comment as I'm not interested in reviewing the code for a change that I see no case for. > I understand that having the clock jump is a Bad Idea(TM). > Especially when it is jumping backward since this violates the > model we have of time (*always* monotonously increasing [...] It may be monotonous, but it's supposed to be monotonically increasing. > And I realize that the DST topic is anything but trivial, cannot > be handled by my ported patch and actions can easily do harm when > done incorrectly. The only solutions turn out to be > - education [...] Not such a bad method. We use it for all the "How do I remove a file named -x?" questions -- we don't "fix" rm or the way the shells parse commands. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 21:32:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 7023337B400; Sat, 13 Jan 2001 21:32:33 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Hfqs-0000DH-00; Sat, 13 Jan 2001 22:37:14 -0700 Message-ID: <3A613B0A.11A50A52@softweyr.com> Date: Sat, 13 Jan 2001 22:37:14 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Alexander Langer , hackers@FreeBSD.ORG Subject: Re: sys/disklabel.h in C++ files References: <20010113182444.A1799@cichlids.cichlids.com> <200101140358.f0E3wrs95918@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <20010113182444.A1799@cichlids.cichlids.com> Alexander > Langer writes: > : How do you include sys/disklabel.h in C++ files? > > You can't. It is broken :-(. Alexande, you could fix it, and submit it in a PR. Hope springs eternal. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 21:34:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 998A537B400; Sat, 13 Jan 2001 21:34:25 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0E5YNs08482; Sat, 13 Jan 2001 22:34:23 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101140534.f0E5YNs08482@harmony.village.org> To: Wes Peters Subject: Re: sys/disklabel.h in C++ files Cc: Alexander Langer , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 13 Jan 2001 22:37:14 MST." <3A613B0A.11A50A52@softweyr.com> References: <3A613B0A.11A50A52@softweyr.com> <20010113182444.A1799@cichlids.cichlids.com> <200101140358.f0E3wrs95918@harmony.village.org> Date: Sat, 13 Jan 2001 22:34:22 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A613B0A.11A50A52@softweyr.com> Wes Peters writes: : Warner Losh wrote: : > : > In message <20010113182444.A1799@cichlids.cichlids.com> Alexander : > Langer writes: : > : How do you include sys/disklabel.h in C++ files? : > : > You can't. It is broken :-(. : : Alexande, you could fix it, and submit it in a PR. : : Hope springs eternal. No need for Hope to Spring. As near as I can tell, I've fixed it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 22:11:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id B4EF637B401 for ; Sat, 13 Jan 2001 22:11:24 -0800 (PST) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=root) by scientia.demon.co.uk with esmtp (Exim 3.20 #1) id 14HgNt-0009zd-00; Sun, 14 Jan 2001 06:11:21 +0000 Received: (from ben@localhost) by strontium.scientia.demon.co.uk (8.11.1/8.11.1) id f0E6BKb45863; Sun, 14 Jan 2001 06:11:20 GMT (envelope-from ben) Date: Sun, 14 Jan 2001 06:11:20 +0000 From: Ben Smithurst To: Warner Losh Cc: "W.H.Scholten" , Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff Message-ID: <20010114061120.K35575@strontium.scientia.demon.co.uk> References: <3A6025F1.794BDF32@xs4all.nl> <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> <20010112081422.U7240@fw.wintelcom.net> <3A6025F1.794BDF32@xs4all.nl> <200101140355.f0E3tIs95857@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101140355.f0E3tIs95857@harmony.village.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message <3A6025F1.794BDF32@xs4all.nl> "W.H.Scholten" writes: > : + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; > > Style(9) says write this like: > while (path[ strlen(path)-1 ] == '/') > path[ strlen(path)-1 ] = 0; No it doesn't. "No spaces after `(' or `[' or preceding `]' or `)' characters." "Unary operators don't require spaces, binary operators do." while (path[strlen(path) - 1] == '/') path[strlen(path) - 1] = 0; :-) Preferably '\0' too of course like you say later. -- Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 22:13:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by hub.freebsd.org (Postfix) with ESMTP id B7C9937B400 for ; Sat, 13 Jan 2001 22:13:00 -0800 (PST) Received: (from kris@localhost) by citusc.usc.edu (8.9.3/8.9.3) id WAA04751; Sat, 13 Jan 2001 22:14:16 -0800 Date: Sat, 13 Jan 2001 22:14:16 -0800 From: Kris Kennaway To: Alfred Perlstein Cc: "W.H.Scholten" , freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff Message-ID: <20010113221416.A4735@citusc.usc.edu> References: <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> <20010112081422.U7240@fw.wintelcom.net> <3A6025F1.794BDF32@xs4all.nl> <20010113191432.G7240@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010113191432.G7240@fw.wintelcom.net>; from bright@wintelcom.net on Sat, Jan 13, 2001 at 07:14:32PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2001 at 07:14:32PM -0800, Alfred Perlstein wrote: > Actually, there already exists a function called dirname in libc, dirname= (3). >=20 > Here's what I'm going to commit: You might also like to contribute this back to the pppd maintainer (Paul.Mackerras@cs.anu.edu.au)..although since our version is so old chances are the patch would need to be rewritten - it would at least show what needs to be done. Kris --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6YUO4Wry0BWjoQKURAuWkAJ9YU2VKfy2LO1bmCqblA9qoaz/urgCdEriq mW4BLY2ljYwijyEy7YqM3Lc= =K8cv -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 22:20: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by hub.freebsd.org (Postfix) with ESMTP id 787EB37B400; Sat, 13 Jan 2001 22:19:48 -0800 (PST) Received: (from kris@localhost) by citusc.usc.edu (8.9.3/8.9.3) id WAA04832; Sat, 13 Jan 2001 22:21:07 -0800 Date: Sat, 13 Jan 2001 22:21:07 -0800 From: Kris Kennaway To: Kris Kennaway Cc: Alfred Perlstein , "W.H.Scholten" , freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff Message-ID: <20010113222107.A4781@citusc.usc.edu> References: <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> <20010112081422.U7240@fw.wintelcom.net> <3A6025F1.794BDF32@xs4all.nl> <20010113191432.G7240@fw.wintelcom.net> <20010113221416.A4735@citusc.usc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010113221416.A4735@citusc.usc.edu>; from kris@FreeBSD.ORG on Sat, Jan 13, 2001 at 10:14:16PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2001 at 10:14:16PM -0800, Kris Kennaway wrote: > On Sat, Jan 13, 2001 at 07:14:32PM -0800, Alfred Perlstein wrote: >=20 > > Actually, there already exists a function called dirname in libc, dirna= me(3). > >=20 > > Here's what I'm going to commit: >=20 > You might also like to contribute this back to the pppd maintainer > (Paul.Mackerras@cs.anu.edu.au)..although since our version is so old > chances are the patch would need to be rewritten - it would at least > show what needs to be done. Duh, I wasn't paying attention enough to note that the patch was for mkdir, not pppd :-) Kris --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6YUVTWry0BWjoQKURAuo8AKDcyrT1t4CrXhbnUz/qfzA4lo/v8gCggur5 MpW3lyfd9IyDz3xW/02opwM= =S+He -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 22:21:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id EA45037B400 for ; Sat, 13 Jan 2001 22:20:59 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0E6Jf121198; Sat, 13 Jan 2001 22:19:41 -0800 (PST) Date: Sat, 13 Jan 2001 22:19:41 -0800 From: Alfred Perlstein To: Warner Losh Cc: "W.H.Scholten" , freebsd-hackers@FreeBSD.ORG Subject: Re: pppd & mkdir diff Message-ID: <20010113221941.L7240@fw.wintelcom.net> References: <3A6025F1.794BDF32@xs4all.nl> <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> <20010112081422.U7240@fw.wintelcom.net> <3A6025F1.794BDF32@xs4all.nl> <200101140355.f0E3tIs95857@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101140355.f0E3tIs95857@harmony.village.org>; from imp@harmony.village.org on Sat, Jan 13, 2001 at 08:55:18PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Warner Losh [010113 19:55] wrote: > In message <3A6025F1.794BDF32@xs4all.nl> "W.H.Scholten" writes: > : + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; > > Style(9) says write this like: > while (path[ strlen(path)-1 ] == '/') > path[ strlen(path)-1 ] = 0; > > : + > : + slash = strrchr(path, '/'); > : + if (slash) { > : + *slash = 0; > > this is not an integer, but rather a character. *slash = '\0'; please. > > : + while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0; > > Ditto. > > > But why do this at all? > > 'mkdir /a/b/////d/e' is required by posix to create /a/b/d/e if /a/b/d > exists. This isn't the point, if you do this: mkdir /someplacethatdoesntexist/foo you'll get: mkdir: /someplacethatdoesntexist/foo: No such file or directory What the patch does is make the error output say: mkdir: /someplacethatdoesntexist: No such file or directory Which makes a bit more sense than telling you it failed because the thing that you know doesn't exist, doesn't exist. :) You missed my latest email on it, basically I can just call dirname(3) on the path depending on the errno to give a more reasonable error message. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 13 22:40:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 63CDC37B400 for ; Sat, 13 Jan 2001 22:40:11 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id AAA22126; Sun, 14 Jan 2001 00:44:53 -0600 (CST) Date: Sun, 14 Jan 2001 00:44:53 -0600 From: Robert Lipe To: Warner Losh Cc: "Justin T. Gibbs" , freebsd-hackers@FreeBSD.ORG Subject: Re: bus_alloc_resource and RF_SHARABLE Message-ID: <20010114004453.D20766@rjlhome.sco.com> References: <200101131529.f0DFTps26367@aslan.scsiguy.com> <200101140356.f0E3uos95880@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200101140356.f0E3uos95880@harmony.village.org>; from imp@harmony.village.org on Sat, Jan 13, 2001 at 08:56:50PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200101131529.f0DFTps26367@aslan.scsiguy.com> "Justin T. Gibbs" writes: > : > : RF_SHARABLE requests to share a resource with another device, not > : within the same device. Further, RF_SHARABLE only applies to > : IRQs, not BARs. Warner Losh wrote: > Actaully, the underlying RF_SHARABLE is for any region of resource > that can be multiplexed between different devices. However, in > practice, only IRQs can be shared. And even then the device drive > would only be working around bugs in the bridge drivers that don't > enable sharing. I can't say I gather that from the man page from bus_alloc_resource at all. The restriction of RF_SHAREABLE applying only to IRQs and the exclusive nature of this call (one per BAR) would be helpful to call out in the doc. Just so I'm completely clear on this though, the intent is that multiple bus_alloc_resource calls for a single BAR within a single driver is explictly prohibited, right? So if I want to map ONLY the first byte and the last byte of, say, a 16MB PCI BAR, I have to map the whole thing, use the same resource handle for everything, and give up any potential address space/vm protection afforded by having the middle unmapped, right? I can get around this for my needs, but I wanted to be sure that I wasn't just misunderstanding the rules. Thanx for the prompt replies. RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message