From owner-freebsd-bugs Sun Sep 3 8:30:10 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8375D37B422 for ; Sun, 3 Sep 2000 08:30:06 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA57658; Sun, 3 Sep 2000 08:30:06 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Sun, 3 Sep 2000 08:30:06 -0700 (PDT) Message-Id: <200009031530.IAA57658@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Vivek Khera Subject: Re: bin/20974: securelevel not reset when going to single user mode Reply-To: Vivek Khera Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20974; it has been noted by GNATS. From: Vivek Khera To: Sheldon Hearn Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/20974: securelevel not reset when going to single user mode Date: Sun, 3 Sep 2000 11:24:13 -0400 (EDT) >>>>> "SH" == Sheldon Hearn writes: SH> I think you're misunderstanding. The page is talking about the SH> transition from single-user mode to multi-user mode (part of init's SH> job). There's no mention of the transition back to single-user mode. "init arranges to run the system in level 0 mode while single- user and in level 1 mode while multi-user." This sentence does not imply any direction. It just says that in single user mode you'll get level 0 and in multi-user mode you'll get level 1. I also don't understand how to not have the initial mode be -1 so that init will do this, since by the time /etc/rc is run to alter the mode, init is already running. There is no option in the kernel LINT file to set the initial mode. It sure is hard to do system maintenance unless the secure level drops back to 0 in single user mode. BSD/OS does this, and it makes sense to do so, I think. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-545-6996 GPG & MIME spoken here http://www.khera.org/~vivek/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Sep 3 11:50: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B302C37B43C for ; Sun, 3 Sep 2000 11:50:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA79989; Sun, 3 Sep 2000 11:50:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 9B58E37B43C; Sun, 3 Sep 2000 11:46:25 -0700 (PDT) Message-Id: <20000903184625.9B58E37B43C@hub.freebsd.org> Date: Sun, 3 Sep 2000 11:46:25 -0700 (PDT) From: huntting@glarp.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21016: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21016 >Category: kern >Synopsis: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 03 11:50:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Brad Huntting >Release: 4.1 >Organization: Qwest Comm >Environment: FreeBSD hunkular.glarp.com 4.1-RELEASE FreeBSD 4.1-RELEASE #0: Sat Aug 26 16:48:20 MDT 2000 root@hunkular.glarp.com:/usr/src/sys/compile/HUNKULAR i386 >Description: When passed a v4 mapped multicast address (e.g. ::ffff:239.255.24.23), setsockopt(IPV6_JOIN_GROUP) returns EINVAL. Part of the problem stems from the fact that the IN6_IS_ADDR_MULTICAST() macro in does not recognise V4 mapped addresses. Should it? And should setsockopt(IPV6_JOIN_GROUP) work on v4 mapped addresses? If you aggree that it should, let me know and I will patch the include file and the kernel accordingly. thanx, brad >How-To-Repeat: Try to use setsockopt(IPV6_JOIN_GROUP) on a v4 mapped multicast address. >Fix: I just want to make sure that this is a bug and not a feature before I go and "fix" it. Please let me know ASAP as I have a deadline to meet. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Sep 3 12:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CF8D137B43C for ; Sun, 3 Sep 2000 12:20:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA83963; Sun, 3 Sep 2000 12:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 7866737B42C for ; Sun, 3 Sep 2000 12:15:26 -0700 (PDT) Received: (qmail 10168 invoked by uid 0); 3 Sep 2000 19:15:24 -0000 Received: from p3ee2164e.dip.t-dialin.net (HELO speedy.gsinet) (62.226.22.78) by mail.gmx.net with SMTP; 3 Sep 2000 19:15:24 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id VAA07806 for FreeBSD-gnats-submit@freebsd.org; Sun, 3 Sep 2000 21:11:43 +0200 Message-Id: <20000903211143.T252@speedy.gsinet> Date: Sun, 3 Sep 2000 21:11:43 +0200 From: Gerhard Sittig To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21017: mtree's "no such file" message at job's end Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21017 >Category: bin >Synopsis: mtree "no such file" message at job's end >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 03 12:20:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Gerhard Sittig >Release: FreeBSD 4.1-STABLE i386 >Organization: in private >Environment: I've seen this on two FreeBSD 4-STABLE systems built in July and on one FreeBSD 4-STABLE system built in August. >Description: mtree -c -K $KEYS | mtree -K $KEYS produces an (IMO) erroneous "no such file" error message for large mtree -c output with a line number one bigger than the database size and a filename which "isn't real". >How-To-Repeat: I built a "tripwire lookalike" script using mtree. The database is generated with the following command: MTREE=/usr/sbin/mtree KEYLIST=nlink,type,mode,flags,uid,gid,size,time,cksum,md5digest,sha1digest,ripemd160digest for FS in / /tmp /var /usr /home; do DB=$DBDIR/`echo $FS | tr '/' '_'` EX=`[ -r $DB.ex ] && echo -X $DB.ex` $MTREE -c -K $KEYLIST -p $FS -x $EX > $DB.db done Checking the fs' content against the database is done via ... $MTREE -K $KEYLIST -p $FS -x $EX < $DB.db ... The checking command's output at the /usr fs is: mtree: line 395022: libtermcap_p.a: No such file or directory "wc _usr.db" output: 395021 929838 21246776 _usr.db "cat _usr.ex" output: ./obj/* This behaviour is repeatable here, works for "small" filesystems and fails at /usr. The other machines list "30_qmail.sh" (an /usr/local/etc/rc.d start script) and "X11" as the "missing" file which makes me say "the filename isn't really searched for or shouldn't be". It's not the last and neither is it the longest name in the list to be checked. Some statistics: stein "uname -a" output: FreeBSD stein.gsinet 4.1-STABLE FreeBSD 4.1-STABLE #0: Mon Jul 31 19:17:22 CEST 2000 root@stein.gsinet:/usr/obj/usr/src/sys/STEIN i386 stein "wc *" output (/usr fails, see above): 3455 10684 203428 _.db 395021 929838 21246776 _usr.db 1 1 8 _usr.ex 756 1741 35231 _var.db organ "uname -a" output: FreeBSD organ.gsinet 4.1-STABLE FreeBSD 4.1-STABLE #0: Tue Aug 29 01:32:17 CEST 2000 root@organ.gsinet:/usr/obj/usr/src/sys/ORGAN i386 organ "wc *" output (/home works! /usr fails): 4328 12284 250597 _.db 505369 1182903 26115651 _home.db 601 1421 36233 _mnt_DOS.db 32 75 670 _tmp.db 1361948 3202398 74490769 _usr.db 1 1 8 _usr.ex 4288 9492 197807 _var.db The third machine is further away and not accessible right now. The error looks quite random and seems to occur when huge data amounts sum up (rare / strange program paths are passed? buffers get overridden?). It's not about fix values, compare stein's /usr against organ's /home (organ has more processing power and way more RAM and this seems to matter). I don't know what's going on when encountering EOF of the database stream and what conditions have to meet to trigger this failure message. >Fix: None known yet, I couldn't even find the problem spot. But you can ask me to watch out for whatever you like -- the error is absolutely reproducable here. 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. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Sep 3 18:47:48 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from blackstar.krsu.edu.kg (blackstar.krsu.edu.kg [195.254.161.130]) by hub.freebsd.org (Postfix) with ESMTP id BCDA137B422 for ; Sun, 3 Sep 2000 18:47:42 -0700 (PDT) Received: from krsu.edu.kg (krsu.edu.kg [195.254.164.3]) by blackstar.krsu.edu.kg (8.9.1a/8.9.1) with ESMTP id IAA08580; Thu, 10 Aug 2000 08:28:14 +0600 (KGST) Received: from localhost (slash@localhost) by krsu.edu.kg (8.9.3/8.9.3) with ESMTP id HAA17435; Mon, 4 Sep 2000 07:51:05 +0600 (KGST) (envelope-from slash@krsu.edu.kg) Date: Mon, 4 Sep 2000 07:51:05 +0600 (KGST) From: CrazZzy Slash To: hostmaster@domainbank.at Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: Date changed from 31.8 to 2.9 ???? In-Reply-To: <001301c014d5$15123c00$5d4e2fd5@zippi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! You use any daemon like to ntpd? and may be energy was down? P.S. Sorry for may bad English.. :) On Sat, 2 Sep 2000 hostmaster@domainbank.at wrote: > Hi! > Last night, two strange things happened! > > 1.) The date changed from 31 August to 2 September > 2.) The machine did a automatic reboot at 04:44:17 (without umounting > filesystems) > > What was going on? > > Aug 31 20:00:56 mail sshd2[6746]: User joe, coming from 67.213.81.56, > authenticated. > Sep 2 04:44:17 mail /kernel: Copyright (c) 1992-2000 The FreeBSD Project. > Sep 2 04:44:17 mail /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 > Sep 2 04:44:17 mail /kernel: The Regents of the University of California. > All rights reserved. > Sep 2 04:44:17 mail /kernel: FreeBSD 4.0-RELEASE #0: Sat Jul 29 13:29:43 > CEST 2000 > Sep 2 04:44:17 mail /kernel: > root@mail.it4you.at:/usr/src/sys/compile/mykernel > Sep 2 04:44:17 mail /kernel: Timecounter "i8254" frequency 1193182 Hz > Sep 2 04:44:17 mail /kernel: CPU: AMD Athlon(tm) Processor (700.03-MHz > 686-class CPU) > Sep 2 04:44:17 mail /kernel: Origin = "AuthenticAMD" Id = 0x621 Stepping > = 1 > Sep 2 04:44:17 mail /kernel: > Features=0x183f9ff RR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR> > Sep 2 04:44:17 mail /kernel: AMD Features=0xc0400000 > Sep 2 04:44:17 mail /kernel: real memory = 268419072 (262128K bytes) > . > . > . > Sep 2 04:44:17 mail /kernel: Mounting root from ufs:/dev/ad0s1a > Sep 2 04:44:17 mail /kernel: WARNING: / was not properly dismounted > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-bugs" in the body of the message > -- Key fingerprint = 08 2C 60 63 FB DE A5 67 96 38 02 0F FA 9B 81 86 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Sep 3 19:50: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D34AE37B423 for ; Sun, 3 Sep 2000 19:50:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id TAA33387; Sun, 3 Sep 2000 19:50:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Sun, 3 Sep 2000 19:50:02 -0700 (PDT) Message-Id: <200009040250.TAA33387@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Matthew Kiser" Subject: Re: i386/20994: /etc/fstab or kernel not correctly installed. Reply-To: "Matthew Kiser" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/20994; it has been noted by GNATS. From: "Matthew Kiser" To: , Cc: Subject: Re: i386/20994: /etc/fstab or kernel not correctly installed. Date: Sun, 3 Sep 2000 21:49:42 -0500 Used FTP install this time from ftp.freebsd.com and all worked correctly. However, I suspect the ftp3.freebsd.com mirror may be incorrect since, like I say, I did download the 4.1-RELEASE stuff twice for a DOS Partition install, and in both cases, it appears as though the 3.1 bin distribution was applied instead of the 4.1 bin distribution. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 0:28:33 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D16CA37B423; Mon, 4 Sep 2000 00:28:31 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA75359; Mon, 4 Sep 2000 00:28:31 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 00:28:31 -0700 (PDT) From: Message-Id: <200009040728.AAA75359@freefall.freebsd.org> To: khera@kciLink.com, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/20974: securelevel not reset when going to single user mode Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: securelevel not reset when going to single user mode State-Changed-From-To: feedback->open State-Changed-By: sheldonh State-Changed-When: Mon Sep 4 00:27:16 PDT 2000 State-Changed-Why: Okay, I see where I'm going wrong. I'm arguing that the manual page is not inaccurate. The originator is arguing that FreeBSD doesn't handle securelevel on return to single-user mode the same way that BSD/OS does and maintains that the BSD/OS behaviour is more useful. http://www.freebsd.org/cgi/query-pr.cgi?pr=20974 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 2:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2C5F137B423 for ; Mon, 4 Sep 2000 02:20:05 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id CAA95199; Mon, 4 Sep 2000 02:20:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 4 Sep 2000 02:20:05 -0700 (PDT) Message-Id: <200009040920.CAA95199@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Dag-Erling Smorgrav Subject: Re: misc/20985: Cannot create pwd.db with passwd file exceeding 65535 users. Reply-To: Dag-Erling Smorgrav Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/20985; it has been noted by GNATS. From: Dag-Erling Smorgrav To: lenwilliams@aplus.net Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: misc/20985: Cannot create pwd.db with passwd file exceeding 65535 users. Date: 04 Sep 2000 11:14:06 +0200 lenwilliams@aplus.net writes: > pwd_mkdb generates the following error upon reaching uid of 65535. It's just a warning. Some file systems (e.g. NFS) can't handle UIDs above 65535. > Will increasing "maxusers" resolve this? No. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 4:43:21 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 96B8437B423; Mon, 4 Sep 2000 04:43:19 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA16821; Mon, 4 Sep 2000 04:43:19 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 04:43:19 -0700 (PDT) From: Message-Id: <200009041143.EAA16821@freefall.freebsd.org> To: lenwilliams@aplus.net, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: misc/20985: Cannot create pwd.db with passwd file exceeding 65535 users. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Cannot create pwd.db with passwd file exceeding 65535 users. State-Changed-From-To: open->closed State-Changed-By: sheldonh State-Changed-When: Mon Sep 4 04:40:41 PDT 2000 State-Changed-Why: If the warnings bug you, pwd_mkdb(8) in FreeBSD 3.5-RELEASE and above support an environment variable, PW_SCAN_BIG_IDS, in the presence of which the warnings are silenced. Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 04:40:41 PDT 2000 Responsible-Changed-Why: Added PW_SCAN_BIG_IDS. http://www.freebsd.org/cgi/query-pr.cgi?pr=20985 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 4:50:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9F6BC37B42C for ; Mon, 4 Sep 2000 04:50:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA18480; Mon, 4 Sep 2000 04:50:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 4 Sep 2000 04:50:03 -0700 (PDT) Message-Id: <200009041150.EAA18480@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: bin/20974: securelevel not reset when going to single user mode Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20974; it has been noted by GNATS. From: Sheldon Hearn To: Vivek Khera Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/20974: securelevel not reset when going to single user mode Date: Mon, 04 Sep 2000 13:39:46 +0200 On Sun, 03 Sep 2000 08:30:06 MST, Vivek Khera wrote: > It sure is hard to do system maintenance unless the secure level drops > back to 0 in single user mode. BSD/OS does this, and it makes sense > to do so, I think. The CVS logs for init.c revealed something interesting: | revision 1.36 | date: 1999/09/06 08:41:32; author: kato; state: Exp; lines: +1 -7 | FreeBSD kernel doesn't allow any process to decrease securelevel. So, | init(8) cannot decrease securelevel. The manual page explains this | and single_user() doesn't try to downgrade kernel to insecure mode. | | Reviewed by: bde (manual page) As I said before, I don't think that the manual page describes the reality of the sitation. So now the issue is whether we want to allow the same behaviour as BSD/OS exhibits, and if so, how to teach the kernel to allow the dropping of the securelevel. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 4:50:12 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9AA9B37B43C for ; Mon, 4 Sep 2000 04:50:05 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA18489; Mon, 4 Sep 2000 04:50:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 4 Sep 2000 04:50:05 -0700 (PDT) Message-Id: <200009041150.EAA18489@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: i386/20994: /etc/fstab or kernel not correctly installed. Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/20994; it has been noted by GNATS. From: Sheldon Hearn To: "Matthew Kiser" Cc: freebsd-gnats-submit@freebsd.org Subject: Re: i386/20994: /etc/fstab or kernel not correctly installed. Date: Mon, 04 Sep 2000 13:48:15 +0200 On Sun, 03 Sep 2000 19:50:02 MST, "Matthew Kiser" wrote: > Used FTP install this time from ftp.freebsd.com and all worked > correctly. However, I suspect the ftp3.freebsd.com mirror may be > incorrect since, like I say, I did download the 4.1-RELEASE stuff > twice for a DOS Partition install, and in both cases, it appears as > though the 3.1 bin distribution was applied instead of the 4.1 bin > distribution. For the installation that failed, were you using an existing /stand/sysinstall from a previous installation, or were you using sysinstall as loaded from the floppies supplied with the release? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 5:10: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A5C9D37B43F for ; Mon, 4 Sep 2000 05:10:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA22922; Mon, 4 Sep 2000 05:10:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from rr.com (rdu25-12-060.nc.rr.com [24.25.12.60]) by hub.freebsd.org (Postfix) with ESMTP id 6AFE837B424 for ; Mon, 4 Sep 2000 05:06:19 -0700 (PDT) Received: (from rhh@localhost) by rr.com (8.9.3/8.9.3) id IAA01191; Mon, 4 Sep 2000 08:09:15 -0400 (EDT) (envelope-from rhh) Message-Id: <200009041209.IAA01191@rr.com> Date: Mon, 4 Sep 2000 08:09:15 -0400 (EDT) From: aa8vb@nc.rr.com Reply-To: aa8vb@nc.rr.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21024: pow() ERANGE bug Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21024 >Category: bin >Synopsis: pow() ERANGE bug >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 04 05:10:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Randall Hopper >Release: FreeBSD 3.4-RELEASE i386 >Organization: self >Environment: Stock 3.4-RELEASE. >Description: According to the man page: The functions exp(), expm1(), pow() detect if the computed value will overflow, set the global variable errno to ERANGE, and ... However, pow() does not set errno to ERANGE on overflow. >How-To-Repeat: Example: The attached code generates: Inf 0 The output should be: Inf 34 (34 is ERANGE) #include #include #include #include main() { fpsetmask(0); printf( "%g\n", pow(1e300,2) ); pow(1e300,2); printf( "%d\n", errno ); } >Fix: Please update the pow() function to set errno on overflow. Might also check other likely suspects such as exp() and expm1(). --Thanks. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 6:30: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8D65437B43C for ; Mon, 4 Sep 2000 06:30:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA34796; Mon, 4 Sep 2000 06:30:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 56A1737B422; Mon, 4 Sep 2000 06:25:06 -0700 (PDT) Message-Id: <20000904132506.56A1737B422@hub.freebsd.org> Date: Mon, 4 Sep 2000 06:25:06 -0700 (PDT) From: kositsyn@chas.ru To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: misc/21025: BTX loader 1.00 gets 1Gb of memory from BIOS instead of 56Kb Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21025 >Category: misc >Synopsis: BTX loader 1.00 gets 1Gb of memory from BIOS instead of 56Kb >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 04 06:30:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Andrew Kositsyn >Release: 4.1-RELEASE >Organization: JSCB Private Bank Ltd >Environment: BTX loader 1.00 BTX verion is 1.01 AcerAltos 9000V 2xP100, 56Mb in 8 SIMMs, AIC7880P >Description: When booting from installation diskettes ACER BIOS shows following: Base Memory : 640 KB Extended Memory : 56320 KB while BTX loader shows another picture: BIOS 639kB/1070100kB available memory And when the loader starts kernel PC's screen flashes several times and machine reboots. While the screen is flashing I can see a part of 'To many holes at ... memory' message. My older FreeBSD boot loader shows following and everything worked well >How-To-Repeat: Every try to install the system. >Fix: Nope :( >Release-Note: >Audit-Trail: >Unformatted: >> FreeBSD BOOT @ 0x10000: 639/56320 k of memory, internal console The diskette set is good because it works well for the other computers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 6:31:32 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E6CCC37B423; Mon, 4 Sep 2000 06:31:30 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA35112; Mon, 4 Sep 2000 06:31:30 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 06:31:30 -0700 (PDT) From: Message-Id: <200009041331.GAA35112@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, ume@FreeBSD.org Subject: Re: kern/21016: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses Responsible-Changed-From-To: freebsd-bugs->ume Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 06:31:20 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21016 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 6:33:22 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5082037B443; Mon, 4 Sep 2000 06:33:19 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA35296; Mon, 4 Sep 2000 06:33:19 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 06:33:19 -0700 (PDT) From: Message-Id: <200009041333.GAA35296@freefall.freebsd.org> To: ishizuka@ish.org, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/21009: /etc/security make the system hangup Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: /etc/security make the system hangup State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Mon Sep 4 06:32:11 PDT 2000 State-Changed-Why: Please explain what "crashs system" means. Since the environment you describe is hard to set up (especially given that you don't define "too many files"), this will be easier to investigate based on the actual error messages you see. http://www.freebsd.org/cgi/query-pr.cgi?pr=21009 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 6:38:14 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F29B037B43C; Mon, 4 Sep 2000 06:38:12 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA42502; Mon, 4 Sep 2000 06:38:12 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 06:38:12 -0700 (PDT) From: Message-Id: <200009041338.GAA42502@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, msmith@FreeBSD.org Subject: Re: misc/21025: BTX loader 1.00 gets 1Gb of memory from BIOS instead of 56Kb Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: BTX loader 1.00 gets 1Gb of memory from BIOS instead of 56Kb Responsible-Changed-From-To: freebsd-bugs->msmith Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 06:37:54 PDT 2000 Responsible-Changed-Why: Mike's code. http://www.freebsd.org/cgi/query-pr.cgi?pr=21025 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 6:43:58 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5F76637B422; Mon, 4 Sep 2000 06:43:57 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA60212; Mon, 4 Sep 2000 06:43:57 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 06:43:57 -0700 (PDT) From: Message-Id: <200009041343.GAA60212@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: kern/21000: 4.1-STABLE doesn't have card ID Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: 4.1-STABLE doesn't have card ID Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 06:43:44 PDT 2000 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=21000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 6:54:41 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F11A237B422; Mon, 4 Sep 2000 06:54:39 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA98220; Mon, 4 Sep 2000 06:54:39 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 06:54:39 -0700 (PDT) From: Message-Id: <200009041354.GAA98220@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, kris@FreeBSD.org Subject: Re: bin/20996: permissions on /usr/bin/opiepasswd Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: permissions on /usr/bin/opiepasswd Responsible-Changed-From-To: freebsd-bugs->kris Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 06:54:24 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=20996 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 7: 0:13 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9AB7637B440 for ; Mon, 4 Sep 2000 07:00:08 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA00421; Mon, 4 Sep 2000 07:00:08 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from bbnrel4.net.external.hp.com (bbnrel4.net.external.hp.com [155.208.254.68]) by hub.freebsd.org (Postfix) with ESMTP id A04E437B424 for ; Mon, 4 Sep 2000 06:59:50 -0700 (PDT) Received: from hpcpbla.bri.hp.com (hpcpbla.bri.hp.com [15.144.112.65]) by bbnrel4.net.external.hp.com (Postfix) with ESMTP id 8E62F15233 for ; Mon, 4 Sep 2000 15:59:48 +0200 (METDST) Received: from sse0691.bri.hp.com (sse0691.bri.hp.com [15.144.0.53]) by hpcpbla.bri.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.0) with ESMTP id OAA29277 for ; Mon, 4 Sep 2000 14:59:47 +0100 (BST) Received: (from steve@localhost) by sse0691.bri.hp.com (8.9.3/8.9.3) id PAA15125; Mon, 4 Sep 2000 15:02:45 +0100 (BST) (envelope-from steve) Message-Id: <200009041402.PAA15125@sse0691.bri.hp.com> Date: Mon, 4 Sep 2000 15:02:45 +0100 (BST) From: Steve Roome Reply-To: steve@sse0691.bri.hp.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: gnu/21026: gcc bug with -mno-ieee-fp and -march=pentiumpro Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21026 >Category: gnu >Synopsis: gcc bug with -mno-ieee-fp and -march=pentiumpro >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 04 07:00:08 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Steve Roome >Release: FreeBSD 4.1-STABLE i386 >Organization: >Environment: 4.1-stable gcc version 2.95.2 19991024 (release) >Description: compiling code with -mno-ieee-fp and -march=pentiumpro cause cc1 to die with sig11 on comparison between float and integer e.g. gcc -mno-ieee-fp -march=pentiumpro -c particlesys.c -o particlesys.o gcc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 >How-To-Repeat: int main() { double xv=0.2; return (xv>0); } try to compile the above with -mno-ieee-fp and -march=pentiumpro >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 7: 0:44 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8917837B422; Mon, 4 Sep 2000 07:00:43 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA00573; Mon, 4 Sep 2000 07:00:43 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 07:00:43 -0700 (PDT) From: Message-Id: <200009041400.HAA00573@freefall.freebsd.org> To: Martin.Karsten@KOM.tu-darmstadt.de, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/20984: conflict between IP_RSVP_ON and IP_RSVP_VIF_ON Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: conflict between IP_RSVP_ON and IP_RSVP_VIF_ON State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Mon Sep 4 06:58:26 PDT 2000 State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=20984 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 7: 1: 2 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1B83E37B423; Mon, 4 Sep 2000 07:01:01 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA00665; Mon, 4 Sep 2000 07:01:01 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 07:01:01 -0700 (PDT) From: Message-Id: <200009041401.HAA00665@freefall.freebsd.org> To: Martin.Karsten@KOM.tu-darmstadt.de, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/20984: conflict between IP_RSVP_ON and IP_RSVP_VIF_ON Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: conflict between IP_RSVP_ON and IP_RSVP_VIF_ON State-Changed-From-To: feedback->open State-Changed-By: sheldonh State-Changed-When: Mon Sep 4 07:00:46 PDT 2000 State-Changed-Why: Status changed in error. http://www.freebsd.org/cgi/query-pr.cgi?pr=20984 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 7: 3:20 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CCCA037B42C; Mon, 4 Sep 2000 07:03:18 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA00900; Mon, 4 Sep 2000 07:03:18 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 07:03:18 -0700 (PDT) From: Message-Id: <200009041403.HAA00900@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, jim@FreeBSD.org Subject: Re: ports/20988: Yahoo has obsoleted instant messenger protocol used by 4.1 everybuddy Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Yahoo has obsoleted instant messenger protocol used by 4.1 everybuddy Responsible-Changed-From-To: freebsd-bugs->jim Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 07:02:42 PDT 2000 Responsible-Changed-Why: Jim is the maintainer of the everybuddy port. http://www.freebsd.org/cgi/query-pr.cgi?pr=20988 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 7: 3:54 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B205437B43C; Mon, 4 Sep 2000 07:03:51 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA01025; Mon, 4 Sep 2000 07:03:51 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 07:03:51 -0700 (PDT) From: Message-Id: <200009041403.HAA01025@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, knu@FreeBSD.org Subject: Re: misc/20989: http://www.freebsd.org/cgi/cvsweb.cgi annotate omits newlines Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: http://www.freebsd.org/cgi/cvsweb.cgi annotate omits newlines Responsible-Changed-From-To: freebsd-bugs->knu Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 07:03:36 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=20989 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 7:55:15 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BDC0637B424; Mon, 4 Sep 2000 07:55:13 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA08841; Mon, 4 Sep 2000 07:55:13 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 07:55:13 -0700 (PDT) From: Message-Id: <200009041455.HAA08841@freefall.freebsd.org> To: lyndon@orthanc.ab.ca, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: bin/20990: [PATCH] acap missing from /etc/services Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: [PATCH] acap missing from /etc/services State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Mon Sep 4 07:54:41 PDT 2000 State-Changed-Why: Any reason to omit the udp version? Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 07:54:41 PDT 2000 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=20990 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 8: 5:15 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CABAA37B43E; Mon, 4 Sep 2000 08:05:13 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA10944; Mon, 4 Sep 2000 08:05:13 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 08:05:13 -0700 (PDT) From: Message-Id: <200009041505.IAA10944@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, obrien@FreeBSD.org Subject: Re: gnu/21026: gcc bug with -mno-ieee-fp and -march=pentiumpro Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: gcc bug with -mno-ieee-fp and -march=pentiumpro Responsible-Changed-From-To: freebsd-bugs->obrien Responsible-Changed-By: sheldonh Responsible-Changed-When: Mon Sep 4 08:04:45 PDT 2000 Responsible-Changed-Why: The problem exists in 5.0-CURRENT as well. Over to the maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21026 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 8:10: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B506F37B43E for ; Mon, 4 Sep 2000 08:10:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA12781; Mon, 4 Sep 2000 08:10:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 4 Sep 2000 08:10:01 -0700 (PDT) Message-Id: <200009041510.IAA12781@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/20992; it has been noted by GNATS. From: Sheldon Hearn To: phk@freebsd.org, peter@freebsd.org Cc: freebsd-gnats-submit@freebsd.org Subject: re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Date: Mon, 04 Sep 2000 17:01:50 +0200 Hi gents, Could you two take a look at PR kern/20992? The reported error message was introduced by Peter, but it looks like it may have been tickled by Poul-Henning's change to the dgb(4) driver. Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 8:21:35 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 370FE37B422; Mon, 4 Sep 2000 08:21:34 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA14527; Mon, 4 Sep 2000 08:21:34 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Mon, 4 Sep 2000 08:21:34 -0700 (PDT) From: Message-Id: <200009041521.IAA14527@freefall.freebsd.org> To: shikut@belpak.brest.by, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Mon Sep 4 08:19:51 PDT 2000 State-Changed-Why: What's the value associated with maxusers in your kernel config? http://www.freebsd.org/cgi/query-pr.cgi?pr=20992 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 8:30:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 40A5C37B43C for ; Mon, 4 Sep 2000 08:30:05 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA15784; Mon, 4 Sep 2000 08:30:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 4 Sep 2000 08:30:05 -0700 (PDT) Message-Id: <200009041530.IAA15784@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Poul-Henning Kamp Subject: Re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Reply-To: Poul-Henning Kamp Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/20992; it has been noted by GNATS. From: Poul-Henning Kamp To: Sheldon Hearn Cc: peter@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Date: Mon, 04 Sep 2000 17:14:23 +0200 In message <56677.968079710@axl.fw.uunet.co.za>, Sheldon Hearn writes: > >Hi gents, > >Could you two take a look at PR kern/20992? The reported error message >was introduced by Peter, but it looks like it may have been tickled by >Poul-Henning's change to the dgb(4) driver. Hmm, I think I have to pass on this one. I just checked the changes I've made and I don't see any which I can implicate in this. Are you sure there are enough kernel resources for your needs ? Consider yanking maxusers up a bit... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 8:49:34 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id D222B37B423 for ; Mon, 4 Sep 2000 08:49:31 -0700 (PDT) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id TAA09211; Mon, 4 Sep 2000 19:49:22 +0400 (MSD) Message-Id: <200009041549.TAA09211@aaz.links.ru> Subject: Re: bin/20974: securelevel not reset when going to single user mode In-Reply-To: <200009041150.EAA18480@freefall.freebsd.org> from "Sheldon Hearn" at "Sep 4, 0 04:50:03 am" To: sheldonh@uunet.co.za Date: Mon, 4 Sep 2000 19:49:22 +0400 (MSD) Cc: freebsd-bugs@FreeBSD.ORG From: "Aleksandr A.Babaylov" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sheldon Hearn writes: > The following reply was made to PR bin/20974; it has been noted by GNATS. > > From: Sheldon Hearn > To: Vivek Khera > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: bin/20974: securelevel not reset when going to single user mode > Date: Mon, 04 Sep 2000 13:39:46 +0200 > > On Sun, 03 Sep 2000 08:30:06 MST, Vivek Khera wrote: > > > It sure is hard to do system maintenance unless the secure level drops > > back to 0 in single user mode. BSD/OS does this, and it makes sense > > to do so, I think. > > The CVS logs for init.c revealed something interesting: > > | revision 1.36 > | date: 1999/09/06 08:41:32; author: kato; state: Exp; lines: +1 -7 > | FreeBSD kernel doesn't allow any process to decrease securelevel. So, > | init(8) cannot decrease securelevel. The manual page explains this > | and single_user() doesn't try to downgrade kernel to insecure mode. > | > | Reviewed by: bde (manual page) > > As I said before, I don't think that the manual page describes the > reality of the sitation. > > So now the issue is whether we want to allow the same behaviour as > BSD/OS exhibits, and if so, how to teach the kernel to allow the > dropping of the securelevel. I propose change via options in config file, because current state is very useful > Ciao, > Sheldon. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 8:50: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0A64D37B424 for ; Mon, 4 Sep 2000 08:50:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA18799; Mon, 4 Sep 2000 08:50:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from front002.cluster1.charter.net (24-216-159-200.hsacorp.net [24.216.159.200]) by hub.freebsd.org (Postfix) with ESMTP id 0B27B37B422 for ; Mon, 4 Sep 2000 08:43:27 -0700 (PDT) Received: from [24.216.138.156] (HELO gforce.johnson.home) by front002.cluster1.charter.net (CommuniGate Pro SMTP 3.2.4) with ESMTP id 17904716 for FreeBSD-gnats-submit@freebsd.org; Mon, 04 Sep 2000 11:42:04 -0400 Received: (from glenn@localhost) by gforce.johnson.home (8.9.3/8.9.3) id KAA08770; Mon, 4 Sep 2000 10:43:23 -0500 (CDT) (envelope-from glenn) Message-Id: <200009041543.KAA08770@gforce.johnson.home> Date: Mon, 4 Sep 2000 10:43:23 -0500 (CDT) From: glennpj@charter.net Reply-To: glennpj@charter.net To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/21028: Add Zoom V90 Internal modem support Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21028 >Category: kern >Synopsis: Add Zoom V90 Internal modem support >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Sep 04 08:50:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Glenn Johnson >Release: FreeBSD 4.1-STABLE i386 >Organization: >Environment: >Description: The patch adds support for the Zoom V90 Internal modem. This modem is a PnP modem that also has jumpers. One of the jumpers toggles PnP mode on/off. This patch allows this modem to work in PnP mode. >How-To-Repeat: >Fix: Apply the patch to sys/isa/sio.c to allow FreeBSD to recognize this modem in PnP mode. --- sio.c.orig Tue Aug 15 16:05:30 2000 +++ sio.c Sat Aug 26 17:38:00 2000 @@ -716,6 +716,7 @@ {0x90917256, NULL}, /* USR9190 - USR 56k Voice INT */ {0x0300695c, NULL}, /* WCI0003 - Fax/Voice/Modem/Speakphone/Asvd */ {0x61f7896a, NULL}, /* ZTIF761 - Zoom ComStar 33.6 */ + {0x01a0896a, NULL}, /* ZTIA001 - Zoom Internal V90 Faxmodem */ {0} }; >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 9: 0: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6F8AF37B42C for ; Mon, 4 Sep 2000 09:00:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA20152; Mon, 4 Sep 2000 09:00:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 4 Sep 2000 09:00:03 -0700 (PDT) Message-Id: <200009041600.JAA20152@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Aleksandr A.Babaylov" Subject: Re: bin/20974: securelevel not reset when going to single user mode Reply-To: "Aleksandr A.Babaylov" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20974; it has been noted by GNATS. From: "Aleksandr A.Babaylov" To: sheldonh@uunet.co.za Cc: freebsd-bugs@freebsd.org Subject: Re: bin/20974: securelevel not reset when going to single user mode Date: Mon, 4 Sep 2000 19:49:22 +0400 (MSD) Sheldon Hearn writes: > The following reply was made to PR bin/20974; it has been noted by GNATS. > > From: Sheldon Hearn > To: Vivek Khera > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: bin/20974: securelevel not reset when going to single user mode > Date: Mon, 04 Sep 2000 13:39:46 +0200 > > On Sun, 03 Sep 2000 08:30:06 MST, Vivek Khera wrote: > > > It sure is hard to do system maintenance unless the secure level drops > > back to 0 in single user mode. BSD/OS does this, and it makes sense > > to do so, I think. > > The CVS logs for init.c revealed something interesting: > > | revision 1.36 > | date: 1999/09/06 08:41:32; author: kato; state: Exp; lines: +1 -7 > | FreeBSD kernel doesn't allow any process to decrease securelevel. So, > | init(8) cannot decrease securelevel. The manual page explains this > | and single_user() doesn't try to downgrade kernel to insecure mode. > | > | Reviewed by: bde (manual page) > > As I said before, I don't think that the manual page describes the > reality of the sitation. > > So now the issue is whether we want to allow the same behaviour as > BSD/OS exhibits, and if so, how to teach the kernel to allow the > dropping of the securelevel. I propose change via options in config file, because current state is very useful > Ciao, > Sheldon. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 9: 2:34 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from itojun.org (dhcp0.itojun.org [210.160.95.106]) by hub.freebsd.org (Postfix) with ESMTP id 1108E37B423 for ; Mon, 4 Sep 2000 09:02:32 -0700 (PDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e84G24X23369; Tue, 5 Sep 2000 01:02:04 +0900 (JST) Message-Id: <200009041602.e84G24X23369@itojun.org> Cc: Hajimu UMEMOTO Cc: core@kame.net To: bugs@freebsd.org To: huntting@glarp.com In-reply-to: ume's message of Tue, 05 Sep 2000 00:34:42 JST. <20000905.003442.96675651.ume@mahoroba.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: kern/21016: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses From: Jun-ichiro itojun Hagino Date: Tue, 05 Sep 2000 01:02:04 +0900 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Description > When passed a v4 mapped multicast address (e.g. ::ffff:239.255.24.23), > setsockopt(IPV6_JOIN_GROUP) returns EINVAL. Part of the problem stems > from the fact that the IN6_IS_ADDR_MULTICAST() macro in > does not recognise V4 mapped addresses. Should it? And should > setsockopt(IPV6_JOIN_GROUP) work on v4 mapped addresses? If you aggree > that it should, let me know and I will patch the include file and the > kernel accordingly. > >How-To-Repeat > Try to use setsockopt(IPV6_JOIN_GROUP) on a v4 mapped multicast address. > >Fix > I just want to make sure that this is a bug and not a feature before > I go and "fix" it. Please let me know ASAP as I have a deadline to meet. this is a feature. IPv4 mapped address on AF_INET6 socket is just to help porting basic IPv4 apps at ease. to manipulate IPv4 traffic in detail (including TOS/TTL, or multicast), you must use AF_INET socket. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 13:10: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A97A837B43F for ; Mon, 4 Sep 2000 13:10:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id NAA55507; Mon, 4 Sep 2000 13:10:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from gwdu60.gwdg.de (gwdu60.gwdg.de [134.76.98.60]) by hub.freebsd.org (Postfix) with ESMTP id 63E3D37B424 for ; Mon, 4 Sep 2000 13:03:55 -0700 (PDT) Received: (from dtanke@localhost) by gwdu60.gwdg.de (8.9.3/8.9.3) id WAA41103; Mon, 4 Sep 2000 22:03:52 +0200 (CEST) (envelope-from dtanke) Message-Id: <200009042003.WAA41103@gwdu60.gwdg.de> Date: Mon, 4 Sep 2000 22:03:52 +0200 (CEST) From: Dietmar Tanke Reply-To: dtanke@gwdu60.gwdg.de To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21039: date -v31d -v08m -v2000y Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21039 >Category: bin >Synopsis: date -v31d -v08m -v2000y >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 04 13:10:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Dietmar Tanke >Release: FreeBSD 4.1-RELEASE i386 >Organization: University of G¨o;ttingen, Germany >Environment: FreeBSD gwdu60.gwdg.de 4.1-RELEASE FreeBSD 4.1-RELEASE #0: Mon Aug 7 10:27:48 CEST 2000 root@gwdp98.gwdg.de:/usr/src/sys/compile/GWDU60 i386 >Description: Date adjustment using the -v option seems not work for any date with the 31th day of a month. Two examples. First one with a good result and the second leads to an unexpected error. Is it a bug? dtanke$ date -v30d -v08m -v2000y Wed Aug 30 21:27:24 CEST 2000 dtanke$ date -v31d -v08m -v2000y 31d: Cannot apply date adjustment This example with "31" works well with 4.1 RELEASE. dtanke$ date -jf "%d.%m.%Y" 31.08.2000 Do 31 Aug 2000 21:38:15 CEST >How-To-Repeat: Same results with 2.2.8, 3.2, 4.0 and 4.1 RELEASE. >Fix: I am no programmer, sorry. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 13:36: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id E861B37B42C; Mon, 4 Sep 2000 13:36:06 -0700 (PDT) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e84Ka3k33917; Mon, 4 Sep 2000 14:36:04 -0600 (MDT) Message-Id: <200009042036.e84Ka3k33917@orthanc.ab.ca> To: sheldonh@FreeBSD.ORG Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/20990: [PATCH] acap missing from /etc/services In-reply-to: Your message of "Mon, 04 Sep 2000 07:55:13 PDT." <200009041455.HAA08841@freefall.freebsd.org> Date: Mon, 04 Sep 2000 14:36:03 -0600 From: Lyndon Nerenberg Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "sheldonh" == writes: sheldonh> Any reason to omit the udp version? ACAP requires a reliable stream transport. It won't run over UDP. I doubt IANA assigned a UDP port to it. IF they did, add it I guess, although it makes no sense to have a UDP entry. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 13:50: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6895137B424 for ; Mon, 4 Sep 2000 13:50:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id NAA59912; Mon, 4 Sep 2000 13:50:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 4 Sep 2000 13:50:02 -0700 (PDT) Message-Id: <200009042050.NAA59912@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Paul Herman Subject: Re: bin/21039: date -v31d -v08m -v2000y Reply-To: Paul Herman Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21039; it has been noted by GNATS. From: Paul Herman To: Dietmar Tanke Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/21039: date -v31d -v08m -v2000y Date: Mon, 4 Sep 2000 22:46:16 +0200 (CEST) On Mon, 4 Sep 2000, Dietmar Tanke wrote: > >Description: > Date adjustment using the -v option seems not work for any date with > the 31th day of a month. Two examples. First one with a good result > and the second leads to an unexpected error. Is it a bug? > > dtanke$ date -v30d -v08m -v2000y > Wed Aug 30 21:27:24 CEST 2000 The order of the "-v"s are important. bash-2.03$ date -v8m -v31d -v2000y Thu Aug 31 22:45:03 CEST 2000 Try it next month and it'll work no matter what the order. :-) -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 13:51:28 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id 194D737B424 for ; Mon, 4 Sep 2000 13:51:27 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id OAA72183; Mon, 4 Sep 2000 14:51:17 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200009042051.OAA72183@hunkular.glarp.com> To: Jun-ichiro itojun Hagino Cc: bugs@freebsd.org, huntting@glarp.com, Hajimu UMEMOTO , core@kame.net Subject: Re: kern/21016: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses In-Reply-To: Your message of "Tue, 05 Sep 2000 01:02:04 +0900." <200009041602.e84G24X23369@itojun.org> Date: Mon, 04 Sep 2000 14:51:16 -0600 From: Brad Huntting Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > this is a feature. IPv4 mapped address on AF_INET6 socket is just > to help porting basic IPv4 apps at ease. to manipulate IPv4 traffic > in detail (including TOS/TTL, or multicast), you must use AF_INET > socket. Section 3.7 of draft-ietf-ipngwg-rfc2553bis-00.txt does not aggre. V4 mapped addresses are clearly intended to allow "basic" v6 apps to interoperate with legacy v4 apps w/o duplicating code. And "basic" in this case most definitly includes multicast. Is KAME planning on fixing this anytime soon? brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 14:57:50 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 09ED537B423; Mon, 4 Sep 2000 14:57:49 -0700 (PDT) Received: (from brian@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA68894; Mon, 4 Sep 2000 14:57:49 -0700 (PDT) (envelope-from brian@FreeBSD.org) Date: Mon, 4 Sep 2000 14:57:49 -0700 (PDT) From: Message-Id: <200009042157.OAA68894@freefall.freebsd.org> To: dtanke@gwdu60.gwdg.de, brian@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/21039: date -v31d -v08m -v2000y Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: date -v31d -v08m -v2000y State-Changed-From-To: open->closed State-Changed-By: brian State-Changed-When: Mon Sep 4 14:55:25 PDT 2000 State-Changed-Why: As Paul says, the -v options are processed in the order given (as mentioned in the man page). Doing things most-significant first will make things work for you. http://www.freebsd.org/cgi/query-pr.cgi?pr=21039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 15:14:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4581A37B422; Mon, 4 Sep 2000 15:14:09 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id PAA72027; Mon, 4 Sep 2000 15:14:09 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 4 Sep 2000 15:14:09 -0700 (PDT) From: Kris Kennaway Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@freebsd.org Subject: Re: bin/20996: permissions on /usr/bin/opiepasswd In-Reply-To: <200009041354.GAA98220@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 4 Sep 2000 sheldonh@FreeBSD.org wrote: > Synopsis: permissions on /usr/bin/opiepasswd Thanks - I've known about this for some time, but wanted to do a source code audit of opiepasswd before giving it the setuid bit. I'll try and get to it soon. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 15:22:35 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3C03337B424; Mon, 4 Sep 2000 15:22:34 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA72779; Mon, 4 Sep 2000 15:22:34 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 15:22:34 -0700 (PDT) From: Message-Id: <200009042222.PAA72779@freefall.freebsd.org> To: marcs@znep.com, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/4696: ping hangs on certain unresolvable hosts Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: ping hangs on certain unresolvable hosts State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 15:21:48 PDT 2000 State-Changed-Why: Fixed by sef in r1.24 of ping.c on 1997/07/13 http://www.freebsd.org/cgi/query-pr.cgi?pr=4696 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 15:24:10 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B9EC837B422; Mon, 4 Sep 2000 15:24:08 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA72907; Mon, 4 Sep 2000 15:24:08 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 15:24:08 -0700 (PDT) From: Message-Id: <200009042224.PAA72907@freefall.freebsd.org> To: shmit@kublai.com, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/5847: Makeworld fails if CXXFLAGS is set. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Makeworld fails if CXXFLAGS is set. State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 15:23:35 PDT 2000 State-Changed-Why: See /etc/defaults/make.conf for examples of how to correctly set CXXFLAGS: # CXXFLAGS controls the compiler settings used when compiling C++ code. # Note that CXXFLAGS is initially set to the value of CFLAGS. If you wish # to add to CXXFLAGS value, "+=" must be used rather than "=". Using "=" # alone will remove the often needed contents of CFLAGS from CXXFLAGS. # #CXXFLAGS+= -fmemoize-lookups -fsave-memoized # http://www.freebsd.org/cgi/query-pr.cgi?pr=5847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 15:26:22 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2B18437B423; Mon, 4 Sep 2000 15:26:21 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA73227; Mon, 4 Sep 2000 15:26:21 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 15:26:21 -0700 (PDT) From: Message-Id: <200009042226.PAA73227@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, kris@FreeBSD.org Subject: Re: bin/9770: An openpty(3) auxiliary program Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: An openpty(3) auxiliary program Responsible-Changed-From-To: freebsd-bugs->kris Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 15:26:06 PDT 2000 Responsible-Changed-Why: This looks interesting, I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=9770 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 15:36:43 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0DA2A37B422; Mon, 4 Sep 2000 15:36:42 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA74056; Mon, 4 Sep 2000 15:36:42 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 15:36:42 -0700 (PDT) From: Message-Id: <200009042236.PAA74056@freefall.freebsd.org> To: easmith@beatrice.rutgers.edu, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, kris@FreeBSD.org Subject: Re: misc/6773: [PATCH] tempnam.c security problems Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: [PATCH] tempnam.c security problems State-Changed-From-To: suspended->open State-Changed-By: kris State-Changed-When: Mon Sep 4 15:35:23 PDT 2000 State-Changed-Why: I'll look at this. Responsible-Changed-From-To: freebsd-bugs->kris Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 15:35:23 PDT 2000 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=6773 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 15:53: 3 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 92F2D37B424; Mon, 4 Sep 2000 15:53:02 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA76012; Mon, 4 Sep 2000 15:53:02 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 15:53:02 -0700 (PDT) From: Message-Id: <200009042253.PAA76012@freefall.freebsd.org> To: lx@hosix.ntu-kpi.kiev.ua, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/7019: [security] pwd.db almost always contains /etc/shells Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: [security] pwd.db almost always contains /etc/shells State-Changed-From-To: suspended->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 15:49:40 PDT 2000 State-Changed-Why: This is expected behaviour: pwd.db contains the fields in /etc/passwd in database format, which includes the shell and home directory fields If this bothers you, create a copy of /etc/passwd with all of the home directories and shells reset to a dummy value, and use pwd_mkdb on that. http://www.freebsd.org/cgi/query-pr.cgi?pr=7019 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 15:56:43 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8711B37B422; Mon, 4 Sep 2000 15:56:41 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA76500; Mon, 4 Sep 2000 15:56:41 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 15:56:41 -0700 (PDT) From: Message-Id: <200009042256.PAA76500@freefall.freebsd.org> To: estartu@augusta.de, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/12221: djpeg halt's freebsd box Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: djpeg halt's freebsd box State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 15:55:57 PDT 2000 State-Changed-Why: This was most likely hardware problems when running the system under load. http://www.freebsd.org/cgi/query-pr.cgi?pr=12221 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 15:58:40 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6FDAD37B424; Mon, 4 Sep 2000 15:58:39 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA76753; Mon, 4 Sep 2000 15:58:39 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 15:58:39 -0700 (PDT) From: Message-Id: <200009042258.PAA76753@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, assar@FreeBSD.org Subject: Re: misc/11478: Non-functional AFS support in KerberosIV library. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Non-functional AFS support in KerberosIV library. Responsible-Changed-From-To: freebsd-bugs->assar Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 15:58:17 PDT 2000 Responsible-Changed-Why: Assar is Mr AFS and Kerberos http://www.freebsd.org/cgi/query-pr.cgi?pr=11478 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16: 8: 2 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 37F8A37B424; Mon, 4 Sep 2000 16:08:01 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA79155; Mon, 4 Sep 2000 16:08:01 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:08:01 -0700 (PDT) From: Message-Id: <200009042308.QAA79155@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, jkh@FreeBSD.org Subject: Re: misc/10302: installer Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: installer Responsible-Changed-From-To: freebsd-bugs->jkh Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 16:07:36 PDT 2000 Responsible-Changed-Why: I don't knwo if this still applies, but jkh is Mr Sysinstall http://www.freebsd.org/cgi/query-pr.cgi?pr=10302 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:10: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D26B537B422; Mon, 4 Sep 2000 16:10:00 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA79312; Mon, 4 Sep 2000 16:10:00 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:10:00 -0700 (PDT) From: Message-Id: <200009042310.QAA79312@freefall.freebsd.org> To: jga@cowboy.net, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/12044: having tcl.h in /usr/local/include:/usr/include hoses /usr/ports installations. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: having tcl.h in /usr/local/include:/usr/include hoses /usr/ports installations. State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 16:09:50 PDT 2000 State-Changed-Why: Answer given http://www.freebsd.org/cgi/query-pr.cgi?pr=12044 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:11: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D940A37B42C; Mon, 4 Sep 2000 16:11:03 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA79515; Mon, 4 Sep 2000 16:11:03 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:11:03 -0700 (PDT) From: Message-Id: <200009042311.QAA79515@freefall.freebsd.org> To: buddabud@hotmail.com, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/12390: Installation hangs during extraction Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Installation hangs during extraction State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 16:10:52 PDT 2000 State-Changed-Why: Timeout waiting for feedback http://www.freebsd.org/cgi/query-pr.cgi?pr=12390 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:12:49 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0233337B423; Mon, 4 Sep 2000 16:12:45 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA79703; Mon, 4 Sep 2000 16:12:44 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:12:44 -0700 (PDT) From: Message-Id: <200009042312.QAA79703@freefall.freebsd.org> To: mohara@ll.mit.edu, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/10167: Upon exiting X11R6, monitor goes blank. Keyboard still responding. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Upon exiting X11R6, monitor goes blank. Keyboard still responding. State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 16:11:55 PDT 2000 State-Changed-Why: Insufficient information to analyse the problem. XFree86 problems should be taken up with the XFree86 developers anyway http://www.freebsd.org/cgi/query-pr.cgi?pr=10167 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:17: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CF1F437B43E; Mon, 4 Sep 2000 16:17:01 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA80159; Mon, 4 Sep 2000 16:17:01 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:17:01 -0700 (PDT) From: Message-Id: <200009042317.QAA80159@freefall.freebsd.org> To: aoki@crl.go.jp, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/8623: [MFC] Time zone for Japan is strange (seen in /stand/sysinstall) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: [MFC] Time zone for Japan is strange (seen in /stand/sysinstall) State-Changed-From-To: suspended->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 16:16:29 PDT 2000 State-Changed-Why: This should be fixed in recent versions of FreeBSD - we now have a more recent tzdata database. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=8623 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:26:55 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8AFC837B422; Mon, 4 Sep 2000 16:26:54 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA81011; Mon, 4 Sep 2000 16:26:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:26:54 -0700 (PDT) From: Message-Id: <200009042326.QAA81011@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, jdp@FreeBSD.org Subject: Re: misc/4468: dlopen is not available from static executables Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: dlopen is not available from static executables Responsible-Changed-From-To: freebsd-bugs->jdp Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 16:26:25 PDT 2000 Responsible-Changed-Why: jdp is Mr dlopen() http://www.freebsd.org/cgi/query-pr.cgi?pr=4468 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:27:15 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 987CA37B423; Mon, 4 Sep 2000 16:27:13 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA81090; Mon, 4 Sep 2000 16:27:13 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:27:13 -0700 (PDT) From: Message-Id: <200009042327.QAA81090@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, jdp@FreeBSD.org Subject: Re: misc/13282: partial compliance of dlopen to the Single Unix specification Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: partial compliance of dlopen to the Single Unix specification Responsible-Changed-From-To: freebsd-bugs->jdp Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 16:27:02 PDT 2000 Responsible-Changed-Why: jdp is Mr dlopen() http://www.freebsd.org/cgi/query-pr.cgi?pr=13282 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:31:51 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B93CB37B423; Mon, 4 Sep 2000 16:31:49 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA81485; Mon, 4 Sep 2000 16:31:49 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:31:49 -0700 (PDT) From: Message-Id: <200009042331.QAA81485@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, billf@FreeBSD.org Subject: Re: misc/15205: Addition to /usr/games/random Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Addition to /usr/games/random Responsible-Changed-From-To: freebsd-bugs->billf Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 16:28:59 PDT 2000 Responsible-Changed-Why: Billf takes care of stuff in /usr/games http://www.freebsd.org/cgi/query-pr.cgi?pr=15205 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:35:23 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2F89E37B42C; Mon, 4 Sep 2000 16:35:22 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA81821; Mon, 4 Sep 2000 16:35:22 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:35:22 -0700 (PDT) From: Message-Id: <200009042335.QAA81821@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, wosch@FreeBSD.org Subject: Re: misc/16131: bizarre dates displayed when searching the mailing lists Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: bizarre dates displayed when searching the mailing lists Responsible-Changed-From-To: freebsd-bugs->wosch Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 16:34:59 PDT 2000 Responsible-Changed-Why: Wosch is the responsible person http://www.freebsd.org/cgi/query-pr.cgi?pr=16131 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:35:45 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5A66E37B422; Mon, 4 Sep 2000 16:35:44 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA81945; Mon, 4 Sep 2000 16:35:44 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:35:44 -0700 (PDT) From: Message-Id: <200009042335.QAA81945@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, wosch@FreeBSD.org Subject: Re: misc/16475: search.cgi gives bogus dates Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: search.cgi gives bogus dates Responsible-Changed-From-To: freebsd-bugs->wosch Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 16:35:31 PDT 2000 Responsible-Changed-Why: Wosch is the responsible person http://www.freebsd.org/cgi/query-pr.cgi?pr=16475 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 16:36: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8860F37B42C; Mon, 4 Sep 2000 16:36:08 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA82039; Mon, 4 Sep 2000 16:36:08 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 16:36:08 -0700 (PDT) From: Message-Id: <200009042336.QAA82039@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, wosch@FreeBSD.org Subject: Re: misc/18220: Mailing list search date problems Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Mailing list search date problems Responsible-Changed-From-To: freebsd-bugs->wosch Responsible-Changed-By: kris Responsible-Changed-When: Mon Sep 4 16:35:51 PDT 2000 Responsible-Changed-Why: Wosch is the responsible person http://www.freebsd.org/cgi/query-pr.cgi?pr=18220 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 17: 0: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3EED337B424 for ; Mon, 4 Sep 2000 17:00:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA84314; Mon, 4 Sep 2000 17:00:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id A08AA37B43E; Mon, 4 Sep 2000 16:56:33 -0700 (PDT) Message-Id: <20000904235633.A08AA37B43E@hub.freebsd.org> Date: Mon, 4 Sep 2000 16:56:33 -0700 (PDT) From: shurd@sk.sympatico.ca To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: i386/21042: Keyboard driver problems with PS/2 Model 95 (MCA) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21042 >Category: i386 >Synopsis: Keyboard driver problems with PS/2 Model 95 (MCA) >Confidential: no >Severity: critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 04 17:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Stephen Hurd >Release: 4.1-Release >Organization: Becquet's Custom Programming >Environment: N/A >Description: When the keyboard driver is loaded on a PS/2 Model 95 (Tried two of them) the keyboard is no longer sane... The keyboard works fine otherwise. Tried with about seven good keyboards. Tried with newest snapshot also - same problem. While I'm here I might as well wish for MCA support for the DEC 212 NIC. >How-To-Repeat: Try installing on a PS/2 Model 95 (I don't have any other PS/2's available for testing) >Fix: someone around here said "mumble mumble mumblity A20 Line mumble mumble Micro Channel" if that helps any :-) >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 17:29:50 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id BE27B37B422 for ; Mon, 4 Sep 2000 17:29:48 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id JAA08623; Tue, 5 Sep 2000 09:29:42 +0900 (JST) To: Brad Huntting Cc: bugs@freebsd.org, huntting@glarp.com, Hajimu UMEMOTO , core@kame.net In-reply-to: huntting's message of Mon, 04 Sep 2000 14:51:16 CST. <200009042051.OAA72183@hunkular.glarp.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: kern/21016: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses From: itojun@iijlab.net Date: Tue, 05 Sep 2000 09:29:42 +0900 Message-ID: <8621.968113782@coconut.itojun.org> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> this is a feature. IPv4 mapped address on AF_INET6 socket is just >> to help porting basic IPv4 apps at ease. to manipulate IPv4 traffic >> in detail (including TOS/TTL, or multicast), you must use AF_INET >> socket. >Section 3.7 of draft-ietf-ipngwg-rfc2553bis-00.txt does not aggre. >V4 mapped addresses are clearly intended to allow "basic" v6 apps >to interoperate with legacy v4 apps w/o duplicating code. And >"basic" in this case most definitly includes multicast. where did you get the impression for the last sentence? from my understanding, multicast is outside of scope (and I'm very convinced about it) the more you try to use IPv4 mapped address in wider scope, the system gets more messy. >Is KAME planning on fixing this anytime soon? I don't think so. I can't speak for other KAME guys. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 17:50: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5609637B440 for ; Mon, 4 Sep 2000 17:50:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA91294; Mon, 4 Sep 2000 17:50:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 84D6737B423; Mon, 4 Sep 2000 17:49:36 -0700 (PDT) Message-Id: <20000905004936.84D6737B423@hub.freebsd.org> Date: Mon, 4 Sep 2000 17:49:36 -0700 (PDT) From: che.wong@philips.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21046: ATAPI interface hangs during install of 4.1 from CDROM Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21046 >Category: kern >Synopsis: ATAPI interface hangs during install of 4.1 from CDROM >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 04 17:50:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Che Wong >Release: 4.1 >Organization: >Environment: Can't get it far enough to perform command. >Description: First, I tried to upgrade to 4.1 from 2.8.8 from the CDROM. During system probing, system powers down. Finally decide to blow the disk away and perform a fresh install. As the data is unpacked from the CD to the hard drive, the ATAPI interface would hang; never in the same spot. Sometimes it would be during the ports, other times later in the process. At all times, just before the hang, the LS120 drive will be accessed. At this point, a power cycle reset is needed before the CD drive can be seen by the BIOS. Have tried: - interchanging the CDROM and LS120 as master and slave; - interchanging IDE channels for the hard drive, CDROM and LS120; - changing different combinations of devices on the IDE channels; - a different CDROM drive; - permutations of the scenarios above; The furthest I got in the install process was to remove the LS120 drive and have the hard disk on an IDE channel and the CDROM on another IDE channel. This configuration installed completely. The LS120 was reconnected to transfer files from the 2.8.8 system. This would not boot. Again various configurations were experimented with. This time, a message about "Read timeout" would occur just before the system hang. Sometimes the hard drive would be accessed just before the hang, other times, it would be the LS120. The hardware works because I reinstalled 2.8.8 from CD after I ran out of ideas. In 2.8.8, I can access the CDROM, LS120 and hard drive. I did get the error message: Sep 4 14:32:01 myname /kernel: wfd0: i/o error, status=51, error=74 when I was getting my files from the LS120 drive, but this did not appear to cause any problems and I continued along. System configuration: - Tyan S1590S motherboard (VIA MVP3 chipset w/82C586 ATA controller and AWARD 1.14 & 1.16 BIOS) - 64 MB RAM w/ECC - AMD K6 @ 380 MHz - Diamond Viper V550 AGP video - IBM IBM-DTTA-351010 Hard drive - Memorex CD-362E CDROM (, removable, accel, dma, iordy 687/6875KB/sec, 128KB cache, audio play, 255 volume levels, e - LS120 drive (LS-120 CSMO 05 UHD Floppy/0512C105>, removable, iordy) Note: In the configuration, I did not have a floppy controller or a parallel port controller defined. Comments: It appears the ATAPI driver in 4.1 is not accessing the hardware correctly in this configuration. There are accesses to devices when there appears to be no need and after the hang, anything but a power cycle reset will not get all the devices back. Since this system will install and work on 2.8.8, I don't think it is a hardware problem. Send EMAIL to get my telephone number if someone wants to talk about this and get more information. >How-To-Repeat: Don't know if this is repeatable on the hardware you have at your disposal. I would try to repeat it on a motherboard using the MVP3 chipset and just have a hard drive, a CDROM and a LS120 and try to install 4.1. Remove the parallel port and floppy controller from the configuration. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 22: 0: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C151B37B42C for ; Mon, 4 Sep 2000 22:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id WAA31667; Mon, 4 Sep 2000 22:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id CB0D337B423; Mon, 4 Sep 2000 21:57:37 -0700 (PDT) Message-Id: <20000905045737.CB0D337B423@hub.freebsd.org> Date: Mon, 4 Sep 2000 21:57:37 -0700 (PDT) From: yu@installer.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21051: Updating 4.1-RELEASE to -current fails because document is insufficient Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21051 >Category: kern >Synopsis: Updating 4.1-RELEASE to -current fails because document is insufficient >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 04 22:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: IMAMURA Tomoaki >Release: 4.1-RELEASE >Organization: installer >Environment: FreeBSD prepre.nic.fujitsu.co.jp 4.1-RELEASE FreeBSD 4.1-RELEASE #1: Mon Sep 4 19:35:47 JST 2000 root@prepre.nic.fujitsu.co.jp:/usr/src/sys/compile/YUPPY i386 >Description: While updating 4.1-RELEASE to -current according to '/usr/src/UPDATING', I got following message in 'make installkernel ...': You must activate /boot/device.hints in loader.conf. >How-To-Repeat: >Fix: Updaters should type '/usr/src/sys/boot; make install' before installkernel rather than previous 'cp src/sys/${MACHINE_ARCH}/GENERIC.hints /boot/device.hints' command, I think. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 22:42:44 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 995D537B506; Mon, 4 Sep 2000 22:42:42 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id WAA40929; Mon, 4 Sep 2000 22:42:42 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Mon, 4 Sep 2000 22:42:42 -0700 (PDT) From: Message-Id: <200009050542.WAA40929@freefall.freebsd.org> To: wosch@freebsd.first.gmd.de, kris@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/10522: make world died due -Werror Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: make world died due -Werror State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Mon Sep 4 22:42:26 PDT 2000 State-Changed-Why: The problem seems to be resolved. http://www.freebsd.org/cgi/query-pr.cgi?pr=10522 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Sep 4 23:50: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9B48937B43E for ; Mon, 4 Sep 2000 23:50:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA50123; Mon, 4 Sep 2000 23:50:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 4 Sep 2000 23:50:03 -0700 (PDT) Message-Id: <200009050650.XAA50123@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: bin/21024: pow() ERANGE bug Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21024; it has been noted by GNATS. From: Bruce Evans To: aa8vb@nc.rr.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/21024: pow() ERANGE bug Date: Tue, 5 Sep 2000 17:40:55 +1100 (EST) On Mon, 4 Sep 2000 aa8vb@nc.rr.com wrote: > >Description: > > According to the man page: > > The functions exp(), expm1(), pow() detect if the computed value will > overflow, set the global variable errno to ERANGE, and ... This is mainly a bug in the man page. This part of it describes the behaviour of pow() in the old BSD libm, but we use Sun's fdlibm. The man page had already rotted for exp() and expm1() in the old libm -- errno was set for pow() on Vaxes and Tahoes, but was not set for exp() or expm1() on any machine. The man page actually says: ... set the global variable errno to ERANGE [no comma here] and cause a reserved operand fault on a Vax or Tahoe. so it is not clear that ERANGE is set except on Vaxes and Tahoes. In fact, according to the sources it _is_ only set on Vaxes and Tahoes (all settings of errno in the old libm are done by infnan.s which only exists for Vaxes and Tahoes). > However, pow() does not set errno to ERANGE on overflow. The actual behaviour on overflow is: (1) Attempt to set the IEEE exception flags (if any) in an IEEE'ish way by evaluating the overflowing expression `huge*huge' where `huge' is `static const double huge = 1.0e300'. This normally fails due to dubious compiler optimizations (gcc evaluates the expression at compile time and doesn't generate code to set the flags at runtime). (2) If libm is compiled with -D_POSIX_MODE and the library mode is not changed from the resulting default, then set errno to ERANGE. -D_POSIX_MODE is not the default and not recommended, although it is required for "POSIX" (actually old Standard C) conformance -- see src/lib/msun/Makefile. It mainly slows things down and messes up the return value for domain errors. There are other configuration flags/library modes which mess up the return value even for range errors. This non-conformance with old Standard C is unlikely to be changed, since setting errno for math functions is considered harmful and is not required in the current C standard. This PR should be turned into one about the libm man pages. The descriptions of error handling are anachronistic and/or incomplete. As an example of incompleteness, there are 19 special cases for pow() (see the sources) and only a couple of these are described in the man page. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 0:20: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9919437B43E for ; Tue, 5 Sep 2000 00:20:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA55781; Tue, 5 Sep 2000 00:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 9B07A37B59E; Tue, 5 Sep 2000 00:15:26 -0700 (PDT) Message-Id: <20000905071526.9B07A37B59E@hub.freebsd.org> Date: Tue, 5 Sep 2000 00:15:26 -0700 (PDT) From: oseberg@hotmail.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: misc/21056: Apache 1.3 Virtual Hosts don't work on 4.0-RELEASE Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21056 >Category: misc >Synopsis: Apache 1.3 Virtual Hosts don't work on 4.0-RELEASE >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 00:20:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Terje Oseberg >Release: 4.0-RELEASE >Organization: Self >Environment: FreeBSD alpha.etiam.net 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Wed Aug 30 13:09:08 GMT 2000 oseberg@alpha.etiam.net:/usr/src/sys/compile/FIREWALL i386 >Description: Virtual Hosts on Apache 1.3.12 on FreeBSD 3.2, but doesn't work on FreeBSD 4.0 >How-To-Repeat: Try to set up Virtual Hosts on Apache 1.3.12 on FreeBSD 4.0-RELEASE >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 0:20: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2FC0937B440 for ; Tue, 5 Sep 2000 00:20:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA55791; Tue, 5 Sep 2000 00:20:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 00:20:04 -0700 (PDT) Message-Id: <200009050720.AAA55791@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Andy Farkas Subject: Re: i386/21042: Keyboard driver problems with PS/2 Model 95 (MCA) Reply-To: Andy Farkas Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/21042; it has been noted by GNATS. From: Andy Farkas To: shurd@sk.sympatico.ca Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: i386/21042: Keyboard driver problems with PS/2 Model 95 (MCA) Date: Tue, 5 Sep 2000 18:19:29 +1100 (EST) > Try installing on a PS/2 Model 95 (I don't have any other PS/2's > available for testing) I have one of these systems and saw exactly what you describe. The solution I came up with was: device atkbd0 at atkbdc? irq 1 flags 0x3 and recompile kernel. See LINT for flag decriptions. -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 1:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id AE3C137B446 for ; Tue, 5 Sep 2000 01:20:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id BAA66119; Tue, 5 Sep 2000 01:20:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 01:20:04 -0700 (PDT) Message-Id: <200009050820.BAA66119@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Dmitry E. Shikut" Subject: Re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Reply-To: "Dmitry E. Shikut" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/20992; it has been noted by GNATS. From: "Dmitry E. Shikut" To: sheldonh@freebsd.org Cc: Subject: Re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Date: Mon, 4 Sep 2000 19:55:35 +0300 >Synopsis: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks > >State-Changed-From-To: open->feedback >State-Changed-By: sheldonh >State-Changed-When: Mon Sep 4 08:19:51 PDT 2000 >State-Changed-Why: >What's the value associated with maxusers in your kernel config? > >http://www.freebsd.org/cgi/query-pr.cgi?pr=20992 maxuser value in kernel config is 32... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 1:20:13 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CFEA237B422 for ; Tue, 5 Sep 2000 01:20:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id BAA66110; Tue, 5 Sep 2000 01:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 01:20:02 -0700 (PDT) Message-Id: <200009050820.BAA66110@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Dmitry E. Shikut" Subject: Re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Reply-To: "Dmitry E. Shikut" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/20992; it has been noted by GNATS. From: "Dmitry E. Shikut" To: sheldonh@freebsd.org Cc: Subject: Re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Date: Mon, 4 Sep 2000 20:10:06 +0300 This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C016AC.1E2C9C80 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit >Synopsis: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks > >State-Changed-From-To: open->feedback >State-Changed-By: sheldonh >State-Changed-When: Mon Sep 4 08:19:51 PDT 2000 >State-Changed-Why: >What's the value associated with maxusers in your kernel config? > >http://www.freebsd.org/cgi/query-pr.cgi?pr=20992 May be You also need dmesg and "sysctl -a" output? There are attachments, plus my kernel config. Dmitry (shikut@belpak.brest.by). ------=_NextPart_000_0039_01C016AC.1E2C9C80 Content-Type: application/octet-stream; name="dmesg.rpt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.rpt" Q29weXJpZ2h0IChjKSAxOTkyLTE5OTkgRnJlZUJTRCBJbmMuCkNvcHlyaWdodCAoYykgMTk4Miwg MTk4NiwgMTk4OSwgMTk5MSwgMTk5MwoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2Yg Q2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCAzLjUuMS1SRUxFQVNFICM1 OiBGcmkgQXVnIDI1IDE3OjE4OjQwIEVFU1QgMjAwMAogICAgcm9vdEBicnVzLmJlbHBhay5icmVz dC5ieTovdXNyL3NyYy9zeXMvY29tcGlsZS9CUlVTClRpbWVjb3VudGVyICJpODI1NCIgIGZyZXF1 ZW5jeSAxMTkzMTgyIEh6ClRpbWVjb3VudGVyICJUU0MiICBmcmVxdWVuY3kgOTk0NzQxNjYgSHoK Q1BVOiBQZW50aXVtL1A1NEMgKDk5LjQ3LU1IeiA1ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJH ZW51aW5lSW50ZWwiICBJZCA9IDB4NTI2ICBTdGVwcGluZyA9IDYKICBGZWF0dXJlcz0weDFiZjxG UFUsVk1FLERFLFBTRSxUU0MsTVNSLE1DRSxDWDg+CnJlYWwgbWVtb3J5ICA9IDMzNTU0NDMyICgz Mjc2OEsgYnl0ZXMpCmNvbmZpZz4gZW4gc2lvMApjb25maWc+IGVuIHNpbzEKY29uZmlnPiBlbiBl ZDAKY29uZmlnPiBwbyBlZDAgMHgzMjAKY29uZmlnPiBpciBlZDAgMTAKY29uZmlnPiBpb20gZWQw IDB4ZDgwMDAKY29uZmlnPiBmIGVkMCAwCmNvbmZpZz4gcQphdmFpbCBtZW1vcnkgPSAzMDEyNjA4 MCAoMjk0MjBLIGJ5dGVzKQpQcmVsb2FkZWQgZWxmIGtlcm5lbCAia2VybmVsIiBhdCAweGMwMjll MDAwLgpQcmVsb2FkZWQgdXNlcmNvbmZpZ19zY3JpcHQgIi9ib290L2tlcm5lbC5jb25mIiBhdCAw eGMwMjllMDljLgpQcm9iaW5nIGZvciBkZXZpY2VzIG9uIFBDSSBidXMgMDoKY2hpcDA6IDxJbnRl bCA4MjQzN0ZYIFBDSSBjYWNoZSBtZW1vcnkgY29udHJvbGxlcj4gcmV2IDB4MDEgb24gcGNpMC4w LjAKY2hpcDE6IDxJbnRlbCA4MjM3MUZCIFBDSSB0byBJU0EgYnJpZGdlPiByZXYgMHgwMiBvbiBw Y2kwLjcuMAp2Z2EwOiA8VHJpZGVudCBtb2RlbCA5NDQwIFZHQS1jb21wYXRpYmxlIGRpc3BsYXkg ZGV2aWNlPiByZXYgMHhlMyBpbnQgYSBpcnEgMTEgb24gcGNpMC4xNS4wClByb2JpbmcgZm9yIFBu UCBkZXZpY2VzOgpQcm9iaW5nIGZvciBkZXZpY2VzIG9uIHRoZSBJU0EgYnVzOgpzYzAgb24gaXNh CnNjMDogVkdBIGNvbG9yIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDA+CmVkMCBhdCAw eDMyMC0weDMzZiBpcnEgMTAgb24gaXNhCmVkMDogYWRkcmVzcyAwMDoyMDo0YzozMDo0NDpmNSwg dHlwZSBORTIwMDAgKDE2IGJpdCkgCmVkMSBhdCAweDI2MC0weDI3ZiBpcnEgNSBvbiBpc2EKZWQx OiBhZGRyZXNzIDAwOjQwOjA1OjFlOjQ0OjU2LCB0eXBlIE5FMjAwMCAoMTYgYml0KSAKYXRrYmRj MCBhdCAweDYwLTB4NmYgb24gbW90aGVyYm9hcmQKYXRrYmQwIGlycSAxIG9uIGlzYQpzaW8wIGF0 IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gaXNhCnNpbzA6IHR5cGUgMTY1NTBBCnNp bzEgYXQgMHgyZjgtMHgyZmYgaXJxIDMgb24gaXNhCnNpbzE6IHR5cGUgMTY1NTBBCmRnYjA6IFBD L1hlIDY0LzhLICh3aW5kb3dlZCkKZGdiMCBhdCAweDMwMC0weDMwMyBtYWRkciAweGQwMDAwIG1z aXplIDgxOTIgb24gaXNhCmRnYjA6IDggcG9ydHMKZmRjMCBhdCAweDNmMC0weDNmNyBpcnEgNiBk cnEgMiBvbiBpc2EKZmRjMDogRklGTyBlbmFibGVkLCA4IGJ5dGVzIHRocmVzaG9sZApmZDA6IDEu NDRNQiAzLjVpbgp3ZGMwIGF0IDB4MWYwLTB4MWY3IGlycSAxNCBmbGFncyAweDgwZmY4MGZmIG9u IGlzYQp3ZGMwOiB1bml0IDAgKHdkMCk6IDxGVUpJVFNVIE0xNjI0VEFVPiwgMzItYml0LCBtdWx0 aS1ibG9jay0xNgp3ZDA6IDIwMTRNQiAoNDEyNDczNiBzZWN0b3JzKSwgNDA5MiBjeWxzLCAxNiBo ZWFkcywgNjMgUy9ULCA1MTIgQi9TCnZnYTAgYXQgMHgzYjAtMHgzZGYgbWFkZHIgMHhhMDAwMCBt c2l6ZSAxMzEwNzIgb24gaXNhCm5weDAgb24gbW90aGVyYm9hcmQKbnB4MDogSU5UIDE2IGludGVy ZmFjZQpJbnRlbCBQZW50aXVtIGRldGVjdGVkLCBpbnN0YWxsaW5nIHdvcmthcm91bmQgZm9yIEYw MEYgYnVnCklQIHBhY2tldCBmaWx0ZXJpbmcgaW5pdGlhbGl6ZWQsIGRpdmVydCBlbmFibGVkLCBy dWxlLWJhc2VkIGZvcndhcmRpbmcgZGlzYWJsZWQsIGRlZmF1bHQgdG8gZGVueSwgbG9nZ2luZyBk aXNhYmxlZApJUCBGaWx0ZXI6IGluaXRpYWxpemVkLiAgRGVmYXVsdCA9IHBhc3MgYWxsLCBMb2dn aW5nID0gZGlzYWJsZWQKY2hhbmdpbmcgcm9vdCBkZXZpY2UgdG8gd2QwczFhCg== ------=_NextPart_000_0039_01C016AC.1E2C9C80 Content-Type: application/octet-stream; name="sysctl.rpt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sysctl.rpt" a2Vybi5vc3R5cGU6IEZyZWVCU0QKa2Vybi5vc3JlbGVhc2U6IDMuNS4xLVJFTEVBU0UKa2Vybi5v c3JldmlzaW9uOiAxOTk1MDYKa2Vybi52ZXJzaW9uOiBGcmVlQlNEIDMuNS4xLVJFTEVBU0UgIzU6 IEZyaSBBdWcgMjUgMTc6MTg6NDAgRUVTVCAyMDAwCiAgICByb290QGJydXMuYmVscGFrLmJyZXN0 LmJ5Oi91c3Ivc3JjL3N5cy9jb21waWxlL0JSVVMKCmtlcm4ubWF4dm5vZGVzOiAyNDE2Cmtlcm4u bWF4cHJvYzogNTMyCmtlcm4ubWF4ZmlsZXM6IDEwNjQKa2Vybi5hcmdtYXg6IDY1NTM2Cmtlcm4u c2VjdXJlbGV2ZWw6IC0xCmtlcm4uaG9zdG5hbWU6IGJydXMuYmVscGFrLmJyZXN0LmJ5Cmtlcm4u aG9zdGlkOiAwCmtlcm4uY2xvY2tyYXRlOiB7IGh6ID0gMTAwLCB0aWNrID0gMTAwMDAsIHRpY2th ZGogPSA1LCBwcm9maHogPSAxMDI0LCBzdGF0aHogPSAxMjggfQprZXJuLnBvc2l4MXZlcnNpb246 IDE5OTMwOQprZXJuLm5ncm91cHM6IDE2Cmtlcm4uam9iX2NvbnRyb2w6IDEKa2Vybi5zYXZlZF9p ZHM6IDAKa2Vybi5ib290dGltZTogeyBzZWMgPSA5NjgwODY3OTMsIHVzZWMgPSA3Mzg4MjYgfSBN b24gU2VwICA0IDE5OjU5OjUzIDIwMDAKa2Vybi5kb21haW5uYW1lOiAKa2Vybi5vc3JlbGRhdGU6 IDM1MDAwMQprZXJuLmJvb3RmaWxlOiAva2VybmVsCmtlcm4ubWF4ZmlsZXNwZXJwcm9jOiAxMDY0 Cmtlcm4ubWF4cHJvY3BlcnVpZDogNTMxCmtlcm4uZHVtcGRldjogeyBtYWpvciA9IDI1NSwgbWlu b3IgPSAtNjUyODEgfQprZXJuLmlwYy5tYXhzb2NrYnVmOiAyNjIxNDQKa2Vybi5pcGMuc29ja2J1 Zl93YXN0ZV9mYWN0b3I6IDgKa2Vybi5pcGMuc29tYXhjb25uOiAxMjgKa2Vybi5pcGMubWF4X2xp bmtoZHI6IDE2Cmtlcm4uaXBjLm1heF9wcm90b2hkcjogNDAKa2Vybi5pcGMubWF4X2hkcjogNTYK a2Vybi5pcGMubWF4X2RhdGFsZW46IDQwCmtlcm4uaXBjLm5tYmNsdXN0ZXJzOiAxMDI0Cmtlcm4u aXBjLm1idWZfd2FpdDogMzIKa2Vybi5pcGMubWF4c29ja2V0czogMTA2NAprZXJuLmR1bW15OiAw Cmtlcm4ucHNfc3RyaW5nczogLTEwNzc5NDQzMzYKa2Vybi51c3JzdGFjazogLTEwNzc5NDQzMjAK a2Vybi5sb2dzaWdleGl0OiAxCmtlcm4uaW5pdF9wYXRoOiAvc2Jpbi9pbml0Oi9zYmluL29pbml0 Oi9zYmluL2luaXQuYmFrOi9zdGFuZC9zeXNpbnN0YWxsCmtlcm4ubW9kdWxlX3BhdGg6IC87L2Jv b3QvOy9tb2R1bGVzLwprZXJuLmFjY3Rfc3VzcGVuZDogMgprZXJuLmFjY3RfcmVzdW1lOiA0Cmtl cm4uYWNjdF9jaGtmcmVxOiAxNQprZXJuLnRpbWVjb3VudGVyLm1ldGhvZDogMAprZXJuLmZhc3Rf dmZvcms6IDEKa2Vybi5zdWdpZF9jb3JlZHVtcDogMAprZXJuLmNvcmVmaWxlOiAlTi5jb3JlCmtl cm4ucXVhbnR1bTogMTAwMDAwCmtlcm4uY2NwdTogMTk0OAprZXJuLmZzY2FsZTogMjA0OAprZXJu LmRldnN0YXQubnVtZGV2czogMgprZXJuLmRldnN0YXQuZ2VuZXJhdGlvbjogMgprZXJuLmRldnN0 YXQudmVyc2lvbjogMwprZXJuLmNvbnNtdXRlOiAwCnZtLmxvYWRhdmc6IHsgMC4wMCAwLjAwIDAu MDAgfQp2bS52X2ZyZWVfbWluOiAxNTkKdm0udl9mcmVlX3RhcmdldDogNjAwCnZtLnZfZnJlZV9y ZXNlcnZlZDogMTIzCnZtLnZfaW5hY3RpdmVfdGFyZ2V0OiA5MDAKdm0udl9jYWNoZV9taW46IDYw MAp2bS52X2NhY2hlX21heDogMTIwMAp2bS52X3BhZ2VvdXRfZnJlZV9taW46IDM0CnZtLnBhZ2Vv dXRfYWxnb3JpdGhtOiAwCnZtLnN3YXBfZW5hYmxlZDogMQp2bS5zd2FwX2lkbGVfdGhyZXNob2xk MTogMgp2bS5zd2FwX2lkbGVfdGhyZXNob2xkMjogMTAKdm0uc3RhdHMuc3lzLnZfc3d0Y2g6IDIz MTEKdm0uc3RhdHMuc3lzLnZfdHJhcDogOTU5MAp2bS5zdGF0cy5zeXMudl9zeXNjYWxsOiAyNDM1 MQp2bS5zdGF0cy5zeXMudl9pbnRyOiAxMzQyNwp2bS5zdGF0cy5zeXMudl9zb2Z0OiAxNDEwCnZt LnN0YXRzLnZtLnZfdm1fZmF1bHRzOiAxMDAxNAp2bS5zdGF0cy52bS52X2Nvd19mYXVsdHM6IDQ5 NjIKdm0uc3RhdHMudm0udl9jb3dfb3B0aW06IDg4Ngp2bS5zdGF0cy52bS52X3pmb2Q6IDI1MjMK dm0uc3RhdHMudm0udl9vemZvZDogMjQxMQp2bS5zdGF0cy52bS52X3N3YXBpbjogMAp2bS5zdGF0 cy52bS52X3N3YXBvdXQ6IDAKdm0uc3RhdHMudm0udl9zd2FwcGdzaW46IDAKdm0uc3RhdHMudm0u dl9zd2FwcGdzb3V0OiAwCnZtLnN0YXRzLnZtLnZfdm5vZGVpbjogMTk1CnZtLnN0YXRzLnZtLnZf dm5vZGVvdXQ6IDAKdm0uc3RhdHMudm0udl92bm9kZXBnc2luOiAxNDE3CnZtLnN0YXRzLnZtLnZf dm5vZGVwZ3NvdXQ6IDAKdm0uc3RhdHMudm0udl9pbnRyYW5zOiAyCnZtLnN0YXRzLnZtLnZfcmVh Y3RpdmF0ZWQ6IDAKdm0uc3RhdHMudm0udl9wZHdha2V1cHM6IDAKdm0uc3RhdHMudm0udl9wZHBh Z2VzOiAwCnZtLnN0YXRzLnZtLnZfZGZyZWU6IDAKdm0uc3RhdHMudm0udl9wZnJlZTogNDMxOAp2 bS5zdGF0cy52bS52X3RmcmVlOiA5MzEyCnZtLnN0YXRzLnZtLnZfcGFnZV9zaXplOiA0MDk2CnZt LnN0YXRzLnZtLnZfcGFnZV9jb3VudDogNzUzNwp2bS5zdGF0cy52bS52X2ZyZWVfcmVzZXJ2ZWQ6 IDEyMwp2bS5zdGF0cy52bS52X2ZyZWVfdGFyZ2V0OiA2MDAKdm0uc3RhdHMudm0udl9mcmVlX21p bjogMTU5CnZtLnN0YXRzLnZtLnZfZnJlZV9jb3VudDogNDExNgp2bS5zdGF0cy52bS52X3dpcmVf Y291bnQ6IDEwMDcKdm0uc3RhdHMudm0udl9hY3RpdmVfY291bnQ6IDExOTkKdm0uc3RhdHMudm0u dl9pbmFjdGl2ZV90YXJnZXQ6IDkwMAp2bS5zdGF0cy52bS52X2luYWN0aXZlX2NvdW50OiAxMjAz CnZtLnN0YXRzLnZtLnZfY2FjaGVfY291bnQ6IDAKdm0uc3RhdHMudm0udl9jYWNoZV9taW46IDYw MAp2bS5zdGF0cy52bS52X2NhY2hlX21heDogMTIwMAp2bS5zdGF0cy52bS52X3BhZ2VvdXRfZnJl ZV9taW46IDM0CnZtLnN0YXRzLnZtLnZfaW50ZXJydXB0X2ZyZWVfbWluOiAyCnZtLnN0YXRzLm1p c2MuemVyb19wYWdlX2NvdW50OiA0MDUyCnZtLnN0YXRzLm1pc2MuY250X3ByZXplcm86IDg5MzgK dm0ucGFnZW91dF9zdGF0c19tYXg6IDYwMAp2bS5wYWdlb3V0X2Z1bGxfc3RhdHNfaW50ZXJ2YWw6 IDIwCnZtLnBhZ2VvdXRfc3RhdHNfaW50ZXJ2YWw6IDUKdm0ucGFnZW91dF9zdGF0c19mcmVlX21h eDogNQp2bS5zd2FwX2lkbGVfZW5hYmxlZDogMAp2bS5kZWZlcl9zd2Fwc3BhY2VfcGFnZW91dHM6 IDAKdm0uZGlzYWJsZV9zd2Fwc3BhY2VfcGFnZW91dHM6IDAKdm0ubWF4X3BhZ2VfbGF1bmRlcjog MzIKdm0uem9uZTogCklURU0gICAgICAgICAgICBTSVpFICAgICBMSU1JVCAgICBVU0VEICAgIEZS RUUgIFJFUVVFU1RTCgpQSVBFOiAgICAgICAgICAgIDE2MCwgICAgICAgIDAsICAgICAgNCwgICAg IDk4LCAgICAgICAyNQp1bnBjYjogICAgICAgICAgICA2NCwgICAgICAgIDAsICAgICAgNSwgICAg MTIzLCAgICAgICAgOApyaXBjYjogICAgICAgICAgICA5NiwgICAgIDEwNjQsICAgICAgMSwgICAg IDgzLCAgICAgICAxMQpkaXZjYjogICAgICAgICAgICA5NiwgICAgIDEwNjQsICAgICAgMSwgICAg IDQxLCAgICAgICAgMAp0Y3BjYjogICAgICAgICAgIDI4OCwgICAgIDEwNjQsICAgICAgNiwgICAg IDIyLCAgICAgICAgNQp1ZHBjYjogICAgICAgICAgICA5NiwgICAgIDEwNjQsICAgICAxMywgICAg IDcxLCAgICAgICAyNwp1bnBjYjogICAgICAgICAgICA2NCwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApzb2NrZXQ6ICAgICAgICAgIDE2MCwgICAgIDEwNjQsICAgICAyNiwgICAg IDQ5LCAgICAgICA1OApBSU9MSU86ICAgICAgICAgIDcwNCwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApBSU9MOiAgICAgICAgICAgICA2NCwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApBSU9DQjogICAgICAgICAgIDEyOCwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApBSU9QOiAgICAgICAgICAgICAzMiwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApBSU86ICAgICAgICAgICAgICA5NiwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApORlNOT0RFOiAgICAgICAgIDI4OCwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApORlNNT1VOVDogICAgICAgIDU0NCwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApWTk9ERTogICAgICAgICAgIDE5MiwgICAgICAgIDAsICAgIDI1NiwgICAg IDYyLCAgICAgIDI1MwpOQU1FSTogICAgICAgICAgMTAyNCwgICAgICAgIDAsICAgICAgMCwgICAg IDE2LCAgICAgMjQ3MApWTVNQQUNFOiAgICAgICAgIDE5MiwgICAgICAgIDAsICAgICAxOSwgICAg IDQ1LCAgICAgIDI3OApQUk9DOiAgICAgICAgICAgIDM1MiwgICAgICAgIDAsICAgICAyMiwgICAg IDM2LCAgICAgIDI4MQpEUCBmYWtlcGc6ICAgICAgICA2NCwgICAgICAgIDAsICAgICAgMCwgICAg ICAwLCAgICAgICAgMApQViBFTlRSWTogICAgICAgICAyOCwgICAxMjI3NzgsICAgMzM4MSwgICA0 ODA4LCAgICA0MDU1NApNQVAgRU5UUlk6ICAgICAgICA0MCwgICAgICAgIDAsICAgIDI3NSwgICAg MTU5LCAgICAgNjA5OQpLTUFQIEVOVFJZOiAgICAgICA0MCwgICAgIDIwMTIsICAgICA0MCwgICAg MTkwLCAgICAgIDE0NwpNQVA6ICAgICAgICAgICAgIDEwMCwgICAgICAgIDAsICAgICAgNywgICAg ICAzLCAgICAgICAgNwpWTSBPQkpFQ1Q6ICAgICAgIDEyNCwgICAgICAgIDAsICAgIDQxNywgICAg IDcwLCAgICAgNDgxNwp2bS56b25lX2ttZW1fcGFnZXM6IDExCnZtLnpvbmVfa21lbV9rdmFzcGFj ZTogNDA3NTUyMAp2bS56b25lX2tlcm5fcGFnZXM6IDQzCnZmcy5uZnMubmZzX3ByaXZwb3J0OiAw CnZmcy5uZnMuYXN5bmM6IDAKdmZzLm5mcy5nYXRoZXJkZWxheTogMTAwMDAKdmZzLm5mcy5nYXRo ZXJkZWxheV92MzogMAp2ZnMubmZzLmRlZmVjdDogMAp2ZnMubmZzLmRpc2tsZXNzX3ZhbGlkOiAw CnZmcy5uZnMuZGlza2xlc3Nfcm9vdHBhdGg6IAp2ZnMubmZzLmRpc2tsZXNzX3N3YXBwYXRoOiAK dmZzLm5mcy5hY2Nlc3NfY2FjaGVfdGltZW91dDogMgp2ZnMubmZzLmFjY2Vzc19jYWNoZV9oaXRz OiAwCnZmcy5uZnMuYWNjZXNzX2NhY2hlX2ZpbGxzOiAwCnZmcy5udW1kaXJ0eWJ1ZmZlcnM6IDEy CnZmcy5sb2RpcnR5YnVmZmVyczogNjMKdmZzLmhpZGlydHlidWZmZXJzOiAxMjcKdmZzLm51bWZy ZWVidWZmZXJzOiA4NDcKdmZzLmxvZnJlZWJ1ZmZlcnM6IDUyCnZmcy5oaWZyZWVidWZmZXJzOiAx MDQKdmZzLm1heGJ1ZnNwYWNlOiAzNTUxMjMyCnZmcy5idWZzcGFjZTogMjE0MzIzMgp2ZnMubWF4 dm1pb2J1ZnNwYWNlOiAyMzY3NDg4CnZmcy52bWlvc3BhY2U6IDE0ODQ4MDAKdmZzLm1heG1hbGxv Y2J1ZnNwYWNlOiAxNzc1NjEKdmZzLmJ1Zm1hbGxvY3NwYWNlOiA1NjMyMAp2ZnMua3ZhZnJlZXNw YWNlOiAwCnZmcy5jYWNoZS5udW1uZWc6IDE1CnZmcy5jYWNoZS5udW1jYWNoZTogMjU1CnZmcy5j YWNoZS5udW1jYWxsczogNDg0Mwp2ZnMuY2FjaGUuZG90aGl0czogMjUKdmZzLmNhY2hlLmRvdGRv dGhpdHM6IDEKdmZzLmNhY2hlLm51bWNoZWNrczogMzgxMAp2ZnMuY2FjaGUubnVtbWlzczogMTMy Nwp2ZnMuY2FjaGUubnVtbWlzc3phcDogMjIKdmZzLmNhY2hlLm51bXBvc3phcHM6IDI5CnZmcy5j YWNoZS5udW1wb3NoaXRzOiAzMjUwCnZmcy5jYWNoZS5udW1uZWd6YXBzOiAxNQp2ZnMuY2FjaGUu bnVtbmVnaGl0czogMTc0CnZmcy5jYWNoZS5tYXhhbGlhc2VzOiA0CnZmcy5jYWNoZS5udW1jd2Rj YWxsczogMTkKdmZzLmNhY2hlLm51bWN3ZGZhaWwxOiAwCnZmcy5jYWNoZS5udW1jd2RmYWlsMjog MAp2ZnMuY2FjaGUubnVtY3dkZmFpbDM6IDAKdmZzLmNhY2hlLm51bWN3ZGZhaWw0OiAwCnZmcy5j YWNoZS5udW1jd2Rmb3VuZDogMTkKdmZzLm1vZDA6IDAKdmZzLm1vZDE6IDAKdmZzLnVzZXJtb3Vu dDogMAp2ZnMuYWlvLm1heF9haW9fcGVyX3Byb2M6IDMyCnZmcy5haW8ubWF4X2Fpb19xdWV1ZV9w ZXJfcHJvYzogMjU2CnZmcy5haW8ubWF4X2Fpb19wcm9jczogMzIKdmZzLmFpby5udW1fYWlvX3By b2NzOiAwCnZmcy5haW8ubnVtX3F1ZXVlX2NvdW50OiAwCnZmcy5haW8ubWF4X2Fpb19xdWV1ZTog MTAyNAp2ZnMuYWlvLnRhcmdldF9haW9fcHJvY3M6IDAKdmZzLmFpby5tYXhfYnVmX2FpbzogMTYK dmZzLmFpby5udW1fYnVmX2FpbzogMAp2ZnMuYWlvLmFpb2RfbGlmZXRpbWU6IDMwMDAKdmZzLmFp by5haW9kX3RpbWVvdXQ6IDEwMDAKdmZzLmZmcy5kb3JlYWxsb2NibGtzOiAxCnZmcy5mZnMuZG9h c3luY2ZyZWU6IDEKbmV0LmxvY2FsLnN0cmVhbS5zZW5kc3BhY2U6IDgxOTIKbmV0LmxvY2FsLnN0 cmVhbS5yZWN2c3BhY2U6IDgxOTIKbmV0LmxvY2FsLmRncmFtLm1heGRncmFtOiAyMDQ4Cm5ldC5s b2NhbC5kZ3JhbS5yZWN2c3BhY2U6IDQwOTYKbmV0LmxvY2FsLmluZmxpZ2h0OiAwCm5ldC5pbmV0 LmlwLnBvcnRyYW5nZS5sb3dmaXJzdDogMTAyMwpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UubG93bGFz dDogNjAwCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5maXJzdDogMTAyNApuZXQuaW5ldC5pcC5wb3J0 cmFuZ2UubGFzdDogNTAwMApuZXQuaW5ldC5pcC5wb3J0cmFuZ2UuaGlmaXJzdDogNDkxNTIKbmV0 LmluZXQuaXAucG9ydHJhbmdlLmhpbGFzdDogNjU1MzUKbmV0LmluZXQuaXAuZm9yd2FyZGluZzog MQpuZXQuaW5ldC5pcC5yZWRpcmVjdDogMQpuZXQuaW5ldC5pcC50dGw6IDY0Cm5ldC5pbmV0Lmlw LnJ0ZXhwaXJlOiAzNjAwCm5ldC5pbmV0LmlwLnJ0bWluZXhwaXJlOiAxMApuZXQuaW5ldC5pcC5y dG1heGNhY2hlOiAxMjgKbmV0LmluZXQuaXAuc291cmNlcm91dGU6IDAKbmV0LmluZXQuaXAuaW50 cl9xdWV1ZV9tYXhsZW46IDUwCm5ldC5pbmV0LmlwLmludHJfcXVldWVfZHJvcHM6IDAKbmV0Lmlu ZXQuaXAuYWNjZXB0X3NvdXJjZXJvdXRlOiAwCm5ldC5pbmV0LmlwLmZhc3Rmb3J3YXJkaW5nOiAw Cm5ldC5pbmV0LmlwLnN1Ym5ldHNfYXJlX2xvY2FsOiAwCm5ldC5pbmV0LmlwLmZ3LmVuYWJsZTog MQpuZXQuaW5ldC5pcC5mdy5vbmVfcGFzczogMQpuZXQuaW5ldC5pcC5mdy5kZWJ1ZzogMQpuZXQu aW5ldC5pcC5mdy52ZXJib3NlOiAwCm5ldC5pbmV0LmlwLmZ3LnZlcmJvc2VfbGltaXQ6IDAKbmV0 LmluZXQuaXAuZncuZHluX2J1Y2tldHM6IDI1NgpuZXQuaW5ldC5pcC5mdy5jdXJyX2R5bl9idWNr ZXRzOiAyNTYKbmV0LmluZXQuaXAuZncuZHluX2NvdW50OiAwCm5ldC5pbmV0LmlwLmZ3LmR5bl9t YXg6IDEwMDAKbmV0LmluZXQuaXAuZncuZHluX2Fja19saWZldGltZTogMzAwCm5ldC5pbmV0Lmlw LmZ3LmR5bl9zeW5fbGlmZXRpbWU6IDIwCm5ldC5pbmV0LmlwLmZ3LmR5bl9maW5fbGlmZXRpbWU6 IDIwCm5ldC5pbmV0LmlwLmZ3LmR5bl9yc3RfbGlmZXRpbWU6IDUKbmV0LmluZXQuaXAuZncuZHlu X3Nob3J0X2xpZmV0aW1lOiA1Cm5ldC5pbmV0LmlwLnN0ZWFsdGg6IDAKbmV0LmluZXQuaWNtcC5t YXNrcmVwbDogMApuZXQuaW5ldC5pY21wLmljbXBsaW06IC0xCm5ldC5pbmV0LmljbXAuZHJvcF9y ZWRpcmVjdDogMApuZXQuaW5ldC5pY21wLmxvZ19yZWRpcmVjdDogMApuZXQuaW5ldC5pY21wLmJt Y2FzdGVjaG86IDAKbmV0LmluZXQudGNwLnJmYzEzMjM6IDAKbmV0LmluZXQudGNwLnJmYzE2NDQ6 IDAKbmV0LmluZXQudGNwLm1zc2RmbHQ6IDUxMgpuZXQuaW5ldC50Y3AucnR0ZGZsdDogMwpuZXQu aW5ldC50Y3Aua2VlcGlkbGU6IDE0NDAwCm5ldC5pbmV0LnRjcC5rZWVwaW50dmw6IDE1MApuZXQu aW5ldC50Y3Auc2VuZHNwYWNlOiAxNjM4NApuZXQuaW5ldC50Y3AucmVjdnNwYWNlOiAxNjM4NApu ZXQuaW5ldC50Y3Aua2VlcGluaXQ6IDE1MApuZXQuaW5ldC50Y3AubG9nX2luX3ZhaW46IDAKbmV0 LmluZXQudGNwLmRlbGF5ZWRfYWNrOiAxCm5ldC5pbmV0LnRjcC5wY2Jjb3VudDogNgpuZXQuaW5l dC50Y3AuYWx3YXlzX2tlZXBhbGl2ZTogMQpuZXQuaW5ldC51ZHAuY2hlY2tzdW06IDEKbmV0Lmlu ZXQudWRwLm1heGRncmFtOiA5MjE2Cm5ldC5pbmV0LnVkcC5yZWN2c3BhY2U6IDQxNjAwCm5ldC5p bmV0LnVkcC5sb2dfaW5fdmFpbjogMApuZXQuaW5ldC5yYXcubWF4ZGdyYW06IDgxOTIKbmV0Lmlu ZXQucmF3LnJlY3ZzcGFjZTogODE5MgpuZXQuaW5ldC5pcGYuZnJfZmxhZ3M6IDAKbmV0LmluZXQu aXBmLmZyX3Bhc3M6IDUxNApuZXQuaW5ldC5pcGYuZnJfYWN0aXZlOiAwCm5ldC5pbmV0LmlwZi5m cl90Y3BpZGxldGltZW91dDogODY0MDAwCm5ldC5pbmV0LmlwZi5mcl90Y3BjbG9zZXdhaXQ6IDYw Cm5ldC5pbmV0LmlwZi5mcl90Y3BsYXN0YWNrOiAyMApuZXQuaW5ldC5pcGYuZnJfdGNwdGltZW91 dDogMTIwCm5ldC5pbmV0LmlwZi5mcl90Y3BjbG9zZWQ6IDEKbmV0LmluZXQuaXBmLmZyX3VkcHRp bWVvdXQ6IDEyMApuZXQuaW5ldC5pcGYuZnJfaWNtcHRpbWVvdXQ6IDEyMApuZXQuaW5ldC5pcGYu ZnJfZGVmbmF0YWdlOiAxMjAwCm5ldC5pbmV0LmlwZi5mcl9pcGZydHRsOiAxMjAKbmV0LmluZXQu aXBmLmlwbF91bnJlYWNoOiAxMwpuZXQuaW5ldC5pcGYuaXBsX2luaXRlZDogMQpuZXQuaW5ldC5p cGYuZnJfYXV0aHNpemU6IDMyCm5ldC5pbmV0LmlwZi5mcl9hdXRodXNlZDogMApuZXQuaW5ldC5p cGYuZnJfZGVmYXVsdGF1dGhhZ2U6IDYwMApuZXQubGluay5nZW5lcmljLnN5c3RlbS5pZmNvdW50 OiA5Cm5ldC5saW5rLmV0aGVyLmluZXQucHJ1bmVfaW50dmw6IDMwMApuZXQubGluay5ldGhlci5p bmV0Lm1heF9hZ2U6IDEyMDAKbmV0LmxpbmsuZXRoZXIuaW5ldC5ob3N0X2Rvd25fdGltZTogMjAK bmV0LmxpbmsuZXRoZXIuaW5ldC5tYXh0cmllczogNQpuZXQubGluay5ldGhlci5pbmV0LnVzZWxv b3BiYWNrOiAxCm5ldC5saW5rLmV0aGVyLmluZXQucHJveHlhbGw6IDAKZGVidWcuZWxmX3RyYWNl OiAwCmRlYnVnLmZkZXhwYW5kOiA5CmRlYnVnLnR0eWRlYnVnOiAwCmRlYnVnLm5jaGFzaDogNDA5 NQpkZWJ1Zy5uY25lZ2ZhY3RvcjogMTYKZGVidWcubnVtbmVnOiAxNQpkZWJ1Zy5udW1jYWNoZTog MjU1CmRlYnVnLnZmc2NhY2hlOiAxCmRlYnVnLnZuc2l6ZTogMTY4CmRlYnVnLm5jc2l6ZTogMzYK ZGVidWcubnVtdm5vZGVzOiAyNTYKZGVidWcud2FudGZyZWV2bm9kZXM6IDI1CmRlYnVnLmZyZWV2 bm9kZXM6IDI2CmRlYnVnLmRpc2FibGVjd2Q6IDAKZGVidWcuYnBmX2J1ZnNpemU6IDQwOTYKZGVi dWcuaWZfdHVuX2RlYnVnOiAwCmRlYnVnLmRnYl9kZWJ1ZzogMApody5tYWNoaW5lOiBpMzg2Cmh3 Lm1vZGVsOiBQZW50aXVtL1A1NEMKaHcubmNwdTogMQpody5ieXRlb3JkZXI6IDEyMzQKaHcucGh5 c21lbTogMzEzNzEyNjQKaHcudXNlcm1lbTogMjcyNDI0OTYKaHcucGFnZXNpemU6IDQwOTYKaHcu ZmxvYXRpbmdwb2ludDogMQpody5tYWNoaW5lX2FyY2g6IGkzODYKaHcuYXZhaWxwYWdlczogNzQ5 OQptYWNoZGVwLmNvbnNkZXY6IHsgbWFqb3IgPSAwLCBtaW5vciA9IDAgfQptYWNoZGVwLmFkamtl cm50ejogLTEwODAwCm1hY2hkZXAuZGlzYWJsZV9ydGNfc2V0OiAwCm1hY2hkZXAud2FsbF9jbW9z X2Nsb2NrOiAxCm1hY2hkZXAuZG9fZHVtcDogMQptYWNoZGVwLmFwbV9zdXNwZW5kX2RlbGF5OiAx Cm1hY2hkZXAuYXBtX3N0YW5kYnlfZGVsYXk6IDEKbWFjaGRlcC5pc3BjOTg6IDAKbWFjaGRlcC5t c2didWY6IAptYWNoZGVwLm1zZ2J1Zl9jbGVhcjogMAptYWNoZGVwLnVjX2Rldmxpc3Q6IBIKbWFj aGRlcC51Y19wbnBsaXN0OiAKbWFjaGRlcC5pODI1NF9mcmVxOiAxMTkzMTgyCm1hY2hkZXAudHNj X2ZyZXE6IDk5NDc0MTY2Cm1hY2hkZXAuY29uc3BlZWQ6IDk2MDAKdXNlci5jc19wYXRoOiAvdXNy L2JpbjovYmluOi91c3Ivc2Jpbjovc2JpbjoKdXNlci5iY19iYXNlX21heDogOTkKdXNlci5iY19k aW1fbWF4OiAyMDQ4CnVzZXIuYmNfc2NhbGVfbWF4OiA5OQp1c2VyLmJjX3N0cmluZ19tYXg6IDEw MDAKdXNlci5jb2xsX3dlaWdodHNfbWF4OiAwCnVzZXIuZXhwcl9uZXN0X21heDogMzIKdXNlci5s aW5lX21heDogMjA0OAp1c2VyLnJlX2R1cF9tYXg6IDI1NQp1c2VyLnBvc2l4Ml92ZXJzaW9uOiAx OTkyMTIKdXNlci5wb3NpeDJfY19iaW5kOiAwCnVzZXIucG9zaXgyX2NfZGV2OiAwCnVzZXIucG9z aXgyX2NoYXJfdGVybTogMAp1c2VyLnBvc2l4Ml9mb3J0X2RldjogMAp1c2VyLnBvc2l4Ml9mb3J0 X3J1bjogMAp1c2VyLnBvc2l4Ml9sb2NhbGVkZWY6IDAKdXNlci5wb3NpeDJfc3dfZGV2OiAwCnVz ZXIucG9zaXgyX3VwZTogMAp1c2VyLnN0cmVhbV9tYXg6IDIwCnVzZXIudHpuYW1lX21heDogMjU1 CnAxMDAzXzFiLmFzeW5jaHJvbm91c19pbzogMApwMTAwM18xYi5tYXBwZWRfZmlsZXM6IDAKcDEw MDNfMWIubWVtbG9jazogMApwMTAwM18xYi5tZW1sb2NrX3JhbmdlOiAwCnAxMDAzXzFiLm1lbW9y eV9wcm90ZWN0aW9uOiAwCnAxMDAzXzFiLm1lc3NhZ2VfcGFzc2luZzogMApwMTAwM18xYi5wcmlv cml0aXplZF9pbzogMApwMTAwM18xYi5wcmlvcml0eV9zY2hlZHVsaW5nOiAxCnAxMDAzXzFiLnJl YWx0aW1lX3NpZ25hbHM6IDAKcDEwMDNfMWIuc2VtYXBob3JlczogMApwMTAwM18xYi5mc3luYzog MApwMTAwM18xYi5zaGFyZWRfbWVtb3J5X29iamVjdHM6IDAKcDEwMDNfMWIuc3luY2hyb25pemVk X2lvOiAwCnAxMDAzXzFiLnRpbWVyczogMApwMTAwM18xYi5haW9fbGlzdGlvX21heDogMApwMTAw M18xYi5haW9fbWF4OiAwCnAxMDAzXzFiLmFpb19wcmlvX2RlbHRhX21heDogMApwMTAwM18xYi5k ZWxheXRpbWVyX21heDogMApwMTAwM18xYi5tcV9vcGVuX21heDogMApwMTAwM18xYi5wYWdlc2l6 ZTogNDA5NgpwMTAwM18xYi5ydHNpZ19tYXg6IDAKcDEwMDNfMWIuc2VtX25zZW1zX21heDogMApw MTAwM18xYi5zZW1fdmFsdWVfbWF4OiAwCnAxMDAzXzFiLnNpZ3F1ZXVlX21heDogMApwMTAwM18x Yi50aW1lcl9tYXg6IDAK ------=_NextPart_000_0039_01C016AC.1E2C9C80 Content-Type: application/octet-stream; name="BRUS.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BRUS.dat" IwojIFBPUCBrZXJuZWwsIEJlbFBBSywgTW9uIEF1ZyAyMSAyMDAwLgojCgoKIwojIE1hY2hpbmUg ZGVzY3JpcHRpb24KIwoKbWFjaGluZQkJImkzODYiCmNwdQkJIkk1ODZfQ1BVIgpjcHUJCSJJNjg2 X0NQVSIKaWRlbnQJCUJSVVMKbWF4dXNlcnMJMzIKCgojCiMgTWFjaGluZSBvcHRpb25zCiMKCm9w dGlvbnMgCUlORVQJCQkjSW50ZXJORVR3b3JraW5nCm9wdGlvbnMgCUZGUwkJCSNCZXJrZWxleSBG YXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJRkZTX1JPT1QJCSNGRlMgdXNhYmxlIGFzIHJvb3QgZGV2 aWNlIFtrZWVwIHRoaXMhXQpvcHRpb25zIAlNRlMJCQkjTWVtb3J5IEZpbGVzeXN0ZW0Kb3B0aW9u cyAJTUZTX1JPT1QJCSNNRlMgdXNhYmxlIGFzIHJvb3QgZGV2aWNlLCAiTUZTIiByZXEnZWQKb3B0 aW9ucyAJTkZTCQkJI05ldHdvcmsgRmlsZXN5c3RlbQpvcHRpb25zIAlORlNfUk9PVAkJI05GUyB1 c2FibGUgYXMgcm9vdCBkZXZpY2UsICJORlMiIHJlcSdlZApvcHRpb25zIAlQUk9DRlMJCQkjUHJv Y2VzcyBmaWxlc3lzdGVtCm9wdGlvbnMgCSJDT01QQVRfNDMiCQkjQ29tcGF0aWJsZSB3aXRoIEJT RCA0LjMgW0tFRVAgVEhJUyFdCm9wdGlvbnMgCVVDT05TT0xFCQkjQWxsb3cgdXNlcnMgdG8gZ3Jh YiB0aGUgY29uc29sZQpvcHRpb25zIAlGQUlMU0FGRQkJI0JlIGNvbnNlcnZhdGl2ZQpvcHRpb25z IAlVU0VSQ09ORklHCQkjYm9vdCAtYyBlZGl0b3IKb3B0aW9ucyAJVklTVUFMX1VTRVJDT05GSUcJ I3Zpc3VhbCBib290IC1jIGVkaXRvcgpvcHRpb25zIAlLVFJBQ0UJCQkja3RyYWNlKDEpIHN5c2Nh bGwgdHJhY2Ugc3VwcG9ydApvcHRpb25zIAlTWVNWU0hNCQkJI1NZU1Ytc3R5bGUgc2hhcmVkIG1l bW9yeQpvcHRpb25zIAlTWVNWTVNHCQkJI1NZU1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXMKb3B0aW9u cyAJU1lTVlNFTQkJCSNTWVNWLXN0eWxlIHNlbWFwaG9yZXMKCgojCiMgS2VybmVsIHdoZXJlCiMK CmNvbmZpZwkJa2VybmVsCXJvb3Qgb24gd2QwCgoKIwojIEJ1cyBjb250cm9sbGVycwojCgpjb250 cm9sbGVyCWlzYTAKY29udHJvbGxlcglwbnAwCQkJIyBQblAgc3VwcG9ydCBmb3IgSVNBCmNvbnRy b2xsZXIJZWlzYTAKY29udHJvbGxlcglwY2kwCgojCiMgRmxvcHB5IGRyaXZlcwojCgpjb250cm9s bGVyCWZkYzAJYXQgaXNhPyBwb3J0ICJJT19GRDEiIGJpbyBpcnEgNiBkcnEgMgpkaXNrCQlmZDAJ YXQgZmRjMCBkcml2ZSAwCgoKIwojIElERSBjb250cm9sbGVycwojCgpvcHRpb25zIAkiQ01ENjQw IgkjIHdvcmsgYXJvdW5kIENNRDY0MCBjaGlwIGRlZmljaWVuY3kKY29udHJvbGxlcgl3ZGMwCWF0 IGlzYT8gcG9ydCAiSU9fV0QxIiBiaW8gaXJxIDE0IGZsYWdzIDB4ODBmZjgwZmYKZGlzawkJd2Qw CWF0IHdkYzAgZHJpdmUgMAoKCiMKIyBLZXlib2FyZCBjb250cm9sbGVycwojCgpjb250cm9sbGVy CWF0a2JkYzAJYXQgaXNhPyBwb3J0IElPX0tCRCB0dHkKZGV2aWNlCQlhdGtiZDAJYXQgaXNhPyB0 dHkgaXJxIDEKZGV2aWNlCQl2Z2EwCWF0IGlzYT8gcG9ydCA/IGNvbmZsaWN0cwoKCiMKIyBTcGxh c2ggc2NyZWVuL3NjcmVlbiBzYXZlcgojCgpwc2V1ZG8tZGV2aWNlCXNwbGFzaAoKCiMKIyBDb25z b2xlIGRyaXZlcgojCgpkZXZpY2UJCXNjMAlhdCBpc2E/IHR0eQoKCiMKIyBGbG9hdGluZyBwb2lu dCBzdXBwb3J0CiMKCmRldmljZQkJbnB4MAlhdCBpc2E/IHBvcnQgSU9fTlBYIGlycSAxMwoKCiMK IyBQb3dlciBtYW5hZ2VtZW50CiMKCmRldmljZQkJYXBtMCAgICBhdCBpc2E/CWRpc2FibGUJZmxh Z3MgMHgzMSAjIEFkdmFuY2VkIFBvd2VyIE1hbmFnZW1lbnQKCgojCiMgU2VyaWFsIChDT00pIHBv cnRzCiMKCmRldmljZQkJc2lvMAlhdCBpc2E/IHBvcnQgIklPX0NPTTEiIGZsYWdzIDB4MTAgdHR5 IGlycSA0CmRldmljZQkJc2lvMQlhdCBpc2E/IHBvcnQgIklPX0NPTTIiIHR0eSBpcnEgMwpkZXZp Y2UJCWRnYjAJYXQgaXNhPyBwb3J0IDB4MzAwIGlvbWVtIDB4RDAwMDAgaW9zaXo/IHR0eQoKCiMK IyBJU0EgRXRoZXJuZXQgTklDcy4KIwoKZGV2aWNlCQllZDAJYXQgaXNhPyBwb3J0IDB4MzIwIG5l dCBpcnEgMTAgaW9tZW0gMHhkODAwMApkZXZpY2UJCWVkMQlhdCBpc2E/IHBvcnQgMHgyNjAgbmV0 IGlycSA1IGlvbWVtPwoKCiMKIyBQc2V1ZG8gZGV2aWNlcwojCgpwc2V1ZG8tZGV2aWNlCWxvb3AJ CSMgTmV0d29yayBsb29wYmFjawpwc2V1ZG8tZGV2aWNlCWV0aGVyCQkjIEV0aGVybmV0IHN1cHBv cnQKcHNldWRvLWRldmljZQl0dW4JMQkjIFBhY2tldCB0dW5uZWwKcHNldWRvLWRldmljZQlwdHkJ MTYJIyBQc2V1ZG8tdHR5cyAodGVsbmV0IGV0YykKcHNldWRvLWRldmljZQlnemlwCQkjIEV4ZWMg Z3ppcHBlZCBhLm91dCdzCnBzZXVkby1kZXZpY2UJYnBmaWx0ZXIgNgkjIEJlcmtlbGV5IHBhY2tl dCBmaWx0ZXIKcHNldWRvLWRldmljZQlwcHAJNQkjIEtlcm5lbCBQUFAKCgojCiMgTmV0d29ya2lu ZyBvcHRpb25zCiMKCm9wdGlvbnMJCUlQRklSRVdBTEwKb3B0aW9ucwkJSVBESVZFUlQKb3B0aW9u cwkJSVBGSUxURVIKb3B0aW9ucwkJSVBTVEVBTFRICm9wdGlvbnMJCVBQUF9CU0RDT01QCm9wdGlv bnMJCVBQUF9ERUZMQVRFCgoKIwojIFBvc2l4IGNvbXBhdGliaWxpdHkKIwoKb3B0aW9ucwkJIlAx MDAzXzFCIgpvcHRpb25zCQkiX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HIgpvcHRpb25zCQki X0tQT1NJWF9WRVJTSU9OPTE5OTMwOUwiCgo= ------=_NextPart_000_0039_01C016AC.1E2C9C80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 2: 1: 1 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6A6E937B422; Tue, 5 Sep 2000 02:01:00 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id CAA72634; Tue, 5 Sep 2000 02:01:00 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 02:01:00 -0700 (PDT) From: Message-Id: <200009050901.CAA72634@freefall.freebsd.org> To: oseberg@hotmail.com, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/21056: Apache 1.3 Virtual Hosts don't work on 4.0-RELEASE Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Apache 1.3 Virtual Hosts don't work on 4.0-RELEASE State-Changed-From-To: open->closed State-Changed-By: sheldonh State-Changed-When: Tue Sep 5 01:57:41 PDT 2000 State-Changed-Why: "Doesn't work" isn't a problem description that anyone can really work with for such a complex beast as Apache. "Try to set up" isn't a feasible How-To-Repeat either, again because of the complexity and number of variables within the scenario. Please either ask for help on the mailing list (if you're not 100% sure that this is a bug in FreeBSD) or refile a new PR that provides enough information for the Apache port maintainer to work with. Such information might include the output of ifconfig -a, nslookup output for each IP address identified, and your Apache config files. http://www.freebsd.org/cgi/query-pr.cgi?pr=21056 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 2: 4: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DEA0537B423; Tue, 5 Sep 2000 02:03:58 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id CAA73183; Tue, 5 Sep 2000 02:03:58 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 02:03:58 -0700 (PDT) From: Message-Id: <200009050903.CAA73183@freefall.freebsd.org> To: shurd@sk.sympatico.ca, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, yokota@FreeBSD.org Subject: Re: i386/21042: Keyboard driver problems with PS/2 Model 95 (MCA) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Keyboard driver problems with PS/2 Model 95 (MCA) State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Tue Sep 5 02:01:57 PDT 2000 State-Changed-Why: Does Andy's suggestion work for you? Please be sure to send your follow-up to , preserving the Subject line of this e-mail message. Responsible-Changed-From-To: freebsd-bugs->yokota Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 02:01:57 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21042 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 2: 6:40 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CA8C537B43F; Tue, 5 Sep 2000 02:06:38 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id CAA75175; Tue, 5 Sep 2000 02:06:38 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 02:06:38 -0700 (PDT) From: Message-Id: <200009050906.CAA75175@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sos@FreeBSD.org Subject: Re: kern/21046: ATAPI interface hangs during install of 4.1 from CDROM Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: ATAPI interface hangs during install of 4.1 from CDROM Responsible-Changed-From-To: freebsd-bugs->sos Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 02:05:06 PDT 2000 Responsible-Changed-Why: I think that wfd was fixed in 4.1-STABLE, but I can't remember. Soren will know. http://www.freebsd.org/cgi/query-pr.cgi?pr=21046 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 2:17:24 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 70CEF37B424; Tue, 5 Sep 2000 02:17:20 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13WEr0-0000nU-00; Tue, 05 Sep 2000 11:17:18 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id LAA27564; Tue, 5 Sep 2000 11:17:16 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 26814; Tue Sep 5 11:13:21 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13WEnB-0002vj-00; Tue, 05 Sep 2000 11:13:21 +0200 From: Sheldon Hearn To: kris@freebsd.org Cc: freebsd-bugs@freebsd.org Subject: Re: misc/10302: installer In-reply-to: Your message of "Mon, 04 Sep 2000 16:08:01 MST." <200009042308.QAA79155@freefall.freebsd.org> Date: Tue, 05 Sep 2000 11:13:21 +0200 Message-ID: <11266.968145201@axl.fw.uunet.co.za> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 04 Sep 2000 16:08:01 MST, kris@FreeBSD.ORG wrote: > Synopsis: installer > > Responsible-Changed-From-To: freebsd-bugs->jkh > Responsible-Changed-By: kris > Responsible-Changed-When: Mon Sep 4 16:07:36 PDT 2000 > Responsible-Changed-Why: > I don't knwo if this still applies, but jkh is Mr Sysinstall For your info, murray is now Mr. Sysinstall. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 2:31:29 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 517B237B42C; Tue, 5 Sep 2000 02:31:28 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id CAA79240; Tue, 5 Sep 2000 02:31:28 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 02:31:28 -0700 (PDT) From: Message-Id: <200009050931.CAA79240@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: kern/21028: Add Zoom V90 Internal modem support Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Add Zoom V90 Internal modem support Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 02:31:13 PDT 2000 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=21028 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 3:20: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 13DAA37B422 for ; Tue, 5 Sep 2000 03:20:07 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA86009; Tue, 5 Sep 2000 03:20:06 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 03:20:06 -0700 (PDT) Message-Id: <200009051020.DAA86009@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: bin/21017: mtree's "no such file" message at job's end Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21017; it has been noted by GNATS. From: Sheldon Hearn To: Gerhard Sittig Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/21017: mtree's "no such file" message at job's end Date: Tue, 05 Sep 2000 12:18:24 +0200 On Sun, 03 Sep 2000 21:11:43 +0200, Gerhard Sittig wrote: > >Number: 21017 > >Category: bin > >Synopsis: mtree "no such file" message at job's end Let us know if you can come up with a simpler How-To-Repeat that generates the error predictably. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 3:26:37 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0955E37B422; Tue, 5 Sep 2000 03:26:35 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA86638; Tue, 5 Sep 2000 03:26:35 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 03:26:35 -0700 (PDT) From: Message-Id: <200009051026.DAA86638@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: bin/21006: Minor fix to 'lprm' message Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Minor fix to 'lprm' message Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 03:26:16 PDT 2000 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=21006 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 3:27:19 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D415A37B422; Tue, 5 Sep 2000 03:27:17 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA86777; Tue, 5 Sep 2000 03:27:17 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 03:27:17 -0700 (PDT) From: Message-Id: <200009051027.DAA86777@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: bin/21007: Improve/fix error messages in lpr's recvjob processing Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Improve/fix error messages in lpr's recvjob processing Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 03:26:39 PDT 2000 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=21007 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 3:29:49 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 06B3E37B422; Tue, 5 Sep 2000 03:29:48 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA87223; Tue, 5 Sep 2000 03:29:48 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 03:29:48 -0700 (PDT) From: Message-Id: <200009051029.DAA87223@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: bin/21008: Fix for lpr's handling of lots of jobs in a queue Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Fix for lpr's handling of lots of jobs in a queue Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 03:29:31 PDT 2000 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=21008 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 3:50: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 922D837B42C for ; Tue, 5 Sep 2000 03:50:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA89445; Tue, 5 Sep 2000 03:50:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by hub.freebsd.org (Postfix) with ESMTP id 89ABE37B422 for ; Tue, 5 Sep 2000 03:49:55 -0700 (PDT) Received: by bulls.mei.co.jp (8.11.0/3.7W) with ESMTP id e85Anob14144 for ; Tue, 5 Sep 2000 19:49:50 +0900 (JST) Received: by mariners.mei.co.jp (8.9.1/3.7W) with ESMTP id TAA15658 for ; Tue, 5 Sep 2000 19:49:50 +0900 (JST) Received: by dream.vrl.mei.co.jp (8.11.0/3.7W-08/28/00) id e85AnnA31919; Tue, 5 Sep 2000 19:49:49 +0900 (JST) Message-Id: <200009051049.e85AnnA31919@dream.vrl.mei.co.jp> Date: Tue, 5 Sep 2000 19:49:49 +0900 (JST) From: takamune@avrl.mei.co.jp Reply-To: takamune@avrl.mei.co.jp To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: conf/21059: `make -jN buildkernel' can't keep source tree read-only Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21059 >Category: conf >Synopsis: `make -jN buildkernel' can't keep source tree read-only >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 03:50:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Kazu TAKAMUNE >Release: FreeBSD 4.1-STABLE i386 >Organization: Matsushita Electric Industrial Co., Ltd. >Environment: FreeBSD 4.1-STABLE(Mon Sep 4 10:23:26 JST 2000) (SMP: Dual PentiumIII/500MHz) >Description: `make -jN buildkernel' will create some object files inside of the source tree. Please divide `make obj depend' into two stages. >How-To-Repeat: Owner of the source files is a normal user: # cd /usr/src # find . -name CVS -prune -o -user root -print # make -j8 buildkernel # find . -name CVS -prune -o -user root -print src/sys/modules/accf_data/@ src/sys/modules/accf_data/machine src/sys/modules/accf_data/.depend src/sys/modules/accf_http/@ src/sys/modules/accf_http/machine src/sys/modules/accf_http/.depend These files should appear in directories such as /usr/obj/usr/src/sys/${KERNEL}/modules/usr/src/sys/modules/accf_{data,http}. Note: `accf_data' and `accf_http' are the first two modules in `src/sys/modules/Makefile' ! >Fix: Index: src/sys/conf/Makefile.i386 =================================================================== RCS file: /home/ncvs/src/sys/conf/Makefile.i386,v retrieving revision 1.179.2.2 diff -u -r1.179.2.2 Makefile.i386 --- src/sys/conf/Makefile.i386 2000/07/07 00:29:27 1.179.2.2 +++ src/sys/conf/Makefile.i386 2000/09/05 10:00:00 @@ -229,13 +229,15 @@ reinstall reinstall.debug: modules-reinstall .endif -modules: +modules-obj: @mkdir -p ${.OBJDIR}/modules - cd $S/modules && env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE} obj all + cd $S/modules && env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE} obj -modules-depend: - @mkdir -p ${.OBJDIR}/modules - cd $S/modules && env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE} obj depend +modules-depend: modules-obj + cd $S/modules && env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE} depend + +modules: modules-obj + cd $S/modules && env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE} all modules-clean: cd $S/modules && env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE} clean >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 3:54:25 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2FFBC37B424; Tue, 5 Sep 2000 03:54:24 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA90055; Tue, 5 Sep 2000 03:54:24 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 03:54:24 -0700 (PDT) From: Message-Id: <200009051054.DAA90055@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, marcel@FreeBSD.org Subject: Re: conf/21059: `make -jN buildkernel' can't keep source tree read-only Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: `make -jN buildkernel' can't keep source tree read-only Responsible-Changed-From-To: freebsd-bugs->marcel Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 03:54:14 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21059 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 4:50: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2161737B43F for ; Tue, 5 Sep 2000 04:50:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA00525; Tue, 5 Sep 2000 04:50:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 04:50:02 -0700 (PDT) Message-Id: <200009051150.EAA00525@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: bin/20993: many ftpd commands not limited to logins Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20993; it has been noted by GNATS. From: Sheldon Hearn To: jedgar@fxp.org Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/20993: many ftpd commands not limited to logins Date: Tue, 05 Sep 2000 13:36:43 +0200 On Sat, 02 Sep 2000 07:18:00 -0400, jedgar@fxp.org wrote: > >Number: 20993 > >Category: bin > >Synopsis: many ftpd commands not limited to logins This would need to spend a _long_ time in CURRENT before being merged into RELENG_4. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 4:50: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id EC60C37B440 for ; Tue, 5 Sep 2000 04:50:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA00537; Tue, 5 Sep 2000 04:50:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 04:50:04 -0700 (PDT) Message-Id: <200009051150.EAA00537@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Chris D. Faulhaber" Subject: Re: bin/20993: many ftpd commands not limited to logins Reply-To: "Chris D. Faulhaber" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20993; it has been noted by GNATS. From: "Chris D. Faulhaber" To: Sheldon Hearn Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/20993: many ftpd commands not limited to logins Date: Tue, 5 Sep 2000 07:43:21 -0400 (EDT) On Tue, 5 Sep 2000, Sheldon Hearn wrote: > On Sat, 02 Sep 2000 07:18:00 -0400, jedgar@fxp.org wrote: > > > >Number: 20993 > > >Category: bin > > >Synopsis: many ftpd commands not limited to logins > > This would need to spend a _long_ time in CURRENT before being merged > into RELENG_4. > Ummm, ok. The changes are quite trivial, though. ----- Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 5: 0: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5D82437B422 for ; Tue, 5 Sep 2000 05:00:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA01625; Tue, 5 Sep 2000 05:00:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 05:00:04 -0700 (PDT) Message-Id: <200009051200.FAA01625@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: bin/20974: securelevel not reset when going to single user mode Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20974; it has been noted by GNATS. From: Sheldon Hearn To: Bruce Evans Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/20974: securelevel not reset when going to single user mode Date: Tue, 05 Sep 2000 13:50:42 +0200 On Tue, 05 Sep 2000 06:07:23 +1100, Bruce Evans wrote: > Some more updates are needed. As far as this PR is concerned, about the best improvement I can think of for the securelevel misunderstanding is included below. I don't think that the manual page is lacking right now, but this patch causes it to state the situation explicitly. Ciao, Sheldon. Index: init.8 =================================================================== RCS file: /home/ncvs/src/sbin/init/init.8,v retrieving revision 1.22 diff -u -d -r1.22 init.8 --- init.8 2000/03/01 11:27:06 1.22 +++ init.8 2000/09/05 11:48:03 @@ -93,6 +93,8 @@ .Pp The kernel runs with four different levels of security. Any super-user process can raise the security level, but no process +(including +.Nm Ns ) can lower it. The security levels are: .Bl -tag -width flag To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 5: 0: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D311F37B422 for ; Tue, 5 Sep 2000 05:00:07 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA01637; Tue, 5 Sep 2000 05:00:07 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 05:00:07 -0700 (PDT) Message-Id: <200009051200.FAA01637@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: bin/20993: many ftpd commands not limited to logins Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20993; it has been noted by GNATS. From: Sheldon Hearn To: "Chris D. Faulhaber" Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/20993: many ftpd commands not limited to logins Date: Tue, 05 Sep 2000 13:56:20 +0200 On Tue, 05 Sep 2000 07:43:21 -0400, "Chris D. Faulhaber" wrote: > > This would need to spend a _long_ time in CURRENT before being merged > > into RELENG_4. > > > > Ummm, ok. The changes are quite trivial, though. The deltas are small and simple, but the potential impact is not trivial. How much time have you spent investigating what this will do to various software packages that rely on the current behaviour? I realize that several other FTP daemons behave as you propose that ours should. I just don't think that we should rush the merge into STABLE, especially since this doesn't seem to fix any glaring security holes. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 5:40: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7DD3237B440 for ; Tue, 5 Sep 2000 05:40:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA09206; Tue, 5 Sep 2000 05:40:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 05:40:04 -0700 (PDT) Message-Id: <200009051240.FAA09206@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Chris D. Faulhaber" Subject: Re: bin/20993: many ftpd commands not limited to logins Reply-To: "Chris D. Faulhaber" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20993; it has been noted by GNATS. From: "Chris D. Faulhaber" To: Sheldon Hearn Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/20993: many ftpd commands not limited to logins Date: Tue, 5 Sep 2000 08:30:16 -0400 (EDT) On Tue, 5 Sep 2000, Sheldon Hearn wrote: > > > On Tue, 05 Sep 2000 07:43:21 -0400, "Chris D. Faulhaber" wrote: > > > > This would need to spend a _long_ time in CURRENT before being merged > > > into RELENG_4. > > > > > > > Ummm, ok. The changes are quite trivial, though. > > The deltas are small and simple, but the potential impact is not > trivial. How much time have you spent investigating what this will do > to various software packages that rely on the current behaviour? > > I realize that several other FTP daemons behave as you propose that ours > should. I just don't think that we should rush the merge into STABLE, > especially since this doesn't seem to fix any glaring security holes. > a) none of the commands affected should be used if a user is not logged in, and the patch does not change the behaviour of commands once a user is authenticated b) all changes were taken from OpenBSD c) we currently allow the SYST command to be issued to anyone who connects (comments about which prompted me to make these changes), which some may not realize (and others may view as a security concern) d) Works Here[tm] (ok, lame excuse) e) if these changes are unwanted, I'll gladly close the PR and save the gnats bloat. ----- Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 6: 0: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A8A9A37B42C for ; Tue, 5 Sep 2000 06:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA12621; Tue, 5 Sep 2000 06:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 06:00:01 -0700 (PDT) Message-Id: <200009051300.GAA12621@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: bin/20993: many ftpd commands not limited to logins Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20993; it has been noted by GNATS. From: Sheldon Hearn To: "Chris D. Faulhaber" Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/20993: many ftpd commands not limited to logins Date: Tue, 05 Sep 2000 14:46:19 +0200 On Tue, 05 Sep 2000 08:30:16 -0400, "Chris D. Faulhaber" wrote: > e) if these changes are unwanted, I'll gladly close the PR and save the > gnats bloat. I think the change is desirable. All I said (third time lucky) is that we should give this a while to settle in CURRENT before merging it into STABLE. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 7:10: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6907F37B42C for ; Tue, 5 Sep 2000 07:10:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA86997; Tue, 5 Sep 2000 07:10:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from duplo.sm.sony.co.jp (duplo.sm.sony.co.jp [133.138.10.36]) by hub.freebsd.org (Postfix) with ESMTP id C5D5D37B422 for ; Tue, 5 Sep 2000 07:02:40 -0700 (PDT) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.0/8.9.3) id e85E2fk00786; Tue, 5 Sep 2000 23:02:41 +0900 (JST) (envelope-from onoe) Message-Id: <200009051402.e85E2fk00786@duplo.sm.sony.co.jp> Date: Tue, 5 Sep 2000 23:02:41 +0900 (JST) From: Atsushi Onoe Reply-To: onoe@duplo.sm.sony.co.jp To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21061: basename(1) ignores suffix argument Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21061 >Category: bin >Synopsis: basename(1) ignores suffix argument >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 07:10:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Atsushi Onoe >Release: FreeBSD 5.0-CURRENT i386 >Organization: Sony Corporation >Environment: FreeBSD duplo.sm.sony.co.jp 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Tue Sep 5 22:16:21 JST 2000 onoe@duplo.sm.sony.co.jp:/work/freebsd/src/sys/compile/DUPLO i386 >Description: As a result of recent change to basename(1) simply to use basename(3), basename(1) no longer delete suffix from the first argument. >How-To-Repeat: % basename foo.c .c foo.c >Fix: back out rev. 1.4 >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 7:20: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 491C437B42C for ; Tue, 5 Sep 2000 07:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA88490; Tue, 5 Sep 2000 07:20:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 07:20:03 -0700 (PDT) Message-Id: <200009051420.HAA88490@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Atsushi Onoe Subject: Re: bin/21061: basename(1) ignores suffix argument Reply-To: Atsushi Onoe Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21061; it has been noted by GNATS. From: Atsushi Onoe To: FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: bin/21061: basename(1) ignores suffix argument Date: Tue, 5 Sep 2000 23:15:38 +0900 (JST) > From: Atsushi Onoe Sorry, I've mailed with wrong address. Atsushi Onoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 7:20: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B6ACA37B42C for ; Tue, 5 Sep 2000 07:20:07 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA88507; Tue, 5 Sep 2000 07:20:07 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 07:20:07 -0700 (PDT) Message-Id: <200009051420.HAA88507@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: bin/4696: ping hangs on certain unresolvable hosts Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/4696; it has been noted by GNATS. From: Bruce Evans To: kris@FreeBSD.ORG Cc: marcs@znep.com, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: bin/4696: ping hangs on certain unresolvable hosts Date: Wed, 6 Sep 2000 01:09:49 +1100 (EST) On Mon, 4 Sep 2000 kris@FreeBSD.ORG wrote: > Synopsis: ping hangs on certain unresolvable hosts > > State-Changed-From-To: open->closed > State-Changed-By: kris > State-Changed-When: Mon Sep 4 15:21:48 PDT 2000 > State-Changed-Why: > Fixed by sef in r1.24 of ping.c on 1997/07/13 No, this was only fixed for some values of "certain", and not the ones described in the PR. Rev.1.24 of ping.c mainly makes all syscalls return EINTR when they are interrupted by a SIGINT or SIGALRM. This fixes hangs in sendto() and/or recvmsg(), but has no effect on the hangs described in the PR since those involve select() and select() always returns EINTR when it is interrupted. As described in the PR, res_send() retries almost endlessly after select() returns EINTR. I think this is a bug in res_send(). It can't be aborted by non-broken signal handlers except by ones that do little more than call _exit(2). ping used to have broken signal handlers that did lots of unsafe cleanups before exiting unsafely by calling exit(3). PR 20613 is about essentially the same bug for "fetch -T n". The timeout doesn't work when the SIGALRM occurs in res_send(), since res_send() just retries after select() returns EINTR. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 7:29: 1 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A866037B422; Tue, 5 Sep 2000 07:28:59 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA89674; Tue, 5 Sep 2000 07:28:59 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 07:28:59 -0700 (PDT) From: Message-Id: <200009051428.HAA89674@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, des@FreeBSD.org Subject: Re: bin/21061: basename(1) ignores suffix argument Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: basename(1) ignores suffix argument Responsible-Changed-From-To: freebsd-bugs->des Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 07:28:35 PDT 2000 Responsible-Changed-Why: Over to DES, so that he can review the patch I'm about to send. http://www.freebsd.org/cgi/query-pr.cgi?pr=21061 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 8: 0: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A5C1137B443 for ; Tue, 5 Sep 2000 08:00:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA95051; Tue, 5 Sep 2000 08:00:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.147.224.201]) by hub.freebsd.org (Postfix) with ESMTP id B8AEC37B424 for ; Tue, 5 Sep 2000 07:58:17 -0700 (PDT) Received: from baby.int.thehousleys.net (baby.int.thehousleys.net. [192.168.0.24]) by thehousleys.net (8.9.3/8.9.3) with ESMTP id KAA51149 for ; Tue, 5 Sep 2000 10:58:12 -0400 (EDT) (envelope-from housley@thehousleys.net) Received: (from housley@localhost) by baby.int.thehousleys.net (8.9.3/8.9.3) id KAA02828; Tue, 5 Sep 2000 10:58:08 -0400 (EDT) (envelope-from housley) Message-Id: <200009051458.KAA02828@baby.int.thehousleys.net> Date: Tue, 5 Sep 2000 10:58:08 -0400 (EDT) From: jim@thehousleys.net Reply-To: jim@thehousleys.net To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21062: /etc/pccard_ether calling IPv6 programs too early Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21062 >Category: bin >Synopsis: /etc/pccard_ether calling IPv6 programs too early >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 08:00:03 PDT 2000 >Closed-Date: >Last-Modified: >Originator: James E. Housley >Release: FreeBSD 4.1-STABLE i386 >Organization: The Housleys dot Net >Environment: FreeBSD 4.1-STABLE CTM as of 9/4/2000 >Description: The IPv6 section of /etc/pccard_ether calls rtsol ${interface}. This produces and "rtsol not configured" or similar. rtsol is run again in /etc/rc.network6 where it succeds in running. The whole IPv6 section might be able to be removed from /etc/pccard_ether. >How-To-Repeat: >Fix: --- pccard_ether Wed Jul 19 07:01:46 2000 +++ pccard_ether.new Tue Sep 5 10:53:01 2000 @@ -68,13 +68,6 @@ # IPv6 setup case ${ipv6_enable} in [Yy][Ee][Ss]) - case ${ipv6_gateway_enable} in - [Yy][Ee][Ss]) - ;; - *) - ifconfig ${interface} up - rtsol ${interface} - ;; - esac + ifconfig ${interface} up ;; esac >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 8: 3: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id 5BA9637B424 for ; Tue, 5 Sep 2000 08:03:01 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id JAA26962; Tue, 5 Sep 2000 09:02:52 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200009051502.JAA26962@hunkular.glarp.com> To: itojun@iijlab.net Cc: bugs@freebsd.org, huntting@glarp.com, Hajimu UMEMOTO , core@kame.net Subject: Re: kern/21016: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses In-Reply-To: Your message of "Tue, 05 Sep 2000 09:29:42 +0900." <8621.968113782@coconut.itojun.org> Date: Tue, 05 Sep 2000 09:02:52 -0600 From: Brad Huntting Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>> this is a feature. IPv4 mapped address on AF_INET6 socket is just >>> to help porting basic IPv4 apps at ease. to manipulate IPv4 traffic >>> in detail (including TOS/TTL, or multicast), you must use AF_INET >>> socket. >>Section 3.7 of draft-ietf-ipngwg-rfc2553bis-00.txt does not aggre. >>V4 mapped addresses are clearly intended to allow "basic" v6 apps >>to interoperate with legacy v4 apps w/o duplicating code. And >>"basic" in this case most definitly includes multicast. > where did you get the impression for the last sentence? > from my understanding, multicast is outside of scope (and I'm very > convinced about it) > the more you try to use IPv4 mapped address in wider scope, the system > gets more messy. "basic" as in draft-ietf-ipngwg-rfc2553bis-00.txt "Basic Socket Interface Extensions for IPv6". But more specifically, the paragraph 4 of section 2: - Where possible, applications should be able to use this API to interoperate with both IPv6 and IPv4 hosts. Applications should not need to know which type of host they are communicating with. [....] Because of the importance of providing IPv4 compatibility in the API, these extensions are explicitly designed to operate on machines that provide complete support for both IPv4 and IPv6. A subset of this API could probably be designed for operation on systems that support only IPv6. However, this is not addressed in this memo. And since section 5.2 of this draft clearly lays out the multicast socket options, it would seem that multicast is "basic", and that one should be able to use this multicast API on mapped addresses. Besides, it makes sense to include multicast. Otherwise each application will need seperate code to deal with v4 and v6 multicast addresses. And this is exactly the problem that mapped v4 addresses are supposed to solve. >>Is KAME planning on fixing this anytime soon? > I don't think so. I can't speak for other KAME guys. It sounds like this is worth asking the ipng group at any rate. brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 8: 9:56 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 9F38737B422 for ; Tue, 5 Sep 2000 08:09:53 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id AAA18538; Wed, 6 Sep 2000 00:09:51 +0900 (JST) To: Brad Huntting Cc: bugs@freebsd.org, huntting@glarp.com, Hajimu UMEMOTO , core@kame.net In-reply-to: huntting's message of Tue, 05 Sep 2000 09:02:52 CST. <200009051502.JAA26962@hunkular.glarp.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: kern/21016: IPV6_JOIN_GROUP doesnt work for mapped IPv4 multicast addresses From: itojun@iijlab.net Date: Wed, 06 Sep 2000 00:09:50 +0900 Message-ID: <18536.968166590@coconut.itojun.org> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >"basic" as in draft-ietf-ipngwg-rfc2553bis-00.txt "Basic Socket >Interface Extensions for IPv6". But more specifically, the paragraph >4 of section 2: (snip) >And since section 5.2 of this draft clearly lays out the multicast >socket options, it would seem that multicast is "basic", and that >one should be able to use this multicast API on mapped addresses. >Besides, it makes sense to include multicast. Otherwise each >application will need seperate code to deal with v4 and v6 multicast >addresses. And this is exactly the problem that mapped v4 addresses >are supposed to solve. My take is that IPv4 mapped address helps porting of very limited set of applications ("basic" application in my sense), and the limitation is like this: - original AF_INET application has no setsockopt(IPPROTO_IP) as there's no document which talk about how to map IPPROTO_IP socket option and IPPROTO_IPV6 socket option, it is not possible to map it. also, in some cases there's no counterpart in IPv6 (like IP_OPTIONS, IP_HDRINCL, IP_RECVOPTS). >>>Is KAME planning on fixing this anytime soon? >> I don't think so. I can't speak for other KAME guys. >It sounds like this is worth asking the ipng group at any rate. please do. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 8:20: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1398B37B424 for ; Tue, 5 Sep 2000 08:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA99305; Tue, 5 Sep 2000 08:20:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 08:20:03 -0700 (PDT) Message-Id: <200009051520.IAA99305@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/20992; it has been noted by GNATS. From: Bruce Evans To: Sheldon Hearn , ru@freebsd.org Cc: freebsd-gnats-submit@freebsd.org Subject: re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks Date: Wed, 6 Sep 2000 02:15:23 +1100 (EST) On Mon, 4 Sep 2000, Sheldon Hearn wrote: > Subject: re: kern/20992: kern/tty_subr.c, b_to_q to a clist with no reserved cblocks > ... > Could you two take a look at PR kern/20992? The reported error message > was introduced by Peter, but it looks like it may have been tickled by > Poul-Henning's change to the dgb(4) driver. tty_subr.c and dgb didn't change between 3.3 and 3.5, and the driver may be sio anyway. (Who knows what is in 3.5.1? It isn't tagged.) sio.c has some small probably-unrelated changes. if_sl.c has some small possibly-related changes. I think the only way there can be no reserved cblocks is when slip of ppp sets the reservation to 0 and the reservation for termios discipline somehow doesn't get restored. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 9:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CE0C137B43E for ; Tue, 5 Sep 2000 09:20:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA09909; Tue, 5 Sep 2000 09:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from mx0.dircon.net (mx0.dircon.net [194.112.50.10]) by hub.freebsd.org (Postfix) with ESMTP id 396C037B424 for ; Tue, 5 Sep 2000 09:16:22 -0700 (PDT) Received: from diablo.dircon.net (desk108.ch.dircon.net [195.157.3.108]) by mx0.dircon.net (8.9.1.Dirconised/8.9.1) with ESMTP id RAA07748 for ; Tue, 5 Sep 2000 17:16:15 +0100 (BST) Received: by diablo.dircon.net (Postfix, from userid 1000) id 51FD61B21A; Tue, 5 Sep 2000 17:16:15 +0100 (BST) Message-Id: <20000905161615.51FD61B21A@diablo.dircon.net> Date: Tue, 5 Sep 2000 17:16:15 +0100 (BST) From: mark.blackman@dircon.net Reply-To: mark.blackman@dircon.net To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21064: /bin/sh core dumps on some 8 bit chars in words or here-docs Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21064 >Category: bin >Synopsis: /bin/sh core dumps on some 8 bit chars in words or here-docs >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 09:20:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Mark Blackman >Release: FreeBSD 4.1-STABLE i386 >Organization: Direct Connection >Environment: 4-STABLE >Description: /bin/sh in 4-STABLE *will* coredump if it gets certain 8 bit chars in either shell words or in here-documents. The main offender is 0x82/\0202/130. >How-To-Repeat: printf "echo \202" > tmpfile sh tmpfile >Fix: only fix is currently in 5-CURRENT. not merged to 4-STABLE yet. That fix is regarded as sub-optimal according to correspondence in the freebsd-current mailing lists (see freebsd-current July 28,2000) >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 9:30: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BF37A37B424 for ; Tue, 5 Sep 2000 09:30:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA11572; Tue, 5 Sep 2000 09:30:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from sunny.ady.ro (ppp-ady.warpnet.ro [194.102.224.65]) by hub.freebsd.org (Postfix) with ESMTP id 87CAA37B423; Tue, 5 Sep 2000 09:28:27 -0700 (PDT) Received: (from ady@localhost) by sunny.ady.ro (8.9.3/8.9.3) id TAA00770; Tue, 5 Sep 2000 19:27:42 +0300 (EEST) (envelope-from ady) Message-Id: <200009051627.TAA00770@sunny.ady.ro> Date: Tue, 5 Sep 2000 19:27:42 +0300 (EEST) From: Adrian Penisoara Reply-To: Adrian Penisoara To: FreeBSD-gnats-submit@freebsd.org Cc: ache@freebsd.org X-Send-Pr-Version: 3.2 Subject: conf/21065: 4.1-STABLE cons25w termcap entry screwed Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21065 >Category: conf >Synopsis: 4.1-STABLE cons25w termcap entry screwed >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 09:30:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Adrian Penisoara >Release: FreeBSD 4.1-RELEASE i386 >Organization: Home >Environment: FreeBSD fw-gw.usv.ro 4.1-STABLE FreeBSD 4.1-STABLE #0: Mon Sep 4 08:56:08 EEST 2000 Might affect 5.0-CURRENT too. >Description: Ever since upgrading from 4.1-RELEASE to 4.1-STABLE whenever viewing manual pages or browsing with less/more the raw terminal was screwed up in the reverse video mode. From what I can see this is caused by a cons25w termcap entry change made by Ache back in July (src/share/termcap/termcap.src rev 1.89.2.7 Jul 27 20:41:26). The -current branch might also be affected but I can't check this. >How-To-Repeat: Do this under a plain syscons console: $ man man $ less /etc/defaults/rc.conf $ more /COPYRIGHT Your console should look pretty weird now :-) ... >Fix: The fix (that I tested to work) is to back out the cons25w changes. You'll find below a (suggested) uuencoded patch. Ady (@freebsd.ady.ro) begin 644 termcap.diff M+2TM('1E1SIU=#II=",X.FMM.@HK"3IM M8CU<15LU;3IM9#U<15LQ;3IM:#U<15LS,#LQ;3IM#(U.EP* M(`DZ86,];%PS,S)M7#,P,&M<,C%PR-C-N7#,P-6!>1&%<,C8P9EPS-S!G7#,V,7Y<,SEPS-C(Z7`H@"3IT8SUC;VYS,C5W.@I9 ` end >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 9:39: 1 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 253B037B423; Tue, 5 Sep 2000 09:39:00 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA12817; Tue, 5 Sep 2000 09:39:00 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 09:39:00 -0700 (PDT) From: Message-Id: <200009051639.JAA12817@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, ache@FreeBSD.org Subject: Re: conf/21065: 4.1-STABLE cons25w termcap entry screwed Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: 4.1-STABLE cons25w termcap entry screwed Responsible-Changed-From-To: freebsd-bugs->ache Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 09:38:45 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21065 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 9:39:32 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2C74E37B422; Tue, 5 Sep 2000 09:39:31 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA12916; Tue, 5 Sep 2000 09:39:31 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 09:39:31 -0700 (PDT) From: Message-Id: <200009051639.JAA12916@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, cracauer@FreeBSD.org Subject: Re: bin/21064: /bin/sh core dumps on some 8 bit chars in words or here-docs Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: /bin/sh core dumps on some 8 bit chars in words or here-docs Responsible-Changed-From-To: freebsd-bugs->cracauer Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 09:39:07 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21064 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 9:41:12 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6F84D37B424; Tue, 5 Sep 2000 09:41:10 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA13235; Tue, 5 Sep 2000 09:41:10 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Tue, 5 Sep 2000 09:41:10 -0700 (PDT) From: Message-Id: <200009051641.JAA13235@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, ume@FreeBSD.org Subject: Re: bin/21062: /etc/pccard_ether calling IPv6 programs too early Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: /etc/pccard_ether calling IPv6 programs too early Responsible-Changed-From-To: freebsd-bugs->ume Responsible-Changed-By: sheldonh Responsible-Changed-When: Tue Sep 5 09:40:59 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21062 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 10:12:41 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by hub.freebsd.org (Postfix) with ESMTP id 536AA37B42C for ; Tue, 5 Sep 2000 10:12:36 -0700 (PDT) Received: from nn.kiev.ua (nn.kiev.ua [193.193.193.203]) by segfault.kiev.ua (8) with ESMTP id UEV47650 for ; Tue, 5 Sep 2000 20:12:30 +0300 (EEST) (envelope-from netch@nn.kiev.ua) Received: (from netch@localhost) by nn.kiev.ua (8.11.0/8.11.0) id e85H9C804397 for freebsd-bugs@freebsd.org; Tue, 5 Sep 2000 20:09:12 +0300 (EEST) (envelope-from netch) Date: Tue, 5 Sep 2000 20:09:12 +0300 From: Valentin Nechayev To: freebsd-bugs@freebsd.org Subject: src/sys/isa/sio.c Message-ID: <20000905200912.A4144@nn.kiev.ua> Reply-To: netch@segfault.kiev.ua Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i X-42: On Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems to me that in some cases, sioopen() does not restore spl. Also, comhardclose() and testing com->wopeners may require spltty (but I'm not sure). The patch in question follows. Original version is `FreeBSD: src/sys/isa/sio.c,v 1.304 2000/08/15 21:03:28 peter Exp' --- sio.c.orig Wed Aug 16 23:08:21 2000 +++ sio.c Tue Sep 5 19:37:21 2000 @@ -1380,8 +1380,10 @@ open_top: while (com->state & CS_DTR_OFF) { error = tsleep(&com->dtr_wait, TTIPRI | PCATCH, "siodtr", 0); - if (com_addr(unit) == NULL) + if (com_addr(unit) == NULL) { + splx(s); return (ENXIO); + } if (error != 0 || com->gone) goto out; } @@ -1403,8 +1405,10 @@ } error = tsleep(&com->active_out, TTIPRI | PCATCH, "siobi", 0); - if (com_addr(unit) == NULL) - return (ENXIO); + if (com_addr(unit) == NULL) { + error = ENXIO; + goto out; + } if (error != 0 || com->gone) goto out; goto open_top; @@ -1511,8 +1515,10 @@ && !(tp->t_cflag & CLOCAL) && !(flag & O_NONBLOCK)) { ++com->wopeners; error = tsleep(TSA_CARR_ON(tp), TTIPRI | PCATCH, "siodcd", 0); - if (com_addr(unit) == NULL) - return (ENXIO); + if (com_addr(unit) == NULL) { + error = ENXIO; + goto out; + } --com->wopeners; if (error != 0 || com->gone) goto out; @@ -1524,9 +1530,9 @@ com->active_out = TRUE; siosettimeout(); out: - splx(s); if (!(tp->t_state & TS_ISOPEN) && com->wopeners == 0) comhardclose(com); + splx(s); return (error); } /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 10:50:10 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E1C1237B440 for ; Tue, 5 Sep 2000 10:50:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id KAA24733; Tue, 5 Sep 2000 10:50:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from gate.cpmet.ufpel.tche.br (gate.cpmet.ufpel.tche.br [200.248.148.33]) by hub.freebsd.org (Postfix) with ESMTP id CD60837B424 for ; Tue, 5 Sep 2000 10:44:54 -0700 (PDT) Received: (from casantos@localhost) by gate.cpmet.ufpel.tche.br (8.9.3/8.9.3) id RAA19231; Tue, 5 Sep 2000 17:48:16 GMT (envelope-from casantos) Message-Id: <200009051748.RAA19231@gate.cpmet.ufpel.tche.br> Date: Tue, 5 Sep 2000 17:48:16 GMT From: Carlos A M dos Santos Reply-To: Carlos A M dos Santos To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: conf/21066: Proposed change in rc scripts Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21066 >Category: conf >Synopsis: Proposed change in rc scripts >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 10:50:03 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Carlos A. M. dos Santos >Release: FreeBSD 4.1-RELEASE i386 >Organization: Universidade Federal de Pelotas, CPMet >Environment: FreeBSD 4.1-RELEASE i386 >Description: I applied the patch below to my rc scripts to configure the parallel printer port operation mode before running lpd. I hope it will be useful to other FreeBSD users too. >How-To-Repeat: Just apply the patch below. >Fix: begin 644 rc.patch M+2TM("]E=&,OVQP=&-O;G1R;VQ?96YA M8FQE?2!I;@HK6UEY75M%95U;4W-=*0HK"65C:&\@+6X@)R!PVQP=&-O;G1R;VQ?<')O9W)A;3HM+W5SRelease-Note: >Audit-Trail: >Unformatted: Carlos A. M. dos Santos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 11:10: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5A11A37B424 for ; Tue, 5 Sep 2000 11:10:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA29493; Tue, 5 Sep 2000 11:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 5 Sep 2000 11:10:02 -0700 (PDT) Message-Id: <200009051810.LAA29493@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Gerhard Sittig Subject: Re: bin/21017: mtree's "no such file" message at job's end Reply-To: Gerhard Sittig Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21017; it has been noted by GNATS. From: Gerhard Sittig To: Sheldon Hearn Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/21017: mtree's "no such file" message at job's end Date: Tue, 5 Sep 2000 18:28:33 +0200 On Tue, Sep 05, 2000 at 12:18 +0200, Sheldon Hearn wrote: > > On Sun, 03 Sep 2000 21:11:43 +0200, Gerhard Sittig wrote: > > > >Number: 21017 > > >Category: bin > > >Synopsis: mtree "no such file" message at job's end > > Let us know if you can come up with a simpler How-To-Repeat > that generates the error predictably. I tried truss(1)ing the mtree process. But that's somewhat pointless with 550MB of /usr files and only 200MB of free disk space (truss will produce a complete line of text for every 1K of data read, and mtree seems to compute every checksum separately). That's when script(1) or "truss mtree 2> logfile" won't work. I guess I have to dig into setting up multilog from the daemontools package for this particular purpose. I hope to have the stderr tail of truss available, then. Maybe I can tell you soon which syscall results in the ENOENT(?) error. Am I really alone in seeing this erroneous message or am I one of very few people using mtree for more than a "make hierarchy"? I wouldn't think so. At least I hoped to have some users jumping in saying "me too, preferably under _these_ conditions" ... 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-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 14:20: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 774FB37B43F for ; Tue, 5 Sep 2000 14:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA58816; Tue, 5 Sep 2000 14:20:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from unity.copyleft.no (unity.copyleft.no [212.71.72.23]) by hub.freebsd.org (Postfix) with ESMTP id 747CB37B422 for ; Tue, 5 Sep 2000 14:14:01 -0700 (PDT) Received: from martin by unity.copyleft.no with local (Exim 3.03 #1) id 13WQ2Z-0001gd-00 for FreeBSD-gnats-submit@freebsd.org; Tue, 05 Sep 2000 23:13:59 +0200 Received: (from martin@localhost) by mudskipper.copyleft.no (8.9.3/8.9.3) id XAA83857; Tue, 5 Sep 2000 23:07:44 +0200 (CEST) (envelope-from martin) Message-Id: <200009052107.XAA83857@mudskipper.copyleft.no> Date: Tue, 5 Sep 2000 23:07:44 +0200 (CEST) From: martin@copyleft.no Reply-To: martin@copyleft.no To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21068: Add ftp.no.freebsd.org to list of sysinstall FTP-servers Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21068 >Category: bin >Synopsis: Add ftp.no.freebsd.org to list of sysinstall(8) FTP servers >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 14:20:03 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Martin Eggen >Release: FreeBSD 4.1-STABLE i386 >Organization: - >Environment: - >Description: sysinstall(8) currently doesn't have any Norwegian FTP servers listed. >How-To-Repeat: - >Fix: *** menus.c.orig Fri Aug 4 03:04:04 2000 --- menus.c Tue Sep 5 22:10:25 2000 *************** *** 657,662 **** --- 657,664 ---- VAR_FTP_PATH _AP("=ftp://ftp5.kr.freebsd.org") }, { "New Zealand", "ftp.nz.freebsd.org", NULL, dmenuSetVariable, NULL, VAR_FTP_PATH _AP("=ftp://ftp.nz.freebsd.org") }, + { "Norway", "ftp.no.freebsd.org", NULL, dmenuSetVariable, NULL, + VAR_FTP_PATH _AP("=ftp://ftp.no.freebsd.org") }, { "Poland", "ftp.pl.freebsd.org", NULL, dmenuSetVariable, NULL, VAR_FTP_PATH _AP("=ftp://ftp.pl.freebsd.org") }, { " Portugal", "ftp.pt.freebsd.org", NULL, dmenuSetVariable, NULL, >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 16:16:13 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from uhura.concentric.net (uhura.concentric.net [206.173.118.93]) by hub.freebsd.org (Postfix) with ESMTP id B019837B422 for ; Tue, 5 Sep 2000 16:16:00 -0700 (PDT) Received: from cliff.concentric.net (cliff.concentric.net [206.173.118.90]) by uhura.concentric.net (8.9.1a/(98/12/15 5.12)) id TAA22014; Tue, 5 Sep 2000 19:15:59 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from UrsaMajor.Ursa.com (ts004d02.atl-ga.concentric.net [64.1.54.158]) by cliff.concentric.net (8.9.1a) id TAA03431; Tue, 5 Sep 2000 19:15:53 -0400 (EDT) Message-ID: <39B57F2F.167EB0E7@cris.com> Date: Tue, 05 Sep 2000 19:18:07 -0400 From: amg X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: Bugs@FreeBSD.org Subject: kernel lpt? support Content-Type: multipart/mixed; boundary="------------794BDF32446B9B3D2781E494" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------794BDF32446B9B3D2781E494 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gentlemen: Version: 4.1 CDROM Hardwar: IBM PPro 200MHz 64MB Ram Symptomes: I am unable to get printer support (lpt?) in any kernel that I build. FYI, there was no printer support in the GENERIC kernel. The criterion for "no support", that I am using, is that there is not mention of any lpt? in the output of dmesg. My actions: I have followed the procedure, in the handbook, for building printer support into a custom kernel. Additionally: I know that its not the hardware, as I just recently converted this node from 2.2.8, where printing worked fine, to 4.1. Attached: KERNEL_MAX1 - the kernel config file for the node in question. !! bugs.html - email between myself and marko@FreeBSD.org, where he points out the code snippet that generates the error msg - pfc.c, line 157. dmesg.out - output of dmesg Conclusion: I believe that the problem is not of my doing. Any help you could lend in this matter will be appreciated. Addendium: I just spoke with another programmer who has downloaded 4.1-Install.iso and his GENERIC kernel does have lpt support. Have some bad disks escaped? If so, how do I go about getting a good disk? august ursa@cris.com --------------794BDF32446B9B3D2781E494 Content-Type: text/plain; charset=us-ascii; name="KERNEL_MAX1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="KERNEL_MAX1" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.8 2000/07/20 02:51:02 msmith Exp $ machine i386 ##cpu I386_CPU ##cpu I486_CPU ##cpu I586_CPU cpu I686_CPU ident KERNEL_MAX1 maxusers 8 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols ##options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem ##options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options EXT2FS #linux Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_LINUX #Run linux binaries ##options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options SCSI_DELAY=8000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores ##options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV #Install a CDEV entry in /dev options VESA #Suport for VESA video modes options SC_HISTORY_SIZE=200 #Number of history buffer lines # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaking, (defaults shown): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs device isa device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices ##device ata0 at isa? port IO_WD1 irq 14 ##device ata1 at isa? port IO_WD2 irq 15 device ata ##device atadisk # ATA disk drives ##device atapicd # ATAPI CDROM drives ##device atapifd # ATAPI floppy drives ##device atapist # ATAPI tape drives ##options ATA_STATIC_ID #Static device numbering #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers ##device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices ##device amd # AMD 53C974 (Teckram DC-390(T)) ##device dpt # DPT Smartcache - See LINT for options! ##device isp # Qlogic family ##device ncr # NCR/Symbios Logic ##device sym # NCR/Symbios Logic (newer chipsets) ##options SYM_SETUP_LP_PROBE_MAP=0x40 # Allow ncr to attach legacy NCR devices when # both sym and ncr are configured ##device adv0 at isa? ##device adw ##device bt0 at isa? ##device aha0 at isa? ##device aic0 at isa? # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # RAID controllers ##device ida # Compaq Smart RAID ##device amr # AMI MegaRAID ##device mlx # Mylex DAC960 family ##device twe # 3ware Escalade # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) ##device apm0 at nexus? disable flags 0x20 # Advanced Power Mgmt # PCCARD (PCMCIA) support ##device card ##device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 ##device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 ##device sio2 at isa? disable port IO_COM3 irq 5 ##device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer ##device lpt0 at isa? port? tty irq 7 vector lptintr device ppi # Parallel port interface device ##device plip # TCP/IP over parallel #device vpo # Requires scbus and da # PCI Ethernet NICs. ##device de # DEC/Intel DC21x4x (``Tulip'') ##device fxp # Intel EtherExpress PRO/100B (82557, 82558) ##device tx # SMC 9432TX (83c170 ``EPIC'') ##device vx # 3Com 3c590, 3c595 (``Vortex'') ##device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. ##device miibus # MII bus support ##device dc # DEC/Intel 21143 and various workalikes ##device rl # RealTek 8129/8139 ##device sf # Adaptec AIC-6915 (``Starfire'') ##device sis # Silicon Integrated Systems SiS 900/SiS 7016 ##device ste # Sundance ST201 (D-Link DFE-550TX) ##device tl # Texas Instruments ThunderLAN ##device vr # VIA Rhine, Rhine II ##device wb # Winbond W89C840F ##device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. device ed0 at isa? port 0x300 irq 5 iomem 0xd8000 ##device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 ##device ex ##device ep # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attatement needed # and resources will always be dynamically assigned by the pccard code. ##device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those paremeters here. ##device an # Xircom Ethernet ##device xe # The probe order of these is presently determined by i386/isa/isa_compat.c. ##device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 ##device fe0 at isa? port 0x300 ##device le0 at isa? port 0x300 irq 5 iomem 0xd0000 ##device lnc0 at isa? port 0x280 irq 10 drq 0 ##device cs0 at isa? port 0x300 ##device sn0 at isa? port 0x300 irq 10 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support ##pseudo-device sl 1 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device gzip # Exec gzipped a.out's pseudo-device gif 4 # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device umass # Disks/Mass storage - Requires scbus and da device ukbd # Keyboard device ulpt # Printer device ums # Mouse # USB Ethernet, requires mii ##device aue # ADMtek USB ethernet ##device cue # CATC USB ethernet ##device kue # Kawasaki LSI USB ethernet --------------794BDF32446B9B3D2781E494 Content-Type: text/html; charset=iso-8859-1; name="bugs.html" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="bugs.html" > > On Mon, Sep 04, 2000 at 04:29:03PM -0400, amg wrote: > > > > Mark: > > > > Thanks for your prompt reply. > > I changed the config file accordingly, > > however, there still is not kernel support > > for the lpt? device. Any other ideas?? > > > > Not really, sorry. The error you see at boot: > > ppc0: cannot reserve I/O port range > > comes from /usr/src/sys/i386/isa/pcf.c:157 > > /* IO port is mandatory */ > pcf->res_ioport = bus_alloc_resource(pcfdev, SYS_RES_IOPORT, > &pcf->rid_ioport, 0ul, ~0ul, > IO_PCFSIZE, RF_ACTIVE); > if (pcf->res_ioport == 0) { > device_printf(pcfdev, "cannot reserve I/O port range\n"); > goto error; > } > > but as to the cause, especially since it worked in earlier versions > of FreeBSD, I've no idea. > > BTW, I've put -questions back in the Cc:. It's always a good idea not > to remove the mailing list from the Cc: in case the person who you > replied to is unable to solve your problem, as is the case here. > Others will assume that you have fixed the problem if they don't see > the messages. > > Hopefully someone else will jump in and help out here. > > > > > august > > ursa@cris.com > > > > > > > > > > > > Mark Ovens wrote: > > > > > > On Mon, Sep 04, 2000 at 01:23:45PM -0400, amg wrote: > > > > Questions: > > > > > > > > Version: FreeBSD 4.1 CDROM > > > > > > > > Hardwar: IBM PPro 200MHz 64MB Ram > > > > > > > > Symptomes: Printer not functioning > > > > > > > > Attached: dmesg.out - output of dmesg > > > > KERNEL_MAX1 - kernel config file > > > > dev.files - lpt devices in /dev > > > > > > > > > > > > When I recently switched from 2.2.8 to 4.1, the > > > > printer no longer prints. When issuing the > > > > following commands, the following output appears: > > > > > > > > "cat myfile > /dev/lpt0" yields: > > > > > > > > ksh: cannot create /dev/ltp0: Device not configured > > > > > > > > "lpr myfile" produces no error msg to the screen > > > > but NO printer output either. > > > > > > > > As far as I know, I have followd the directions in the > > > > "handbook". > > > > > > > > I see no mention of lpt? in the output of dmesg, which > > > > leads me to believe that there is not kernel support. > > > > However, I have added printer support to the kernel > > > > config file and rebuilt the kernel, twice, with the > > > > same results, see attached files. > > > > > > > > Additionally, there was not support for lpt? in the > > > > GENERIC kernel. > > > > > > > > I'd appreciate any wisdom on this, as I need to be > > > > able to print any number of files. > > > > > > > > > > > > august > > > > ursa@cris.com > > > > > > [snip] > > > > > > > > > > > # Parallel port > > > > device ppc0 at isa? irq 7 > > > > device ppbus # Parallel port bus (required) > > > > device lpt # Printer > > > > device lpt0 at isa? port? tty irq 7 vector lptintr > > > > ##device plip # TCP/IP over parallel > > > > ##device ppi # Parallel port interface device > > > > #device vpo # Requires scbus and da > > > > > > > > > > Try removing the ``device lpt0'' line and uncommenting the ``device > > > ppi'' line. Here's what I have in my config file and it works fine (HP > > > 610C): > > > > > > # Parallel port > > > device ppc0 at isa? irq 7 > > > device ppbus # Parallel port bus (required) > > > device lpt # Printer > > > device plip # TCP/IP over parallel > > > device ppi # Parallel port interface device > > > > > > -- > > > 4.4 - The number of the Beastie > > > ________________________________________________________________ > > > 51.44°N FreeBSD - The Power To Serve http://www.freebsd.org > > > 2.057°W My Webpage http://ukug.uk.freebsd.org/~mark > > > mailto:marko@freebsd.org http://www.radan.com --------------794BDF32446B9B3D2781E494 Content-Type: text/plain; charset=us-ascii; name="dmesg.out" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.out" Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.1-RELEASE #4: Mon Sep 4 16:03:11 EDT 2000 amg@UrsaMax.Ursa.com:/usr/src/sys/compile/KERNEL_MAX1 Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 199310511 Hz CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbff real memory = 67108864 (65536K bytes) config> di pcic0 No such device: pcic0 Invalid command or syntax. Type `?' for help. config> di sn0 No such device: sn0 Invalid command or syntax. Type `?' for help. config> di lnc0 No such device: lnc0 Invalid command or syntax. Type `?' for help. config> di le0 No such device: le0 Invalid command or syntax. Type `?' for help. config> di ie0 No such device: ie0 Invalid command or syntax. Type `?' for help. config> di fe0 No such device: fe0 Invalid command or syntax. Type `?' for help. config> di cs0 No such device: cs0 Invalid command or syntax. Type `?' for help. config> di bt0 No such device: bt0 Invalid command or syntax. Type `?' for help. config> di ata1 No such device: ata1 Invalid command or syntax. Type `?' for help. config> di ata0 No such device: ata0 Invalid command or syntax. Type `?' for help. config> di aic0 No such device: aic0 Invalid command or syntax. Type `?' for help. config> di aha0 No such device: aha0 Invalid command or syntax. Type `?' for help. config> di adv0 No such device: adv0 Invalid command or syntax. Type `?' for help. config> q avail memory = 61943808 (60492K bytes) Preloaded elf kernel "kernel" at 0xc0354000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc035409c. VESA: v1.2, 512k memory, flags:0x0, mode table:0xc02f3d74 (1000014) VESA: Cirrus Logic GD-54xx VGA Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 Correcting Natoma config for non-SMP Correcting Natoma config for non-SMP isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0xfff0-0xffff at device 1.1 on pci0 uhci0: port 0x5400-0x541f irq 15 at device 1.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 uhub0: port 1 power on failed, IOERROR uhub0: port 2 power on failed, IOERROR pcib1: at device 2.0 on pci0 pci1: on pcib1 ahc0: port 0x5000-0x50ff mem 0x90000000-0x90000fff irq 15 at device 15.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pci0: at 16.0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: failed to get data. psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: cannot reserve I/O port range ed0 at port 0x300-0x31f iomem 0xd8000 irq 5 on isa0 ed0: address 00:c0:f0:10:de:08, type NE2000 (16 bit) Waiting 8 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4303MB (8813870 512 byte sectors: 64H 32S/T 4303C) --------------794BDF32446B9B3D2781E494-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 16:40:41 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from uhura.concentric.net (uhura.concentric.net [206.173.118.93]) by hub.freebsd.org (Postfix) with ESMTP id 167D637B422 for ; Tue, 5 Sep 2000 16:40:39 -0700 (PDT) Received: from cliff.concentric.net (cliff.concentric.net [206.173.118.90]) by uhura.concentric.net (8.9.1a/(98/12/15 5.12)) id TAA28586; Tue, 5 Sep 2000 19:40:38 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from UrsaMajor.Ursa.com (ts021d41.atl-ga.concentric.net [209.220.251.53]) by cliff.concentric.net (8.9.1a) id TAA11959; Tue, 5 Sep 2000 19:40:36 -0400 (EDT) Message-ID: <39B584FA.15FB7483@cris.com> Date: Tue, 05 Sep 2000 19:42:50 -0400 From: amg X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: Bugs@FreeBSD.org Subject: kernel funkiness? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gentlemen: Version: 4.1 CDROM Hardwar: IBM PPro 200MHz 64MB Ram Symptomes: Though I am able to mount a CD, when I attempt to dd from the CD, /dev/cd0a, I get the error msg, "invalid device". This is with 4.1. With 2.2.8, on another node, and with this node until I installed 4.1, dd would, indeed, dump from the device to the "of=" file. !! Most noticable, EVERY device in /dev is a character device! Is this correct? Additionally: The reason that I am sure about dd's past behavior is that it is invoked in a script that I use, often, in burning CD's. august ursa@cris.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 17:22:35 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from ns.itga.com.au (ns.itga.com.au [202.53.40.210]) by hub.freebsd.org (Postfix) with ESMTP id 10F9337B423 for ; Tue, 5 Sep 2000 17:22:32 -0700 (PDT) Received: from lightning.itga.com.au (lightning.itga.com.au [192.168.71.20]) by ns.itga.com.au (8.9.3/8.9.3) with ESMTP id LAA15029; Wed, 6 Sep 2000 11:22:24 +1100 (EST) (envelope-from gnb@itga.com.au) Received: from itga.com.au (lightning.itga.com.au [192.168.71.20]) by lightning.itga.com.au (8.9.3/8.9.3) with ESMTP id LAA27380; Wed, 6 Sep 2000 11:22:24 +1100 (EST) Message-Id: <200009060022.LAA27380@lightning.itga.com.au> X-Mailer: exmh version 2.0.1 12/23/97 From: Gregory Bond To: amg Cc: Bugs@FreeBSD.ORG Subject: Re: kernel funkiness? In-reply-to: Your message of Tue, 05 Sep 2000 19:42:50 -0400. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Sep 2000 11:22:23 +1100 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Version: 4.1 CDROM > Symptomes: Though I am able to mount a CD, > when I attempt to dd from the > CD, /dev/cd0a, I get the error > msg, "invalid device". This is > with 4.1. > > !! Most noticable, EVERY device in > /dev is a character device! Is > this correct? These are both symptoms of the one change: 4.x no longer has (user-visible) block devices. Use /dev/rcd0a for the dd instead. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 18:30: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 814EF37B42C for ; Tue, 5 Sep 2000 18:30:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id SAA04575; Tue, 5 Sep 2000 18:30:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id B770E37B422; Tue, 5 Sep 2000 18:26:35 -0700 (PDT) Message-Id: <20000906012635.B770E37B422@hub.freebsd.org> Date: Tue, 5 Sep 2000 18:26:35 -0700 (PDT) From: MillikenDB@schofield.army.mil To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: i386/21071: SCSI Controller Not Detected When Attempting Install FreeBSD OS Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21071 >Category: i386 >Synopsis: SCSI Controller Not Detected When Attempting Install FreeBSD OS >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 18:30:02 PDT 2000 >Closed-Date: >Last-Modified: >Originator: David Milliken >Release: FreeBSD Version 4.0, Walnut Creek with Rockey Ridge Extensions >Organization: 25th Infantry Division, US Army Hawaii >Environment: Attempting to install on Dell PowerEdge 4350/550 Rackmount server. Cannot get started. Never worked with FreeBSD before. Assuming issue is controller - Adaptic AIC-7890 scalable Narrow SCSI with PERC 2 configuration controller. Standard server hardware with Dell Power Edge Server. >Description: Attempting to use full screen setup utility. Upon boot of system to CD-ROM, system displays all drives on system as created with SCSI Management feature. Window selection for configuration is displayed and visual mode is selected. Active devices in visual mode are displayed for SCSI and narrow controllers but there are no settings to change, only flags. No Base I/O or IRQ when selected can be changed. When select to continue with installation, sys install window appears correctly but when any selection to start the rest of the installation is selected, a window appears indicating that no disks have been found. >How-To-Repeat: Problem is consistent on all versions that I have attempted. Only have 4.0 and 5.0 Versions on hand. >Fix: Unknown >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 18:30: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4F7D337B424 for ; Tue, 5 Sep 2000 18:30:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id SAA04566; Tue, 5 Sep 2000 18:30:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id C64A237B423 for ; Tue, 5 Sep 2000 18:25:32 -0700 (PDT) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13WTxw-000G1H-00 for FreeBSD-gnats-submit@freebsd.org; Wed, 06 Sep 2000 01:25:28 +0000 Message-Id: Date: Wed, 06 Sep 2000 01:25:28 +0000 From: Tony Finch Reply-To: Tony Finch To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: misc/21070: default setting of ${SUP} in Makefile.inc1 doesn't work Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21070 >Category: misc >Synopsis: default setting of ${SUP} in Makefile.inc1 doesn't work >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 18:30:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Tony Finch >Release: FreeBSD 4.1-STABLE-20000831 i386 >Organization: dotat >Environment: FreeBSD hand.dotat.at 4.1-STABLE-20000831 FreeBSD 4.1-STABLE-20000831 #1: Fri Sep 1 04:51:19 UTC 2000 root@hand.dotat.at:/FreeBSD/obj/FreeBSD/releng4/sys/DELL-Latitude-CPx i386 >Description: cvsup is usually installed in /usr/local/bin /usr/src/Makefile sets the PATH to /sbin:/bin:/usr/sbin:/usr/bin before running Makefile.inc1 /usr/src/Makefile.inc1 sets SUP to just "cvsup" if it isn't already set The result of all this is not as helpful as it tries to be. >How-To-Repeat: Run `make update` with a make.conf containing a definition of SUPFILE but no definition of SUP. Make will then bomb when it fails to find cvsup. >Fix: Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.141.2.8 diff -u -r1.141.2.8 Makefile.inc1 --- Makefile.inc1 2000/08/23 19:27:30 1.141.2.8 +++ Makefile.inc1 2000/09/06 01:14:25 @@ -111,7 +111,7 @@ CLEANDIR= cleandir .endif -SUP?= cvsup +SUP?= /usr/local/bin/cvsup SUPFLAGS?= -g -L 2 -P - .if defined(SUPHOST) SUPFLAGS+= -h ${SUPHOST} >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 21:18:39 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from mail.ecd.org (smtp.ecd.org [208.137.129.18]) by hub.freebsd.org (Postfix) with ESMTP id C6EC737B424 for ; Tue, 5 Sep 2000 21:17:59 -0700 (PDT) From: Sergey Nickolaevich To: "freebsd-bugs@FreeBSD.ORG" Subject: Çàðàáîòàéòå â èíòåðíåòå !!! ÍÅ ÏÐÎÑÌÎÒÐ ÐÅÊËÀÌÛ !!! Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="====================54535pksmiu====" Message-Id: <20000906041759.C6EC737B424@hub.freebsd.org> Date: Tue, 5 Sep 2000 21:17:59 -0700 (PDT) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --====================54535pksmiu==== Content-Type: text/plain; charset=windows-1251 Æåëàþ Âàì ïðèÿòíîãî è óñïåøíîãî äíÿ! Âû õîòèòå çàðàáàòûâàòü îò $3000 â ìåñÿö? Åñëè äà, òî ïðî÷òèòå ïîæàéëóéñòà ýòîò e-mail(Çàðàáîòîê.txt)! Ýòî íå êàêàÿ-íèáóäü îô¸ðà - ýòî óæå äàâíî èçâåñòíûé è ïîïóëÿðíûé íà Çàïàäå áèçíåñ. Ñîâåòóþ íå ïðîïóñêàòü ýòó âîçìîæíîñòü - âåäü âñÿ èíôîðìàöèÿ áåñïëàòíà è îçíàêîìëåíèå ñ íåé çàéì¸ò ó Âàñ íå áîëåå 5-òè ìèíóò, ÷òî ñîâåðøåííî íå ñðàâíèìî ñ òåìè çàðàáîòêàìè, êîòîðûå ýòîò áèçíåñ ñóëèò. Ïðîùó ïðîùåíèÿ, êîíå÷íî, ÷òî îáåñïîêîèë Âàñ.Ñïàñèáî Âàì çà âðåìÿ, êîòîðîå âû ïîòðàòèëè íà ÷òåíèå ýòîãî e-mail. Æåëàåì Âàì ïðèÿòíî ïðîâåñòè äåíü è ìíîãî óñïåõîâ!!! !!!Åñëè ïðåäëîæåíèå Âàñ íè÷åì íå çàèíòåðåñîâàëî, ïðèíîøó ñâîè èçâèíåíèÿ è íå íàäî ñåðäèòüñÿ ("ñïàì" èìååò ñâîè èçäåðæêè, òàê æå êàê ðàäèî è TV), ýòî îäíîðàçîâàÿ ðàññûëêà. ÍÅ ÏÐÎÏÓÑÒÈÒÅ ÝÒÓ ÂÎÇÌÎÆÍÎÑÒÜ! - ÝÒÎ ÍÈ×ÅÃÎ ÍÅ ÑÒÎÈÒ, ÒÀÊ ÏÎ×ÅÌÓ ÍÅ ÏÎÏÐÎÁÎÂÀÒÜ? Ñ óâàæåíèåì Cåðãåé Íèêîëàåâè÷. --====================54535pksmiu==== Content-Type: application/octet-stream; name="Çàðàáîòîê.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Çàðàáîòîê.htm" PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi DQp4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpv ZmZpY2UiDQp4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTp3b3JkIg0KeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1U eXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTEi Pg0KPG1ldGEgbmFtZT1Qcm9nSWQgY29udGVudD1Xb3JkLkRvY3VtZW50Pg0K PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg OSI+DQo8bWV0YSBuYW1lPU9yaWdpbmF0b3IgY29udGVudD0iTWljcm9zb2Z0 IFdvcmQgOSI+DQo8bGluayByZWw9RmlsZS1MaXN0IGhyZWY9Ii4vx+Dw4OHu 8u7qLmZpbGVzL2ZpbGVsaXN0LnhtbCI+DQo8dGl0bGU+IDwvdGl0bGU+DQo8 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpEb2N1bWVudFByb3BlcnRp ZXM+DQogIDxvOkF1dGhvcj5OaWNrb048L286QXV0aG9yPg0KICA8bzpUZW1w bGF0ZT5Ob3JtYWw8L286VGVtcGxhdGU+DQogIDxvOkxhc3RBdXRob3I+Tmlj a29OPC9vOkxhc3RBdXRob3I+DQogIDxvOlJldmlzaW9uPjU8L286UmV2aXNp b24+DQogIDxvOlRvdGFsVGltZT4yNjwvbzpUb3RhbFRpbWU+DQogIDxvOkNy ZWF0ZWQ+MjAwMC0wOC0xN1QwNjoyNTowMFo8L286Q3JlYXRlZD4NCiAgPG86 TGFzdFNhdmVkPjIwMDAtMDgtMjRUMTE6MjY6MDBaPC9vOkxhc3RTYXZlZD4N CiAgPG86UGFnZXM+NzwvbzpQYWdlcz4NCiAgPG86V29yZHM+NDQxMjwvbzpX b3Jkcz4NCiAgPG86Q2hhcmFjdGVycz4yNTE0OTwvbzpDaGFyYWN0ZXJzPg0K ICA8bzpDb21wYW55PkhPTUU8L286Q29tcGFueT4NCiAgPG86TGluZXM+MjA5 PC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjUwPC9vOlBhcmFncmFwaHM+ DQogIDxvOkNoYXJhY3RlcnNXaXRoU3BhY2VzPjMwODg0PC9vOkNoYXJhY3Rl cnNXaXRoU3BhY2VzPg0KICA8bzpWZXJzaW9uPjkuMjgxMjwvbzpWZXJzaW9u Pg0KIDwvbzpEb2N1bWVudFByb3BlcnRpZXM+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+ DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpVc2VGRUxheW91dC8+DQog IDwvdzpDb21wYXRpYmlsaXR5Pg0KIDwvdzpXb3JkRG9jdW1lbnQ+DQo8L3ht bD48IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3Ro aWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0Ow0KCW1zby1m b250LWFsdDoiXEZGMkRcRkYzMyBcMzBCNFwzMEI3XDMwQzNcMzBBRiI7DQoJ bXNvLWZvbnQtY2hhcnNldDoxMjg7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1p bHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250 LXNpZ25hdHVyZToxIDEzNDY3NjQ4MCAxNiAwIDEzMTA3MiAwO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRpbWVzICBOZXcgUm9tYW4iOw0KCXBh bm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtYWx0OiJU aW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28t Z2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1mb3JtYXQ6 b3RoZXI7DQoJbXNvLWZvbnQtcGl0Y2g6YXV0bzsNCgltc28tZm9udC1zaWdu YXR1cmU6MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQXJpYWwgIEN5ciI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDsNCgltc28tZm9udC1hbHQ6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZv bnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFu Ow0KCW1zby1mb250LWZvcm1hdDpvdGhlcjsNCgltc28tZm9udC1waXRjaDph dXRvOw0KCW1zby1mb250LXNpZ25hdHVyZTowIDAgMCAwIDAgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJbXNvLWZv bnQtY2hhcnNldDoxMjg7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9k ZXJuOw0KCW1zby1mb250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25h dHVyZToxIDEzNDY3NjQ4MCAxNiAwIDEzMTA3MiAwO30NCiAvKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9u OndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmgxDQoJe21zby1zdHlsZS1uZXh0 Os7h+/ft++k7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCXBhZ2UtYnJl YWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLW91dGxpbmUtbGV2ZWw6MTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Ow0KCW1zby1mb250LWtlcm5pbmc6MHB0Ow0KCW1zby1hbnNpLWxhbmd1YWdl OkVOLVVTOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6 c2luZ2xlO30NCnANCgl7bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3Jw aGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0 IDg0MS45cHQ7DQoJbWFyZ2luOjIuMGNtIDQyLjVwdCAyLjBjbSAzLjBjbTsN Cgltc28taGVhZGVyLW1hcmdpbjozNS40cHQ7DQoJbXNvLWZvb3Rlci1tYXJn aW46MzUuNHB0Ow0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuU2VjdGlv bjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTc2MzUzOTI7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjU1 NDk0MjM2IDQzNjY1ODA4MCAtMTM3MTc1MjE2NiAtMTc3MjYwNzE2MCAzNzM0 NDM0MTIgNjk5ODM2MDk4IDM0MTQ1ODg0NCAtODk4OTYxNTY0IC0xNzc1MDc2 OTk4IC0xNDY3MDI1ODAwO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1 NjE5MDcxNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MjAxNzM0ODk3MCA3ODUxNzYyODggOTk5MzM0MjAgLTYx OTY4MDMwNCAxNjgxMTY2NzY0IDUxNTY2NjUyMiAxNjAxOTk0NjE0IDk3OTkw MjYzOCAxMDE1MDU1NzQwIDE4MzAzNDAwOTg7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+DQo8 L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNyIvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPVJV IGxpbms9Ymx1ZSB2bGluaz1ibHVlIHN0eWxlPSd0YWItaW50ZXJ2YWw6MzUu NHB0Jz4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUaW1lcyAgTmV3IFJvbWFuIic+Jm5ic3A7DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUaW1lcyAgTmV3IFJvbWFuIic+xuXr4P4gwuDsIO/w 6P/y7e7j7g0K6CDz8e/l+O3u4+4g5O3/ITxicj4NCjxicj4NCtDg5CDxIMLg 7Ogg7+7k5evo8vzx/yDv8OXq8ODx7e7pIOLu5+zu5u3u8fL8/iDh6Oft5fHg LCDt7iDv8OXm5OUsIOHu6/z47uUg8e/g8ejh7g0K5+Ag4vDl7P8sIOru8u7w 7uUgwvsg7+7y8ODy6PLlIO3gIPfy5e3o5SD98u7j7iDv6PH87OAuPGJyPg0K 3yD17vfzIO/u5OXr6PL88f8g8SDC4OzoIO/w5eLu8fXu5O3u6SDi7ufs7ubt 7vHy/P4g7eD34PL8IPHu4fHy4uXt7fvpIOHo5+3l8SDiIMjt8uXw7eXyDQro IOfg8ODh4PL74uDy/CDh7uv8+OjlIOTl7fzj6C48YnI+DQrP7u/w7uHz6fLl LCDu8iDC4PEg8vDl4fPl8vH/IPLu6/zq7iDC4PjlIOLw5ez/IOgg9+Xx8u3u 8fL8LiDQ5efz6/zy4PL7IO/w7vHy7iDPztDAx8jSxcvczdssDQrt8+bt7iDy 7uv86u4g7+7v8O7h7uLg8vwg6CDC0cUuIDxicj4NCtLg6ublIOrg6iD/LCDq 7uPk4CDs7eUg7eXk4OLt7iD98u4g7/Dl5Ovu5ujrIPHu4uXw+OXt7e4g7eXn 7eDq7uz76SD35evu4uXqIOgg/yDl7PMNCufgIP3y7iwg6PHq8OXt7eUsIOHr 4OPu5ODw5e0uIDxicj4NCjxicj4NCs/w5ebk5SD35ewg8OX46PL8IC0g9+jy 4PL8IP3y7iDv6PH87O4g5ODr/PjlIOjr6CDt5fIsIPLu6/zq7iDv8OXk8fLg 4vzy5Swg6uDq6OUNCuLu5+zu5u3u8fLoIO/l8OXkIOLg7Ogg7vLq8Pvi4P7y 8f86PGJyPg0KPGJyPg0KLSDH4PDg4e7y4PL8IOfgIDMg7OXx//bgIDUwMDAw JCDoIOHu6/z45SEgz/DoIP3y7uwg7vIgwuDxIO/u8vDl4fPl8vH/IPLw4PLo 8vwg8u7r/OruDQoyLTMg9+Dx4CDiIOTl7fwsIOL79e7kIOIgyO3y5fDt5fIg 6CDx7uHx8uLl7e376SBlLW1haWwuIDxicj4NCjxicj4NCi0gz+7r8/fo8vwg 5+3g7ej/IO/uIPHg7O7s8yDv5fDx7+Xq8uji7e7s8yDoIOH78fLw7vDg5+Lo 4uD++ejs8/H/IOHo5+3l8fMgWFhJIOLl6uAhPGJyPg0KPGJyPg0KzeUg8+/z 8fLo8uUg/fLuIO/w5eTr7ubl7ejlLCDv8O736PLg6fLlIOXj7iDv7uvt7uUg 7u/o8eDt6OUhPGJyPg0KPGJyPg0KxfHr6CDi+yDz5uUg7+7r8/fg6+gg8uDq 7uUg7/Dl5Ovu5uXt6OUg8ODt/PjlIOvo4e4g4uDxIO3lIOjt8uXw5fHz5fIg 7/Dl5O7x8uDi6//l7OD/DQri7ufs7ubt7vHy/Cwg8e7y8Ojy5SD98u4g7+jx /OzuISA8YnI+DQo8YnI+DQrK4Oru5SDh+yDi+yDw5fjl7ejlIO3lIO/w6O3/ 6+ggLSDu7e4g4fPk5fIg5eTo7fHy4uXt7e4g7/Dg4ujr/O377CDk6/8gwuDx IOIg5ODt7e7lDQri8OXs/yEgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+0SDz4uDm5e3o5ews IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiO21zby1mYXJlYXN0LWxh bmd1YWdlOkpBJz7R5fDj5ek8L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz4uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBhbGln bj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCAg Q3lyIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHAg YWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPs3FDQrTxMDL38nSxSwgztLP xdfA0sDJ0sUg3dLOIM/OxsDL08nR0sAgyCDRz87KzsnNziDP0M7XyNLAydLF ICE8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8cCBhbGlnbj1jZW50 ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Yj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+wtsNCsfA0MDBztLAxdLFIMzNzsPOIMTFzcXD ITxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQoNCjxwIGFsaWduPWNlbnRl ciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz7d0s7SDQrByMfNxdEg0MDBztLAxdIgz9DO0dLO IMLFy8jKzsvFz83OISEhPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0K PHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPt8NCtDAwc7SwN4gz84g3dLO ySDP0M7D0MDMzMUgzsTIzSAtIMTCwCDXwNHAIMIgxMXN3CwgwsrL3tfA3yDO wdDAwc7SytMgx8DKwMfOwiDIDQrEztDOw9MgwiDBwM3KISEhPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+zeD37ejy5SDw4OHu8uDy/CDxIO3g7Ogg6CDz4ujk6PLlLCD38u4g 4fPk5fLlDQrw4OT7IPLu7PMsIPfy7iDy4Oog8eTl6+Dr6CEhITwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJB cmlhbCAgQ3lyIjtjb2xvcjpyZWQnPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXIn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7HwNDAwc7SwMnSxQ0K MTAwLjAwMCwtIFVTRCDHwCDDzsQgzcAg0MXKy8DMxSDCIMjN0sXQzcXSxSDI INDA0dHby8rFIEUtTUFJTCEhITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPtPi4Obg5ez75SDk 8PPn/P8g6CDv7uTw8+PoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsL7IOzu5uXy5SDn4PDg 4e7y4PL8IDUwLjAwMCwtIFVTRCDoIOHu6/z45SDiDQry5ffl7ejoIPHr5eTz /vno9SA5MCDk7eXpIO3gIPDg8fH76+rlIGUtbWFpbC4gysDGxdLR3yDNxcLO x8zOxs3bzD8/IM/w7vfo8uDp8uUNCuTl8uDr6Cwg4iD98u7sIO3l8iDt6Org 6u7pIOrg4uXw5/sg6OvoIO7h7ODt4Cwg7/Du8fLuIOTl6+Dp8uUg8eXh5SDw 5err4OzzIOINCsjt8uXw7eXyLCDw4PHx++vg6fLlIGUtbWFpbCDoIPDg5+zl +eDp8uUg8OXq6+Ds7fvlIO7h+v/i6+Xt6P8sIOggwtsg4vHy4O3l8uUg7eAN Cu/z8vwg6iD06O3g7fHu4u7pIO3l5+Di6PHo7O7x8ugg6CDRws7BzsTFISE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHls ZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwgIEN5ciI7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPiZxdW90O0FTIFNFRU4gT04NCk5B VElPTkFMIFRFTEVWSVNJT04mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7R7+Dx6OHu IOfgIMLg+OUg4vDl7P8g6CDo7fLl8OXxLiDO4SD98u7sDQrv6PH87OUg7eXk 4OLt7iDh++vuIO3g7+jx4O3uIOIg4Ozl8Ojq4O3x6uj1IOPg5+Xy4PUuINLg 6ublLCDi4ujk8yDl4+4NCu/u7/Pr//Dt7vHy6CDiIMjt8uXw7eXy5Swg4+vg 4u3g/yDt7vft4P8g6O307vDs4Pbo7u3t4P8g7/Du4/Dg7OzgIO/u8eLl8ujr 4CDl7PMNCvbl6/P+IO/l8OXk4PfzIO3gIO7h+v/x7eXt6OUg6CDi+//x7eXt 6OUsIOTl6fHy4ujy5ev87e4g6+gg7ejm5SDu7+jx4O3t4P8NCu/w7uPw4Ozs 4CDs7ubl8iDv8Ojt5fHy6CDr/uT/7CDk5e384+guINLg6ublIO/w7uLl5OXt 7iDo8fHr5eTu4uDt6OUg6+Xj4Ov87e7x8ugNCuTg7e3u6SDv8O7j8ODs7Psu IMIg8OXn8+v88uDy5SDq7vLu8O7j7iwg8ODnIOgg7eDi8eXj5OAg7+7k8uLl 8OTo6+7x/Cwg9/LuIO3lDQrt4PDz+OD+8vH/IO3o6uDq6OUg5+Dq7u37IOgg 7+7x8uDt7uLr5e3o/y4g3fLuIO/u7O7j6+4g7+7q4Ofg8vwg6/7k/+wsIPfy 7iD98u4NCu/w7vHy7uksIOHl5+Lw5eTt++kg6CDo7fLl8OXx7fvpIPHv7vHu 4SDn4PDg4e7y6uAg5OXt5eMg7eAg5O7s8y4gwvsg7+7p7OXy5Q0K8fPy/Cwg 6uDqIPLu6/zq7iDv8O736PLg5fLlIP3y7iDw8+ru4u7k8fLi7i48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4 dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQt YWxpZ246Y2VudGVyJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ zeDv5ffg8uDp8uUNCv3y7vIg5O7q8+zl7fIg8eXp9+DxLCDk6/8g7+7x6+Xk 8/755ePuIPfy5e3o/y48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGFs aWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz4oyO307vDs4Pbo/w0K8vDl4fPl8iDi 7ejs4PLl6/zt7uPuIO/w7vfy5e3o/yk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXIn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7R6+Xk8/754P8NCuLu 5+zu5u3u8fL8LCDv8Ojt7vHo8iDk7vXu5CAsIOgg7O7m5fIgwuDxIOfg6O3y 5fDl8e7i4PL8LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgYWxpZ249 Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQnPsXx8vwg4u7n7O7m7e7x8vwNCuXlIO3g9+Dy /CDxIOzo7ejs4Ov87fvs6CDo7eLl8fLo9uj/7OgsIOAg5O717uQg7/Du8fLu IM/O0MDHyNLFy9zN28khISEhITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJp YWwgIEN5ciInPiQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7V7vLo8uUNCufg8ODh7vLg8vwg NTAuMDAwLC0gVVNEIOzl7fz45SD35ewg5+AgOTAg5O3l6SE/IM/u5uDr8+nx 8uAsIO/w7vfo8uDp8uUg5ODt7fP+DQrv8O7j8ODs7PMsIPHt4Pfg6+Ag/yD9 8u7s8yDy7ublIO3lIOLl8OjrLCDu5O3g6u4g/fLuIPLg6iEhITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0 LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PsANCu/u8u7sIO/w7vfo8uDp8uUg/fLuIMXZxSDQwMchIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFs aWduOmNlbnRlcic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseToiQXJpYWwgIEN5ciInPiQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGln bjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7d0s4N CsvFw8DL3M3A3yDCzsfMzsbNztHS3CDHwNDAwc7SwNLcIMTFzdzDyCAhISEg ISEhPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+3fLuIO3lIPLw5eHz5fIsIPfy7uH7IOL7IOLx 8vDl9+Dr6PH8IPEg6/7k/OzoDQoo6uDqIOLuIOzt7uPo9SDk8PPj6PUg7+7k 7uHt+/Ug7/Dl5Ovu5uXt6P/1KSEhISDM7ubl8uUg8ODh7vLg8vwg8eLu6Owg 8uXs7+7sLg0K0eDs7uUg6/P3+OXlIP3y7iDy7iwg9/LuIO3l8iDt5e7h9e7k 6Ozu8fLoIO/u6ujk4PL8IPHi7ukg5O7sLiDF8evoIOL7IOLl8Ojy5SwNCvfy 7iDq7uPk4C3t6OHz5PwsIOIg7uTo7SDv8OXq8ODx7fvpIOTl7fwsIPMgwuDx IO/u/+Lo8vzx/yDi7ufs7ubt7vHy/CDk7uvj7g0K7vLk+/Xg8vwsIPLg6iD9 8m8sIOjs5e3t7iwg6CDl8fL8IPLg6uD/IMLOx8zOxs3O0dLcISEhISE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz7P8O7x8u4sIPHr5eTz6fLlIOTg7e3u6SDo7fHy8PPq9ujo LCDoIMLg+CDx7u0NCujx7+7r7ejy8f8uIN3y7vIg4ejn7eXxIC0gTXVsdGkt bGV2ZWwtRS1NQUlMIPLu8OPu4uv/IO/uIOfg6uDn4OwsIO/w7uPw4Ozs4A0K 5OXp8fLi8+XyIO/w5eLu8fXu5O3uIO3gIDEwMCUg6CDq7uPk4CDoIOPk5SDz 4+7k7e4uIEUtbWFpbCD/4uv/5fLx/yDy7vDj7uL77A0K6O3x8vDz7OXt8u7s IOHz5PP55ePuISEhIMjx7+7r/Ofz6fLlIP3y7vIg7eXq7uzs5fD35fHq6Okg 7OXy7uQg8OXq6+Ds+y4NCtHk5evg6fLlIP3y7iDx5en34PEhISEg1+XsIOTu 6/z45SDh8+Tl8uUg5uTg8vwsIPLl7CDh7uv8+OUg6/7k5ekg4fPk5fIg5OXr 4PL8DQr98u7yIOHo5+3l8fE8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4uPC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IMLu5/zs6PLlIPHl4eUg 9+Dx8vwg3dLOySDAytbIyCEhDQpNVUxUSS1MRVZFTC1NQVJLRVRJTkcgKE1M TSkg7eDq7u3l9i3y7iDk7vHy6OMg8+Lg5uXt6P8uIM7tIO/w5e/u5ODl8vH/ IOINCsPg8OLg8OTx6u7pIPLu8OPu4u7pIPjq7uvlLiDR8v3t9O7w5PHq6Okg 6PHx6+Xk7uLg8uXr/PHq6Okg6O3x8ujy8/Ig6CDm8/Dt4OsNCldhbGwgU3Ry ZWV0IOfg/+Lo6+gsIPfy7iA1MC02NSUg4vHl9SDy7uLg8O7iIOgg8/Hr8+Mg 5O4g6u7t9uAg8vvx//fl6+Xy6P8g4fPk8/INCu/w7uTg4uDy/PH/IO/u8fDl 5PHy4u7sIG11bHRpLWxldmVsIOzl8u7k7uIuIN3y7iDs7e7j7iDs6Ovr6ODw 5O3g/yDk7uvr4PDu4uD/DQro7eTz8fLw6P8sIOgg8u7r/OruIOjnIDUwMCww MDAg7Ojr6+ju7eXw7uIg4iDR2MAsIPbl6/v1IDIwJSAoMTAwLjAwMCD35evu 4uXqKQ0K8eTl6+Dr6CDx4u7lIPHu8fLu/+3o5SDn4CDv7vHr5eTt6OUg7+Dw 8yDr5fIg4evg4+7k4PD/IE1MTS4gwCDl+eUsIPHy4PLo8fLo6uANCu/u6uDn ++Lg5fIsIPfy7iA0NSD35evu4uXqIOrg5uT76SDk5e38IPHy4O3u4v/y8f8g 7Ojr6+ju7eXw4OzoIOHr4OPu5ODw/w0KTXVsdGktTGV2ZWwtTWFya2V0aW5n LiDC7ufs7ubt7iwg9/LuIOL7IPPm5SDx6/v44OvoIOjx8u7w6P4sIOrg6iDE 7u3g6/zkINLw4OzvDQrr5fLu7CDt4OLl8fLo6yD47vMgxOXi6OTgIMvl8vLl 8Ozg7eAuIMTl4ujkIPHv8O7x6Osg5ePuLCD38u7h+yDu7SDk5evg6yDl8evo IOH7DQrv7vLl8P/rIOLx5SDx4u7lIPHu8fLu/+3o5SDoIOL77fPm5OXtIOH7 6yDt4Pfg8vwg4vHlIPEg7eD34OvgLiDE7u3g6/zkIOHl5w0K6u7r5eHg7ej/ IO7y4uXy6OssIPfy7iDt4Pjl6yDh+yD17vDu+PP+IE1MTSD06PDs8yDoIO3g 9+DrIPDg4e7y4PL8LiDP8+Hr6OrgDQrt4Pfg6+Ag8eLo8fLl8vwg4vvw4Obg /yDt5fHu4+vg8ejlLiDE7u3g6/zkIO/u8ezu8vDl6yDt4CDn8Ojy5ev87fvp IOfg6yDoDQrx5fD85eft7iDv8O7o5+3l8TogJnF1b3Q7wevg4+7k4PD/IP3y 7uzzIP8g5+Tl8fwg7eDi5fD18ywg4CDi+yDy4OwsIOLt6OfzPC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwgIEN5ciInPiEmcXVvdDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+0SDx5fLl4vvsIOzg 8Orl8ujt4+7sIOL7IOjs5eXy5SDk4uAg6PHy7vft6OrgDQrv8Ojh++voOiDP 8P/s4P8g7/Do4fvr/CDxIO/w7uTg5ugsIOru8u7w8/4g7/Du4u7k6PLlIML7 IPHg7Ogg6CDv8Ojh++v8IPENCu7h7vDu8uAg6/7k5eksIOru8u7w+/Ug7/Do 4uXk5fLlIOIg4ejn7eXxLiDB5fHq7u3l9+3g/yDv8Ojh++v8IP/i6//l8vH/ IPLg6e3u6Q0K4e7j4PLx8uLgLiDd8u4g5+3g9+jyIO7k6O0g8ODnIOjt4uXx 8ujw7uLg8vwg4vDl7P8g6OvoIOTl7fzj6CDgIO/u8u7sIO/u6/P34PL8DQrk 5e384+gg8e3u4uAg6CDx7e7i4C4gwiDx5fLl4u7sIOzg8Orl8ujt4+Ug/fLu IPLg6ublIO7n7eD34OXyIO/u6/P34PL8IOTl7fzj6A0K5+Ag8ODh7vLzIOTw 8+Po9S48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz7KIPHu5uDr5e3o/iwg7/Du9+jy4OIg/fLu IO/o8fzs7iDi7+Xw4vvlLCD/DQrv8ODq8uj35fHq6CDv8O7v8/Hy6Osg8uDq 8/4g4u7n7O7m7e7x8vwg8eri7uf8IO/g6/z2+ywg6CDk4OblIO3lIPHy4Osg 9+jy4PL8DQrk4Ov8+OUsIO3uIOLx6u7w5SD/IO/l8OX36PLg6yDi8eUg5+Dt 7uLuLiDH4OTz7ODr8f8g6CDv7u3/6yDi8f4g8ejr8yD98u7j7g0K7/Dl5Ovu 5uXt6P8uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+yCDy5e/l8Pwg/yDh7uPg8iDoIPHi7uHu 5OXtLiDfIOzu4/Mg5PP17uLt7iDw4Ofi6OLg8vzx/ywNCu7y5Pv14PL8LCDt 4OTuIOzt7ukg7eXyIOPt5fLgIO3g9+Dr/PHy4uAsIOzu5ekg8eXs/OUg6CDs 7eUg7eUg7OX44OXyDQrz7ejn6PLl6/zt4P8g4eXk7e7x8vwg6CDh7vD84eAg 5+Ag6vPx7uog9evl4eAsIOzl+OD/IPfl6+7i5ffl8eru6SDm6Oft6IUgPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBhbGlnbj1jZW50ZXIgc3R5bGU9 J3RleHQtYWxpZ246Y2VudGVyJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+zeDv8Ojs5fAsIOLu8iD38u4g4+7i7vDo8iDs 6PHy5fAgxObl8Oggz/Du6vLu8CwNCuDs5fDo6uDt8ero6SDs6Ovr6O7t5fAu PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+xOLgIOPu5OAg7eDn4OQg4fvr4CDz7/Dg5+Tt5e3g IOzu/yDk7uvm7e7x8vwNCuIg9Ojw7OUsIOIg6u7y7vDu6SD/IPDg4e7y4Osg 7+7x6+Xk7ej1IO//8u3g5Pbg8vwg6+XyLiDP7vHr5SDt5fHq7uv86uj1DQrt 5fPx7+X47fv1IPHu4eXx5eTu4uDt6Okg/yDw5fjo6yDt4Pfg8vwg8eLu6SDx 7uHx8uLl7e376SDh6Oft5fEuIMIg8uX35e3o6A0K7/Du+Ov79SDr5fIg/yDv 8O745esg7O3u4+4g9Ojt4O3x7uL79SDn4PLw8+Tt5e3o6S4g3yDh++sg5O7r 5uXtIPHi7uXpIPHl7PzlLA0K5PDz5/z/7CDoIOrw5eTo8u7w4Owg4e7r5eUg MzUuMDAwLC0gVVNELiDfIOH76yDi++3z5uTl7SDn4Ovu5ujy/CDx4u7pIOTu 7CwNCvfy7uH7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+IDwvc3Bhbj48c3Bhbg0Kc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPu/w7uru8Ozo8vwg8eLu/iDx5ez8/iDo IPPk5fDm4PL8IPHi7ukg4ejn7eXxLiDCIN3SztINCszOzMXN0iDv8O7o5+74 6+4g7eX38u4g4vvk4P755eXx/yDiIOzu5ekg5ujn7egsIOgg/yDv6PjzIOTr /yDy7uPuLCD38u7h+yDv7uTl6+jy/PH/DQru4SD98u7sIOft4Ozl7eDy5ev8 7e7sIPHu4fvy6Ogg8SDC4OzoLiDCIPHl8OXk6O3lIOTl6uDh8P8gMTk5OCD/ IO/u6/P36OsgZS1tYWlsDQrxIP3y7ukg7/Du4/Dg7Ozu6S4gz+Xw5eQg/fLo 7CD/IPjl8fL8PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4gPC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz7s5fH/9uXiIOjx6uDrDQrw4Oft++Ug 8u7w4+7i++Ug4u7n7O7m7e7x8uguIMLx5SDv8O7j8ODs7PssIOru8u7w++Ug /yDv7uvz9+jrIO3lIOH76+gNCv309OXq8uji7fvs6CAo7+4g6vDg6e3l6SDs 5fDlIO3gIOzu6SDi5+Pr/+QpLiDO7egg4fvr6CDo6+gg8evo+Oru7CDx6+7m 7fvs6CDo6+gNCvLw5eHu4uDr6CDh7uv8+Oj1IOjt4uXx8uj26OksIOAg8Ojx 6u7i4PL8IPHi7ujsIOLq6+Dk7uwsIPfy7uH7IPPn7eDy/CDk5enx8uLz5fIN Cv3y7iDo6+gg7eXyPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+LDwvc3Bhbj48c3Bhbg0K c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiD/IO3lIPXu8uXrLiDK4Oog/yDz 5uUg4+7i7vDo6ywg4iDk5erg4fDlIDE5OTgg/w0K7+7r8/fo6yD98vMg7/Du 4/Dg7OzzLiDfIO3lIPXu8uXrIOXlIO/u6/P34PL8LCDv8O7x8u4sIO/u6/P3 6Osg8uDqIOblIOrg6iDoIML7Lg0K0e/g8ejh7iDB7uPzIOfgIP3y7iEg3yDv 8O736PLg6yDv8O7j8ODs7PMg7eXx6u7r/OruIPDg5ywg7+7y7uzzIPfy7iDt 5SDs7uMg4g0K7eXlIO/u4uXw6PL8LCDoIO/w6O3/6/H/IOfgIPDg4e7y8y4g 3yDs7uMg6O3i5fHy6PDu4uDy/CDy7uv86u4g8fLu6/zq7iDk5e3l4ywNCvHq 7uv86u4g4iDk4O3t++kg7O7s5e3yIOH76+4g4u7n7O7m7e4uINLg6iDm5SDq 4Oog6CDC+yD/IOH76yDx6uXv8uj35e0g6A0K7eXs7e7j7iDh7v/r8f8g7iDr 5ePg6/zt7vHy6CDk4O3t7ukg7/Du4/Dg7Oz7LiDP7vHr5SDo8err/vfl7ej/ IPLu4+4sIPfy7g0K7/Du4/Dg7OzgIOzu5uXyIOH78vwg7eXr5ePg6/zt7uks IP8g8erg5+DrIPHl4eUsIO/u9+Xs8yDh+yDs7eUg/fLuIO3lDQrv7u/w7uHu 4uDy/C4gz+7y7uwg/yDv7vHr4Osg7uru6+4gMTAuMDAwIGUtbWFpbC4g0fLu 6OvuIOzt5SD98u4g7uru6+4gMTUsLSBVU0QNCufgIOzu5SDi8OXs/yBvbi1s aW5lLiDP8OXi7vH17uTt7uUg8eLu6fHy4u4gZS1tYWlsIPHu8fLu6PIg4iDy 7uwsIPfy7iDt5SDt4OTuDQrt6Pfl4+4g7+X34PLg8vwsIOAg7fPm7e4g8u7r /OruIO/u8fvr4PL8LiDS4Oog6uDqIOLx5SDn4Org5/sg7vTu8Ozr//7y8f8g 9+Xw5ecNCmUtbWFpbCwg8u4g7O7l6SDo7eLl8fLo9ujl6SDh++vuIPLu6/zq 7iDs7uUg4vDl7P8sIOru8u7w7uUg/yDv8O7i5esg8w0K6u7s7/z+8uXw4C4g w+7i7vD+IMLg7CDq4Oog/fLuIOH76+4sIO3g5OX+8fwsIPfy7iDC4PEg/fLu IO3lIPDg5+734PDz5fIsIPLg6g0K6uDqIP8g7+7u4eX54Osg8eXh5Swg9/Lu IO3o6u7j7iDt5SDu4ezg7fMsIPfl4+4g4fsg7O3lIP3y7iDt5SDx8u7o6+4u IMzl7fz45Q0K9+XsIPfl8OXnIO3l5OXr/iD/IO3g9+DrIO/u6/P34PL8IOfg 6uDn+yDt4CBSRVBPUlQgIzEuPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwgIEN5ciI7Y29sb3I6cmVk Jz4gPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+xO4g MTMg/+3i4PD/IDE5OTkg/yDv7uvz9+jrIDI2IOfg6uDn7uIg7eAgUkVQT1JU ICMxLg0KwuD45ekg9uXr/P4g/+Lr/+Xy8f8g7+7r8/fo8vwg7Ojt6Ozg6/zt 7iAyMCDn4Org5+7iIO3gIFJFUE9SVCAjMSDCINLF18XNyMggxMLT1Q0KzcXE xcvcLiDF0cvIIMLbIMjVIM3FIM/Oy9PXyNLFLCDPztjLxdLFIMHOy9zYxSDE wM3N29Ugz9DOw9DAzMwsIMTL3yDSzsPOINfSzsHbDQrI1SDPzsvT18jS3CEg zO7pIPjg4yDqIO/u6/P35e3o/iA1MC4wMDAsLSBVU0Qg5+AgOTAg5O3l6SDh ++sg8eTl6+DtLiDE7iAzMA0K/+3i4PD/IDE5OTkg/yDv7uvz9+jrIDE5NiDn 4Org5+7iIO3gIFJFUE9SVCAjMi4gwuD45ekg9uXr/P4g/+Lr/+Xy8f8g7+7r 8/fo8vwNCuzo7ejs4Ov87e4gMTAwIOfg6uDn7uIg7eAgUkVQT1JUICMyIOIg 8uX35e3o6CDk4vP1IO3l5OXr/C4gxfHr6CD98u4g7eUNCu/u6/P36PLx/ywg 8uDqIPDg8fH76+Dp8uUg4e7r/PjlIP3y6PUg7/Du4/Dg7OwuIMrg6iDy7uv8 6u4g5O7x8ujj7ejy5SAxMDANCufg6uDn7uIg7eAgUkVQT1JUICMyIPLuIOLx 5SDu8fLg6/zt7uUg4fPk5fIg4iDv7vD/5OrlIOggwvsg8u737e4g7+7r8/fo 8uUg8eLu6A0KNTAuMDAwLC0gVVNELiDTIOzl7f8g4fvr7iAxOTYg5+Dq4Ofu 4iDt4CBSRVBPUlQgIzIsIPLuIOXx8vwg7eAgOTYg4e7r/PjlIPfl7A0K7O3l IOH76+4g7fPm7e4uIM/u/fLu7PMg/yDx5esg6CDu8uT79eDrLiDE7iAxIOzg 8PLgIDE5OTkg5+Ag8eLu6CAxMC4wMDANCu7y7vHr4O379SBlLW1haWwg/yDv 7uvz9+jrIDU4LjAwMDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+LDwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+LSBVU0Qg6CDq4Obk++kNCuTl 7fwg7/Do9e7k6OvoIO3u4vvlIOTl7fzj6C4g3yDn4O/r4PLo6yDx4u7oIOTu 6+PoIOgg6vPv6Osg8eXh5SDs4Pjo7fMuDQrP7ubg6/Pp8fLgLCDt4Onk6PLl IOLw5ez/IOgg4u3o7ODy5ev87e4g7/Du9+jy4Ony5SD98vMg7/Du4/Dg7Ozz LiDd0s4gzcDC0cXDxMANCsjHzMXNyNIgwsDY0yDGyMfN3CEhISDP7uzt6PLl LCD38u4g/fLuIO3lIOfg8ODh7vLg5fIsIO/u6uAg4vsg/fLuIO3lDQrv7u/w 7uHz5fLlISDd8uAg7/Du4/Dg7OzgIOTl6fHy4vPl8iwg7e4gwvsg5O7r5u37 IPLu9+3uIO/w6OTl8Obo4uDy/PH/DQrw5eru7OXt5OD26OkhISA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz7R7+X26ODr/O3u5SDv8ODi6OvuIC0g7eUg8fLg8ODp8uXx/CDi 7+jx++Lg8vwNCsLg+OUg6Oz/IPLg7Cwg4+TlIP3y7iDt5SDt8+bt7i4g3fLu IO3lIOHz5OXyIOTl6fHy4u7i4PL8LCDgIML7IO3l5O7v7uvz9+jy5Q0K7O3u 4+4g5OXt5eMhISDB7uvl5SDy7uPuLCDv8Ogg6Ofs5e3l7ejoIOTg7e379SDv 8O7k4OL27uIg6O3g9+UsIPfl7CD98u4g8+rg5+Dt7g0K4iDo7fHy8PPq9ujo IO3o5uUsIOTg7e376SDi6OQg7/Dl5O/w6O3o7ODy5ev88fLi4CDx8uDt7uLo 8vH/IO3l6+Xj4Ov87fvsLiDR7e7i4A0K7+7i8u7w//4sIPfy7iDiIPHr8/fg 5SDx7uHr/uTl7ej/IOLx5fUg7ejm5fPq4Ofg7e379SDw5eru7OXt5OD26Oks IPDl9/wg6OTl8iDuDQrr5ePg6/zt7uwg7/Dl5O/w6O3o7ODy5ev88fLi5SEh IMTr/yDy7uPuLCD38u7h+yDi+yDk7vHy6OPr6CDx4u7l6SD25evoDQrt5e7h 9e7k6OzuIO/u6/P36PL8IDIwIOgg4e7r/PjlIOfg6uDn7uIg7eAgUkVQT1JU ICMxIOggMTAwIOgg4e7r/PjlIO3gIFJFUE9SVA0KIzIuIMIg/fLu7CDx6/P3 4OUg5+Dw4OHu8uDl8uUgNTAuMDAwLC0gVVNEICjo6+gg4e7r/PjlKSDn4CA5 MCDk7eXpISDfIC0NCtDFwMvczc7FIMTOysDHwNLFy9zR0sLOINLOw84sINfS ziDd0s4gzcAg0cDMzswgxMXLxSDExcnR0sLTxdIhISEgxfHr6CDi+w0K8OX4 6Ovo8fwsIPfy7iDiIP3y7ukg7/Du4/Dg7OzlIPP34PHy4u7i4PL8IO3lIOHz 5OXy5Swg8uDqIOzt5SDi4PEg6PHq8OXt7eUNCubg6/wuINLg6iDq4Oog/fLu IPDl4Ov87eD/IO/w5eLu8fXu5O3g/yDi7ufs7ubt7vHy/CDxIOzo7ejs4Ov8 7fvsIPDo8eru7CDoDQro7eLl8fLo9uj/7OghIMXx6+gg9e7y6PLlIPP34PHy 4u7i4PL8LCDv8Ojk5fDm6OLg6fLl8fwg5ODt7fv1IPDl6u7s5e3k4Pbo6SDo DQrh8+Tl8uUg7eAg5O7w7uPlIOog9Ojt4O3x7uLu6SDt5efg4ujx6Ozu8fLo LiDF8evoIOfg7ejs4OXy5fH8DQrv8OXk7/Do7ejs4PLl6/zx8uLu7CDo6+gg 9e7y6PLlIO3g9+Dy/CDx4u7pIPHu4fHy4uXt7fvpIOHo5+3l8Swg8uDqIPH3 6PLg6fLlDQr98u4g5+Ag9e7w7vjz/iDi7ufs7ubt7vHy/C4g3yDd0s4g0cTF y8DLICEhITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPtEg8+Lg5uXt6OXsIMTm5fDoIM/w7ury 7vAuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48cz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwgIEN5ciIn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcz48L3A+DQoNCjxwIGFsaWdu PWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsICBDeXIi Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGFsaWduPWNl bnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRl ciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz7d0s4NCs/O0MDHyNLFy9zNziEhITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFs aWduOmNlbnRlcic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPijL yNfNwN8NCsfAzMXSysAgztIgztHNzsLA0sXL3yDd0s7JIM/QzsPQwMzM2yk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHls ZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4qKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz7P5fDl5CDy5ewg6uDqIO/w7vfo8uDl8uUg /fLzIO/w7uPw4Ozs8ywg4vsNCuTu6+bt+yDv7u3/8vwsIPfy7iD98uAg6+Xj 4Ov87eD/IO/w7uPw4Ozs4CDt5SDs7uPr4CDh++vgIOH78vwg8e7n5ODt4CDr /uHo8uXr5ewuDQrP7ufi7uv88uUg7O3lIO3l7O3u4+4g8ODx8erg5+Dy/CDu IPHl4eUuINbl6/v1IDEwIOvl8iDzIOzl7f8g4fvrIPHu4fHy4uXt7fvpDQrw 4Ofi6OLg/vno6fH/IOHo5+3l8S4gwiAxOTc5IOPu5PMg7O7pIOHo5+3l8SDt 4Pfg6yDw8/jo8vzx/y4g3yDk5evg6yDi8eUsIPfy7g0K7O3lIOTuIP3y7uPu IO/w6O3u8ejr7iDz8e/l9Swg7e4g4eXn8/Hv5fjt7i4gzeDq7u3l9iD/IO/u 7f/rLCD38u4g/fLuIO3lIOjnLefgDQrs5e3/LCDgIOjnLefgIP3q7u3u7Ojq 6Cwg6u7y7vDg/yDt4PEg8e7v8O7i7ubk4OvgIPEgMTk0NSDj7uTgLiDE8+zg /iDt5SDt8+bt7g0KwuDsIO7h+v/x7f/y/Cwg6uDqIP3y7iDv7uLr6P/r7iDt 4CDh5efw4OHu8uj28yDiIPHy8ODt5Swg7O3u4+jlIOjnIMLg8SD98u4NCuft 4P7yIO/uIPHu4fHy4uXt7e7s8yDu7/vy8y4gz/Do+OvuIOzt7uPuIO/g5OXt 6Okg6CDh4O3q8O7y7uIuINHw5eTt6Okg6uvg8fENCujx9+Xn4OssIPLlLCDq 7vLu8PvlIOft4OvoIPfy7iDk5evg/vIsIOzz5PDuIOjt4uXx8ujw7uLg6+gg 6CDv8O7k4ujt8+vo8fwg4vv45SwNCuAg8uUg6vLuIO3lIOft4OssIO/g5ODr 6CDi8eUg7ejm5Swg4iDh5eTt7vLzLiDK4Oog4+7i7vDo8iDo5+Ll8fLt4P8g 7+7j7uLu8OrgOjwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4gPC9zcGFuPjxzcGFuDQpz dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+JnF1b3Q7wc7DwNLbxSDBzsPA0sXe 0iwgwCDBxcTN28UgwcXEzcXe0iZxdW90Oy4NCtLw4OTo9uju7e375SDx7+7x 7uH7IOfg8ODh7vLq4CDk5e3l4yDt6Oru4+TgIO3lIO/u5+Lu6//yIMLg7CDi +/Hu6u4g7+7k7f/y/PH/LA0K4CDo7fTr//bo/yDy7uv86u4g/fLu7PMg7+7s 7ubl8i4g0eXp9+DxIOL7IO/u6/P36OvoIO/o8fzs7iwg6u7y7vDu5SDs7ubl 8iDk4PL8DQrC4Owg9Ojt4O3x7uLz/iDt5efg4ujx6Ozu8fL8IO3gIOLx/iDC 4PjzIObo5+38IOggJnF1b3Q7wcXHINDI0crAJnF1b3Q7IOgg8Q0KJnF1b3Q7 zMjNyMzAy9zN28zIINPRyMvI38zIJnF1b3Q7LiDCIO/u8evl5PP++ej1IOzl 8f/24PUgwvsg8ezu5uXy5SDn4PDg4e7y4PL8DQrk5e3l4yDh7uv8+OUsIPfl 7CDs7ubl8uUg8eXh5SDv8OXk8fLg4ujy/C4gzfPm7e4g7+7k9+Xw6u3z8vws IPfy7iD/IPEg/fLo9Q0K5OXt5eMg7eUg8+Lo5vMg7egg9uXt8uAuIMrg6iDo IO3o6vLuIOjnIOv+5OXpLCDq7vLu8PvlIPLl8fLo8O7i4OvoIOTg7e3z/g0K 7/Du4/Dg7OzzLiDfIPPm5SDn4PDg4e7y4Osg4e7r5eUgNC4wMDAuMDAwLC0g VVNEISEhIM/l8OXx8uDrIOjx7+7r/Ofu4uDy/CD98vMNCu/w7uPw4Ozs8yDv 7vHr5SDy7uPuLCDq4Oog7+7x6+DrIDE2LjAwMCDv8O7j8ODs7C4g0eXp9+Dx IPMg7OXt/yDt5fHq7uv86u4g9Ojw7CwNCuru8u7w++Ug6Ofu4fDl8uD+8iDv 7uTu4e375SDv8O7j8ODs7PsuIML77+7r7f/p8uUg7/Du4/Dg7OzzINLO183O IM/ODQrIzdHS0NPK1sjIISEgzeUg6Ofs5e3/6fLlIOXlIO3o6uDq6Owg7uHw 4Ofu7CEhIM7t4CDk5enx8uLz5fIg7ODq8ejs4Ov87e4NCv309OXq8uji7e4g 6Ozl7e3uIOIg/fLu7CDi6OTlLiDN5SDn4OHz5Pzy5SDv7vHr4PL8PC9zcGFu PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwgIEN5ciI7Y29sb3I6cmVkJz4gPC9zcGFuPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+6u7v6P4g/fLu6SDv8O7j8ODs7Psg6uDm5O7s 8ywg6u7j7iDy7uv86u4g4vHv7uzt6PLlIQ0KzuTo7SD35evu4uXqLCDq7vLu 8O7s8yDi+yD98u4g7+746+Xy5SDs7ubl8iDv7vHr4PL8IOggNTAuMDAwIOru 7+jpIC4uLiDgIMLg+OUNCujs/yDh8+Tl8iDt4CDq4Obk7ukg6Ocg7ej1ISEh IM/u7O3o8uUsIPfy7iD35ewg4e7r/PjlIO/w7uPw4OzsIOL7IO/u+Ovl8uUs IPLl7A0K4e7r/PjlIO/u8uXt9ujg6/zt+/Ug5+Dq4Of36Oru4iDv8Oju4fDl 8uXy5SEg0uDqIPfy7iwg5PDz5/z/LCD/IO/w5eTu8fLg4uv//g0KwuDsIOLu 5+zu5u3u8fL8LCDo7fTu8Ozg9uj+LCDs4PLl8Ojg6yDk6/8g8u7j7iD38u7h +yDi+yDv7uvz9+jr6CD06O3g7fHu4vP+DQrt5efg4ujx6Ozu8fL8LiDSxc/F 0Nwg3dLOIMfAwsjRyNIg0s7L3MrOIM7SIMLA0SEgJnF1b3Q7z87E08zAydLF IM7BIN3SzswmcXVvdDsNCu/l8OXkIPLl7CDq4Oo8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIi Jz4gPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+8+Tg 6+jy5SD98u7yIG1haWwsIOrg6iD38/L8IO3lIPHk5evg6yD/LiDO8uLl5Ojy 5SDx5eHlDQrt5ezt7uPuIOLw5ezl7egsIO/w7vfy6PLlIOgg7+4t7eDx8u7/ +eXs8yDv7uTz7ODp8uUg7eDkIP3y6OwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+wu7n/Ozo 8uUg8PP36vMg6CDv7vH36PLg6fLlLCD38u4g7O7m5fIg6OcNCv3y7uPuIO/u 6/P36PL88f8sIOXx6+ggwvsg/fLuIO/u7/Du4fPl8uUuIMLu5/zs6PLlIPHg 7PvpIO/r7vXu6SDi4PDo4O3yLCDt7iDoIOINCv3y7uwg8evz9+DlIPMg4uDx IOHz5OXyIOzt7uPuIOTl7eXjLiDCIPHg7O7sIPXz5Pjl7CDx6/P34OUg7+7r 8/fo8uUg8eLu/g0K6O3i5fHy6Pbo/iDt4Ofg5C4gwvHlIPHu7O3l7ej/LCDq 7vLu8PvlIPMg4uDxIOXx8vwsIOjx9+Xn7fPyLCDq7uPk4CDv7uvz9+jy5Q0K 8eLu6SDv5fDi++kg5+Dq4OcuIN3SziDExcnR0sLTxdIhISEhITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz5Kb2R5IEphY29icywN ClJpY2htb25kLFZBLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgYWxp Z249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsANCtLFz8XQ3Cwgws7SIN3SwCDP0MXC ztHVzsTNwN8gz9DOw9DAzMzALCDKztLO0MDfIMLAzCDHwNDAwc7SwMXSINLb 0d/XyA0KxM7Ly8DQzsIhISEhITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJp YWwgIEN5ciInPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsjN0dLQ 08rWyN8gOiDd8u7yIOzl8u7kIOfg8ODh7vLq4CDk5e3l4yDt4A0K8eDs7uwg 5OXr5SDExcnR0sLTxdIgzcAgMTAwJSwgys7DxMAg08POxM3OLCDDxMUg08PO xM3OLiDfIPPi5fDl7Swg9/LuIML7DQrx7O7m5fLlIOfg8ODh7vLg8vwg4e7r 5eUgNTAuMDAwLC0gVVNEIOIg7+7x6+Xk8/756OUgOTAg5O3l6S4gz+Xw5eQg 8uXsIOrg6g0K8erg5+Dy/CAmcXVvdDvj6/Pv7vHy/C4uLiZxdW90OyDv7ubg 6/Pp8fLgIO/w7vfo8uDp8uUg4u3o7ODy5ev87e4g6CDi7ejq7ejy5SDiDQrx 8/L8IP3y7ukg7/Du4/Dg7Oz7LiDd8u4g7eUg9uXv7e7lIO/o8fzs7iwg4CDu 8uvo9+3g/yDr5ePg6/zt4P8g4u7n7O7m7e7x8vwNCufg8ODh7vLg8vwg5OXt /OPoLiDCIPfl7CDx7Pvx6z8g0uDqIOrg6iDoIOIg6/7h7ukgbXVsdGktbGV2 ZWwg8fXl7OUsIPLu8OPu4uv/DQrx8vDu6PLx/yDt4CDv8Oji6+X35e3o6CDt 7uL79SDv4PDy7eXw7uIg6CDv8O7k4OblIPHi7uj1IPLu4uDw7uIuIMfAysDH 2yDKIMLAzA0Kz9DI1c7E39IgyCDC28/Oy83f3tLR3yDPziBFLU1BSUwsIO/u /fLu7PMg7eUg4u7n7ejq4OXyIOvo9+3u4+4g6u7t8uDq8uAuIMTl6+Dl8vH/ DQri8eUg5O7s4CDo6+gg4iDz9/Dl5uTl7ejoLiDd8u4g8eDs4P8g4e7r/Pjg /yBtdWx0aS1sZXZlbCDi7ufs7ubt7vHy/CDt4A0K8eLl8uUhISEhISDIIN3S ziDNxSDP0MXTwsXLyNfFzcjFISE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCAgQ3lyIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTpBcmlhbCc+0fP55fHy4vPl8iDk4uAg7vHt7uLt+/UNCuzl8u7k4CDk 6/8g8fLw7ujy5ev88fLi4CDi4Pjo9SDt6Obt6PUg8/Du4u3l6TogPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHA+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPszl8u7kICMxLSDPztHby8rAIMzA0dHOws7JIEUt TUFJTCDQxcrLwMzbPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHA+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPs/w5eTv7uvu5ujsLCDt 4O/w6Ozl8Cwg9/LuIML7IPXu8ujy5SDt4Pfg8vwg8Q0K7ODr7uPuIOru6+j3 5fHy4uAsIPLu6/zq7iDk6/8g8u7j7iwg9/Lu4fsg7+7x7O7y8OXy/CDq4Oog /fLuIOTl6fHy4vPl8i4NCsTu7/Px8ujsLCD38u4gwvsg6CDi8eUg4u7i6+X3 5e3t++UgwuDs6CDq7uzv4O387u37IO/u+Ovl8uUg8u7r/OruIDIuMDAwIGUt bWFpbA0KKOrg5uT76SDo5yDC4PEpLiDS4Orm5SDv8OXk7+7r7ubo7Cwg9/Lu IO/u6/P36PLlIOLx5ePuIDAsNSUg7vLi5fLu4i4gxfHr6A0K6PHv7uv85/Pl 8uUg9e7w7vjo6SDv5fDl9+Xt/CDg5PDl8e7iIPLuIDElLiDP7vLu7CDs7e7j 7iDr/uTl6SDw4Ofu+Ov+8iDz5uUNCvHu8u3oIPL78f/3IP3y6PUg7/Du4/Dg 7OwsIOHr4OPu5ODw/yDi4Pjo7CAyLjAwMC4gz/Du5O7r5ujsIO3g+CDv8Ojs 5fAsIOL7DQrv7vHr4OvoIDIuMDAwIO/w7uPw4OzsLiDI5yAwLDUlIO7y4uXy 7uIg/fLuIPLu6/zq7iAxMCDn4Org5+7iIO3gIFJFUE9SVCAjMS4NCt3y6PUg 5OXx//L8IPfl6+7i5eog7+7x6+Dr7iAyMC4wMDAg7/Du4/Dg7OwsIPfy7iDv 8OggMCw1JSAtIPPm5SAxMDAg5+Dq4Ofu4iDt4A0KUkVQT1JUICMyLiDK4Obk ++kg6Ocg/fLo9SAxMDAg7+7x6+Dr6CDv7iAyLjAwMCDv8O7j8ODs7Cwg4CDC +yDv7uvz9+jr6CAxLjAwMA0K5+Dq4Ofu4iDt4CBSRVBPUlQgIzMsIOAg5fHr 6CDq4Obk++kg6Ocg/fLo9SAxLjAwMCDv7vjr5fIgMi4wMDAg8eLu6PUg7/Du 4/Dg7OwsDQry4Oog7/DoIDAsNSUg7+7r8/fo8uUgMTAuMDAwIOfg6uDn7uIg 7eAgUkVQT1JUICM0LiDAIP3y7iAxMC4wMDAg9SA1ID0gNTAuMDAwDQpVU0Qg 4iDt4Ovo9+3u8fLoISEhISEgwuD4IOru7eX37fvpIOfg8ODh7vLu6iDiIP3y 7uwg8evz9+DlIOHz5OXyOg0KNTArNTAwKzUuMDAwKzUwLjwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwg IEN5ciInPjA8L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz4wMCA9IDU1LjU1MCwtIFVTRCEhISEhISEgz+7s7ejy5Swg9/LuIP3y7g0K 7/Dl5O/u6+7m5e3o5SDk6/8gMTk5MCD35evu4uXqLiDS5Swg6u7y7vD75SDt 5SDn4PXu8v/yIPP34PHy4u7i4PL8LCD98vMNCuLu5+zu5u3u8fL8IPPk4Ov/ 8iwg6CDt6Pfl4+4g7eUg8evz9+jy8f8hIM/u7/Du4fPp8uUg7+7k8+zg8vwg 7Ojt8/Lq8yEgwCD38u4NCuXx6+gg6uDm5PvpIO/u+Ovl8iAxMDAuMDAwIO/w 7uPw4OzsIOLs5fHy7iAyLjAwMCA/ISDC5fD88uUg7O3lLDwvc3Bhbj48c3Bh bg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs ICBDeXIiJz4gPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+9/LuIOv+5Ogg/fLuIPHk5evg/vIsIOLu5+zu5u3uIOgg4e7r/PjlISDM 5ebk8yDv8O736OwsDQrC4Pgg9Ojt4O3x7uL76SDi6uvg5CD/4uv/5fLx/yDs 6O3o7ODr/O377C4uLiDC+yDz5uUg6Ozl5fLlIO/u5Orr/vfl7ejlIOoNCsjt 8uXw7eXyLCDgIGUtbWFpbCAtIOHl8e/r4PLl7SE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5S RVBPUlQgIzIgwuDsIO/u6uDm5fIg8eDs++Ug6/P3+OjlIOzl8u7k+w0K7ODx 8e7i7ukg8ODx8fvr6uggZS1tYWlsIOgg4+TlIOzu5u3uIO3g6fLoIO/l8OX3 5e38IODk8OXx7uIuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48Yj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+zMXSzsQgIzIgLSDBxdHP y8DSzcDfINDFysvAzMAgwiDIzdLF0M3F0sUgPG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PtDl6uvg7OAg4iDI7fLl8O3l8uUg/+Lr/+Xy8f8g7eXy8OXh7uLg8uXr/O3u 6Q0K6CDx8/nl8fLi8+XyIPL78f/34CDBxdHPy8DSzdvVIOzl8fIg5Ov/IPDl 6uvg7PsuINHq4Obl7Cwg7eDv8Ojs5fAsIPfy7iDi+w0K7eD37eXy5SDx6vDu 7O3uLCDy7uv86u4g5Ov/IPLu4+4sIPfy7uH7IPPn7eDy/CDk5enx8uLz5fIg 6+gg/fLuLiDC4Pjl6SD25ev8/iDh+w0K4fvr7iDt4Ony6CDi8eXj7iDr6Pj8 IDEwIPfl6+7i5eog7eAg7+Xw4vvpIPPw7uLl7fwg8u4g5fHy/CDy5fUsIOry 7iDn4Org5+DrIOH7DQrzIMLg8SBSRVBPUlQjMSAo8ODn7OX55e3o5ewg4eXx 7+vg8u379SDu4fr/4uvl7ejpIOIgyO3y5fDt5fIg6+Xj6u4g7eDp8ugg6A0K 4e7r/Pjl5SDq7uvo9+Xx8uLuIOfg6uDn7uIpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsTg 6/z45SDv8OXk7+7r7ubo7Cwg9/LuIOrg5uT76SDo5yDC4Pjl6Q0K7vDj4O3o 5+D26Ogg7eDp5OXyIPLu6/zq7iAxMCD35evu4uXqLiDP7vHs7vLw6Owg7eAg 7/Do7OXw5SDoIPPi6OTo7Cwg9/LuDQrv8O7o5+7p5OXyOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yOw0K dGFiLXN0b3BzOmxpc3QgMzYuMHB0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+MS48c3Bhbg0Kc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjEt6SBs ZXZlbCAtIOLg+Oj1IDEwDQrq6+jl7fLu4iDv7iA1IFVTRC4uLi4uLi4uhYWF hYWFhTUwLC0gVVNELiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxvbCBz dGFydD0yIHR5cGU9MT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7dGFiLXN0b3Bz Omxpc3QgMzYuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KICAgICAx MC4wcHQnPjIt6SBsZXZlbCAtIO/uIDEwIOrr6OXt8u7iIO7yIPLl9SAxMC3y 6CAoNSwtIFVTRCB4IDEwMCkgLi4uLi4uLi4NCiAgICAgNTAwLC0gVVNELiA8 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KICAgICBtc28tbGlzdDpsMCBsZXZlbDEgbGZvMjt0 YWItc3RvcHM6bGlzdCAzNi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQogICAgIDEwLjBwdCc+My3pIGxldmVsIC0g/fLuIPPm5SAxLjAwMCDq6+jl 7fLu4iAoNSwtIFVTRCB4IDEuMDAwKSAuhYUuNS4wMDwvc3Bhbj48c3Bhbg0K ICAgICBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwgIEN5ciInPjAsLSBVU0QuIDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+DQog PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1s aXN0OmwwIGxldmVsMSBsZm8yO3RhYi1zdG9wczpsaXN0IDM2LjBwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToNCiAgICAgMTAuMHB0Jz40LekgbGV2ZWwg LSAxMC4wMDAg6uvo5e3y7uIgKDUsLSBVU0QgeCAxMC4wMDApIC4uLi4uhYWF LiA1MC4wMDAsLQ0KICAgICBVU0QuIDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ DQo8L29sPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ yPLu4+4gNTUuNTUwLC0gVVNELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPs/u7O3o8uUsIPfy 7iD98u4g8u7r/OruIO/w6Ozl8CDk6/8gMTAg6uvo5e3y7uIuDQrM7e7j6OUg 6/7k6CDt4Onk8/Ig8e7y7egg6uvo5e3y7uIhISEgz87E08zAydLFIM7BIN3S zswhISEgwvHlLCD38u4g4vsg5O7r5u37DQrx5OXr4PL8LCDn4CDq4Obk++Ug JDUgVVNELCDq7vLu8PvlIO/u6/P36PLlIOIg8eLu6SDq7vjl6+XqIC0g/fLu IO/u8evg8vwNCu/u6vPv4PLl6/4g5+Dq4Ofg7e376SBSRVBPUlQuIMgg3dLO IMLRxSEhISDC0cXDxMAgztLP0MDCy9/J0sUgx8DKwMfbIMIg0s7SDQrExc3c LCDKzsPEwCDOzcggz9DIycTT0iEhISDd8u4gwuDsIOPg8ODt8ujw8+XyLCD3 8u4gZS1tYWlsLCDq7vLu8PvlIOHz5PPyDQrv7vH76+Dy/CDxIMLA2MjMIOjs 5e3l7Cwg4fPk8/Ig4fvx8vDl5SDw4PHv8O7x8vDg7f/y/PH/PC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwgIEN5ciInPiw8L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz4g7+7y7uzzIPfy7iDu7egg7eUg7O7j8/Ig4fvy/CDv7vHr4O37IO/u 6uAgUkVQT1JUknMNCu3l8iDzIOLg+OXj7iDn4Org5/fo6uAhISEgPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cD48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+yNLAyiwgxM7R0tPPzdvFIFJFUE9SVCdzOjxvOnA+PC9v OnA+PC9zcGFuPjwvYj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0n dGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMu NXB0Jz4qKioqKioNCsfg6uDm6CDx5eHlIOrg5uT76SDo5yDt6PUg8e7j6+Dx 7e4g7e7s5fDzIOgg7eDn4uDt6P4gKioqKioqPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwgIEN5ciInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHA+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PsfAysDGyNLFINHFwcUgUkVQT1JUknMg0cXJ18DRICEhITxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cD48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+0uDh6+j24CA8L3NwYW4+PC9iPjxiPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwgIEN5ciIn PjEuIFJFUE9SPC9zcGFuPjwvYj48Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPlSScyDoIPDl6uLo5+jy+yDv8O7k4OL27uIuPG86cD48L286 cD48L3NwYW4+PC9iPjwvcD4NCg0KPGRpdiBhbGlnbj1yaWdodD4NCg0KPHRh YmxlIGJvcmRlcj0xIGNlbGxzcGFjaW5nPTEgY2VsbHBhZGRpbmc9MCB3aWR0 aD02NDQgc3R5bGU9J3dpZHRoOjQ4My4wcHQ7DQogbXNvLWNlbGxzcGFjaW5n Oi43cHQ7bXNvLXBhZGRpbmctYWx0OjUuMjVwdCA1LjI1cHQgNS4yNXB0IDUu MjVwdCc+DQogPHRyIHN0eWxlPSdoZWlnaHQ6MjEuMHB0Jz4NCiAgPHRkIHdp ZHRoPSI0JSIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6NC45NCU7YmFja2dy b3VuZDp3aGl0ZTtwYWRkaW5nOjUuMjVwdCA1LjI1cHQgNS4yNXB0IDUuMjVw dDsNCiAgaGVpZ2h0OjIxLjBwdCc+DQogIDxwPrk8L3A+DQogIDwvdGQ+DQog IDx0ZCB3aWR0aD0iNDclIiBzdHlsZT0nd2lkdGg6NDcuNjIlO2JhY2tncm91 bmQ6d2hpdGU7cGFkZGluZzo1LjI1cHQgNS4yNXB0IDUuMjVwdCA1LjI1cHQ7 DQogIGhlaWdodDoyMS4wcHQnPg0KICA8cD7P5fDl9+Xt/CBSRVBPUlSSczwv cD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPSIyNCUiIHZhbGlnbj10b3Agc3R5 bGU9J3dpZHRoOjI0LjglO2JhY2tncm91bmQ6d2hpdGU7cGFkZGluZzo1LjI1 cHQgNS4yNXB0IDUuMjVwdCA1LjI1cHQ7DQogIGhlaWdodDoyMS4wcHQnPg0K ICA8cD5SLeru+OXr5eog7/Du5ODi9uAg4iDx6PHy5ezlIFdlYk1vbmV5IDxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46DQogIHllcyI+oDwvc3Bhbj4oIDxz cGFuIHN0eWxlPSdtc28tZmFyZWFzdC1mb250LWZhbWlseToiTVMgR290aGlj Ijttc28tZmFyZWFzdC1sYW5ndWFnZToNCiAgSkEnPujt5OX06Org8u7wIO/w 7uTu4vbgKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiAgPHRk IHdpZHRoPSIyMSUiIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjIxLjklO2Jh Y2tncm91bmQ6d2hpdGU7cGFkZGluZzo1LjI1cHQgNS4yNXB0IDUuMjVwdCA1 LjI1cHQ7DQogIGhlaWdodDoyMS4wcHQnPg0KICA8cD5FLW1haWwg7/Du5ODi 9uAgPC9wPg0KICA8L3RkPg0KIDwvdHI+DQogPHRyIHN0eWxlPSdoZWlnaHQ6 MjEuNzVwdCc+DQogIDx0ZCB3aWR0aD0iNCUiIHZhbGlnbj10b3Agc3R5bGU9 J3dpZHRoOjQuOTQlO2JhY2tncm91bmQ6d2hpdGU7cGFkZGluZzo1LjI1cHQg NS4yNXB0IDUuMjVwdCA1LjI1cHQ7DQogIGhlaWdodDoyMS43NXB0Jz4NCiAg PHA+MTwvcD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPSI0NyUiIHZhbGlnbj10 b3Agc3R5bGU9J3dpZHRoOjQ3LjYyJTtwYWRkaW5nOjUuMjVwdCA1LjI1cHQg NS4yNXB0IDUuMjVwdDsNCiAgaGVpZ2h0OjIxLjc1cHQnPg0KICA8cD5SRVBP UlQgIzEgJnF1b3Q70PPq7uLu5PHy4u4g7+4g4eXx7+vg8u3u6SDoIP309OXq 8uji7e7pIPDl6uvg7OUg4g0KICDI7fLl8O3l8iZxdW90OyA8L3A+DQogIDwv dGQ+DQogIDx0ZCB3aWR0aD0iMjQlIiBzdHlsZT0nd2lkdGg6MjQuOCU7cGFk ZGluZzo1LjI1cHQgNS4yNXB0IDUuMjVwdCA1LjI1cHQ7DQogIGhlaWdodDoy MS43NXB0Jz4NCiAgPHA+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNv LWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPlI8L3NwYW4+NjQ1ODk0MjQ1Nzk2ICgw ODYyMTU4MTg5NjQpPG86cD48L286cD48L2I+PC9wPg0KICA8L3RkPg0KICA8 dGQgd2lkdGg9IjIxJSIgc3R5bGU9J3dpZHRoOjIxLjklO3BhZGRpbmc6NS4y NXB0IDUuMjVwdCA1LjI1cHQgNS4yNXB0Ow0KICBoZWlnaHQ6MjEuNzVwdCc+ DQogICAgICAgICAgPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1z aXplOg0KICAxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPnJlcG9y dHNAbm0ucnU8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+DQogIDwvdGQ+DQogPC90cj4NCiA8dHIgc3R5bGU9 J2hlaWdodDoyNi4yNXB0Jz4NCiAgPHRkIHdpZHRoPSI0JSIgdmFsaWduPXRv cCBzdHlsZT0nd2lkdGg6NC45NCU7YmFja2dyb3VuZDp3aGl0ZTtwYWRkaW5n OjUuMjVwdCA1LjI1cHQgNS4yNXB0IDUuMjVwdDsNCiAgaGVpZ2h0OjI2LjI1 cHQnPg0KICA8cD4yPC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9IjQ3JSIg dmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6NDcuNjIlO3BhZGRpbmc6NS4yNXB0 IDUuMjVwdCA1LjI1cHQgNS4yNXB0Ow0KICBoZWlnaHQ6MjYuMjVwdCc+DQog IDxwPlJFUE9SVCAjMiAmcXVvdDvQ8+ru4u7k8fLi7iDv7iDs4PHx7uLu6SDw 5err4Ozt7ukg8ODx8fvr6uUgRS1NYWlsICZxdW90OzwvcD4NCiAgPC90ZD4N CiAgPHRkIHdpZHRoPSIyNCUiIHN0eWxlPSd3aWR0aDoyNC44JTtwYWRkaW5n OjUuMjVwdCA1LjI1cHQgNS4yNXB0IDUuMjVwdDsNCiAgaGVpZ2h0OjI2LjI1 cHQnPg0KICA8cD48Yj5SNjYyNDk1ODAzNzA1ICgyMzYzNjU4NTU4OTIpPC9i PjwvcD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPSIyMSUiIHN0eWxlPSd3aWR0 aDoyMS45JTtwYWRkaW5nOjUuMjVwdCA1LjI1cHQgNS4yNXB0IDUuMjVwdDsN CiAgaGVpZ2h0OjI2LjI1cHQnPg0KICA8aDE+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTIu MHB0Jz5idXNpbmVzczwvc3Bhbj48c3Bhbg0KICBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0O21zby1hbnNpLWxh bmd1YWdlOlJVJz5fPC9zcGFuPjxzcGFuDQogIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdCc+ eHg8L3NwYW4+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNv LWJpZGktZm9udC1zaXplOjEyLjBwdDttc28tYW5zaS1sYW5ndWFnZTpSVSc+ QDwvc3Bhbj48c3Bhbg0KICBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQnPm1hbGU8L3NwYW4+ PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9u dC1zaXplOjEyLjBwdDttc28tYW5zaS1sYW5ndWFnZTpSVSc+Ljwvc3Bhbj48 c3Bhbg0KICBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O21z by1iaWRpLWZvbnQtc2l6ZToxMi4wcHQnPnJ1PC9zcGFuPjxzcGFuDQogIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4w cHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6UlUnPjxvOnA+PC9vOnA+PC9zcGFuPjwv aDE+DQogIDwvdGQ+DQogPC90cj4NCiA8dHIgc3R5bGU9J2hlaWdodDoxNi41 cHQnPg0KICA8dGQgd2lkdGg9IjQlIiB2YWxpZ249dG9wIHN0eWxlPSd3aWR0 aDo0Ljk0JTtiYWNrZ3JvdW5kOndoaXRlO3BhZGRpbmc6NS4yNXB0IDUuMjVw dCA1LjI1cHQgNS4yNXB0Ow0KICBoZWlnaHQ6MTYuNXB0Jz4NCiAgPHA+Mzwv cD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPSI0NyUiIHZhbGlnbj10b3Agc3R5 bGU9J3dpZHRoOjQ3LjYyJTtwYWRkaW5nOjUuMjVwdCA1LjI1cHQgNS4yNXB0 IDUuMjVwdDsNCiAgaGVpZ2h0OjE2LjVwdCc+DQogIDxwPlJFUE9SVCAjMyAm cXVvdDvR5erw5fL7IOzt7uPu8/Du4u3l4u7j7iDs4PDq5fLo7ePgIOIgyO3y 5fDt5fImcXVvdDs8L3A+DQogIDwvdGQ+DQogIDx0ZCB3aWR0aD0iMjQlIiBz dHlsZT0nd2lkdGg6MjQuOCU7cGFkZGluZzo1LjI1cHQgNS4yNXB0IDUuMjVw dCA1LjI1cHQ7DQogIGhlaWdodDoxNi41cHQnPg0KICA8cD48Yj5SNjEyMTcx MzMwMDU4ICgxMDg5ODI3NDIzOTMpPC9iPjwvcD4NCiAgPC90ZD4NCiAgPHRk IHdpZHRoPSIyMSUiIHN0eWxlPSd3aWR0aDoyMS45JTtwYWRkaW5nOjUuMjVw dCA1LjI1cHQgNS4yNXB0IDUuMjVwdDsNCiAgaGVpZ2h0OjE2LjVwdCc+DQog IDxwPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5tbG1AbWFs ZS5ydTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQogIDwvdGQ+DQogPC90 cj4NCiA8dHIgc3R5bGU9J2hlaWdodDoxNy4yNXB0Jz4NCiAgPHRkIHdpZHRo PSI0JSIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6NC45NCU7YmFja2dyb3Vu ZDp3aGl0ZTtwYWRkaW5nOjUuMjVwdCA1LjI1cHQgNS4yNXB0IDUuMjVwdDsN CiAgaGVpZ2h0OjE3LjI1cHQnPg0KICA8cD40PC9wPg0KICA8L3RkPg0KICA8 dGQgd2lkdGg9IjQ3JSIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6NDcuNjIl O3BhZGRpbmc6NS4yNXB0IDUuMjVwdCA1LjI1cHQgNS4yNXB0Ow0KICBoZWln aHQ6MTcuMjVwdCc+DQogIDxwPlJFUE9SVCAjNCAmcXVvdDvK4Oog8fLg8vwg 7Ojr6+ju7eXw7uwsIOjx7+7r/Ofz/yBNTE0g6CDI7fLl8O3l8iZxdW90Ozwv cD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPSIyNCUiIHN0eWxlPSd3aWR0aDoy NC44JTtwYWRkaW5nOjUuMjVwdCA1LjI1cHQgNS4yNXB0IDUuMjVwdDsNCiAg aGVpZ2h0OjE3LjI1cHQnPg0KICA8cD48Yj5SMDcwMjU0MTcxMTE3ICgxOTYw NTE5MDAyNjYpPC9iPjwvcD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPSIyMSUi IHN0eWxlPSd3aWR0aDoyMS45JTtwYWRkaW5nOjUuMjVwdCA1LjI1cHQgNS4y NXB0IDUuMjVwdDsNCiAgaGVpZ2h0OjE3LjI1cHQnPg0KICA8cD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+bGVhZGVyQG1hbGUucnU8L3Nw YW4+PC9iPjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KPC90YWJsZT4NCg0KPC9k aXY+DQoNCjxwPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7R IOv+4fvsIOjnIO/w7uTg4vbu4iDi8eXj5OAg7O7m7e4g8eL/5+Dy/PH/DQr3 5fDl5yDl4+4gZS1tYWlsLiDN7iwg7+7m4Ovz6fHy4Cwg7eUg5+Dj8PPm4Ony 5SDo9SDr6Pjt6OzoIOLu7/Du8eDs6Cwg7u3oIOzu4/PyDQrh+/L8IO735e38 IOfg7f/y+yDu4fDg4e7y6u7pIOfg6uDn7uIgKO7x7uHl7e3uIO3gIPLw5fL8 5ewg6CD35fLi5fDy+/Ug8/Du4u3/9SkuPG86cD48L286cD48L3NwYW4+PC9i PjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsLO 0iwg19LOIM3Txs3OINHExcvA0twgwsDMOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjEuINHq 7u/o8O7i4PL8IO/w7uPw4Ozs8yBXZWJNb25leSBrZWVwZXIgMiDoDQrx7ufk 4PL8IPHl4eUg8PPh6+Xi++kgUi3q7vjl6+XqLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7I 7fHy8PPq9ujoIO/uIPDg4e7y5SDxIOru+OXr/Oru7CDoIOjt9O7w7OD26P8N Cu7hIP3y7ukg8ejx8uXs5SDv6+Dy5ebl6TxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPu3gIPHg 6fLlIDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+PGEgaHJlZj0iaHR0cDovL3d3dy53 ZWJtb25leS5ydS8iPmh0dHA6Ly93d3cud2VibW9uZXkucnUvPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPjIuIM/u7+7r7ejy/CDRws7JIOru+OXr5eog8PPh6+Xi++wN Cv3q4uji4Ovl7fLu7CAkMjAgKyAzJSDv7iDq8/Dx8yDWwSwg4vvh8ODiIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPuv+4e7pIOjnIOTu8fLz7+379SDt4CA8L3NwYW4+PHNw YW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCAgQ3lyIic+PGENCmhyZWY9Imh0dHA6Ly93d3cud2VibW9uZXkucnUvcnVz L3BlcmV2b2RzLmh0bSI+aHR0cDovL3d3dy53ZWJtb25leS5ydS9ydXMvcGVy ZXZvZHMuaHRtPC9hPjwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPiDx7+7x7uHu4iDv5fDl4u7k4C48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4zLiDP 7vHr5SDv7vHy8+/r5e3o/yDk5e3l4yDiIOLg+CDq7vjl6+XqLA0K5+Dq4Obo 8uUg8eXh5SDi8eUg9+Xy+/DlIFJFUE9SVCdzIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPijo 5yDv5fDl9+3/INLg4evo9vsgMSksIO/z8uXsIO/l8OXi7uTgDQpXZWJNb25l eSDo5yDx4u7l4+4g6u745ev86uAg4iDq7vjl6+XqPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ 7/Du5ODi9uAsIPHz7Oz7ICQ1INHYwCDv7iDq8/Dx8yDWwSwg5+Ag6uDm5Pvp DQpSRVBPUlQuIM7h/+fg8uXr/O3uLCDz6uDm6PLlIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PuIg7+7r5SDq7uzs5e3y4PDo/yDt7uzl8CBSRVBPUlQg6CDu4fDg8u376Q0K ZS1tYWlsIODk8OXxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPs/w6Ozl8DogPC9zcGFuPjxi PjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsICBDeXIiJz5SRVBPUlQjMSB4eHh4eHhAeHh4eC54eHg8bzpwPjwv bzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+KM/u5PLi5fDk6PLlIO7v6+Dy8yDv7iBlLW1haWwpPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+NC4gwiDS4OHr6PblIDEsIPPk4Ovo8uUg7e7s5fAg6u74 5ev86uAg6OcNCvHy8O7q6CA8L3NwYW4+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz40PC9zcGFu PjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiDoIO/l8OXs 5fHy6PLlIO3gIOXj7iDs5fHy7iA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7t7uzl8CDq7vjl 6/zq4CDo5yDx8vDu6uggPC9zcGFuPjxiPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwgIEN5ciInPjM8L3NwYW4+ PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+LiDH4PLl7Cwg 7+Xw5ezl8fLo8uUg7e7s5fAg6u745ev86uAg6Ocg8fLw7uroIDwvc3Bhbj48 Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsICBDeXIiJz4yPC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4gPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+4iDu8eLu4e7k6OL45eXx/yDs5fHy7iDiIPHy7vDu6uUgPC9z cGFuPjxiPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwgIEN5ciInPjM8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+LiDILCDt4Oru7eX2LCDv5fDl7OXx8ujy5SDt 7uzl8CDq7vjl6/zq4CDo5yA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7x8vDu6uggPC9zcGFu PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6IkFyaWFsICBDeXIiJz4xPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+IOIg8fLw7urzIDwvc3Bhbj48Yj48c3Bhbg0Kc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIi Jz4yPC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4uIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsIg 7vHi7uHu5Oji+OXl8f8g7OXx8u4g4iDx8vDu6uUgPC9zcGFuPjxiPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwg IEN5ciInPjE8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+IOLx8uDi/PLlIO3u7OXwIPHi7uXj7iBSLSDq7vjl6/zq4C4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+0uXv5fD8IML7IPHy4OvoIO/w7uTg4vbu7CBSRVBPUlQj MS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz41LiDS7ublIPHg7O7lIO/w7uTl6+Dp8uUg8SBl LW1haWwg4OTw5fHg7OguPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+z9DIzMXXwM3IxTo8bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+KsfgIOrg5uT76SBSRVBPUlQN Cu/l8OXi5eTo8uUg8PPh6+Xi++kg/eri6OLg6+Xt8iAkNSBVU0Qg7+4g6vPw 8fMg1sEsIPHuIPHi7uXj7iDq7vjl6/zq4CDt4CDt7uzl8A0K6u745ev86uAg 7/Du5ODi9uAuIChVU0Qg7+7y7uzzLCD38u4g4iD98u4g4u7i6+X35e37IObl 6+D++ejlIPHuIOLx5ePuIPHi5fLgKS4NCsLx5SDu7+Xw4Pbo6CDu8iDx7ufk 4O3o/yDq7vjl6/zq4CDk7iDu7+vg8vsgUkVQT1JUknMg7/Du6Ofi7uT/8vH/ IOIg7/Du4/Dg7OzlDQpXZWJNb25leSBLZWVwZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+KiDC7ufs7ubt4CDy4Orm5Q0K 7u/r4PLgIPEg4uDr/vLt7uPuIFot6u745ev86uAsIOTr/yD35ePuIPHi/+bo 8uXx/Cwg7+7m4Ovz6fHy4Cwg8SDv8O7k4OL27uwg7+4NCuLt8/Lw5e3t5ekg 7+738uUgV2ViTW9uZXkgS2VlcGVyIOgg7+7v8O7x6PLlIOXj7iDx7ufk4PL8 IFot6u745evl6iDoIPHu7uH56PL8DQrl4+4g7e7s5fAuPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+KsIg6u745ev86uUsDQrk 5e384+gg9fDg7f/y8f8g4iDi6OTlIPPx6+7i7fv1IOXk6O3o9iAoV2ViTW9u ZXkpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJn aW4tbGVmdDozNi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz7P7iDq8/Dx8yAxV00gPSAxDQrw8+EuIOTr/yBSLSDq7vjl6/zq4CA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tbGVmdDoz Ni4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4xV00gPSAx IOTu6+vg8CDR2MANCuTr/yBaLSDq7vjl6/zq4C48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4qyu7j5OAg8eTl6+Dl8uUNCvHi 7ukg5+Dq4OcsIPPh5eTo8uXx/Cwg9/LuIOL7IOfg6uDn4OvoIOLx5SBSRVBP UlQuIMLx5SDu7egg7+7t4OTu4f/y8f8g5Ov/DQry7uPuLCD38u7h+yDC+yDx 7vXw4O3o6+gg8yDx5eH/IOIg6u7s7/z+8uXw5SDoLCDv7vLu7Cwg7O7j6+gg 7/Du5ODi4PL8IOru7+joLg0KwuDsIOTl6fHy4ujy5ev87e4g7fPm7fsg4vHl IP3y6CBSRVBPUlQsIOjt4PflIOv+5Ogg7eUg8ezu4/PyIPHk5evg8vwg8yDi 4PENCufg6uDnLCDgIPHg7O7lIOPr4OLt7uUsIP3y6CBSRVBPUlSScyDx7uTl 8Obg8iDi4Obt8/4g6O307vDs4Pbo/iDuIPLu7Cwg6uDqIOjsDQrk7vHy6Pf8 IPPx7+X14CEhIMgg8ODn4uji4PL8IP3y7vIg4ejn7eXx8S48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4qwiDy5ffl7ejoDQrt 5fHq7uv86uj1IOTt5ekg7+7x6+Ug7u/r4PL7LCDi+yDv7uvz9+jy5SD35fL7 8OUgZS1tYWlsLCDiIOrg5uTu7CDv7iDu5O3u7PMNClJFUE9SVCjzKS4g0e71 8ODt6PLlIOj1IOIg4uD45ewg6u7s7/z+8uXw5SAo6CDt4CDk6PHq5fLlIOTr /yDt4OTl5u3u8fLoKSwg9/Lu4fsNCu7t6CDi8eXj5OAg4fvr6CDj7vLu4vsg 6iDv7vH76+rlIPL78f/34Owg6/7k5eksIOru8u7w++Ug6PUg8yDi4PEg5+Dq 4Obz8i4NCtLl7+Xw/CD98u4gwuD4IPLu4uDwLCDxIO/w4OLu7CDv8O7k4Obo ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PGI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQnPsLAxs3OOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+IC0g7eUg7OXt/+ny5SDt7uzl8OAg 6u745ev86u7iLCDq7vLu8PvlIO3g9e7k//Lx/yDiIPHv6PHq5SDn4CDq4Obk ++wg6OcNClJFUE9SVCdzICjt6Org6ujsIPHv7vHu4e7sKSwg8u7r/OruIPLg 6iwg6uDqIP3y7iDz6uDn4O3uIOIg7/Pt6vLg9SAoMSCWIDUpLA0K6O3g9+Ug 7+7y5fD/5fLlIOHu6/z48/4g9+Dx8vwg8eLu6PUg5O717uTu4i4gyu7j5OAg 7+7p7OXy5Swg6uDqIP3y7iDk5enx8uLz5fIsDQrC4Owg8fDg5/Mg8fLg7eXy IO/u7f/y7e4sIO/u9+Xs8yD98u4g7+Xw5fHy4OXyIOTl6fHy4u7i4PL8LCDq 7uPk4CD38u4t7ejh8+T8DQro5+zl7ej4/CDt5SDv7iDv8+3q8uDsKDEgliA1 KSAuIM/u7O3o8uUsIP3y7vIg7OXy7uQg4fvrIO/w7uLl8OXtLCDoIOXx6+gg wvsg6Ofs5e3o8uUNCuXj7iwg7u0g7+Xw5fHy4O3l8iDw4OHu8uDy/CEhPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+wu7n/Ozo8uUg/fLu8iDk7urz7OXt8iDxIOjn7OXt5e3t ++wg7+Xw5fft5ewNCujs5e0g6CDx9+Xy7uIg6CDx6u7v6PDz6fLlIOXj7iDt 4CDi4Pgg6u7s7/z+8uXwLiDS5e/l8Pwg4vsg4+7y7uL7IOog8ODh7vLlIOgN Cuzu5uXy5SDw4PHx++vg8vwg/fLuIO/w5eTr7ubl7ejlIOIg7+7o8erg9SDx 4u7o9SDq6+jl7fLu4iwg7e4g7/Dl5OLg8Ojy5ev87e4NCu7h/+fg8uXr/O3u IO/w7vfo8uDp8uUg4vHlIPfl8vvw5SDw8+ru4u7k8fLi4CAtIO7t6CDx6Ov8 7e4g7+7s7uPz8iDi4OwuIM3lDQrk5evg6fLlIO3o6uDq6PUg6Ofs5e3l7ejp IOIg9+Dx8uggyM3R0tDTytbIyCEhISDC4Pgg9Ojt4O3x7uL76SDi6uvg5CDi IOTg7e3u5Q0K7/Dl5O/w6P/y6OUg/+Lr/+Xy8f8g7/Dg6vLo9+Xx6ugg7ej3 8u7m7fvsICjq7u3l9+3uIOblIOXx6+gg4vsg7O7m5fLlIO/u5+Lu6+jy/A0K 8eXh5SDo7eLl8fLo8O7i4PL8IDIwLC0gVVNELCDo6+gsIO3g7/Do7OXwLCDs 7ubl8uUg8evu5ujy/PH/IPEg5PDz5/z/7OguINfl7A0K4e7r/PjlIOHz5OXy IMLg8SDk6/8g7+7x++vq6CDw5err4Oz7IOggZW1haWwsIPLl7CDh7uv8+OUg 4vsg6PUg7+746+Xy5SEuIML7LA0K6u7t5fft7iDm5Swg8+blIO/u5Orr/vfl 7fsg6iDx5fLoIMjt8uXw7eXyIOgg6Ozl5fLlIOHl8e/r4PLt++kgZS1tYWls ISDCIO/u7O75/A0KwuDsIPEg4uD46Owg7ODw6uXy6O3j7uwsIPHu5+Tg7fsg NCBSRVBPUlQo8PPq7uLu5PHy4uApLCDq7vLu8PvlIOL7IOfg6uDn4OvoLg0K zu3oIPHu5OXw5uDyIO/u6+Xn7fP+IOjt9O7w7OD26P4sIO3g7/Do7OXwLCDq 4Oog7+7x++vg8vwg7ODx8e7i8/4g7+738u7i8/4NCvDg8fH76+rzIChlLW1h aWwpLCDj5OUg7eDp8ugg8vvx//fzIOLu5+zu5u3u8fLl6SDx5OXr4PL8IOHl 8e/r4PLt8/4g8OXq6+Ds8yDoDQryLuQuINLg6ublIOLg7CDh8+Tz8iDk4O37 IOjt9O7w7OD26Ogg7uEgyM3SxdDNxdItzMDQysXSyM3DLcrL08HA1S4gx+Tl 8fwNCu3g6eTl8uUg6u7t9OXw5e326P4sIOPk5SDo7fLl8O3l8i3v8OXk7/Do 7ejs4PLl6+gg8SD25evu4+4g8eLl8uAg4ufg6Ozt7g0K7uHs5e3o4uD+8vH/ IOjt9O7w7OD26OXpIOgg8eXq8OXy4OzoIPPx7+X14C4gyuvz4SDy4Orm5Twv c3Bhbj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsICBDeXIiJz4gPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+4eXx7+vg8u3uIO/w5eTu8fLg4uv/5fIg6O3y5fDt5fLu 4vvlIOjt8fLw8+zl7fL7IOgNCvPx6/Pj6CDk6/8g8e7n5ODt6P8g0c7B0dLC xc3NzsPOIMjN0sXQzcXSIM/QxcTP0Mjf0sjfLiDP7vHy4OL/8iDh5fHv6+Dy 7e4NCnNvZnR3YXJlIOTr/yDu8u/w4OLr5e3o/yDs4PHx7uL79SBlLW1haWwg 6CDq4Obk++kg5OXt/CAxLjAwMC4wMDAg7e7i+/UgZS1tYWlsDQrg5PDl8e7i LiDS4Orm5SDC4Owg7+7x7uLl8vP+8iwg4+TlIO3g6fLoIOHl8e/r4PLt8/48 L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCAgQ3lyIic+IDwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPldFQiDx8vDg7ej28ywg6uDqIO/u6/P36PL8IFRPUCDu 9uXt6vMg4iDv7ujx6u7i+/UNCu/w7uPw4Ozs4PUg5Ov/IMLg+OXpIPHy8ODt 6Pb7LCDq4Oog7/Du5ODy/CDC4Pgg7/Du5PPq8iDv8Ogg7+7s7vnoIPDl6uvg 7PssDQrh/uvr5fLl7eXpLCDh4O3t5fDu4iDoIOzt7uPuIOTw8+Po9SDx7uLl 8u7iLiDA5PDl8SBJTVI6DQpodHRwOi8vd3d3Lm1hcmtldGluZ29udGhld2Vi Lm5ldCDP8Ojr7ubl7ejlIODk8OXx7uIg8e4g8e/o8erg7Ogg6CDv7ujx6u7i ++zoDQrv8O7j8ODs7ODs6CBlLW1haWwg4OTw5fHu4jo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+aHR0cDovL3d3dy53aG93aGVy ZS5seWNvcy5jb20vRW1haWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsICBDeXIiJz5odHRwOi8vd3d3LmluZm9zcGFjZS5jb20vaW5mby9l bWFpbDEuaHRtDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4hISEgzsHfx8DSxcvczc4gz9DO wsXQ3NLFIM/QwMLIy9zNztHS3CDIx8zFzcXNyN8NCtLAwcvI1tsgISEhPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBhbGlnbj1jZW50ZXIgc3R5bGU9 J3RleHQtYWxpZ246Y2VudGVyJz48Yj48dT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+z/Do4evo5+jy5ev87e4NCjUwLjAwMCDt7uL79SDr/uTl 6SDv7uTq6/734P7y8f8g6iDI7fLl8O3l8vMg6uDm5PvpIOzl8f/2ITxvOnA+ PC9vOnA+PC9zcGFuPjwvdT48L2I+PC9wPg0KDQo8cCBhbGlnbj1jZW50ZXIg c3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48dT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC91PjwvcD4NCg0KPHA+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIi Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCAgQ3ly Iic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBzdHlsZT0n bWFyZ2luLWxlZnQ6MzYuMHB0Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+z/Du4uXw/PLlLA0K7vHu4eXt7e4g4u3o7ODy5ev87e4sIO/w 4OLo6/zt7vHy/CDz6uDn4O3o/yDt7uzl8OAg6u745ev86uAg7/DoIO/l8OXi 7uTlLiDd8u4g7vfl7fwNCuLg5u3uLCDy4Oog6uDqIO/u6uAg7eUg5+Dv6+Dy 6PLlIO/w4OLo6/zt7iwg5+Dq4Ocg7eUg7/Do5OXyLCDgIML7IO3lIO/u6/P3 6PLlDQrx4u7pIHJlcG9ydC4gzeDp5Ojy5SDi8OXs/ywg9/Lu4fsg4vsg8ezu 4+voIPHk5evg8vwg4vHlIO/w4OLo6/zt7iDoIO3lDQry7vDu7//x/Cwg7+7y 7uzzIPfy7iD98u4g7vHt7uLgIMLg+OXj7iDh6Oft5fHgLjxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0nbWFy Z2luLWxlZnQ6MzYuMHB0O3RleHQtYWxpZ246Y2VudGVyJz48Yj48c3Bhbg0K c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBD eXIiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8cCBh bGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+KioqKioqKioqKioqKg0K0c7C xdLbIMog09HPxdXTICoqKioqKioqKioqKjxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4q 0dfI0sDJ0sUg3dLOINHCzsjMIMHIx83F0c7MISEhIMHz5Pzy5Q0K4fvx8vD7 7OgsIO/w7vTl8fHo7u3g6/zt++zoIOgg7/Do5OXw5uji4Ony5fH8IOjt8fLw 8+r26OkuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+Ksfg6uDm6PLlIPHl4eUg9+Xy+/DlIFJF UE9SVCdzIM/Q38zOINHFydfA0SwNCvfy7uH7IOL7IOj1IOjs5evoLCDq7uPk 4CDqIOLg7CDt4Pft8/Ig7/Do9e7k6PL8IOfg6uDn+ywg7+7y7uzzIPfy7jo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4qyu7j5OAg7+7r8/fo8uUgJDUg0djALCDi+yDEzsvG zdsg7+7x6+Dy/A0K5uXr4OXs++kg7/Du5PPq8iAoUkVQT1JUKSE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz4qIMLRxcPEwCDO0s/QwMLL38nSxSDHwMrAx9sgwiDSztIgxMXN 3CDKzsPEwA0Kzs3IIM/QyMnE09IhISEhPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+KsHz5Pzy 5SDy5fDv5evo4vsg6CDt5SDx5ODi4Ony5fH8ISEgxfHr6A0K4fPk5fLlIPLu 9+3uIOjx7+7r7f/y/CDv8OXk7+jx4O3o/ywgwuD46CA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz7w5efz6/zy4PL7IMHTxNPSINPRz8XYzdvMyCEhISE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz4qwCDDy8DCzc7FLCDCxdDc0sUgwiDRxcHfIMgg0s7M0ywg19LOINMgwsDR DQrPzsvT18jS3NHfISEhISEhITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPioqKioqKioqKioqKg0KzcDY yCDQ38TbINPRz8XVwCAqKioqKioqKioqKjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHA+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPs/w 6OTl8Obo4uDp8uXx/CD98uj1IPD/5O7iIOgg8yDi4PEg4vHlDQrv7uvz9+jy /PH/Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PiDF8evoIO3lIO/u6/P36PLlIDIwDQrn4Org5+7iIO3gIFJlcG9ydCAjMSDi IPLl9+Xt6Ogg5OLz9SDt5eTl6/wsIO/w7uTu6+bg6fLlIOTl6+Dy/CDw5err 4OzzIOgNCu/u8fvr4PL8IGUtbWFpbCwg5O4g8uX1IO/u8Cwg7+7q4CDo9SDt 5SDv7uvz9+jy5S4gz+7y7uwg4vsg4iDy5ffl7ejoIO3l8eru6/zq6PUNCu3l 5OXr/CDC+yDk7uvm7fsg7+7r8/fo8vwg5+Dq4Of7IO3gIFJlcG9ydCAjMi4g xfHr6CD98u4g7eUg7/Du6Ofu6eTl8iwg7eUNCu/l8OXx8uDi4Ony5SDv7vH7 6+Dy/CDw5err4OzzIOTuIPLl9SDv7vAsIO/u6uAg7eUg5O7x8ujj7ejy5SAx MDAg5+Dq4Ofu4iDt4A0KUmVwb3J0ICMyLiDK4Oog8u7r/OruIO/u6/P36PLl IDEwMCDn4Org5+7iIO3gIFJlcG9ydCAjMiwgzM7GxdLFIM3A18DS3A0KztLE 29XA0twsIO/u8u7s8yD38u4g8ejx8uXs4CDiIP3y7uwg8evz9+DlIPPm5SDw 4OHu8uDl8iDn4CDC4PEg4CDC4PjoIOTl7fzj6A0K4fPk8/Ig7/Do9e7k6PL8 IPHg7Ogg7+4g8eXh5S48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7d0s4gwsDGzc4gx8DPzszN yNLcOiDC8eXj5OAsIOru4+TgIOLg+OUg6Oz/DQrv8O7k4ujj4OXy8f8g4u3o 5yDv7iDx7+jx6vMsIML7IO/u6/P34OXy5SDn4Org5yDt4CDx6+Xk8/756Okg UmVwb3J0LCDv7v3y7uzzDQrs7ubl8uUg8evl5Ojy/CDx4u7lIO/w7uTi6Obl 7ejlLCDv7iDy7uzzIOrg6u7pIFJlcG9ydCDu8iDC4PEg5+Dq4Of74uD+8iDr /uToIQ0KxfHr6CDv7ubl6+Dl8uUg7+7i+/Ho8vwg8eLu6SDk7vXu5Cwg8u4g 7/Du8fLuIO/u8fvr4Ony5SDt7uLz/iDv4PDy6P4gZS1tYWlsLg0K0uDqIML7 IO3g9+3l8uUg4uXx/CDv8O725fHxIPHt4Pfg6+AuIM3FINHT2cXR0sLTxdIg zcjKwMrOySDD0MDNyNbbIM/QyMHby8gsDQrKztLO0NPeIMzOxs3OIMTO0dLI w83T0twgwiDd0s7MIMHIx83F0cUhISEgz+Xw5eQg8uXsLCDq4Oog8OX46PLl IPXu8ujy5SD98ujsDQrn4O3o7ODy/PH/IOjr6CDt5fIsIO/w7vfo8uDp8uUg 8evl5PP++ejlIPTg6vL7IO7hIP3y7ukg7/Du4/Dg7OzlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm81Ow0K dGFiLXN0b3BzOmxpc3QgMzYuMHB0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+MS48c3Bhbg0Kc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPs/QzsTA xdLFIM/QzsTTytIsDQrP0M7Ix8LOxNHSws4gys7SztDOw84gwsDMIM3I18XD ziDNxSDR0s7I0iEgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8b2wgc3Rh cnQ9MiB0eXBlPTE+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQogICAgIG1zby1saXN0OmwxIGxldmVsMSBsZm81O3RhYi1zdG9wczps aXN0IDM2LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCiAgICAgMTAu MHB0Jz7P0M7EwMXSxSDP0M7E08rSLCDS0MDN0c/O0NLI0M7CysAgys7SztDO w84gwsDMIM3I18XDziDNxSDR0s7I0iEgPG86cD48L286cD48L3NwYW4+PC9s aT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAgICAg bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzU7dGFiLXN0b3BzOmxpc3QgMzYuMHB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KICAgICAxMC4wcHQnPs/QzsTA xdLFIM/QzsTTytIsINDFysvAzMAgys7SztDOw84gwsDMIM3I18XDziDNxSDR 0s7I0iEgPG86cD48L286cD48L3NwYW4+PC9saT4NCiA8bGkgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzU7dGFiLXN0b3BzOmxpc3QgMzYuMHB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KICAgICAxMC4wcHQnPsjRz87L3MfTxdLFINHIy9MgyM3SxdDN xdLAIMggTVVMVEktTEVWRUwgTUFSS0VUSU5HISA8bzpwPjwvbzpwPjwvc3Bh bj48L2xpPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K ICAgICBtc28tbGlzdDpsMSBsZXZlbDEgbGZvNTt0YWItc3RvcHM6bGlzdCAz Ni4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQogICAgIDEwLjBwdCc+ wsDYxckgxcTIzdHSwsXNzc7JIMLbxMDXxckgytDOzMUgzcDXwMvczc7JIMjN wsXR0sjWyMggMjAsLSBVU0QNCiAgICAg38LL38XS0d8g0s7L3MrOIMLA2MUg wtDFzN8hIDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+DQogPGxpIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwxIGxldmVs MSBsZm81O3RhYi1zdG9wczpsaXN0IDM2LjBwdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCiAgICAgMTAuMHB0Jz7CxdHcIMfA0MDBztLOyiDKztLO0NvJ IMLbIM/Oy9PXyNLFIN/Cy9/F0tHfINfI0dLOySDP0MjB28vc3iEgPG86cD48 L286cD48L3NwYW4+PC9saT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzU7dGFiLXN0 b3BzOmxpc3QgMzYuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KICAg ICAxMC4wcHQnPt3SwCDP0M7D0MDMzMAgzcDC0cXDxMAgyMfMxc3I0iDCwNjT IMbIx83cISA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPg0KPC9vbD4NCg0KPHA+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsICBDeXIiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4qKioqKg0Kzs/b0iDE0NPDyNUg KioqKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz7d8uAg7/Du4/Dg7OzgIOTl6fHy4vPl8iwg 7e4g4vsg5O7r5u37IPLu9+3uDQro8e/u6+3/8vwg6O3x8vDz6vbo6CEgw8vA ws3OxSDNxSDPzszF2cDJ0sUgwsDYxSDIzN8gzcAgxNDTw9PeIM/Ox8jWyN4s IN3Szg0KzsHOycTF0tHfIMLAzCDBzsvc2M7JIM/O0sXQxckgxMXNxcMsIN3S ziDP0M7R0s4gzcUgxMXJ0dLC08XSISEhIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPt8gLSDw 5eDr/O3u5SDk7urg5+Dy5ev88fLi7iDw4OHu8u7x7+7x7uHt7vHy6A0K/fLu 4+4g4ejn7eXx4C4g3fLuIOTl6fHy4ujy5ev87e4g7/Dl4u7x9e7k7eD/IOLu 5+zu5u3u8fL8LCDy4Oog8OXg6/zt7iDoIOvl4+ruDQrn4PDg4e7y4PL8IOTl 7fzj6CDxIOzo7ejs4Ov87fvsIOLq6+Dk7uwuIMXx6+gg8OX46PLl8fwg/fLu IO/u7/Du4e7i4PL8LA0K7/Do5OXw5uji4Ony5fH8IOjt8fLw8+r26Okg7/Du 4/Dg7Oz7IOgg4fPk5fLlIO3gIOvz9/jl6SDk7vDu4+Ug6iD06O3g7fHu4u7p DQrt5efg4ujx6Ozu8fLoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwgIEN5ciI7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1V Uyc+U3RldmVuIEJhcmRmaWVsZCwgUG9ydGxhbmQsIE9SIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFs aWduOmNlbnRlcic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseToiQXJpYWwgIEN5ciInPioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPt3y4CDv8O7j8ODs7OAg5OXp8fLi6PLl6/zt7iDk5enx8uLz 5fIuIMbo4vMNCu3lIOIgwOzl8Ojq5Swg4CDiIMXi8O7v5SDoIPHt4Pfg6+Ag /yDh7v/r8f8sIO3l4fvrIPPi5fDl7Swg5OXp8fLi6PLl6/zt7iDr6CD98u4N CuTl6fHy4vPl8iwg4CDv7vLu7PMsIO3lIO7y7e7x6Ovx/yDqIP3y7uzzIPHl 8Pzl5+3uLiDAIO/u8u7sIPHq4Ofg6yDx5eHlOg0KJnF1b3Q7wCDv7vfl7PMg 7eXyPyZxdW90Oy4g0e7n5ODrIOru+OXr5eosIO/u7+7r7ejrIOXj7iAsIOgg 8eTl6+DrIO/l8OXi7uQsDQrn4Org5+DiIPHl4eUg9+Xy+/DlIFJlcG9ydHku IMIg8uX35e3o6CA1LfUg5O3l6SDv7uvz9+jrIOj1IOLx5fUg7+4gPC9zcGFu PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwgIEN5ciInPmUtbWFpbC4gPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+xO7r/PjlIOLx 5ePuIO/w6Pjr7vH8IObk4PL8IFJlcG9ydCAjNC4gze4g/fLuDQroIO/u7f/y 7e4sIOLl5Pwg8yDv8O7k4OL24CD98u7j7iwg7+7x6+Xk7eXj7iDz8O7i7f8s IPL78f/36CDn4Org5+7iLiDC8eUg8eTl6+DrDQry7vft7iDv7iDo7fHy8PPq 9ujoICj38u7h+yDh+/L8IPPi5fDl7e377Cwg5fHr6CD98u4g5OXr7iDt5SDn 4PDg4e7y4OXyLCDy7iD98u4NCu3lIO/w6Pfo7eAg7O7l6SDu+Ojh6ugpIOgg 5uTg6y4g3yDi7ejs4PLl6/zt7iDv8O736PLg6yDi8eUg7+7r8/fl7e375Q0K 8PPq7uLu5PHy4uAsIOAg6u7j5OAg8+ft4OssIOrg6iDi8eUg7eDk7iDk5evg 8vwsIO3g9+DrIPHi7ukg4ejn7eXxLiDfIOjx6uDrDQrg5PDl8eAg4uXn5OUg 6CDx5OXr4Osg8eXh5SDk6+jt7fvpIPHv6PHu6iAo7O3lIP3y7iDh++vuIOTl 6fHy4ujy5ev87e4NCujt8uXw5fHt7iwg/fLuIOH76+4g6uDqIO3u4u7lIPXu 4eHoLCDoIP8g7eUg7O7jIO3o9+Xj7iDv7vLl8P/y/CksIOrg6g0K7eXt7vDs 4Ov87fvpIP8g7eD34Osg7+7x++vg8vwgZS1tYWlsIOv+5P/sIOIg9uXr7uwg 8eLl8uUuIMTl6+DrIP8g/fLuDQrv7vHy7v/t7e4sIOgg6uDm5PvpIOTl7fwg 6u7t8vDu6+jw7uLg6yDx4u7pIO/u9/Lu4vvpIP/56Oog6CDq7vjl6+XqLiDP 8Ojs5fDt7g0K9+Xw5ecg5OXt/CDt4Pfg6+gg7/Do9e7k6PL8IOfg6uDn+y4g xO4g8ej1IO/u8CDv7uzt/iDy7vIg7O7s5e3yLCDq7uPk4A0K7uHt4PDz5ujr IO/l8OL76SDn4Org5y4gzeXq7vLu8O7lIOLw5ez/PC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsICBD eXIiJz4gPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7/ IO/w7vHy7iDx8u7/6w0K6CDt5SDs7uMg5OLo4+Dy/PH/OiAmcXVvdDvd8u4g 8ODh7vLg5fIhIN3y4CD48vPq4CDn4PDg4e7y4OvgIOzg8vwg5eUNCvLg6iEm cXVvdDsuIM/w7vjzIO/w7vnl7ej/IOfgIOL78ODm5e3o5Swg7e4g3yDh++sg 7vfl7fwg8ffg8fLr6OIsIOgg7eD34OsNCu/u8fvr4PL8IOX55SDh7uv8+OUg ZS1tYWlsIO/u/+Lo6/H/IPHo6/zt5en46Okg8fLo7PPrIOog8ODh7vLlLiDN 4CDx6+Xk8/756OkNCuTl7fwgLSDv8/Hy7ukg//no6iDoIPHt7uLgIP88L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 DQoiQXJpYWwgIEN5ciInPiA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPu/u5PPs4OssIPfy7iD98u4g7eUg4fPk5fINCvDg4e7y4PL8 LCDt7iDu6uDn4Ovu8fwg7eDu4e7w7vIuIM3gIPHr5eTz/vno6SDk5e38IP8g 7+7r8/fo6yAzIOfg6uDn4Cwg4iDy7vIg5uUNCuzu7OXt8iD/IO/u8evg6yDr /uT/7CDo9SByZXBvcnR5LCD38u7h+yDs7uPr6CDy7ublIOH78fLw7iDn4PDg 4e7y4PL8IOTl7fzj6A0KKOTr/yDx5eH/IOgg5Ov/IOzl7f8pLiDH4CDk4uUg 7eXk5evoLCDq4Obk++kg5OXt/CD/IPHo5OXrIO/w6Ozl8O3uIDMwIOzo7fPy IPMNCuru7O/8/vLl8OAg6CDv7vH76+DrIOfg6uDn+y4gwiDy5ffl7ejoIOTi 8/Ug7eXk5ev8IP8g7+7r8/fo6yAyOSDn4Org5+7iIO3gDQpSZXBvcnQgIzEu IM/u8u7sIOfg6uDn+yDx8uDr6CDv8Oj17uTo8vwg9+D55SDoIOH78fLw5eUs IOrg5uTz/iDt5eTl6/4g/yDv7uvz9+DrDQru6u7r7iDx8uAg5+Dq4Ofu4iwg YSDk5e384+gg4vHlIO/u8fLz7+Dr6CDt4CDs7ukg8ffl8i4gwiD25evu7CD/ IOfg8ODh7vLg6w0K7uru6+4gNjQuMDAwLC0gVVNELiDCPC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCAg Q3lyIic+DQo8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn Pt3SziDNxSDCzsfMzsbNziDB28vOIM/OwsXQyNLcISDN4CDv8O746+7pDQrt 5eTl6+Ug/yDq8+/o6yDx5eHlIO3u4vP+IPLg9+rzIOgg/fLuIOHr4OPu5ODw /yDv8O7j8ODs7OUuIMXx6+gg6CDy5e/l8Pwgwvsg7eUNCuft4OXy5Swg9/Lu IOTl6+Dy/Cwg8uDqIP8gwuDsIOPu4u7w/iA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7PX85f z1/QX85fwV/TX8lf0l/FIOgg7eUg7+7m4Ovl5fLlLiDd8u4g4uD4DQr44O3x LCDl8evoIOXj7iDz7/Px8ujy5Swg8uDqIOHz5OXy5SDm4Ovl8vwg7uEg/fLu 7CDk7iDq7u324CDm6Oft6CE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7NLiDQ5eHw7uIsINDu 8fHo/y48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRl ciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7M5e3/IOfu4vPyIE1pdGNoZWxs IGEg7O7/IObl7eAgSm9keSwg5uji5ewg4g0K1+jq4OPuLiDfIOHz9ePg6/Ll 8CDiIO7k7e7pIODs5fDo6uDt8eru6SD06PDs5SDoIOfg8ODh4PL74uD+IO3g IObo5+38DQrk7vHy4PLu9+3uIOTl7eXjLiDK7uPk4CD/IO/u6/P36Osg/fLu 8iBlLW1haWwsIP8g4fvrIOfu6yDt4CDm5e3zIOjnLefgDQrv7uvz9+Xt6P8g JnF1b3Q7anVuayBtYWlsJnF1b3Q7ICjw5err4Ozt++Ug6+jx8vssIOgg8i7k Li4sIOHl5yDv7ubl6+Dt6P8pLiDfDQrv7vHs5f/r8f8g7eDkIO/w5eTr7ubl 7ejl7Cwg/yDn7eDrLCD38u4g/fLuIO3lIOHz5OXyIOTl6fHy4u7i4PL8LiBK b2R5IOzl7f8NCuDh8e7r/vLt7iDo4+3u8Ojw7uLg6+Ag6CDt4Pfg6+Ag/fLo 7CDn4O3o7ODy/PH/LiDfIPjz8ujrIO3g5CDt5ekg6CDh++sg4+7y7uINCu/w 7ujn7eXx8ugg6Ofi5fHy7fP+IPTw4OfzICZxdW90O8Lo5Oj4/Cwg/yDm5SDy 5eHlIOPu4u7w6OssIPfy7iD98u4g7eUg4fPk5fINCuTl6fHy4u7i4PL8ISZx dW90OyDN7iDx7OX/6+jx/CDv7vLu7CDt4OTuIOzt7ukhISEgx+AgNDUg5O3l 6SDu7eAg7+7r8/fo6+ANCjQ3LjIwMCwtIFVTRC4g3yDh++sg4iD47urlISEh IN8g4fvrIPPi5fDl7Swg9/LuIP3y7iDt5SDk5enx8uLz5fIsIGEg/fLuIOH7 6+ANCu3l7/Dg4uTgISEhIN8g7/Do8e7l5Ojt6Ovx/yDqIEpvZHksIOTuIO/l 7fHo6CDs7eUg7vHy4OLg6+7x/CDx5ez8IOvl8iwgYSD98uANCu/w7uPw4Ozs 4CDi5fDt8+vgIOzt5SDm5evg7ejlIPDg4e7y4PL8LCDv7vLu7PMg9/LuIP8g 4ujk5esg8eLu6CDw5efz6/zy4PL7ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHA+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQXJpYWwgIEN5ciI7DQptc28tYW5zaS1sYW5ndWFn ZTpFTi1VUyc+TWl0Y2hlbGwgV29sZiwgTUQsIENoaWNhZ28sIElMLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0 ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LWZhbWlseToiQXJpYWwgIEN5ciInPioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPsPr4OLt++wg5O7i7uTu7CD98u7j7iDv6PH87OAg /+Lr/+Xy8f8g8u4sDQr38u7h+yDz4eXk6Osg4uDxLCD38u4g/fLuIPfl8fLt 4P8sIOvl4+Dr/O3g/ywg7/Do4fvr/O3g/yDx6PHy5ezgIOTr/w0K5+Dw4OHg 8vvi4O3o/yDh7uv8+Oj1IOTl7eXjIOfgIOru8O7y6u7lIOLw5ez/LiDfIPLu 6/zq7iDv7u/w7uHu4uDrLCD38u7h+w0K8+ft4PL8LCD38u4g7O7m7e4g7+7r 8/fo8vwg4ufg7OXtIOfgIOzo7ejs4Ov87fvpIOLq6+DkIOgg8fLg8ODt6OUu IMog7O7l7PMNCvPk6OLr5e3o/iD/IO/u6/P36OsgMy40NzAsLSBVU0Qg5+Ag 7+Xw4vv1IDE0IOTt5ekg4CDu8fLg6/zt++Ug5OXt/OPoIOLx5SDl+eUNCu/w 6PXu5P/yISEhPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCAgQ3lyIjsNCm1zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz5DaGFy bGVzIE1vcnJpcywgRXNxLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFs ICBDeXIiJz4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7S4Oog6uDq IP8g7eUg/+Lr//7x/CDy6O/u7CDg5+Dw8u3u4+4g6OPw7urgLA0K7/Du+Ovu IO3l8eru6/zq7iDt5eTl6/wsIO/l8OXkIPLl7CDq4Oog/yDw5fjo6yDv7u/w 7uHu4uDy/C4g3yDv8Oj45esg6iDi++Lu5PMsDQr38u4gMjAsLSBVU0Qg/fLu IPLg6u7pIOzg6+Xt/Oro6SDi6uvg5Cwg9/LuIO/w7vHy7iDo8err/vfl7e4s IPfy7uH7IP8g7eUg7eD45esNCvXu8v8g4fsg7eXx6u7r/OruIOfg6uDn7uIs IOTr/yDi7ufi8ODy4CDx4u7l6SDo7eLl8fLo9ujoLiDB7ublLCDq4Oog/yDh ++sNCvPk6OLr5e0sIOru4+TgIPPi6OTl6yDx4u7pIOru+OXr5eosIO/u6+37 6SDn4Org5+7iISDH4CDt5eru8u7w7uUg4vDl7P8g6PUNCu/u8fLz7+jr7iDx 8u7r/OruLCD38u4g/yDh++sg4vvt8+bk5e08L3NwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwgIEN5ciIn PiA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPuLn//L8 IO7y7/Px6iDt4A0K8ODh7vLlLiDH4CD98u7yIOPu5CD/IOfg8ODh7vLg6yDh 7uv8+OUg5OXt5eMsIPfl7CDn4CDv7vHr5eTt6OUg5OXx//L8IOvl8iENCtHg 7O7lIO/w5erw4PHt7uUg4iDy7uwsIPfy7iDt5eLg5u3uIOPk5SDr/uToIObo 4vPyLiDd8u4g7/Du8fLuIC0g8eDs4P8g6/P3+OD/DQro7eLl8fLo9uj/IPEg 7vfl7fwg4fvx8vD77CDu4e7w7vLu7C48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiOw0KbXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVMnPlBhaWdlIFdpbGxpcywgRGVzIE1vaW5lcywgSUEuPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBhbGlnbj1jZW50ZXIgc3R5bGU9J3Rl eHQtYWxpZ246Y2VudGVyJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OiJBcmlhbCAgQ3lyIic+KioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+zuTo7SDw4Ocg/yDz5uUg7+7r8/fo6yD98vMg7/Du 4/Dg7OzzLiDfIOXlDQrz5ODr6OssIO3uIO/u8u7sIP8g7+7k8+zg6yDuIPLu 7Cwg9/LuIPHy7ujr7iDh+yDv7u/w7uHu4uDy/C4gyu7t5fft7iwg/yDt5SDo 7OXrDQrv8OXk8fLg4uvl7ej/IOru4+TgIO/u6/P38yDu7//y/CDv7uTu4e3u 5SDv8OXk6+7m5e3o5Swg7+798u7s8yD/IOH76yDi++3z5uTl7Q0K5uTg8vws IO/u6uAg7O3lIOry7i3t6OHz5Pwg7eUg7/Do+Ovl8iDn4O3u4u4uIM/w7vjr 7iAxMSDs5fH/9uXiIOru4+TgIP8g8e3u4uANCu/u6/P36Osg5ePuLiDS5e/l 8Pwg/yDl4+4g7eUg8e7y8PNsISEhINEg7+Xw4u7j7iDw4OfgIP8g7+7r8/fo 6yA0MS4wMDAsLQ0KVVNEISEhITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHA+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwgIEN5ciI7DQptc28tYW5zaS1sYW5ndWFnZTpF Ti1VUyc+VmlvbGV0IFdpbHNvbiwgSm9obnN0b3duLCBQQS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1h bGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4qKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz7T9+Dx8uLz/iDiIP3y7ukg7/Du4/Dg7OzlIPPmIOIg8vDl 8ujpIPDg5y4gzPsNCvP46+gg8SDw4OHu8vssIOAg9+Xw5ecg7eXq7vLu8O7l IOLw5ez/IOrz7+jr6CDx5eHlIOTu7CDt4CDv6//m5SDoIOHz5OXsIObo8vwg 7eUNCuTz7OD/IO4g5OXt/OPg9S4gxfHy/CDy7uv86u4g7uTo7SDx7+7x7uEg 7eAgx+Xs6+UsIPfy7uH7IOfg8fLg4ujy/CDo8e/u6+3/8vzx/w0K8eLu6CDv 6+Dt+yAtIN3SziDNwNfA0twgwtvPzsvN39LcIMjVLiDQ4OToIMHu4+AsIO3l IO/w7u/z8fLo8uUg/fLzPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwgIEN5ciInPiA8L3NwYW4+PHNw YW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7HzsvO0tPeIOLu5+zu5u7x 8vwhISEgzO3u4+4g8ffg8fL8/yDoIO/w6P/y7e7pIPLw4PL7DQrk5e3l4yE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBD eXIiOw0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPktlcnJ5IEZvcmQsIENl bnRlcnBvcnQsIE5ZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgYWxp Z249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwgIEN5 ciInPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsfAysDGyNLFDQrRxcHFIFJF UE9SVFkgz9DfzM4g0cXJ18DRIMggwtHSwM3CwMnSxSDNwCDP09LcIMogzcXH wMLI0cjMztHSyCwg0cLOwc7ExSDIDQrR18DR0tzeISA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGln bjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7Sxc/F 0NwNCsLQxczfIM3AIMTO0dLIxsXNyMUgzsPQzszN29Ug0MXH08vc0sDSzsIh ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsICBDeXIiJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz7PzsbAy9PJ0dLAIMLNyMzAzcjFOiDF8evoIOLg 7CDt8+bl7SDx7uLl8iDq4OoNCu3g9+Dy/CDv8OXk7/Do7ejs4PL8LCDn4PDl 4+jx8vDo8O7i4PL8IPLu8OPu4u7lIO3g5+Lg7ejlLCDt4PP36PL88f8g7+vg 8ujy/A0K7eDr7uPoLCDq7u3y4Ory6PDz6fLlIPEg7vLk5evu7CDv8OXk7/Do 7ejs4PLl6/zx8uLgLiDC4PjoIPDl5/Pr/PLg8vsg5+Di6PH/8g0K8u7r/Oru IO7yIMLg8Swg7vIgwuD45ekg8ODh7vL7LiDd8u4g7+jx/OzuIO3lIOPg8ODt 8ujw8+XyIO3o6uDq6PUg5O717uTu4iDoDQrt6Org6uj1IPDl5/Pr/PLg8u7i LCDt7iDi8eUg8fPs7Psg6CDw5efz6/zy4PL7LCDz6uDn4O3t++Ug4iD98u7s IOTu6vPs5e3y5SAtLQ0K1MDK0i48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCAgQ3lyIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE4LjBwdCc+ISEhwtHFDQrHwMLI 0cjSINLOy9zKziDO0iDCwNEhISE8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KDQo8cCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVy Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+wc7L3NjOw84N CtPRz8XVwCEhITxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQoNCjxwPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCAgQ3lyIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+UFMuIMTl6fHy4ujy5ev8 7e4g/fLuIO3g9+Dr7iDk5enx8uLu4uDy/CEhITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPtDu 7ODtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvYm9k eT4NCg0KPC9odG1sPg0K --====================54535pksmiu====-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Sep 5 21:30: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8A3DD37B423 for ; Tue, 5 Sep 2000 21:30:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA28492; Tue, 5 Sep 2000 21:30:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 236FB37B423; Tue, 5 Sep 2000 21:25:42 -0700 (PDT) Message-Id: <20000906042542.236FB37B423@hub.freebsd.org> Date: Tue, 5 Sep 2000 21:25:42 -0700 (PDT) From: edmarw@yahoo.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: i386/21072: Unable to install. Can't write disklabel to ad0 (ata disk0, udma33) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21072 >Category: i386 >Synopsis: Unable to install. Can't write disklabel to ad0 (ata disk0, udma33) >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 05 21:30:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Edmar Wiggers >Release: 4.0 >Organization: Personal >Environment: Can't run uname -a. Can't even install! The machine is a Pentium III 500MHz,Asus Motherboard,10GB IDE Hard disk,128MB RAM,IDE CD-ROM. >Description: After booting from Installation CD-ROM, going through everything (editing slices and partitions on the disk, selecting a distribution, etc.), the system hangs while writing the partition/slice table to the disk. After a while it gives up, giving error messages (couldn't activate swap, etc.) On virtual console 1 (alt-f2), I see messages like ad0: WRITE command timeout - resetting ata0: resetting devices - done ad0: WRITE command timeout - resetting ata0: resetting devices - done ... and so on The disk is OK, Win98 installs hassle-free. >How-To-Repeat: Just try installing it in a similar machine... >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 0:20: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 30A1237B423 for ; Wed, 6 Sep 2000 00:20:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA55625; Wed, 6 Sep 2000 00:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id BADB937B42C for ; Wed, 6 Sep 2000 00:18:18 -0700 (PDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e867IHo14401 for ; Wed, 6 Sep 2000 09:18:17 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e867IHh26813 for ; Wed, 6 Sep 2000 09:18:17 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.11.0/8.11.0) id e867IHo37512 for FreeBSD-gnats-submit@freebsd.org; Wed, 6 Sep 2000 09:18:17 +0200 (CEST) Message-Id: <200009060718.e867IGj45601@curry.mchp.siemens.de> Date: Wed, 6 Sep 2000 09:18:16 +0200 (CEST) From: Andre Albsmeier To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/21073: PCM sound driver silently accepts improper parameters of SNDCTL_DSP_SETFMT Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21073 >Category: kern >Synopsis: PCM sound driver silently accepts improper parameters of SNDCTL_DSP_SETFMT >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 00:20:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Andre Albsmeier >Release: FreeBSD 4.1-STABLE i386 >Organization: >Environment: 4.1-STABLE machine using the pcm driver on an AB AWE64: andre@bali:~>cat /dev/sndstat FreeBSD Audio Driver (newpcm) Sep 2 2000 10:33:49 Installed devices: pcm0: at io 0x220 irq 5 drq 1:5 (1p/1r channels duplex) >Description: When setting a sound format with SNDCTL_DSP_SETFMT, the system call does not tell us if an improper format was set. >How-To-Repeat: The following program demonstrates the error: #include #include #include #include #include #include #include #include #include int main( ) { int bits; int fd; if( (fd = open("/dev/dsp", O_RDONLY)) < 0 ) { fprintf( stderr, "Can't open /dev/dsp for read\n" ); exit( 1 ); } if( ioctl(fd, SNDCTL_DSP_GETFMTS, &bits) < 0 ) { fprintf( stderr, "SNDCTL_DSP_GETFMTS error\n" ); exit( 1 ); } printf( "GETFMTS: 0x%X\n", bits ); bits = 0x10; if( ioctl(fd, SNDCTL_DSP_SETFMT, &bits) < 0 ) { fprintf( stderr, "SNDCTL_DSP_SETFMT error\n" ); exit( 1 ); } printf( "After setting 0x10 with SETFMT: 0x%X\n", bits ); return( 0 ); } andre@bali:~>./sndcheck GETFMTS: 0x10000008 After setting 0x10 with SETFMT: 0x10 So the AWE64 only supports AFMT_U8 in STEREO. Now we set AFMT_S16_LE but there is no error returned neither was the bits variable modified as it was the case in voxware. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 0:40:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DC3E537B446 for ; Wed, 6 Sep 2000 00:40:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA58236; Wed, 6 Sep 2000 00:40:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from scan1.fhg.de (scan1.fhg.de [153.96.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 88AD237B424 for ; Wed, 6 Sep 2000 00:30:11 -0700 (PDT) Received: from scan1.fhg.de (localhost [127.0.0.1]) by scan1.fhg.de (8.9.3/8.9.3) with ESMTP id JAA14517 for ; Wed, 6 Sep 2000 09:30:09 +0200 (MET DST) Received: from iml2.iml.fhg.de (iml2.iml.fhg.de [153.96.188.3]) by scan1.fhg.de (8.9.3/8.9.3) with ESMTP id JAA14511 for ; Wed, 6 Sep 2000 09:30:09 +0200 (MET DST) Received: from antivirus.iml.fhg.de (antivirus.iml.fhg.de [153.96.189.119]) by iml2.iml.fhg.de (8.9.3/8.9.3) with ESMTP id JAA28867 for ; Wed, 6 Sep 2000 09:30:08 +0200 (MET DST) Received: (from udo@localhost) by antivirus.iml.fhg.de (8.11.0/8.11.0) id e867U6734280; Wed, 6 Sep 2000 09:30:06 +0200 (CEST) (envelope-from udo) Message-Id: <200009060730.e867U6734280@antivirus.iml.fhg.de> Date: Wed, 6 Sep 2000 09:30:06 +0200 (CEST) From: Udo Erdelhoff To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21074: chkgrp vs group(5) inconsistency Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21074 >Category: bin >Synopsis: chkgrp vs group(5) inconsistency >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 00:40:03 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Udo Erdelhoff >Release: FreeBSD 4.1-STABLE i386 >Organization: Fraunhofer IML, Dortmund >Environment: 4.1-stable, last cvsup 05-SEP-2000 >Description: group(5) contains the following information ``YP/NIS INTERACTION The /etc/group file can be configured to enable the YP/NIS group database. An entry whose name field consists of a plus sign (`+') fol- lowed by a group name, will be replaced internally to the C library with the YP/NIS group entry for the named group. An entry whose name field consists of a single plus sign with no group name following, will be re- placed with the entire YP/NIS ``group.byname'' map.'' My /etc/group contains an entry that consists of a single plus sign and things work as expected (i.e. the whole YP/NIS map is imported). grpchk doesn't like this entry at all: chkgrp: /etc/group: line 23: missing field(s) >How-To-Repeat: Add a line with a single plus sign to the end of your /etc/groups file and run chkgroup. >Fix: chkgrp should be changed to accept NIS entries. Until then, the problem should be mentioned in chkgrp(8): --- chkgrp.8.orig Wed Sep 6 09:21:22 2000 +++ chkgrp.8 Wed Sep 6 09:29:22 2000 @@ -82,3 +82,8 @@ .Sh BUGS Should check fields more thoroughly for allowed/disallowed characters, and the range of the group ID. +The +.Nm +utility will report errors for valid NIS-related entries, +especially lines containing a single plus character +.Po import whole map Pc . >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 1: 0: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9B84937B42C for ; Wed, 6 Sep 2000 01:00:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id BAA61010; Wed, 6 Sep 2000 01:00:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 1259537B43E; Wed, 6 Sep 2000 00:50:48 -0700 (PDT) Message-Id: <20000906075048.1259537B43E@hub.freebsd.org> Date: Wed, 6 Sep 2000 00:50:48 -0700 (PDT) From: lan@kru.ru To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: bin/21075: top: can't allocate sufficient memory Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21075 >Category: bin >Synopsis: top: can't allocate sufficient memory >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 01:00:04 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Andrey Lobov >Release: 4.1-STABLE, 4.0-STABLE, 4.3-STABLE >Organization: KuzbassRazrezUgol >Environment: FreeBSD lan.xxx.tu 4.1-STABLE FreeBSD 4.1-STABLE #0: Sat Aug 12 11:14:35 KRAST 2000 lan@lan.xxx.ru:/usr/src/sys/compile/LAN i386 FreeBSD paul.yyy.ru 4.0-STABLE FreeBSD 4.0-STABLE #3: Tue Jul 18 18:18:09 GMT 2000 paul@paul.yyy.ru:/usr/src/sys/compile/PAUL i386 FreeBSD proxy.zzz.ru 3.4-STABLE FreeBSD 3.4-STABLE #1: Fri Apr 21 12:10:45 KRAST 2000 lan@proxy.zzz.ru:/usr/src/sys/compile/LAN i386 >Description: If to run /usr/bin/top in any Xterminal (kvt, konsole, xterm, Eterm) and a size of the window of the terminal less or it is equal to six strings on a vertical we receive error messages: top: can't allocate sufficient memory. At the greater size - without any errors. >How-To-Repeat: Reduce a vertical size of the window of the Xterminal up to six strings (lines) and start /usr/bin/top. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 1:10: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 41C7437B422 for ; Wed, 6 Sep 2000 01:10:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id BAA63357; Wed, 6 Sep 2000 01:10:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 01:10:04 -0700 (PDT) Message-Id: <200009060810.BAA63357@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: bin/21017: mtree's "no such file" message at job's end Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21017; it has been noted by GNATS. From: Sheldon Hearn To: Gerhard Sittig Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/21017: mtree's "no such file" message at job's end Date: Wed, 06 Sep 2000 10:00:39 +0200 On Tue, 05 Sep 2000 18:28:33 +0200, Gerhard Sittig wrote: > Am I really alone in seeing this erroneous message or am I one of > very few people using mtree for more than a "make hierarchy"? I > wouldn't think so. At least I hoped to have some users jumping > in saying "me too, preferably under _these_ conditions" ... I'm not sure of that. You might try drawing people's attention to this PR on the freebsd-questions mailing list. Perhaps they've had reports of this there. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 2:46: 2 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id 4BC7337B422; Wed, 6 Sep 2000 02:45:58 -0700 (PDT) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.9.3/3.7Wpl2-2000/05/28) with ESMTP id SAA59553; Wed, 6 Sep 2000 18:45:56 +0900 (JST) To: sheldonh@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/21009: /etc/security make the system hangup In-Reply-To: <200009041333.GAA35296@freefall.freebsd.org> References: <200009041333.GAA35296@freefall.freebsd.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000906184556F.ishizuka@onion.ish.org> Date: Wed, 06 Sep 2000 18:45:56 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 45 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Synopsis: /etc/security make the system hangup > State-Changed-From-To: open->feedback > State-Changed-By: sheldonh > State-Changed-When: Mon Sep 4 06:32:11 PDT 2000 > State-Changed-Why: > > Please explain what "crashs system" means. Since the environment > you describe is hard to set up (especially given that you don't > define "too many files"), this will be easier to investigate > based on the actual error messages you see. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=21009 Hi, sheldonh-san. Thank you for your mail. There is no error messages. I can't login if it happens. There is no response from ping. Only Alt-F? is available, but after screen is switched by Alt-F?, I push return key and the login prompt will be scrolled up with no news messages. After I typed return key for 25 times, there is no messages on screen at all. There are 4 machines with hangup. The following is the output of 'df -ki' command. All machines are 4.1-RELEASE. Most of directories and files on the disk mounted on /www have about 5000 hard links, so there are more than 6,000,000 links, files or directories on each /www disks. The running time for /etc/security is about 1.5 or 2.5 hours on Pentium III/600 or Pentium II/400. The ccd0c and /dev/vinum/www are two 16GB or 20GB UDMA33 ata drives with striped. (1) /dev/ccd0c 17591175 1999479 14184402 12% 443610 3952932 10% /www (2) /dev/ccd0c 17072631 2645276 13061545 17% 448429 8096465 5% /www (3) /dev/vinum/www 17072515 353165 15353549 2% 119432 8425462 1% /www (4) /dev/ccd0c 17072631 2407959 13298862 15% 454757 8090137 5% /www -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 2:50: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 672D237B443 for ; Wed, 6 Sep 2000 02:50:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id CAA78536; Wed, 6 Sep 2000 02:50:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 02:50:04 -0700 (PDT) Message-Id: <200009060950.CAA78536@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Masachika ISHIZUKA Subject: Re: kern/21009: /etc/security make the system hangup Reply-To: Masachika ISHIZUKA Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21009; it has been noted by GNATS. From: Masachika ISHIZUKA To: sheldonh@freebsd.org Cc: freebsd-bugs@freebsd.org Subject: Re: kern/21009: /etc/security make the system hangup Date: Wed, 06 Sep 2000 18:45:56 +0900 > Synopsis: /etc/security make the system hangup > State-Changed-From-To: open->feedback > State-Changed-By: sheldonh > State-Changed-When: Mon Sep 4 06:32:11 PDT 2000 > State-Changed-Why: > > Please explain what "crashs system" means. Since the environment > you describe is hard to set up (especially given that you don't > define "too many files"), this will be easier to investigate > based on the actual error messages you see. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=21009 Hi, sheldonh-san. Thank you for your mail. There is no error messages. I can't login if it happens. There is no response from ping. Only Alt-F? is available, but after screen is switched by Alt-F?, I push return key and the login prompt will be scrolled up with no news messages. After I typed return key for 25 times, there is no messages on screen at all. There are 4 machines with hangup. The following is the output of 'df -ki' command. All machines are 4.1-RELEASE. Most of directories and files on the disk mounted on /www have about 5000 hard links, so there are more than 6,000,000 links, files or directories on each /www disks. The running time for /etc/security is about 1.5 or 2.5 hours on Pentium III/600 or Pentium II/400. The ccd0c and /dev/vinum/www are two 16GB or 20GB UDMA33 ata drives with striped. (1) /dev/ccd0c 17591175 1999479 14184402 12% 443610 3952932 10% /www (2) /dev/ccd0c 17072631 2645276 13061545 17% 448429 8096465 5% /www (3) /dev/vinum/www 17072515 353165 15353549 2% 119432 8425462 1% /www (4) /dev/ccd0c 17072631 2407959 13298862 15% 454757 8090137 5% /www -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 3:10: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B5D6837B424 for ; Wed, 6 Sep 2000 03:10:06 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA82813; Wed, 6 Sep 2000 03:10:06 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 03:10:06 -0700 (PDT) Message-Id: <200009061010.DAA82813@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: bin/21075: top: can't allocate sufficient memory Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21075; it has been noted by GNATS. From: Sheldon Hearn To: lan@kru.ru Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/21075: top: can't allocate sufficient memory Date: Wed, 06 Sep 2000 12:05:02 +0200 On Wed, 06 Sep 2000 00:50:48 MST, lan@kru.ru wrote: > >Number: 21075 > >Category: bin > >Synopsis: top: can't allocate sufficient memory This happens because top needs 7 lines for headers. display_resize() calculates that the number of lines available is -1 and returns this value. As it happens, display_init() interprets this -1 return value as a memory allocation error. I'm downloading top-3.5beta9 to see whether this problem is fixed in that version. As a work-around, you can use top's -b (batch mode) option. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 4: 0:10 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 72F2C37B424; Wed, 6 Sep 2000 04:00:09 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA89181; Wed, 6 Sep 2000 04:00:09 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 04:00:09 -0700 (PDT) From: Message-Id: <200009061100.EAA89181@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: bin/21075: top: can't allocate sufficient memory Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: top: can't allocate sufficient memory Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Wed Sep 6 03:58:56 PDT 2000 Responsible-Changed-Why: I'll manage this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=21075 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 4:18:12 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9C2C737B423; Wed, 6 Sep 2000 04:18:10 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA95442; Wed, 6 Sep 2000 04:18:10 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 04:18:10 -0700 (PDT) From: Message-Id: <200009061118.EAA95442@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, davidn@FreeBSD.org Subject: Re: bin/21074: chkgrp vs group(5) inconsistency Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: chkgrp vs group(5) inconsistency Responsible-Changed-From-To: freebsd-bugs->davidn Responsible-Changed-By: sheldonh Responsible-Changed-When: Wed Sep 6 04:17:52 PDT 2000 Responsible-Changed-Why: Let's see if we can get Mr Nugent to take a look at this. :-) http://www.freebsd.org/cgi/query-pr.cgi?pr=21074 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 4:19:49 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A20F237B422; Wed, 6 Sep 2000 04:19:47 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA95722; Wed, 6 Sep 2000 04:19:47 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 04:19:47 -0700 (PDT) From: Message-Id: <200009061119.EAA95722@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, cg@FreeBSD.org Subject: Re: kern/21073: PCM sound driver silently accepts improper parameters of SNDCTL_DSP_SETFMT Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: PCM sound driver silently accepts improper parameters of SNDCTL_DSP_SETFMT Responsible-Changed-From-To: freebsd-bugs->cg Responsible-Changed-By: sheldonh Responsible-Changed-When: Wed Sep 6 04:19:11 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 4:20: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BDF5C37B42C for ; Wed, 6 Sep 2000 04:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA95836; Wed, 6 Sep 2000 04:20:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 04:20:03 -0700 (PDT) Message-Id: <200009061120.EAA95836@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: kern/21009: /etc/security make the system hangup Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21009; it has been noted by GNATS. From: Sheldon Hearn To: Masachika ISHIZUKA Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/21009: /etc/security make the system hangup Date: Wed, 06 Sep 2000 13:15:33 +0200 On Wed, 06 Sep 2000 02:50:04 MST, Masachika ISHIZUKA wrote: > There are 4 machines with hangup. The following is the output of > 'df -ki' command. All machines are 4.1-RELEASE. Most of directories > and files on the disk mounted on /www have about 5000 hard links, > so there are more than 6,000,000 links, files or directories on each > /www disks. > The running time for /etc/security is about 1.5 or 2.5 hours on > Pentium III/600 or Pentium II/400. The ccd0c and /dev/vinum/www > are two 16GB or 20GB UDMA33 ata drives with striped. Could you stick a debugging kernel on one of those boxes and use DDB or remote kgdb to figure out what the kernel's stuck in? There are just two many variables here. Instructions that you might find helpful are available at: http://www.freebsd.org/handbook/kerneldebug.html Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 4:24:21 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2C70737B43E; Wed, 6 Sep 2000 04:24:20 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA96523; Wed, 6 Sep 2000 04:24:20 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 04:24:20 -0700 (PDT) From: Message-Id: <200009061124.EAA96523@freefall.freebsd.org> To: edmarw@yahoo.com, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: i386/21072: Unable to install. Can't write disklabel to ad0 (ata disk0, udma33) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Unable to install. Can't write disklabel to ad0 (ata disk0, udma33) State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Wed Sep 6 04:21:42 PDT 2000 State-Changed-Why: Actually, lots of people _have_ installed successfully using several "similar machine" configurations. However, your description of your hardware is very vague. Can you list exactly which chipset you have for your IDE controller on the motherboard? Also of interest is the exact model of your hard drive and of your CDROM device. It would probably also be interesting to hear which IDE channel you have your hard drive on, and which channel you have your CDROM on, and whether these devices are jumpered as masters, slaves, or cable-select. http://www.freebsd.org/cgi/query-pr.cgi?pr=21072 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 5: 0: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D082137B424 for ; Wed, 6 Sep 2000 05:00:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA01320; Wed, 6 Sep 2000 05:00:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 32F0337B424; Wed, 6 Sep 2000 04:50:24 -0700 (PDT) Message-Id: <20000906115024.32F0337B424@hub.freebsd.org> Date: Wed, 6 Sep 2000 04:50:24 -0700 (PDT) From: jim@thehousleys.net To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: bin/21078: rtsol does not work on USB interface aue0 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21078 >Category: bin >Synopsis: rtsol does not work on USB interface aue0 >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 05:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: James Housley >Release: 4.1-STABLE >Organization: The Housleys dot Net >Environment: FreeBSD vaio.ipv6.thehousleys.net 4.1-STABLE FreeBSD 4.1-STABLE #6: Mon Sep 4 22:56:36 EDT 2000 root@vaio.ipv6.thehousleys.net:/usr/src4/sys/compile/VAIOKERNEL i386 >Description: rtsol aue0 does not configure the interface. All the other machines on my network, PIC NICs and PCMCIA, all are able to be configured by rtsol except the USB NIC. All are running from the same buildworld. root@vaio:~ {2} rtsol -d aue0 checking if aue0 is ready... aue0 is ready send RS on aue0, whose state is 2 send RS on aue0, whose state is 2 send RS on aue0, whose state is 2 No answer after sending 3 RSs stop timer for aue0 there is no timer >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 5:39:26 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2925E37B422; Wed, 6 Sep 2000 05:39:24 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA08226; Wed, 6 Sep 2000 05:39:24 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 05:39:24 -0700 (PDT) From: Message-Id: <200009061239.FAA08226@freefall.freebsd.org> To: MillikenDB@schofield.army.mil, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, gibbs@FreeBSD.org Subject: Re: i386/21071: SCSI Controller Not Detected When Attempting Install FreeBSD OS Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: SCSI Controller Not Detected When Attempting Install FreeBSD OS State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Wed Sep 6 04:28:17 PDT 2000 State-Changed-Why: The manual page for the ahc driver lists the 7890 as a supported controller. So I'd say that either your kernel doesn't have support for the ahc device compiled into it, or your controller has been "re-badged" in such a way as to make it unrecognizable. Could you try a pciconf -l on your box and send back the output? Also, the output of the dmesg command might be useful. Responsible-Changed-From-To: freebsd-bugs->gibbs Responsible-Changed-By: sheldonh Responsible-Changed-When: Wed Sep 6 04:28:17 PDT 2000 Responsible-Changed-Why: Over to the maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21071 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 5:52:14 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A790C37B43E; Wed, 6 Sep 2000 05:52:13 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA10155; Wed, 6 Sep 2000 05:52:13 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 05:52:13 -0700 (PDT) From: Message-Id: <200009061252.FAA10155@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, wpaul@FreeBSD.org Subject: Re: bin/21078: rtsol does not work on USB interface aue0 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: rtsol does not work on USB interface aue0 Responsible-Changed-From-To: freebsd-bugs->wpaul Responsible-Changed-By: sheldonh Responsible-Changed-When: Wed Sep 6 05:52:00 PDT 2000 Responsible-Changed-Why: Over to aue maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21078 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 5:52:31 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from radon.gryphonsoft.com (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id 61B9837B423; Wed, 6 Sep 2000 05:52:28 -0700 (PDT) Received: by radon.gryphonsoft.com (Postfix, from userid 1000) id 9AE32192C; Wed, 6 Sep 2000 07:50:14 -0500 (EST) Date: Wed, 6 Sep 2000 07:50:14 -0500 From: Will Andrews To: sheldonh@FreeBSD.ORG Cc: MillikenDB@schofield.army.mil, freebsd-bugs@FreeBSD.ORG, gibbs@FreeBSD.ORG Subject: Re: i386/21071: SCSI Controller Not Detected When Attempting Install FreeBSD OS Message-ID: <20000906075014.Z23702@radon.gryphonsoft.com> Reply-To: Will Andrews References: <200009061239.FAA08226@freefall.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: <200009061239.FAA08226@freefall.freebsd.org>; from sheldonh@FreeBSD.ORG on Wed, Sep 06, 2000 at 05:39:24AM -0700 X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 06, 2000 at 05:39:24AM -0700, sheldonh@FreeBSD.ORG wrote: > The manual page for the ahc driver lists the 7890 as > a supported controller. So I'd say that either your kernel For the record, my 4.1-STABLE machine (which has survived since 3.1-RELEASE), runs on this Adaptec AIC-7890 onboard SCSI chip..: <1 5001-0> (7:49:35) [will@radon ~]% dmesg | grep ahc ahc0: port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff irq 10 at device 14.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs da0 at ahc0 bus 0 target 0 lun 0 cd0 at ahc0 bus 0 target 1 lun 0 -- Will Andrews GCS/E/S @d- s+:+ a--- C++ UB++++$ P+ L- E--- W+ N-- !o ?K w--- O- M+ V- PS+ PE++ Y+ PGP+>+++ t++ 5 X+ R+ tv+ b++ DI+++ D+ G++ e>++++ h! r- y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 6: 2:41 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 78CA137B422; Wed, 6 Sep 2000 06:02:40 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA11468; Wed, 6 Sep 2000 06:02:40 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 06:02:40 -0700 (PDT) From: Message-Id: <200009061302.GAA11468@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, marcel@FreeBSD.org Subject: Re: misc/21070: default setting of ${SUP} in Makefile.inc1 doesn't work Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: default setting of ${SUP} in Makefile.inc1 doesn't work Responsible-Changed-From-To: freebsd-bugs->marcel Responsible-Changed-By: sheldonh Responsible-Changed-When: Wed Sep 6 05:58:18 PDT 2000 Responsible-Changed-Why: Marcel restricted the PATH in rev 1.232. The ideal solution here is for both bsd.port.mk and Makefile to include some other .mk file that provides a default definition of LOCALBASE. Then we can use ${LOCALBASE}/bin/cvsup as the default value for SUP. http://www.freebsd.org/cgi/query-pr.cgi?pr=21070 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 6: 5:59 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D254F37B42C; Wed, 6 Sep 2000 06:05:58 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA13319; Wed, 6 Sep 2000 06:05:58 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 06:05:58 -0700 (PDT) From: Message-Id: <200009061305.GAA13319@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, sheldonh@FreeBSD.org Subject: Re: bin/21068: Add ftp.no.freebsd.org to list of sysinstall(8) FTP servers Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Add ftp.no.freebsd.org to list of sysinstall(8) FTP servers Responsible-Changed-From-To: freebsd-bugs->sheldonh Responsible-Changed-By: sheldonh Responsible-Changed-When: Wed Sep 6 06:04:49 PDT 2000 Responsible-Changed-Why: Sure thing. http://www.freebsd.org/cgi/query-pr.cgi?pr=21068 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 7:13:16 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0617B37B422; Wed, 6 Sep 2000 07:13:15 -0700 (PDT) Received: (from bde@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA85753; Wed, 6 Sep 2000 07:13:15 -0700 (PDT) (envelope-from bde@FreeBSD.org) Date: Wed, 6 Sep 2000 07:13:15 -0700 (PDT) From: Message-Id: <200009061413.HAA85753@freefall.freebsd.org> To: marcs@znep.com, bde@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/4696: ping hangs on certain unresolvable hosts Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: ping hangs on certain unresolvable hosts State-Changed-From-To: closed->open State-Changed-By: bde State-Changed-When: Wed Sep 6 07:12:22 PDT 2000 State-Changed-Why: Closed in error. http://www.freebsd.org/cgi/query-pr.cgi?pr=4696 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 7:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 350C537B422 for ; Wed, 6 Sep 2000 07:20:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA86805; Wed, 6 Sep 2000 07:20:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 07:20:04 -0700 (PDT) Message-Id: <200009061420.HAA86805@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: bin/20974: securelevel not reset when going to single user mode Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20974; it has been noted by GNATS. From: Bruce Evans To: Sheldon Hearn Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/20974: securelevel not reset when going to single user mode Date: Thu, 7 Sep 2000 01:11:19 +1100 (EST) On Tue, 5 Sep 2000, Sheldon Hearn wrote: > On Tue, 05 Sep 2000 06:07:23 +1100, Bruce Evans wrote: > > > Some more updates are needed. > > As far as this PR is concerned, about the best improvement I can think > of for the securelevel misunderstanding is included below. I don't > think that the manual page is lacking right now, but this patch causes > it to state the situation explicitly. I meant something like the following: --- diff -c2 init.8~ init.8 *** init.8~ Thu Sep 7 01:04:21 2000 --- init.8 Thu Sep 7 01:06:54 2000 *************** *** 135,147 **** .El .Pp ! If the security level is initially -1, then .Nm leaves it unchanged. Otherwise, .Nm ! arranges to run the system in level 0 mode while single-user ! and in level 1 mode while multi-user. ! If level 2 mode is desired while running multi-user, ! it can be set while single-user, e.g., in the startup script .Pa /etc/rc , using --- 135,149 ---- .El .Pp ! If the security level is initially nonzero, then .Nm leaves it unchanged. Otherwise, .Nm ! raises the level to 1 before going multi-user for the first time. ! No process can reduce the level, so it will be at least 1 for ! subsequent operation, even on return to single-user. ! If a level higher than 1 is desired while running multi-user, ! it can be set while single-user for the first time, ! e.g., in the startup script .Pa /etc/rc , using --- Init no longer even attempts to lower the level, and the example of switching to level 2 rotted when we implemented level 3. Please improve my wording if possible. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 9:10: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8BBA537B43F for ; Wed, 6 Sep 2000 09:10:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA06146; Wed, 6 Sep 2000 09:10:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id E841B37B42C; Wed, 6 Sep 2000 09:00:51 -0700 (PDT) Message-Id: <20000906160051.E841B37B42C@hub.freebsd.org> Date: Wed, 6 Sep 2000 09:00:51 -0700 (PDT) From: B.Candler@pobox.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21079: IPSEC, kernel ARPs for tunnel endpoint instead of next-hop gateway Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21079 >Category: kern >Synopsis: IPSEC, kernel ARPs for tunnel endpoint instead of next-hop gateway >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 09:10:04 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Brian Candler >Release: 4.1-RELEASE >Organization: >Environment: FreeBSD godl-vpn.example.com 4.1-RELEASE FreeBSD 4.1-RELEASE #0: Sun Sep 3 14:00:33 BST 2000 root@example.com:/usr/src/sys/compile/GODL-VPN i386 >Description: When sending IPSEC packets, and the ARP cache for the next hop expires, the machine tries to ARP for the tunnel endpoint address instead of the next hop router. Thus the symptom is that connectivity drops after a few minutes. e.g. +- - - - - - - - + R1 R2 | | A B -+-+--- -+-+--- W1 W2 Box A is a FreeBSD-4.1 PC configured as IPSEC VPN gateway. W1, W2 are workstations. A points defaultroute at R1. This works for a couple of minutes, until A's ARP entry for R1 expires. At that point, A sends out ARP packets for B's IP address, not R1's IP address! The kernel logs the following message: Sep 4 10:33:01 godl-vpn /kernel: arplookup b.b.b.b failed: host is not on local network (where b.b.b.b is B's IP address, i.e. the remote tunnel endpoint) arp -an shows: ? (b.b.b.b) at (incomplete) [ethernet] Connectivity is lost until you manually do # arp -d b.b.b.b # ping b.b.b.b At this point the IPSEC packets start to flow, until the ARP cache expires again. >How-To-Repeat: You can do this with just one PC running FreeBSD, as it doesn't matter that the remote end does not exist. (1) Create /etc/ipsec.conf [Replace 192.168.1.180 with your PC's ethernet address, but leave all the other numbers as they are here] flush; add 192.168.1.180 192.0.2.1 esp 256 -E des-cbc 0x1111111111111111 -A hmac-md5 0x22222222222222222222222222222222; add 192.0.2.1 192.168.1.180 esp 256 -E des-cbc 0x1111111111111111 -A hmac-md5 0x22222222222222222222222222222222; spdflush; spdadd 10.0.0.0/24[any] 10.0.1.0/24[any] any -P out ipsec esp/tunnel/192.168.1.180-192.0.2.1/require; spdadd 10.0.1.0/24[any] 10.0.0.0/24[any] any -P in ipsec esp/tunnel/192.0.2.1-192.168.1.180/require; (2) ifconfig lo0 10.0.0.1 netmask 255.255.255.0 alias (3) setkey -f /etc/ipsec.conf (4) ping -S 10.0.0.1 10.0.1.1 Make sure there is no other IP traffic being generated by this PC (i.e. no ntpd etc) (5) On another VC, run a tcpdump. You should see 16:49:18.950061 192.168.1.180 > 192.0.2.1: ESP(spi=256,seq=0x1b) 16:49:19.960064 192.168.1.180 > 192.0.2.1: ESP(spi=256,seq=0x1c) 16:49:20.970104 192.168.1.180 > 192.0.2.1: ESP(spi=256,seq=0x1d) 16:49:21.980124 192.168.1.180 > 192.0.2.1: ESP(spi=256,seq=0x1e) (except with 192.168.1.180 changed to your local ethernet address) (6) On a third VC, type "arp -d 192.168.1.254" (but use your PC's gateway address instead of 192.168.1.254) Go back to the second VC and you will see: 16:49:22.990120 arp who-has 192.0.2.1 tell 192.168.1.180 ^^^^^^^^^ i.e. it is ARPing for the tunnel endpoint, not the gateway. If you have a Cisco on your network in its default mode (gratiously proxy ARP) then the Cisco will respond, but the kernel will ignore it.  (7) arp -n 192.168.1.254 ? (192.168.1.254) at (incomplete) [ethernet] (8) Stop the ping -S process and do arp -d 192.168.1.254 ping 192.168.1.254 Then restart the ping -S; the packets will be flowing again. >Fix: Workaround: add static ARP entry for the gateway, so that it never expires. arp -S 192.168.1.254 gg:gg:gg:gg:gg:gg >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 9:15:25 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id 71A2537B423 for ; Wed, 6 Sep 2000 09:15:22 -0700 (PDT) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.9.3/3.7Wpl2-2000/05/28) with ESMTP id BAA79879 for ; Thu, 7 Sep 2000 01:15:20 +0900 (JST) In-Reply-To: <13491.968238933@axl.fw.uunet.co.za> References: <200009060950.CAA78536@freefall.freebsd.org> <13491.968238933@axl.fw.uunet.co.za> X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Subject: Re: kern/21009: /etc/security make the system hangup Cc: freebsd-bugs@FreeBSD.org X-Mailer: Mew version 1.94.2 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: <20000907011520X.ishizuka@onion.ish.org> Date: Thu, 07 Sep 2000 01:15:20 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 22 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> There are 4 machines with hangup. The following is the output of >> 'df -ki' command. All machines are 4.1-RELEASE. Most of directories >> and files on the disk mounted on /www have about 5000 hard links, >> so there are more than 6,000,000 links, files or directories on each >> /www disks. > > Could you stick a debugging kernel on one of those boxes and use DDB or > remote kgdb to figure out what the kernel's stuck in? There are just > two many variables here. > > Instructions that you might find helpful are available at: > > http://www.freebsd.org/handbook/kerneldebug.html Hi, sheldonh-san. Thank you for mail. I'll try above. But these machines are not able to panic, so I must create a test machine with the same environment. Because I'm too busy to do so, please wait for a couple of weeks or more. -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 9:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C5DB837B422 for ; Wed, 6 Sep 2000 09:20:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA07563; Wed, 6 Sep 2000 09:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 09:20:02 -0700 (PDT) Message-Id: <200009061620.JAA07563@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Masachika ISHIZUKA Subject: Re: kern/21009: /etc/security make the system hangup Reply-To: Masachika ISHIZUKA Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21009; it has been noted by GNATS. From: Masachika ISHIZUKA To: sheldonh@uunet.co.za Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/21009: /etc/security make the system hangup Date: Thu, 07 Sep 2000 01:13:49 +0900 >> There are 4 machines with hangup. The following is the output of >> 'df -ki' command. All machines are 4.1-RELEASE. Most of directories >> and files on the disk mounted on /www have about 5000 hard links, >> so there are more than 6,000,000 links, files or directories on each >> /www disks. > > Could you stick a debugging kernel on one of those boxes and use DDB or > remote kgdb to figure out what the kernel's stuck in? There are just > two many variables here. > > Instructions that you might find helpful are available at: > > http://www.freebsd.org/handbook/kerneldebug.html Hi, sheldonh-san. Thank you for mail. I'll try above. But these machines are not able to panic, so I must create a test machine with the same environment. Because I'm too busy to do so, please wait for a couple of weeks or more. -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 9:20: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DDDBB37B423 for ; Wed, 6 Sep 2000 09:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA07572; Wed, 6 Sep 2000 09:20:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 09:20:03 -0700 (PDT) Message-Id: <200009061620.JAA07572@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Brian Candler Subject: Re: kern/21079: IPSEC, kernel ARPs for tunnel endpoint instead of next-hop gateway Reply-To: Brian Candler Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21079; it has been noted by GNATS. From: Brian Candler To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/21079: IPSEC, kernel ARPs for tunnel endpoint instead of next-hop gateway Date: Wed, 6 Sep 2000 17:17:58 +0100 Turns out this has already been reported to KAME project as http://orange.kame.net/dev/query-pr.cgi?pr=233 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 9:30: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C897437B423 for ; Wed, 6 Sep 2000 09:30:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA09021; Wed, 6 Sep 2000 09:30:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 09:30:02 -0700 (PDT) Message-Id: <200009061630.JAA09021@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Brian Candler Subject: Re: kern/21079: IPSEC, kernel ARPs for tunnel endpoint instead of next-hop gateway Reply-To: Brian Candler Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21079; it has been noted by GNATS. From: Brian Candler To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/21079: IPSEC, kernel ARPs for tunnel endpoint instead of next-hop gateway Date: Wed, 6 Sep 2000 17:26:18 +0100 [And the last part of the description should read as:] arp -an shows: ? (g.g.g.g) at (incomplete) [ethernet] where g.g.g.g is R1's IP address on the link to A, i.e. A's default gateway. Connectivity is lost until you manually do # arp -d g.g.g.g # ping g.g.g.g At this point the IPSEC packets start to flow, until the ARP cache expires again. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 9:36:39 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from poseidon.dcs.napier.ac.uk (poseidon.dcs.napier.ac.uk [146.176.161.4]) by hub.freebsd.org (Postfix) with ESMTP id 3D8E637B424 for ; Wed, 6 Sep 2000 09:36:37 -0700 (PDT) Received: from artemis (artemis [146.176.161.5]) by poseidon.dcs.napier.ac.uk (8.9.3/8.9.3) with SMTP id RAA16391 for ; Wed, 6 Sep 2000 17:34:56 +0100 (BST) Date: Wed, 6 Sep 2000 17:32:19 +0100 (BST) From: Robin Carey X-Sender: bsc4093@artemis To: bugs@freebsd.org Subject: cons25 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The default terminal-type for ttyv0-7 in FreeBSD-4.0 is "cons25" (set in /etc/ttys). This would appear to be a non-standard terminal-type, as it causes me problems when I rlogin/telnet to other systems, i.e. they do not recognise this terminal-type. I've come across the same problem with Linux and their "linux" terminal-type. I've found that doing a "setenv TERM ansi" or "export TERM=ansi" seems to work, so why not change the "cons25" default settings in /etc/ttys to "ansi". Yours sincerely, Rob C. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 9:41: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from poseidon.dcs.napier.ac.uk (poseidon.dcs.napier.ac.uk [146.176.161.4]) by hub.freebsd.org (Postfix) with ESMTP id E2CA937B424 for ; Wed, 6 Sep 2000 09:41:02 -0700 (PDT) Received: from artemis (artemis [146.176.161.5]) by poseidon.dcs.napier.ac.uk (8.9.3/8.9.3) with SMTP id RAA16498 for ; Wed, 6 Sep 2000 17:39:31 +0100 (BST) Date: Wed, 6 Sep 2000 17:37:24 +0100 (BST) From: Robin Carey X-Sender: bsc4093@artemis To: bugs@freebsd.org Subject: microuptime() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org O/S: FreeBSD-4.0/i386 Aug 29 00:26:11 /kernel: microuptime() went backwards (3075.065348 -> 3075,-695310955) Aug 31 18:28:29 /kernel: microuptime() went backwards (10060.318928 -> 10060,-695057360) Sep 4 22:06:56 /kernel: microuptime() went backwards (1867.046016 -> 1867,-695330292) Presumably, these log messages are indicative of some kind of error, i.e. Time (in general) doesn't go backwards. Yours sincerely, Rob C. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 9:41:58 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 33E7737B423 for ; Wed, 6 Sep 2000 09:41:56 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.11.0/8.11.0) id e86GfUH01339; Wed, 6 Sep 2000 20:41:30 +0400 (MSD) (envelope-from ache) Date: Wed, 6 Sep 2000 20:41:29 +0400 From: "Andrey A. Chernov" To: Robin Carey Cc: bugs@FreeBSD.ORG Subject: Re: cons25 Message-ID: <20000906204129.A980@nagual.pp.ru> 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 bsc4093@dcs.napier.ac.uk on Wed, Sep 06, 2000 at 05:32:19PM +0100 Organization: Biomechanoid Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 06, 2000 at 05:32:19PM +0100, Robin Carey wrote: > This would appear to be a non-standard terminal-type, as it causes me > problems when I rlogin/telnet to other systems, i.e. they do not recognise > this terminal-type. I've come across the same problem with Linux and their > "linux" terminal-type. It is other systems problem, ask corresponding maintainers to add cons25 to their termcap/terminfo databases. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 10: 0: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 97B0337B424 for ; Wed, 6 Sep 2000 10:00:07 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id KAA13568; Wed, 6 Sep 2000 10:00:07 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 10:00:07 -0700 (PDT) Message-Id: <200009061700.KAA13568@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: kern/21009: /etc/security make the system hangup Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21009; it has been noted by GNATS. From: Sheldon Hearn To: Masachika ISHIZUKA Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/21009: /etc/security make the system hangup Date: Wed, 06 Sep 2000 18:53:31 +0200 On Thu, 07 Sep 2000 01:15:20 +0900, Masachika ISHIZUKA wrote: > I'll try above. But these machines are not able to panic, so I > must create a test machine with the same environment. Because > I'm too busy to do so, please wait for a couple of weeks or more. Another suggestion that I got in private mail was this: Run something like this on its own virtual terminal: while sleep 1; do vmstat -m | tail -2 done Report back the values displayed at the time of the lock-up. This should be easy to do, since you said that you were able to switch virtual terminals during the lock-up. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 11: 0: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5A40E37B423 for ; Wed, 6 Sep 2000 11:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA25025; Wed, 6 Sep 2000 11:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 775B637B422 for ; Wed, 6 Sep 2000 10:58:47 -0700 (PDT) Received: from nellie.feral.com (nellie.feral.com [192.67.166.18]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA24141 for ; Wed, 6 Sep 2000 10:58:47 -0700 Received: (from mjacob@localhost) by nellie.feral.com (8.9.3/8.9.1) id KAA63557; Wed, 6 Sep 2000 10:58:46 -0700 (PDT) (envelope-from mjacob) Message-Id: <200009061758.KAA63557@nellie.feral.com> Date: Wed, 6 Sep 2000 10:58:46 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21080: dump doesn't use eject tape device correctly Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21080 >Category: bin >Synopsis: dump doesn't use eject tape device correctly >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 11:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Matthew Jacob >Release: FreeBSD 5.0-CURRENT alpha >Organization: Feral Software >Environment: Not relevant. >Description: If you use the eject tape device, e.g., ersa0, for a multi tape backup, the tape drive gets bunged up trying to change tapes because a close ejects the tape, and then dump gets stuck trying (re)open the tape drive to tell you to change tapes (!). >How-To-Repeat: See above. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 11: 1:10 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E9C5B37B423; Wed, 6 Sep 2000 11:01:08 -0700 (PDT) Received: (from mjacob@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA25555; Wed, 6 Sep 2000 11:01:08 -0700 (PDT) (envelope-from mjacob@FreeBSD.org) Date: Wed, 6 Sep 2000 11:01:08 -0700 (PDT) From: Message-Id: <200009061801.LAA25555@freefall.freebsd.org> To: mjacob@FreeBSD.org, freebsd-bugs@FreeBSD.org, mjacob@FreeBSD.org Subject: Re: bin/21080: dump doesn't use eject tape device correctly Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: dump doesn't use eject tape device correctly Responsible-Changed-From-To: freebsd-bugs->mjacob Responsible-Changed-By: mjacob Responsible-Changed-When: Wed Sep 6 11:00:43 PDT 2000 Responsible-Changed-Why: I'll fix it. http://www.freebsd.org/cgi/query-pr.cgi?pr=21080 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 11:42: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D8C1937B424; Wed, 6 Sep 2000 11:42:03 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA34034; Wed, 6 Sep 2000 11:42:03 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Wed, 6 Sep 2000 11:42:03 -0700 (PDT) From: Message-Id: <200009061842.LAA34034@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, ume@FreeBSD.org Subject: Re: kern/21079: IPSEC, kernel ARPs for tunnel endpoint instead of next-hop gateway Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: IPSEC, kernel ARPs for tunnel endpoint instead of next-hop gateway Responsible-Changed-From-To: freebsd-bugs->ume Responsible-Changed-By: sheldonh Responsible-Changed-When: Wed Sep 6 11:41:54 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21079 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 14:59:52 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id DA4C337B422; Wed, 6 Sep 2000 14:59:49 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id RAA04854; Wed, 6 Sep 2000 17:59:49 -0400 (EDT) Date: Wed, 6 Sep 2000 17:59:48 -0400 (EDT) From: "Matthew N. Dodd" To: sheldonh@FreeBSD.ORG Cc: shurd@sk.sympatico.ca, freebsd-bugs@FreeBSD.ORG, yokota@FreeBSD.ORG Subject: Re: i386/21042: Keyboard driver problems with PS/2 Model 95 (MCA) In-Reply-To: <200009050903.CAA73183@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This should remain open regardless, (and assigned to me as should all MCA specific issues.) I've got a better solution than specifying flags but it will involve some doing. On Tue, 5 Sep 2000 sheldonh@FreeBSD.ORG wrote: > Synopsis: Keyboard driver problems with PS/2 Model 95 (MCA) > > State-Changed-From-To: open->feedback > State-Changed-By: sheldonh > State-Changed-When: Tue Sep 5 02:01:57 PDT 2000 > State-Changed-Why: > Does Andy's suggestion work for you? Please be sure to > send your follow-up to , > preserving the Subject line of this e-mail message. > > > Responsible-Changed-From-To: freebsd-bugs->yokota > Responsible-Changed-By: sheldonh > Responsible-Changed-When: Tue Sep 5 02:01:57 PDT 2000 > Responsible-Changed-Why: > Over to maintainer. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=21042 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-bugs" in the body of the message > -- | 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-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 15: 0:10 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A618B37B42C for ; Wed, 6 Sep 2000 15:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA73394; Wed, 6 Sep 2000 15:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from barbera.system.pl (barbera.system.pl [195.205.185.21]) by hub.freebsd.org (Postfix) with ESMTP id D8FE837B422; Wed, 6 Sep 2000 14:55:46 -0700 (PDT) Received: (from saper@localhost) by barbera.system.pl (SYSTEM Internet) id e86Lrj102738; Wed, 6 Sep 2000 23:53:45 +0200 (CEST) Message-Id: <200009062153.e86Lrj102738@barbera.system.pl> Date: Wed, 6 Sep 2000 23:53:45 +0200 (CEST) From: saper@SYSTEM.PL Reply-To: saper@SYSTEM.PL To: FreeBSD-gnats-submit@freebsd.org Cc: peter@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/21085: [patch] SYSV IPC msg queues creation failed with ENOSPC Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21085 >Category: kern >Synopsis: [patch] SYSV IPC msg queues creation failed with ENOSPC >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 15:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Marcin Cieslak >Release: FreeBSD 4.1-STABLE i386 >Organization: SYSTEM Internet Provider - http://www.system.pl/ >Environment: Any -current system after 2000/05/01 Any RELENG_4 system after 2000/08/04 /* $FreeBSD: src/sys/kern/sysv_msg.c,v 1.23.2.1 2000/08/04 22:31:08 peter Exp $ */ ipcs -Q msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) >Description: The msgget(3) began to fail strangely with errno = ENOSPC even at the system boot. The problem is with msqids struct initialization - msg_perm.mode field was tested at sys/kern/sysv_msg.c:442, but has not been previously initialized properly at sys/kern/sysv_msg.c:190. >How-To-Repeat: Try to run the following program, however we were unable to reproduce the bug on some other machines. The program failed with ENOSPC even with empty msg queue table. #include #include #include #include #include int main() { int msgq; msgq = msgget(IPC_PRIVATE,IPC_CREAT); printf("Result: %d\n", msgq); if (msgq == -1) perror("msgget"); return 0; } >Fix: Beware, all other sysv_* files should be inspected closely, because malloc() for the structures has been introduced on May, 1st. 2000. Index: sysv_msg.c =================================================================== RCS file: /home/ncvs/src/sys/kern/sysv_msg.c,v retrieving revision 1.23.2.1 diff -u -r1.23.2.1 sysv_msg.c --- sysv_msg.c 2000/08/04 22:31:08 1.23.2.1 +++ sysv_msg.c 2000/09/06 21:29:54 @@ -188,6 +188,7 @@ for (i = 0; i < msginfo.msgmni; i++) { msqids[i].msg_qbytes = 0; /* implies entry is available */ msqids[i].msg_perm.seq = 0; /* reset to a known value */ + msqids[i].msg_perm.mode = 0; /* this should be reset, too */ } } SYSINIT(sysv_msg, SI_SUB_SYSV_MSG, SI_ORDER_FIRST, msginit, NULL) >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 16: 0: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1C1C737B423 for ; Wed, 6 Sep 2000 16:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA81953; Wed, 6 Sep 2000 16:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id E015F37B424; Wed, 6 Sep 2000 15:56:27 -0700 (PDT) Message-Id: <20000906225627.E015F37B424@hub.freebsd.org> Date: Wed, 6 Sep 2000 15:56:27 -0700 (PDT) From: eddier@home.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: bin/21086: Annoying little bug using ls -G with colorized prompts. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21086 >Category: bin >Synopsis: Annoying little bug using ls -G with colorized prompts. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 16:00:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Eddie Rohwedder >Release: 4.1-RELEASE >Organization: >Environment: 4.1-RELEASE FreeBSD 4.1-RELEASE #0: Wed Sep 6 13:34:46 PDT 2000 >Description: When using "ls -G" while also using colored bash prompts, if the first file(s) outputted are not to be colorized, they take on the bash prompt color until reaching a file that does have color. Then the folowing non-colored files take on the defualt white. In other words, there is no *initial* setting of the default color. I know it's a tiny thing and you have better things to worry about, but... :) >How-To-Repeat: Add a colorized bash prompt. Do a ls -G (Make sure that the directory's first few files have no color attribute.) >Fix: Easy fix is to add endcolor(0); to parsecolors() in src/bin/ls/print.c This forces an initial setting of the color, once, before displaying any files. Looks like you tried to fix it with some signal() code just before the call to pasrecolors() but it didn't seem to fix it. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 18: 0: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id AC3AA37B424 for ; Wed, 6 Sep 2000 18:00:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id SAA99910; Wed, 6 Sep 2000 18:00:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 18:00:02 -0700 (PDT) Message-Id: <200009070100.SAA99910@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Gregory Bond Subject: Re: bin/21086: Annoying little bug using ls -G with colorized prompts. Reply-To: Gregory Bond Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21086; it has been noted by GNATS. From: Gregory Bond To: eddier@home.com Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: bin/21086: Annoying little bug using ls -G with colorized prompts. Date: Thu, 07 Sep 2000 11:52:41 +1100 > When using "ls -G" while also using colored bash prompts, if the first file(s > ) outputted are not to be colorized, they take on the bash prompt color until > reaching a file that does have color. Surely this is a bug in the way the bash color prompt is implemented (I assume you're doing it with funky escape codes in PS1). It should leave the terminal in the default color mode at the end of the pormpt, rather than rely on all the other color-using programs to fix it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 18:19: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from darius.concentric.net (darius.concentric.net [207.155.198.79]) by hub.freebsd.org (Postfix) with ESMTP id CE41A37B422 for ; Wed, 6 Sep 2000 18:19:04 -0700 (PDT) Received: from newman.concentric.net (newman.concentric.net [207.155.198.71]) by darius.concentric.net (8.9.1a/(98/12/15 5.12)) id VAA27314; Wed, 6 Sep 2000 21:19:03 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from UrsaMajor.Ursa.com (ts020d02.atl-ga.concentric.net [206.173.85.206]) by newman.concentric.net (8.9.1a) id VAA27519; Wed, 6 Sep 2000 21:19:01 -0400 (EDT) Message-ID: <39B6ED8D.41C67EA6@cris.com> Date: Wed, 06 Sep 2000 21:21:17 -0400 From: amg X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: Bugs@FreeBSD.org Subject: cdrecord is now broke Content-Type: multipart/mixed; boundary="------------446B9B3D2781E494167EB0E7" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------446B9B3D2781E494167EB0E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gentlemen: Don't shoot the messenger .... With the change, in 4.1, to all character special files, the utility/package cdrecord is now broke. Attacted is the output of a script, and the script itself, that I used extensively with 2.2.8. I have the bad feeling that cdrecord is not the only utility that is now broken. Attacted: cdClone - the script that I mentioned above cdClone.out - the script's output under 4.1 august ursa@cris.com --------------446B9B3D2781E494167EB0E7 Content-Type: text/plain; charset=iso-8859-1; name="cdClone.out" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="cdClone.out" cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). cdrecord: WARNING: This causes a high risk for buffer underruns. cdrecord: Invalid argument. Open by 'devname' not supported on this OS. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. Cdrecord 1.8.1 (i386-unknown-freebsd4.1) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '/dev/rcd0.ctl:0,4,0' devname: '/dev/rcd0.ctl' scsibus: 0 target: 4 lun: 0 --------------446B9B3D2781E494167EB0E7 Content-Type: text/plain; charset=us-ascii; name="cdClone" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cdClone" #!/bin/sh # # cdClone - clones a CD # # Notes - based on the FreeBSD scripts, makecdfs.sh and burncd.sh, # which are located in /usr/share/examples/worm # ThisProg=${0##*/} # # check for proper invocation # if [ $# -lt 2 ] then echo "" echo " Usage: $ThisProg InputCDToClone OutputCDImageFile " echo " Too few arguments." echo "" echo " Exmpl: $ThisProg /dev/cd0a myCDClone" echo "" echo " Notes: InputCDToClone MUST be the CD device;" echo " for 4.1 and later, the invocation in <...> MUST be used." echo " $ThisProg MUST be run as root." echo " The optional \"Dummy\" parameter will turn off the laser" echo " during the call to the cdrecord utility." echo "" exit fi # if [ $# -gt 3 ] then echo "" echo " Usage: $ThisProg InputCDToClone OutputCDImageFile " echo " Too many arguments." echo "" echo " Exmpl: $ThisProg /dev/cd0a myCDClone" echo "" echo " Notes: InputCdToClone MUST be the CD device;" echo " for 4.1 and later, the invocation in <...> MUST be used." echo " $ThisProg MUST be run as root." echo " The optional \"Dummy\" parameter will turn off the laser" echo " during the call to the cdrecord utility." echo "" exit fi # # variable assignments # InputCDToClone=$1 OutputCDImageFile=$2 if [ $# -eq 3 ] then Dummy=-dummy else Dummy="" fi # # dd an image from the CD device # echo "" echo " dd is now starting ..." echo "" dd if=$InputCDToClone bs=32k of=$OutputCDImageFile echo "" echo " dd just finished." echo "" # # swap CD's # echo " Do NOT touch any key! REMOVE the CD to clone and insert a blank CD." echo " Then, hit Enter ..." read keyStroke echo "" echo " cdrecord will now start ..." echo "" # # burn the CD-R # cdrecord $Dummy -v speed=4 dev=/dev/rcd0.ctl:0,4,0 -data $OutputCDImageFile # ^ ^ ^ ^ # | verbose | | | Logical U. N. # | | Physical U. N. # | SCSIBUS # echo "" echo " cdrecord just finished." echo "" echo "" # # end cdClone # --------------446B9B3D2781E494167EB0E7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 19:20: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DFCD737B422 for ; Wed, 6 Sep 2000 19:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id TAA18476; Wed, 6 Sep 2000 19:20:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 6 Sep 2000 19:20:03 -0700 (PDT) Message-Id: <200009070220.TAA18476@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Gerhard Sittig Subject: Re: bin/21017: mtree's "no such file" message at job's end Reply-To: Gerhard Sittig Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21017; it has been noted by GNATS. From: Gerhard Sittig To: FreeBSD-gnats-submit@freebsd.org Cc: Sheldon Hearn Subject: Re: bin/21017: mtree's "no such file" message at job's end Date: Wed, 6 Sep 2000 22:26:08 +0200 On Tue, Sep 05, 2000 at 18:28 +0200, Gerhard Sittig wrote: > > [ ... ] I hope to have the stderr tail of truss available, > then. Maybe I can tell you soon which syscall results in the > ENOENT(?) error. truss(1)ing mtree is what happened now. The result of KEYS=nlink,type,mode,flags,uid,gid,size,time,cksum,md5digest,sha1digest,ripemd160digest truss /usr/sbin/mtree -K $KEYS -p /usr -x -X $DBDIR/_usr.ex < $DBDIR/_usr.db 2>&1 >/dev/null | tail -500 looks like this ----- truss mtree | tail snippets ------------------------------- ... open("./compat/linux/usr/lib/libz.so.1",0,027757774510) = 3 (0x3) read(0x3,0xbfbff548,0x400) = 1024 (0x400) ... read(0x3,0xbfbff548,0x400) = 1024 (0x400) read(0x3,0xbfbff548,0x400) = 421 (0x1a5) read(0x3,0xbfbff548,0x400) = 0 (0x0) close(3) = 0 (0x0) open("./compat/linux/usr/lib/libz.so.1",0,027757774510) = 3 (0x3) read(0x3,0xbfbff548,0x400) = 1024 (0x400) ... read(0x3,0xbfbff548,0x400) = 1024 (0x400) read(0x3,0xbfbff548,0x400) = 421 (0x1a5) read(0x3,0xbfbff548,0x400) = 0 (0x0) close(3) = 0 (0x0) open("./compat/linux/usr/lib/libz.so.1.1.3",0,00) = 3 (0x3) read(0x3,0xbfbfb948,0x4000) = 16384 (0x4000) read(0x3,0xbfbfb948,0x4000) = 16384 (0x4000) read(0x3,0xbfbfb948,0x4000) = 16384 (0x4000) read(0x3,0xbfbfb948,0x4000) = 13733 (0x35a5) read(0x3,0xbfbfb948,0x4000) = 0 (0x0) close(3) = 0 (0x0) open("./compat/linux/usr/lib/libz.so.1.1.3",0,027757774510) = 3 (0x3) read(0x3,0xbfbff548,0x400) = 1024 (0x400) ... read(0x3,0xbfbff548,0x400) = 1024 (0x400) read(0x3,0xbfbff548,0x400) = 421 (0x1a5) read(0x3,0xbfbff548,0x400) = 0 (0x0) close(3) = 0 (0x0) open("./compat/linux/usr/lib/libz.so.1.1.3",0,027757774510) = 3 (0x3) read(0x3,0xbfbff548,0x400) = 1024 (0x400) ... read(0x3,0xbfbff548,0x400) = 1024 (0x400) read(0x3,0xbfbff548,0x400) = 421 (0x1a5) read(0x3,0xbfbff548,0x400) = 0 (0x0) close(3) = 0 (0x0) ... open("./compat/linux/usr/lib/python1.5/site-packages/rpmmodule.so",0,027757774510) = 3 (0x3) read(0x3,0xbfbff548,0x400) = 1024 (0x400) ... read(0x3,0xbfbff548,0x400) = 1024 (0x400) read(0x3,0xbfbff548,0x400) = 168 (0xa8) read(0x3,0xbfbff548,0x400) = 0 (0x0) close(3) = 0 (0x0) readlink("X11",0x804ef00,1023) ERR#2 'No such file or directory' mtree: write(2,0xbfbff1b4,7) = 7 (0x7) line 1361949: X11write(2,0xbfbff1e4,17) = 17 (0x11) : write(2,0xbfbff1a4,2) = 2 (0x2) No such file or directory write(2,0xbfbff1a4,26) = 26 (0x1a) sigprocmask(0x1,0x280605a0,0xbfbff84c) = 0 (0x0) sigprocmask(0x3,0x280605b0,0x0) = 0 (0x0) write(1,0xd2da000,958) = 958 (0x3be) exit(0x1) process exit, rval = 256 ----- truss mtree | tail snippets ------------------------------- Whoops! Why is libz.so.1.1.3 being read in chunks of 16KB when every other file is read in single KB buffers? This "finding" was done by chance ... There's no (obvious) reference to read in usr.sbin/mtree/*.[ch], so I would expect it to be called from {MD5,SHA1_,RIPEMD160_}File(3). The symlink /usr/compat/linux/usr/lib/X11 seems to cause the error. The db description looks like this: ----- _usr.db snippet for the symlink --------------------------- ... # ./compat/linux/usr/lib /set type=file uid=0 gid=0 mode=0755 nlink=1 lib type=dir nlink=8 size=1536 time=964377066.0 X11 type=link size=16 time=964377066.0 link=../X11R6/lib/X11 libbfd-2.9.1.0.24.so \ ... ----- _usr.db snippet for the symlink --------------------------- The symlink is there but "broken". This should never hurt mtree, neither when creating nor when comparing the database. ----- ls -l output ---------------------------------------------- lrwxr-xr-x 1 root wheel 16 Jul 23 20:31 /usr/compat/linux/usr/lib/X11@ -> ../X11R6/lib/X11 ls: /usr/compat/linux/usr/X11R6/lib/X11: No such file or directory ----- ls -l output ---------------------------------------------- So I ctag(1)ed /usr/src/usr.sbin/mtree, read manpages for readlink(2), symlink(7) and fts(3) and tried building and checking a database for the /usr/compat/linux path only -- this time everything worked! Well that's a surprise. (Now I can see why you wish for a better way to cause the symptom ...) The only thing I could see is that the above mentioned "X11" file is the only broken symlink on the /usr filesystem (that's what I get from "find /usr -xdev -type l -print0 | xargs -0 file | grep broken", although symlinks aren't necessarily a problem -- perl has a lot of these). And why does this broken symlink break readlink(2) sometimes and sometimes it does not? The only readlink(2) reference I can see in mtree is in the rlink() function in compare.c -- but of course I miss all the implicit invocations libc or fts(3) could bring with them. But the code makes me quite sure: errors in readlink cause err(3) to be called with the formerly mentioned "line %d: %s" message with lineno and fname. Does it matter that lineno is always _behind_ the last db line? I'll dig into this place a little further ... I'm really confused as to where to continue searching, but I'm willing to help with whatever I can do ... To summarize: It's not about the broken symlink in itself. But readlink(2) fails at a broken symlink when something else happened before -- but I don't know what this is. :< Could bin/4961 (nonzero errno although there's no error) apply in this case? 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-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 21:36:27 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 9708E37B424 for ; Wed, 6 Sep 2000 21:36:24 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA05370; Wed, 6 Sep 2000 22:36:13 -0600 (MDT) (envelope-from ken) Date: Wed, 6 Sep 2000 22:36:13 -0600 From: "Kenneth D. Merry" To: amg Cc: Bugs@FreeBSD.ORG Subject: Re: cdrecord is now broke Message-ID: <20000906223612.A5302@panzer.kdm.org> References: <39B6ED8D.41C67EA6@cris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <39B6ED8D.41C67EA6@cris.com>; from ursa@cris.com on Wed, Sep 06, 2000 at 09:21:17PM -0400 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 06, 2000 at 21:21:17 -0400, amg wrote: > Gentlemen: > > Don't shoot the messenger .... > > With the change, in 4.1, to all character > special files, the utility/package cdrecord > is now broke. > > Attacted is the output of a script, and the > script itself, that I used extensively with > 2.2.8. > > I have the bad feeling that cdrecord is not > the only utility that is now broken. > The SCSI subsystem was completely overhauled in FreeBSD 3.0. Anything that used SCSI passthrough in 2.2.x must be ported to the new CAM SCSI subsystem. (cdrecord has been ported, and it appears that you're using a version of cdrecord compiled on FreeBSD 4.1.) It looks like you may have one or two problems. First, don't use the 'devname' syntax for telling cdrecord which device you want to talk to. Instead of using dev=/dev/rcd0.ctl:0,4,0 just use: dev=0,4,0 > cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler > cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). > cdrecord: WARNING: This causes a high risk for buffer underruns. > cdrecord: Invalid argument. Open by 'devname' not supported on this OS. Cannot open SCSI driver. > cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. > Cdrecord 1.8.1 (i386-unknown-freebsd4.1) Copyright (C) 1995-2000 Jörg Schilling > TOC Type: 1 = CD-ROM > scsidev: '/dev/rcd0.ctl:0,4,0' > devname: '/dev/rcd0.ctl' > scsibus: 0 target: 4 lun: 0 You also need to make sure you have the pass device in your kernel, that you have enough pass devices created in /dev for *every* SCSI device in the system. You also need to make sure that whatever user that is going to be using cdrecord has read and write permission on /dev/pass*. You also should make sure you've got the following options in your kernel config file, so the posix scheduler stuff can work: options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING I'm not sure whether the scheduler warnings you're getting from cdrecord are due to not having the posix scheduler code in your kernel, or whether it's because you aren't running with root. If you still get the errors with the kernel options in, try running as root. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 22: 8:29 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from mail1.sirius.com (mail1.sirius.com [205.134.253.131]) by hub.freebsd.org (Postfix) with ESMTP id 6D61437B422 for ; Wed, 6 Sep 2000 22:08:28 -0700 (PDT) Received: from star1.sirius.com ([207.44.191.2]) by mail1.sirius.com (8.9.3/8.9.1) with SMTP id WAA35541 for ; Wed, 6 Sep 2000 22:08:07 -0700 (PDT) Date: Wed, 6 Sep 2000 22:08:07 -0700 (PDT) Message-Id: <200009070508.WAA35541@mail1.sirius.com> From: eps@sirius.com (Eric P. Scott) Subject: Re: cons25 To: bugs@FreeBSD.ORG Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My /etc/rc.conf contains: font8x8="iso-8x8" font8x14="iso-8x14" font8x16="iso-8x16" so I have to edit /etc/ttys to make my default terminal type cons25-iso8859-1 (i.e. cons25l1) or I'll get the wrong ACS mapping (particularly nasty for /stand/sysinstall). -=EPS=- -- CP437 is dead. Get over it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 22:30: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 870AB37B424 for ; Wed, 6 Sep 2000 22:30:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id WAA49003; Wed, 6 Sep 2000 22:30:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 930A637B422; Wed, 6 Sep 2000 22:25:27 -0700 (PDT) Message-Id: <20000907052527.930A637B422@hub.freebsd.org> Date: Wed, 6 Sep 2000 22:25:27 -0700 (PDT) From: buchanan@orbitworld.net To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: i386/21087: ed driver incorrectly fails probe for ISA HP PCLAN+ Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21087 >Category: i386 >Synopsis: ed driver incorrectly fails probe for ISA HP PCLAN+ >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 06 22:30:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: M. B. Buchanan >Release: 4.1-RELEASE >Organization: >Environment: FreeBSD 4.1-RELEASE FreeBSD 4.1-RELEASE #5: Thu Sep 7 00:00:24 CDT 2000 root@:/usr/src/sys/compile/V20000905 i386 >Description: ed_probe_HP_pclanp() in /sys/dev/ed/if_ed.c returns ED_HPP_IO_PORTS (32) after a successful probe, instead of zero as device_probe_child() in /sys/kern/subr_bus.c expects. device_probe_child() then (silently!) fails to attach the device. Returning ED_HPP_IO_PORTS (the number of I/O ports occupied by the device) appears to be behavior from the v3 driver that was missed in building the v4 driver. >How-To-Repeat: Install/configure HP PCLAN+ card; boot 4.1-RELEASE install media; configure ed0 device appropriately; observe that ed0 is not detected. Compare with 3.4-RELEASE behavior. >Fix: Change the last line of ed_probe_HP_pclanp() to return zero. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Sep 6 23:53: 1 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2087837B424; Wed, 6 Sep 2000 23:53:00 -0700 (PDT) Received: (from cracauer@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA61748; Wed, 6 Sep 2000 23:53:00 -0700 (PDT) (envelope-from cracauer@FreeBSD.org) Date: Wed, 6 Sep 2000 23:53:00 -0700 (PDT) From: Message-Id: <200009070653.XAA61748@freefall.freebsd.org> To: andre.albsmeier@mchp.siemens.de, cracauer@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/17765: sh in free(): warning: junk pointer, too low to make sense. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: sh in free(): warning: junk pointer, too low to make sense. State-Changed-From-To: open->closed State-Changed-By: cracauer State-Changed-When: Thu Sep 7 08:51:55 MEST 2000 State-Changed-Why: Author says it is fixed in 20000907070059.A80754@curry.mchp.siemens.de http://www.freebsd.org/cgi/query-pr.cgi?pr=17765 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 0:25:47 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id E3E2F37B424 for ; Thu, 7 Sep 2000 00:25:43 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13Ww41-0000Ws-00; Thu, 07 Sep 2000 09:25:37 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id JAA15495; Thu, 7 Sep 2000 09:25:36 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 15246; Thu Sep 7 09:24:40 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13Ww35-000EMt-00; Thu, 07 Sep 2000 09:24:39 +0200 From: Sheldon Hearn To: Gerhard Sittig Cc: freebsd-bugs@freebsd.org Subject: Re: bin/21017: mtree's "no such file" message at job's end In-reply-to: Your message of "Wed, 06 Sep 2000 22:32:22 +0200." <20000906223221.G252@speedy.gsinet> Date: Thu, 07 Sep 2000 09:24:39 +0200 Message-ID: <55234.968311479@axl.fw.uunet.co.za> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 06 Sep 2000 22:32:22 +0200, Gerhard Sittig wrote: > I'm absolutely not clear about the PR procedure. Whom do I email > to? Is freebsd-gnats-submit the relevant address or is it you? No, freebsd-gnats-submit is good. Using that address ensures that your comments are entered into the Audit Trail for the PR. Your message will also be copied to freebsd-bugs, freebsd-ports, or whomever's address appears in the Responsible field of the PR. If you only mail freebsd-bugs, your comments don't reach the Audit Trail of the PR. :-( There's nothing wrong with copying freebsd-gnats-submit _and_ whomever replies to your message, though. I replied to your message in public because you're certainly not the only person who is confused about this. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 0:39:57 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 6E25B37B423 for ; Thu, 7 Sep 2000 00:39:51 -0700 (PDT) Received: from bagabeedaboo.security.at12.de (dial-213-168-64-160.netcologne.de [213.168.64.160]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id JAA21247; Thu, 7 Sep 2000 09:39:49 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.11.0/8.11.0) with ESMTP id e877dgo00323; Thu, 7 Sep 2000 09:39:42 +0200 (CEST) (envelope-from pherman@frenchfries.net) Date: Thu, 7 Sep 2000 09:39:42 +0200 (CEST) From: Paul Herman To: Robin Carey Cc: bugs@FreeBSD.ORG Subject: Re: microuptime() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 6 Sep 2000, Robin Carey wrote: > O/S: FreeBSD-4.0/i386 > > Aug 29 00:26:11 /kernel: microuptime() went backwards (3075.065348 -> 3075,-695310955) > Aug 31 18:28:29 /kernel: microuptime() went backwards (10060.318928 -> 10060,-695057360) > Sep 4 22:06:56 /kernel: microuptime() went backwards (1867.046016 -> 1867,-695330292) According to the mail archives, the suggested workaround is to remove APM support from your kernel. You should get in touch with Poul-Henning Kamp who is working on this. I belive he has already fixed this in -CURRENT. He may be able to help you further. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 3: 0: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2F6EC37B423 for ; Thu, 7 Sep 2000 03:00:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA92104; Thu, 7 Sep 2000 03:00:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id E8B8037B422; Thu, 7 Sep 2000 02:50:34 -0700 (PDT) Message-Id: <20000907095034.E8B8037B422@hub.freebsd.org> Date: Thu, 7 Sep 2000 02:50:34 -0700 (PDT) From: lfrigault@teaser.fr To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: misc/21089: vi silently corrupt open file on SIGINT when entering :wq in command mode Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21089 >Category: misc >Synopsis: vi silently corrupt open file on SIGINT when entering :wq in command mode >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 07 03:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Laurent Frigault >Release: 4.1-STABLE >Organization: France Teaser >Environment: FreeBSD becile.teaser.fr 4.1-STABLE FreeBSD 4.1-STABLE #12: Mon Aug 21 20:26:08 CEST 2000 lfrigault@becile.teaser.fr:/usr/src/sys/compile/BECILE i386 >Description: The version of vi that come with FreeBSD 4.1 can silently corrupt files on SIGINT when typing :wq in command mode >How-To-Repeat: 1/ open a file (~70K) 2/ in command mode enter :wq without validating with return 3/ in an other term, killall -INT vi 4/ vi terminate silently and the file is corrupted. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 8:40: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6A9EC37B43E for ; Thu, 7 Sep 2000 08:40:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA54695; Thu, 7 Sep 2000 08:40:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) by hub.freebsd.org (Postfix) with ESMTP id EB49F37B443 for ; Thu, 7 Sep 2000 08:39:33 -0700 (PDT) Received: (from ak03@localhost) by h132-197-97-45.gte.com (8.11.0/8.11.0) id e87FdWd07360; Thu, 7 Sep 2000 11:39:32 -0400 (EDT) (envelope-from ak03) Message-Id: <200009071539.e87FdWd07360@h132-197-97-45.gte.com> Date: Thu, 7 Sep 2000 11:39:32 -0400 (EDT) From: ak03@gte.com Reply-To: ak03@gte.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21092: Resolver errors are not reported properly in NIS-only case Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21092 >Category: bin >Synopsis: _gethostbynis function does not set h_errno on failure >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 07 08:40:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Alexander Kabaev >Release: FreeBSD 5.0-CURRENT i386 >Organization: Verizon Laboratories Inc. >Environment: FreeBSD kanpc.gte.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Sep 6 12:19:50 EDT 2000 root@kanpc.gte.com:/usr/src/sys/compile/KANPC i386 >Description: If NIS is selected as the only source used for the name resolution in host.conf or in nsswitch.conf on newer -CURRENT and then name resolution attempted for an unknown hostname using gethostbyname* functions, h_error is not getting set correctly when resolution fails. It seems like _gethostbynis function fails to set h_errno variable to the appropriate value when returning. All other functions in the family, i.e. _gethostbydns and _gethostbyht, do so. Without attached patch, the following command returns with strange message: [ak03@kanpc ~]$ ping sjkjss ping: cannot resolve sjkjss: Resolver Error 0 (no error) With patch applied, ping produces more reasonable output: [ak03@kanpc ~]$ ping sjkjss ping: cannot resolve sjkjss: Unknown host >How-To-Repeat: Comment out non-nis entries in host.conf or nsswitch.conf and try to ping some unknown host. Index: gethostbynis.c =================================================================== RCS file: /usr/ncvs/src/lib/libc/net/gethostbynis.c,v retrieving revision 1.10 diff -u -r1.10 gethostbynis.c --- gethostbynis.c 1999/08/28 00:00:06 1.10 +++ gethostbynis.c 2000/09/07 15:12:50 @@ -76,15 +76,20 @@ case AF_INET6: size = NS_IN6ADDRSZ; errno = EAFNOSUPPORT; + h_errno = NETDB_INTERNAL; return NULL; } if (domain == (char *)NULL) - if (yp_get_default_domain (&domain)) + if (yp_get_default_domain (&domain)) { + h_errno = NETDB_INTERNAL; return ((struct hostent *)NULL); + } - if (yp_match(domain, map, name, strlen(name), &result, &resultlen)) + if (yp_match(domain, map, name, strlen(name), &result, &resultlen)) { + h_errno = HOST_NOT_FOUND; return ((struct hostent *)NULL); + } /* avoid potential memory leak */ bcopy((char *)result, (char *)&ypbuf, resultlen); >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 9:10:15 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C289237B424 for ; Thu, 7 Sep 2000 09:10:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA60689; Thu, 7 Sep 2000 09:10:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from public.ndh.com (public.ndh.net [195.94.90.21]) by hub.freebsd.org (Postfix) with ESMTP id D286937B424 for ; Thu, 7 Sep 2000 09:05:14 -0700 (PDT) Received: from elan.firekeys.org (port2089.duesseldorf.ndh.net [195.227.37.89]) by public.ndh.com (8.9.3/8.8.0) with ESMTP id SAA26229 for ; Thu, 7 Sep 2000 18:05:06 +0200 (MET DST) Received: from esprit.firekeys.org (esprit.firekeys.org [192.168.1.101]) by elan.firekeys.org (8.11.0/8.11.0) with ESMTP id e87G5oX01608 for ; Thu, 7 Sep 2000 18:05:50 +0200 (CEST) (envelope-from sm@firekeys.org) Message-Id: <200009071605.e87G5o001105@esprit.firekeys.org> Date: Thu, 7 Sep 2000 18:05:50 +0200 (CEST) From: s.moeding@ndh.net Reply-To: s.moeding@ndh.net To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21093: New option for restore (patch) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21093 >Category: bin >Synopsis: New option for restore (patch) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Sep 07 09:10:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Stefan Moeding >Release: FreeBSD 4.1-STABLE i386 >Organization: FreeBSD: The Power to Serve >Environment: FreeBSD 4.1-STABLE i386 >Description: The vrestore command in Compaqs Tru64 Unix has an option '-D', which allows the vrestore command to perform a chdir into a given directory before performing the restore. This allows the simpler command line dump -0af - /usr | restore -rf - -D /mnt instead of dump -0 -a -f - /usr | (cd /mnt; restore -r -f -) >How-To-Repeat: >Fix: The attached patch adds the '-D' flag to the restore command. Stefan ============================================================================== diff -ruN restore/main.c /usr/src/sbin/restore/main.c --- restore/main.c Wed Sep 6 21:58:51 2000 +++ /usr/src/sbin/restore/main.c Thu Sep 7 17:41:01 2000 @@ -52,6 +52,7 @@ #include #include +#include #include #include #include @@ -99,9 +100,9 @@ inputdev = _PATH_DEFTAPE; obsolete(&argc, &argv); #ifdef KERBEROS -#define optlist "b:cdf:hikmNRrs:tuvxy" +#define optlist "b:cD:df:hikmNRrs:tuvxy" #else -#define optlist "b:cdf:himNRrs:tuvxy" +#define optlist "b:cD:df:himNRrs:tuvxy" #endif while ((ch = getopt(argc, argv, optlist)) != -1) switch(ch) { @@ -117,6 +118,12 @@ case 'c': cvtflag = 1; break; + case 'D': + if (chdir(optarg) < 0) + errx(1, + "error accessing file system %s; %s", + optarg, strerror(errno)); + break; case 'd': dflag = 1; break; @@ -293,11 +300,11 @@ usage() { (void)fprintf(stderr, "usage:\t%s\n\t%s\n\t%s\n\t%s\n\t%s\n", - "restore -i [-chkmuvy] [-b blocksize] [-f file] [-s fileno]", - "restore -r [-ckuvy] [-b blocksize] [-f file] [-s fileno]", - "restore -R [-ckuvy] [-b blocksize] [-f file] [-s fileno]", - "restore -x [-chkmuvy] [-b blocksize] [-f file] [-s fileno] [file ...]", - "restore -t [-chkuvy] [-b blocksize] [-f file] [-s fileno] [file ...]"); + "restore -i [-chkmuvy] [-b blocksize] [-D path] [-f file] [-s fileno]", + "restore -r [-ckuvy] [-b blocksize] [-D path] [-f file] [-s fileno]", + "restore -R [-ckuvy] [-b blocksize] [-D path] [-f file] [-s fileno]", + "restore -x [-chkmuvy] [-b blocksize] [-D path] [-f file] [-s fileno] [file ...]", + "restore -t [-chkuvy] [-b blocksize] [-D path] [-f file] [-s fileno] [file ...]"); done(1); } diff -ruN restore/restore.8 /usr/src/sbin/restore/restore.8 --- restore/restore.8 Wed Sep 6 21:58:51 2000 +++ /usr/src/sbin/restore/restore.8 Thu Sep 7 17:31:00 2000 @@ -44,24 +44,28 @@ .Fl i .Op Fl chkmNuvy .Op Fl b Ar blocksize +.Op Fl D Ar path .Op Fl f Ar file .Op Fl s Ar fileno .Nm restore .Fl R .Op Fl ckNuvy .Op Fl b Ar blocksize +.Op Fl D Ar path .Op Fl f Ar file .Op Fl s Ar fileno .Nm restore .Fl r .Op Fl ckNuvy .Op Fl b Ar blocksize +.Op Fl D Ar path .Op Fl f Ar file .Op Fl s Ar fileno .Nm restore .Fl t .Op Fl chkNuvy .Op Fl b Ar blocksize +.Op Fl D Ar path .Op Fl f Ar file .Op Fl s Ar fileno .Op file ... @@ -69,6 +73,7 @@ .Fl x .Op Fl chkmNuvy .Op Fl b Ar blocksize +.Op Fl D Ar path .Op Fl f Ar file .Op Fl s Ar fileno .Op file ... @@ -275,6 +280,11 @@ .Fl c flag disables this check, and only allows reading a dump in the old format. +.It Fl D Ar path +Specifies the destination path of where to restore the files. +Without the +.Fl D +flag, the files are restored to the current directory. .It Fl f Ar file Read the backup from .Ar file ; @@ -422,6 +432,17 @@ owner, mode, and time stamps for directories. .It Pa \&./restoresymtable information passed between incremental restores. +.El +.Sh EXAMPLES +The dump and +.Nm restore +commands may be used in a pipeline expression to copy file systems. +The following are typical commands, both equivalent: +.Bd -literal -offset indent +dump -0 -a -f - /usr | (cd /mnt; restore -r -f -) +dump -0af - /usr | restore -rf - -D /mnt +.Ed +.Pp .El .Sh SEE ALSO .Xr dump 8 , >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 9:20: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6E37537B422 for ; Thu, 7 Sep 2000 09:20:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA62213; Thu, 7 Sep 2000 09:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 7 Sep 2000 09:20:02 -0700 (PDT) Message-Id: <200009071620.JAA62213@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Matthew Jacob Subject: Re: bin/21093: New option for restore (patch) Reply-To: Matthew Jacob Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21093; it has been noted by GNATS. From: Matthew Jacob To: s.moeding@ndh.net Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/21093: New option for restore (patch) Date: Thu, 7 Sep 2000 09:12:06 -0700 (PDT) Other than making this look like Tru64's changes, why is this desirable? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 9:30: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 06C1537B422 for ; Thu, 7 Sep 2000 09:30:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA63662; Thu, 7 Sep 2000 09:30:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 7 Sep 2000 09:30:01 -0700 (PDT) Message-Id: <200009071630.JAA63662@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Stefan Moeding Subject: Re: bin/21093: New option for restore (patch) Reply-To: Stefan Moeding Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21093; it has been noted by GNATS. From: Stefan Moeding To: mjacob@feral.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/21093: New option for restore (patch) Date: Thu, 7 Sep 2000 18:20:12 +0200 (CEST) Matthew Jacob writes: > Other than making this look like Tru64's changes, why is this desirable? To avoid the (IMHO!) awkward subshell. Stefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 9:30: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4BA0837B423 for ; Thu, 7 Sep 2000 09:30:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA63672; Thu, 7 Sep 2000 09:30:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 7 Sep 2000 09:30:03 -0700 (PDT) Message-Id: <200009071630.JAA63672@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Matthew Jacob Subject: Re: bin/21093: New option for restore (patch) Reply-To: Matthew Jacob Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21093; it has been noted by GNATS. From: Matthew Jacob To: Stefan Moeding Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/21093: New option for restore (patch) Date: Thu, 7 Sep 2000 09:21:26 -0700 (PDT) IMO, this is not sufficient enough reason to add the feature. On Thu, 7 Sep 2000, Stefan Moeding wrote: > Matthew Jacob writes: > > > Other than making this look like Tru64's changes, why is this desirable? > > To avoid the (IMHO!) awkward subshell. > > Stefan > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 10: 0: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 396D737B42C for ; Thu, 7 Sep 2000 10:00:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id KAA67638; Thu, 7 Sep 2000 10:00:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 7 Sep 2000 10:00:02 -0700 (PDT) Message-Id: <200009071700.KAA67638@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Will Andrews Subject: Re: bin/21093: New option for restore (patch) Reply-To: Will Andrews Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21093; it has been noted by GNATS. From: Will Andrews To: Matthew Jacob , Stefan Moeding Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: bin/21093: New option for restore (patch) Date: Thu, 7 Sep 2000 11:51:02 -0500 On Thu, Sep 07, 2000 at 09:30:03AM -0700, Matthew Jacob wrote: > IMO, this is not sufficient enough reason to add the feature. I agree with Matt. If X feature does not require complex scripts, it's probably not going to be added to Y program (see df -c, etc.). -- Will Andrews GCS/E/S @d- s+:+ a--- C++ UB++++$ P+ L- E--- W+ N-- !o ?K w--- O- M+ V- PS+ PE++ Y+ PGP+>+++ t++ 5 X+ R+ tv+ b++ DI+++ D+ G++ e>++++ h! r- y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 11:40: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 98C0C37B423 for ; Thu, 7 Sep 2000 11:40:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA85287; Thu, 7 Sep 2000 11:40:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 7 Sep 2000 11:40:02 -0700 (PDT) Message-Id: <200009071840.LAA85287@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Matthew Jacob Subject: Re: bin/21093: New option for restore (patch) Reply-To: Matthew Jacob Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21093; it has been noted by GNATS. From: Matthew Jacob To: Will Andrews Cc: Stefan Moeding , FreeBSD-gnats-submit@FreeBSD.org Subject: Re: bin/21093: New option for restore (patch) Date: Thu, 7 Sep 2000 11:30:57 -0700 (PDT) > On Thu, Sep 07, 2000 at 09:30:03AM -0700, Matthew Jacob wrote: > > IMO, this is not sufficient enough reason to add the feature. > > I agree with Matt. If X feature does not require complex scripts, it's > probably not going to be added to Y program (see df -c, etc.). If there were some overriding other reason, like, "Amanda needs it", or "PicoBSD needs it and doesn't like to run subshells", or "subshells are bad", I could go for it. It's a trivial change. But, especially for dump (which should Die! Die! Die!), creeping featurism probably should be avoided. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 12:10:24 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from portnoy.lbl.gov (portnoy.lbl.gov [131.243.2.11]) by hub.freebsd.org (Postfix) with ESMTP id 30BA137B422 for ; Thu, 7 Sep 2000 12:10:20 -0700 (PDT) Received: (from jin@localhost) by portnoy.lbl.gov (8.10.0/8.10.0) id e87JAHC25955; Thu, 7 Sep 2000 12:10:17 -0700 (PDT) Date: Thu, 7 Sep 2000 12:10:17 -0700 (PDT) From: Jin Guojun (DSD staff) Message-Id: <200009071910.e87JAHC25955@portnoy.lbl.gov> To: freebsd-bugs@FreeBSD.ORG, mjacob@feral.com Subject: Re: bin/21093: New option for restore (patch) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > But, especially for dump (which should Die! Die! Die!), ... I have heard this before, but forgot what will be the replacement for dump? Any one knows what is a better back-up mechanism? -Jin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 12:11: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AA3CE37B422 for ; Thu, 7 Sep 2000 12:11:04 -0700 (PDT) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA29675; Thu, 7 Sep 2000 12:11:03 -0700 Date: Thu, 7 Sep 2000 12:07:26 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jin Guojun Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/21093: New option for restore (patch) In-Reply-To: <200009071910.e87JAHC25955@portnoy.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > But, especially for dump (which should Die! Die! Die!), ... > > I have heard this before, but forgot what will be the replacement for dump? > Any one knows what is a better back-up mechanism? I'm working on an NDMP implementation which will be the network transport portion of it. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 12:20: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 99A5537B446 for ; Thu, 7 Sep 2000 12:20:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA92105; Thu, 7 Sep 2000 12:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 7 Sep 2000 12:20:02 -0700 (PDT) Message-Id: <200009071920.MAA92105@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Terje Oseberg" Subject: Re: misc/21056: Apache 1.3 Virtual Hosts don't work on 4.0-RELEASE Reply-To: "Terje Oseberg" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/21056; it has been noted by GNATS. From: "Terje Oseberg" To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: misc/21056: Apache 1.3 Virtual Hosts don't work on 4.0-RELEASE Date: Thu, 07 Sep 2000 19:13:48 GMT It turns out that the problem is with the firewall/nat combination which I'm using. Basically, when someone from the internet is accessing the web server, the web server believes that they are comming in from the internal IP rather than the external IP. The way I fixed the problem was I added name virtual host entries to the Apache config file for the internal IP numbers as well as for the external IP numbers. I also added a name for my interal IP number in /etc/hosts so that Apache wouldn't have any problems looking it up. For my firewall configuration, I added to my kernel: options IPFIREWALL # Firewall options IPFIREWALL_VERBOSE # Print information about # dropped packets options IPFIREWALL_DEFAULT_TO_ACCEPT # Allow everything by # default options IPDIVERT # Divert sockets options IPFILTER # Kernel ipfilter support options IPFILTER_LOG # Ipfilter logging Then I added to my rc.config file: # Normal stuff network_interfaces="dc0 lo0" ifconfig_dc0="inet 216.15.83.94 netmask 255.255.255.224" defaultrouter="216.15.83.65" hostname="alpha.etiam.net" sendmail_enable="NO" # Run the sendmail daemon (or NO). # NAT stuff natd_enable="YES" natd_interface="dc0" ifconfig_dc0_alias0="inet 192.168.1.1 netmask 255.255.0.0" natd_flags="-redirect_address 192.168.1.1 216.15.83.94" # Firewall stuff. firewall_enable="YES" firewall_quiet="NO" firewall_type="OPEN" gateway_enable="YES" tcp_extensions="YES" ################################################################## To sum things up, there's definatly a strange problem with FreeBSD 4.0 which doesn't exist in pre-4.0 FreeBSD, but there's an easy workaround, so this problem isn't really a big issue. What's a big issue is the fact that it was extremely difficult to diagnose the problem. I'm posting this followup in order to help others who might want to have the same or similar setup resolve their problems more efficiently. (setup: Firewall, NAT, Apache, Name Virtual Hosts) Terje Oseberg _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 12:20:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0C3AC37B505 for ; Thu, 7 Sep 2000 12:20:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA92116; Thu, 7 Sep 2000 12:20:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 7 Sep 2000 12:20:03 -0700 (PDT) Message-Id: <200009071920.MAA92116@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Gerhard Sittig Subject: Re: bin/21017: mtree's "no such file" message at job's end Reply-To: Gerhard Sittig Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21017; it has been noted by GNATS. From: Gerhard Sittig To: FreeBSD-gnats-submit@freebsd.org Cc: Subject: Re: bin/21017: mtree's "no such file" message at job's end Date: Thu, 7 Sep 2000 21:08:16 +0200 On Wed, Sep 06, 2000 at 22:26 +0200, Gerhard Sittig wrote: > > [ ... a whole bunch trying to chase it down ... ] > > To summarize: It's not about the broken symlink in itself. > But readlink(2) fails at a broken symlink when something else > happened before -- but I don't know what this is. :< Could > bin/4961 (nonzero errno although there's no error) apply in > this case? I hate to disappoint the gentle reader here. :( Just when I thought I had a grip to the problem -- it turned out to not lead any further. Hmmm ... I expanded /usr/src/usr.sbin/mtree/compare.c with the following printout, did a make and made sure by means of strings(1) that I ran the newly compiled executable: ----- snip ------------------------------------------------------ # cvs diff -u compare.c Index: compare.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/mtree/compare.c,v retrieving revision 1.15.2.1 diff -u -r1.15.2.1 compare.c --- compare.c 2000/06/28 02:33:17 1.15.2.1 +++ compare.c 2000/09/06 20:07:23 @@ -362,6 +362,9 @@ static char lbuf[MAXPATHLEN]; register int len; + if (errno) { + warn("nonzero errno before readlink(2) in compare:rlink(%s)", name); + } if ((len = readlink(name, lbuf, sizeof(lbuf) - 1)) == -1) err(1, "line %d: %s", lineno, name); lbuf[len] = '\0'; # strings /usr/obj/usr/src/usr.sbin/mtree/mtree | grep nonzero nonzero errno before readlink(2) in compare:rlink(%s) # truss /usr/obj/usr/src/usr.sbin/mtree/mtree \ -K $KEYS -p /usr -x -X $DB/_usr.ex < $DB/_usr.db \ 2> ~/nonzero.err > ~/nonzero.std # tail -15 ~/nonzero.err read(0x3,0xbfbff520,0x400) = 1024 (0x400) read(0x3,0xbfbff520,0x400) = 1024 (0x400) read(0x3,0xbfbff520,0x400) = 168 (0xa8) read(0x3,0xbfbff520,0x400) = 0 (0x0) close(3) = 0 (0x0) readlink("X11",0x804ef80,1023) ERR#2 'No such file or directory' mtree: write(2,0xbfbff18c,7) = 7 (0x7) line 1361949: X11write(2,0xbfbff1bc,17) = 17 (0x11) : write(2,0xbfbff17c,2) = 2 (0x2) No such file or directory write(2,0xbfbff17c,26) = 26 (0x1a) sigprocmask(0x1,0x280605a0,0xbfbff824) = 0 (0x0) sigprocmask(0x3,0x280605b0,0x0) = 0 (0x0) write(1,0xd2dd000,2466) = 2466 (0x9a2) exit(0x1) process exit, rval = 256 ----- snap ------------------------------------------------------ In the end I can only see two reasons for mtree's failure: - readlink(2) barfs on broken symlinks under not known yet conditions (after "long" runs?) and does so unpredictably - mtree fails to chdir(2) to the new directory and therefor fails to read _any_ file there with a relative pathname The latter thought is new and comes from the fact, that "X11" on organ as well as "30_qmail.sh" on the third machine are the first files in their directories (and in the .db file's respective section). But this doesn't hold any longer when looking at "libtermcap_p.a" on stein which is "in the middle" of the listing and the .db dir section. Once I can find another spare moment I will try to dump the relevant info of the readlink invocation's environment (current dir, fts' root + path + filename, fts' already provided slink and access failure info, etc). And I will try to determine the "needed" depth of the tree somewhere between /usr and /usr/compat/linux/usr/lib to make the mtree run fail. 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-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 14:40:13 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 357CA37B43E for ; Thu, 7 Sep 2000 14:40:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA16806; Thu, 7 Sep 2000 14:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from laptop.firehouse.net (rdu25-12-043.nc.rr.com [24.25.12.43]) by hub.freebsd.org (Postfix) with ESMTP id 4EBC037B43F for ; Thu, 7 Sep 2000 14:31:52 -0700 (PDT) Received: (from root@localhost) by laptop.firehouse.net (8.11.0/8.11.0) id e87LViH25063; Thu, 7 Sep 2000 17:31:44 -0400 (EDT) (envelope-from abc) Message-Id: <200009072131.e87LViH25063@laptop.firehouse.net> Date: Thu, 7 Sep 2000 17:31:44 -0400 (EDT) From: abc@bsdi.com Reply-To: abc@bsdi.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: i386/21099: BSD/OS partition type wrong in boot0.s Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21099 >Category: i386 >Synopsis: BSD/OS partition type wrong in boot0.s >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 07 14:40:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Alan Clegg >Release: FreeBSD 4.1-STABLE i386 >Organization: BSDi >Environment: Dual-Boot Intel system with BSD/OS and FreeBSD >Description: bootmgr shows BSD/OS partitions as "Unknown". It seems that the BSD/OS partition is really 9f, not b7 as is found in /usr/src/sys/boot/i386/boot0/boot0.s >How-To-Repeat: Install bootmgr on a system with a BSD/OS partition. >Fix: *** boot0.s.orig Thu Sep 7 17:26:34 2000 --- boot0.s Thu Sep 7 17:26:53 2000 *************** *** 443,449 **** # These valuse indicate bootable types we know the names of # table1: .byte 0x1, 0x4, 0x6, 0x7, 0xb, 0xc, 0xe, 0x63, 0x83 ! .byte 0xa5, 0xa6, 0xa9, 0xb7 table1_end: # # These are offsets that match the known names above and point to the strings --- 443,449 ---- # These valuse indicate bootable types we know the names of # table1: .byte 0x1, 0x4, 0x6, 0x7, 0xb, 0xc, 0xe, 0x63, 0x83 ! .byte 0xa5, 0xa6, 0xa9, 0x9f table1_end: # # These are offsets that match the known names above and point to the strings >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 15:14:27 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id CCB6237B422 for ; Thu, 7 Sep 2000 15:14:23 -0700 (PDT) Received: (qmail 18782 invoked from network); 7 Sep 2000 22:14:21 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 7 Sep 2000 22:14:21 -0000 Date: Fri, 8 Sep 2000 09:14:17 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Sheldon Hearn Cc: Gerhard Sittig , freebsd-bugs@FreeBSD.ORG Subject: Re: bin/21017: mtree's "no such file" message at job's end In-Reply-To: <55234.968311479@axl.fw.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Wed, 06 Sep 2000 22:32:22 +0200, Gerhard Sittig wrote: > > > I'm absolutely not clear about the PR procedure. Whom do I email > > to? Is freebsd-gnats-submit the relevant address or is it you? > > No, freebsd-gnats-submit is good. Using that address ensures that your > comments are entered into the Audit Trail for the PR. Your message will > also be copied to freebsd-bugs, freebsd-ports, or whomever's address > appears in the Responsible field of the PR. Does it work to put only the subject line in a reply to freebsd-gnats-submit? How do you reply if you don't have old gnats mail to reply to. I'd like to reply from within edit-pr. > If you only mail freebsd-bugs, your comments don't reach the Audit Trail > of the PR. :-( It's annoying that gnats doesn't put itself in the cc list for all mail that it sends. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Sep 7 17:40: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 61A5F37B424 for ; Thu, 7 Sep 2000 17:40:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA44421; Thu, 7 Sep 2000 17:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from monsta.privatelabs.com (ppp197.max-01.intercom.com [198.143.0.197]) by hub.freebsd.org (Postfix) with ESMTP id 2676237B422 for ; Thu, 7 Sep 2000 17:34:25 -0700 (PDT) Received: (from mi@localhost) by monsta.privatelabs.com (8.9.3/8.9.3) id UAA71332; Thu, 7 Sep 2000 20:32:32 -0400 (EDT) (envelope-from mi) Message-Id: <200009080032.UAA71332@monsta.privatelabs.com> Date: Thu, 7 Sep 2000 20:32:32 -0400 (EDT) From: Mikhail Teterin Reply-To: mi@aldan.algebra.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21100: sshd does not consider authorized_keys2 unless 2 is the _only_ protocol Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21100 >Category: bin >Synopsis: sshd does not consider authorized_keys2 unless 2 is the _only_ protocol >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 07 17:40:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Mikhail Teterin >Release: FreeBSD 4.1-RC i386 >Organization: Virtual Estates, Inc. >Environment: >Description: A particular account wishes to only use DSA keys and hence the SSH2 protocol. Unfortunately, sshd does not even look at the ~/.ssh/authorized_keys2 unless the /etc/ssh/sshd_config states ``Protocol 2''. Listing (as the man-page suggests) both 1 and 2 on the line does not work -- the server insists on password. Removing 1 helps (and proves that everything else is configured properly), but prevents other accounts from logging in using older ssh-clients. >How-To-Repeat: See description. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 0:37:34 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9940237B422; Fri, 8 Sep 2000 00:37:32 -0700 (PDT) Received: (from rnordier@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA14426; Fri, 8 Sep 2000 00:37:32 -0700 (PDT) (envelope-from rnordier@FreeBSD.org) Date: Fri, 8 Sep 2000 00:37:32 -0700 (PDT) From: Message-Id: <200009080737.AAA14426@freefall.freebsd.org> To: rnordier@FreeBSD.org, freebsd-bugs@FreeBSD.org, rnordier@FreeBSD.org Subject: Re: i386/21099: BSD/OS partition type wrong in boot0.s Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: BSD/OS partition type wrong in boot0.s Responsible-Changed-From-To: freebsd-bugs->rnordier Responsible-Changed-By: rnordier Responsible-Changed-When: Fri Sep 8 00:36:40 PDT 2000 Responsible-Changed-Why: I'll handle this. http://www.freebsd.org/cgi/query-pr.cgi?pr=21099 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 1:36:34 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 0877C37B422 for ; Fri, 8 Sep 2000 01:36:31 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13XJe5-0000XL-00; Fri, 08 Sep 2000 10:36:25 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id KAA08716; Fri, 8 Sep 2000 10:36:22 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 8477; Fri Sep 8 10:34:46 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13XJcU-0003Wb-00; Fri, 08 Sep 2000 10:34:46 +0200 From: Sheldon Hearn To: Bruce Evans Cc: Gerhard Sittig , freebsd-bugs@freebsd.org Subject: Re: bin/21017: mtree's "no such file" message at job's end In-reply-to: Your message of "Fri, 08 Sep 2000 09:14:17 +1100." Date: Fri, 08 Sep 2000 10:34:46 +0200 Message-ID: <13552.968402086@axl.fw.uunet.co.za> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 08 Sep 2000 09:14:17 +1100, Bruce Evans wrote: > Does it work to put only the subject line in a reply to freebsd-gnats-submit? Yes. As far as I know, all the GNATS engine looks for on the Subject line is the first number. > I'd like to reply from within edit-pr. I do that a lot, by changing the status of an open PR to ``feedback'' and then merrily typing my message when prompted for the reason for the status change. > It's annoying that gnats doesn't put itself in the cc list for all mail > that it sends. Steve Price might be able to help us with that. It doesn't bug me enough to bother. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 5:40: 0 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B7FA537B422; Fri, 8 Sep 2000 05:39:59 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA63660; Fri, 8 Sep 2000 05:39:59 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Fri, 8 Sep 2000 05:39:59 -0700 (PDT) From: Message-Id: <200009081239.FAA63660@freefall.freebsd.org> To: s.moeding@ndh.net, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/21093: New option for restore (patch) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: New option for restore (patch) State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Fri Sep 8 05:39:43 PDT 2000 State-Changed-Why: So can we close this, or what? :-) http://www.freebsd.org/cgi/query-pr.cgi?pr=21093 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 5:49:23 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7D52337B423; Fri, 8 Sep 2000 05:49:22 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA64842; Fri, 8 Sep 2000 05:49:22 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Fri, 8 Sep 2000 05:49:22 -0700 (PDT) From: Message-Id: <200009081249.FAA64842@freefall.freebsd.org> To: Gerhard.Sittig@gmx.net, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/21017: mtree "no such file" message at job's end Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: mtree "no such file" message at job's end State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Fri Sep 8 05:48:52 PDT 2000 State-Changed-Why: Gerhard is still trying to get a handle on this. Anyone else seeing the problem, please feel free to chirp up. http://www.freebsd.org/cgi/query-pr.cgi?pr=21017 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 5:50: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A21FC37B424 for ; Fri, 8 Sep 2000 05:50:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA64926; Fri, 8 Sep 2000 05:50:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 8 Sep 2000 05:50:01 -0700 (PDT) Message-Id: <200009081250.FAA64926@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: misc/21056: Apache 1.3 Virtual Hosts don't work on 4.0-RELEASE Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/21056; it has been noted by GNATS. From: Sheldon Hearn To: "Terje Oseberg" Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/21056: Apache 1.3 Virtual Hosts don't work on 4.0-RELEASE Date: Fri, 08 Sep 2000 14:41:06 +0200 On Thu, 07 Sep 2000 12:20:02 MST, "Terje Oseberg" wrote: > To sum things up, there's definatly a strange problem with FreeBSD 4.0 > which doesn't exist in pre-4.0 FreeBSD, but there's an easy workaround, > so this problem isn't really a big issue. It might be interesting to hear whether you experience similar problems with FreeBSD 4.1-RELEASE or 4.1-STABLE. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 5:50:15 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D74D437B440; Fri, 8 Sep 2000 05:50:13 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA65006; Fri, 8 Sep 2000 05:50:13 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Fri, 8 Sep 2000 05:50:13 -0700 (PDT) From: Message-Id: <200009081250.FAA65006@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, nectar@FreeBSD.org Subject: Re: bin/21092: _gethostbynis function does not set h_errno on failure Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: _gethostbynis function does not set h_errno on failure Responsible-Changed-From-To: freebsd-bugs->nectar Responsible-Changed-By: sheldonh Responsible-Changed-When: Fri Sep 8 05:50:03 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21092 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 6: 6:27 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F309E37B422; Fri, 8 Sep 2000 06:06:25 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA68750; Fri, 8 Sep 2000 06:06:25 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Fri, 8 Sep 2000 06:06:25 -0700 (PDT) From: Message-Id: <200009081306.GAA68750@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, kris@FreeBSD.org Subject: Re: bin/21100: sshd does not consider authorized_keys2 unless 2 is the _only_ protocol Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: sshd does not consider authorized_keys2 unless 2 is the _only_ protocol Responsible-Changed-From-To: freebsd-bugs->kris Responsible-Changed-By: sheldonh Responsible-Changed-When: Fri Sep 8 06:06:10 PDT 2000 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=21100 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 6:30: 0 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7573B37B507; Fri, 8 Sep 2000 06:29:58 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA71717; Fri, 8 Sep 2000 06:29:58 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Fri, 8 Sep 2000 06:29:58 -0700 (PDT) From: Message-Id: <200009081329.GAA71717@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, joe@FreeBSD.org Subject: Re: bin/21086: Annoying little bug using ls -G with colorized prompts. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Annoying little bug using ls -G with colorized prompts. Responsible-Changed-From-To: freebsd-bugs->joe Responsible-Changed-By: sheldonh Responsible-Changed-When: Fri Sep 8 06:29:34 PDT 2000 Responsible-Changed-Why: Joe, could you check out whether the problem lies in ls(1) or bash? http://www.freebsd.org/cgi/query-pr.cgi?pr=21086 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 6:32:10 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F015E37B449; Fri, 8 Sep 2000 06:32:08 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA72134; Fri, 8 Sep 2000 06:32:08 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Fri, 8 Sep 2000 06:32:08 -0700 (PDT) From: Message-Id: <200009081332.GAA72134@freefall.freebsd.org> To: sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org, tanimura@FreeBSD.org Subject: Re: i386/21087: ed driver incorrectly fails probe for ISA HP PCLAN+ Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: ed driver incorrectly fails probe for ISA HP PCLAN+ Responsible-Changed-From-To: freebsd-bugs->tanimura Responsible-Changed-By: sheldonh Responsible-Changed-When: Fri Sep 8 06:30:40 PDT 2000 Responsible-Changed-Why: Tanimura-san, could you take a look at this? http://www.freebsd.org/cgi/query-pr.cgi?pr=21087 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 6:37:14 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from sentry.granch.com (sentry.granch.com [212.109.197.135]) by hub.freebsd.org (Postfix) with ESMTP id 788C837B42C for ; Fri, 8 Sep 2000 06:37:09 -0700 (PDT) Received: (from shelton@localhost) by sentry.granch.com (8.9.3/8.9.3) id UAA00453; Fri, 8 Sep 2000 20:36:43 +0700 (NOVST) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 08 Sep 2000 20:36:43 +0700 (NOVST) Reply-To: "Rashid N. Achilov" Organization: Granch Ltd. From: "Rashid N. Achilov" To: Robin Carey Subject: RE: cons25 Cc: bugs@FreeBSD.ORG Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 06-Sep-00 Robin Carey wrote: > The default terminal-type for ttyv0-7 in FreeBSD-4.0 is "cons25" (set in > /etc/ttys). > > This would appear to be a non-standard terminal-type, as it causes me > problems when I rlogin/telnet to other systems, i.e. they do not recognise > this terminal-type. I've come across the same problem with Linux and their > "linux" terminal-type. What is a "standard" type and what is a "non-standard", and who established, that these types are "standard", but these is "non-standard"? For FreeBSD cons25 is a standard terminal type, and I don't see a reason to change it to something else. If you need it, you can immediately afterfinishing install edit the /etc/ttys file to your favorite terminal type (for me this is pc3r - full and right support for Russian locale, only one bug with 'Del' key) and restart system or ask administrators of other systems to add cons25 in their terminal databases. -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), Brainbench ID: 28514 Granch Ltd. lead engineer, e-mail: achilov@granch.ru tel/fax (383-2) 24-2363 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 6:40: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E11D837B506 for ; Fri, 8 Sep 2000 06:40:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA73126; Fri, 8 Sep 2000 06:40:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 8 Sep 2000 06:40:02 -0700 (PDT) Message-Id: <200009081340.GAA73126@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Sheldon Hearn Subject: Re: misc/21089: vi silently corrupt open file on SIGINT when entering :wq in command mode Reply-To: Sheldon Hearn Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/21089; it has been noted by GNATS. From: Sheldon Hearn To: lfrigault@teaser.fr Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/21089: vi silently corrupt open file on SIGINT when entering :wq in command mode Date: Fri, 08 Sep 2000 15:33:40 +0200 On Thu, 07 Sep 2000 02:50:34 MST, lfrigault@teaser.fr wrote: > >Number: 21089 > >Category: misc > >Synopsis: vi silently corrupt open file on SIGINT when entering :wq in command mode As a datapoint, I don't see this behaviour in the development branch. In fact, SIGINT doesn't even kill vi when it's in command state! It just aborts out of command-state, as expected. Can anyone else confirm the results reported? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 6:49:55 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5D50F37B422 for ; Fri, 8 Sep 2000 06:49:51 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id AAA13494; Sat, 9 Sep 2000 00:49:28 +1100 Date: Sat, 9 Sep 2000 00:49:24 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Sheldon Hearn Cc: Gerhard Sittig , freebsd-bugs@FreeBSD.ORG Subject: Re: bin/21017: mtree's "no such file" message at job's end In-Reply-To: <13552.968402086@axl.fw.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 8 Sep 2000, Sheldon Hearn wrote: > On Fri, 08 Sep 2000 09:14:17 +1100, Bruce Evans wrote: > > I'd like to reply from within edit-pr. > > I do that a lot, by changing the status of an open PR to ``feedback'' > and then merrily typing my message when prompted for the reason for the > status change. I do that too, but it is only right the first time, if at all, unless you make a mess of the history by changing back and forth. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 7: 0: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C7E6637B440 for ; Fri, 8 Sep 2000 07:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA75721; Fri, 8 Sep 2000 07:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id D5FAA37B423; Fri, 8 Sep 2000 06:58:15 -0700 (PDT) Message-Id: <20000908135815.D5FAA37B423@hub.freebsd.org> Date: Fri, 8 Sep 2000 06:58:15 -0700 (PDT) From: khigh@scioto.net To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: i386/21117: When booting 4.0 install disk receive this error: panic:isa_wait: incorrect qcb returned Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21117 >Category: i386 >Synopsis: When booting 4.0 install disk receive this error: panic:isa_wait: incorrect qcb returned >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 08 07:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Kevin High >Release: 4.0 >Organization: Scioto Net >Environment: Compaq 1500 server >Description: When I am using the 4.0 install disks, seems to find all the correct hardware but then errors with panic: ida_wait: incorrect qcb returned. I booted with the 4.1 install disks and was able to load 4.0, however when I boot the system, I receive the panic: ida_wait: incorrect qcb returned error. Please help. thanks kevin high khigh@scioto.net >How-To-Repeat: Boot the system >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 7: 6: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6978637B424; Fri, 8 Sep 2000 07:06:07 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA78343; Fri, 8 Sep 2000 07:06:07 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Fri, 8 Sep 2000 07:06:07 -0700 (PDT) From: Message-Id: <200009081406.HAA78343@freefall.freebsd.org> To: khigh@scioto.net, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: i386/21117: When booting 4.0 install disk receive this error: panic:isa_wait: incorrect qcb returned Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: When booting 4.0 install disk receive this error: panic:isa_wait: incorrect qcb returned State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Fri Sep 8 07:05:09 PDT 2000 State-Changed-Why: The use of install diskettes for the installation of a release other than the one for which they were designed is not supported. Please let us know what happens when you use 4.1-RELEASE diskettes to install 4.1-RELEASE. http://www.freebsd.org/cgi/query-pr.cgi?pr=21117 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 7:38:40 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from public.ndh.com (public.ndh.net [195.94.90.21]) by hub.freebsd.org (Postfix) with ESMTP id B94C137B422; Fri, 8 Sep 2000 07:38:37 -0700 (PDT) Received: from elan.firekeys.org (port2090.duesseldorf.ndh.net [195.227.37.90]) by public.ndh.com (8.9.3/8.8.0) with ESMTP id QAA04303; Fri, 8 Sep 2000 16:38:33 +0200 (MET DST) Received: from esprit.firekeys.org (esprit.firekeys.org [192.168.1.101]) by elan.firekeys.org (8.11.0/8.11.0) with ESMTP id e88EdUR00696; Fri, 8 Sep 2000 16:39:30 +0200 (CEST) (envelope-from sm@firekeys.org) Date: Fri, 8 Sep 2000 16:39:28 +0200 (CEST) Message-Id: <200009081439.e88EdSe00385@esprit.firekeys.org> From: Stefan Moeding To: sheldonh@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org In-reply-to: <200009081239.FAA63660@freefall.freebsd.org> (sheldonh@FreeBSD.org) Subject: Re: bin/21093: New option for restore (patch) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Reply-To: s.moeding@ndh.net Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sheldonh writes: > Synopsis: New option for restore (patch) > State-Changed-From-To: open->feedback > State-Changed-By: sheldonh > State-Changed-When: Fri Sep 8 05:39:43 PDT 2000 > State-Changed-Why: > So can we close this, or what? :-) Since there seems to be nobody else who regards this as useful: Yes, go ahead and close the pr. Stefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 7:42:49 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3ADF137B42C; Fri, 8 Sep 2000 07:42:48 -0700 (PDT) Received: (from sheldonh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA83925; Fri, 8 Sep 2000 07:42:48 -0700 (PDT) (envelope-from sheldonh@FreeBSD.org) Date: Fri, 8 Sep 2000 07:42:48 -0700 (PDT) From: Message-Id: <200009081442.HAA83925@freefall.freebsd.org> To: s.moeding@ndh.net, sheldonh@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/21093: New option for restore (patch) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: New option for restore (patch) State-Changed-From-To: feedback->closed State-Changed-By: sheldonh State-Changed-When: Fri Sep 8 07:41:59 PDT 2000 State-Changed-Why: Nobody seems to think this should be included. The patch remains here for all to see, of course. http://www.freebsd.org/cgi/query-pr.cgi?pr=21093 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 7:50:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BFA2537B440 for ; Fri, 8 Sep 2000 07:50:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA85047; Fri, 8 Sep 2000 07:50:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from sneakerz.org (sneakerz.org [207.154.226.254]) by hub.freebsd.org (Postfix) with ESMTP id EBF2137B42C for ; Fri, 8 Sep 2000 07:45:40 -0700 (PDT) Received: by sneakerz.org (Postfix, from userid 1023) id 988115D006; Fri, 8 Sep 2000 09:45:35 -0500 (CDT) Message-Id: <20000908144535.988115D006@sneakerz.org> Date: Fri, 8 Sep 2000 09:45:35 -0500 (CDT) From: missnglnk@sneakerz.org Reply-To: missnglnk@sneakerz.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/21118: Multiple problems in ipfw's stateful code Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21118 >Category: kern >Synopsis: Multiple problems in ipfw's stateful code >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 08 07:50:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Lawrence N. King >Release: FreeBSD 4.1-FEARSOME-20000818 i386 >Organization: >Environment: FreeBSD 4.0-RELEASE FreeBSD 4.1-STABLE FreeBSD 5.0-CURRENT Above version with IPFIREWALL defined in kernel >Description: When a connection is made and kept track of (keep-state): 1) Connections expire prematurely if dynamic ACK lifetime is is greater than the keepalive interval. 2) Expired connections aren't actually expired, but are allowed to continue (TCP connections are extended by the dynamic RST lifetime even though they have expired, and all other protocol connections are extended by the dynamic short lifetime). 3) Expired connections aren't cleaned from the state table unless the next dynamic rule added reaches the maximum amount of dynamic rules. 4) A new state is installed for any packet which matches the rule (with keep-state), regardless of whether its not a TCP packet with the SYN flag set, or if its an ICMP query packet. >How-To-Repeat: ipfw -f flush ipfw add check-state ipfw add allow ip from any to any via fxp0 out keep-state ipfw add deny ip from any to any Now issue a couple of connections, I did SSH, a new state was installed, the rule expired, but I still could continue my SSH connection since its expiration time was being extended by the dynamic RST lifetime. Instead of issuing a TCP packet with the SYN flag set, issue a TCP packet with any other flag set, and a new state is installed for this packet. Let a couple of dynamic rules timeout (you can check via ipfw show), and watch as they linger around, they aren't cleaned out until the amount of dynamic rules is equal to the maximum and a new rule is being installed. >Fix: Nothing for problem 1, but solutions for 2-4 are in the below patch: -- snip -- --- sys/netinet/ip_fw.c.orig Wed Sep 6 21:01:07 2000 +++ sys/netinet/ip_fw.c Wed Sep 6 21:40:55 2000 @@ -735,4 +735,3 @@ break ; - default: -#if 0 + case TH_RST | (TH_RST << 8) : /* @@ -741,7 +740,18 @@ */ - if ( (q->state & ((TH_RST << 8)|TH_RST)) == 0) - printf("invalid state: 0x%x\n", q->state); -#endif + printf("invalid state: 0x%x\n", q->state); q->expire = time_second + dyn_rst_lifetime ; break ; + default: + /* + * A TCP packet found in unknown state, drop it. + */ + DEB(printf("packet should be dropped (state: 0x%x)\n", q->state)); + old_q = q ; + if (prev != NULL) + prev->next = q = q->next ; + else + ipfw_dyn_v[i] = q = q->next ; + dyn_count-- ; + free(old_q, M_IPFW); + break ; } @@ -838,4 +848,7 @@ } - if (dyn_count >= dyn_max) /* try remove old ones... */ - remove_dyn_rule(NULL, 0 /* expire */); + /* + * Unconditionally remove expired states. + */ + remove_dyn_rule(NULL, 0 /* expire */); + if (dyn_count >= dyn_max) { @@ -1277,4 +1290,43 @@ */ - if (q == NULL && f->fw_flg & IP_FW_F_KEEP_S) - install_state(chain); + if (q == NULL && f->fw_flg & IP_FW_F_KEEP_S) { + /* + * Instead of unconditionally adding a new state, + * check the protocol and flags, and add a new state + * or ignore packet. + */ + switch(proto) { + case IPPROTO_TCP: + if (flags & TH_SYN) { + DEB(printf("-- installing state for TCP packet\n")); + install_state(chain); + } else { + DEB(printf("-- invalid TCP connection state\n")); + } + break; + case IPPROTO_UDP: + DEB(printf("-- installing state for UDP packet\n")); + install_state(chain); + break; + case IPPROTO_ICMP: + if (is_icmp_query(ip)) { + DEB(printf("-- installing state for ICMP packet\n")); + install_state(chain); + } else { + DEB(printf("-- invalid ICMP connection state\n")); + } + break; + default: + /* + * Unknown packet, if default is to accept all + * packets, add a new state, otherwise ignore. + */ +#ifdef IPFIREWALL_DEFAULT_TO_ACCEPT + DEB(printf("-- installing state for unknown packet\n")); + install_state(chain); +#else + DEB(printf("invalid unknown protocol connection state\n")); +#endif + break; + } + } #endif -- snip -- >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 8: 3:50 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7818337B422 for ; Fri, 8 Sep 2000 08:03:46 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id BAA16793; Sat, 9 Sep 2000 01:59:24 +1100 Date: Sat, 9 Sep 2000 01:59:20 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Sheldon Hearn Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: misc/21089: vi silently corrupt open file on SIGINT when entering :wq in command mode In-Reply-To: <200009081340.GAA73126@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 8 Sep 2000, Sheldon Hearn wrote: > > >Synopsis: vi silently corrupt open file on SIGINT when entering :wq in > command mode > > As a datapoint, I don't see this behaviour in the development branch. > In fact, SIGINT doesn't even kill vi when it's in command state! It > just aborts out of command-state, as expected. > > Can anyone else confirm the results reported? It happens here. An 89288-byte file was truncated to 3290 bytes. (SIGINT never kills vi directly since vi has to catch it to clean up. I wish it wouldn't catch it when it can't clean up due to a disk-full error.) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 8:10: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F04B237B440 for ; Fri, 8 Sep 2000 08:10:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA90454; Fri, 8 Sep 2000 08:10:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 02BC137B423; Fri, 8 Sep 2000 08:03:20 -0700 (PDT) Message-Id: <20000908150320.02BC137B423@hub.freebsd.org> Date: Fri, 8 Sep 2000 08:03:20 -0700 (PDT) From: STRICKLIN@WWW.COM To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: misc/21119: SOMEONE NAMED HELO LUKE.WWWCOM,USING WEB-MAILER 3.0 TO ESND ME E-MAIL IN THE NAME OF MAILER-DAEMON Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21119 >Category: misc >Synopsis: SOMEONE NAMED HELO LUKE.WWWCOM,USING WEB-MAILER 3.0 TO ESND ME E-MAIL IN THE NAME OF MAILER-DAEMON >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Fri Sep 08 08:10:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: JAMES STRICKLIN >Release: THIS MAIL COLDNOT BE DELIVERD >Organization: WWW.COM >Environment: BAD >Description: THIS MESSAGE COULNNOT BE DELIVERD ,I HAVE YOUR DELIVERD TO LINE >How-To-Repeat: DONT >Fix: TELL THE DAEMON TO NOT SEND MORE E-MAIL >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 8:12:45 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from sentinel.office1.bg (sentinel.office1.bg [195.24.48.182]) by hub.freebsd.org (Postfix) with SMTP id AAAC337B43E for ; Fri, 8 Sep 2000 08:12:39 -0700 (PDT) Received: (qmail 63312 invoked by uid 1001); 8 Sep 2000 15:10:42 -0000 Date: Fri, 8 Sep 2000 18:10:42 +0300 From: Peter Pentchev To: Sheldon Hearn Cc: freebsd-bugs@FreeBSD.org Subject: Re: misc/21089: vi silently corrupt open file on SIGINT when entering :wq in command mode Message-ID: <20000908181042.B62958@ringwraith.office1.bg> References: <200009081340.GAA73126@freefall.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: <200009081340.GAA73126@freefall.freebsd.org>; from sheldonh@uunet.co.za on Fri, Sep 08, 2000 at 06:40:02AM -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mmmm excuse the probably dumb question, but.. are you sure you are really using vi, and not some aliased/symlinked other editor? One of the first things I do on any freshly-installed system is to install vim and symlink it to vi *and* put it in my shell aliases file. For the record, RELENG_4's /usr/bin/vi writes out the file on a SIGINT received before hitting Enter on a command line containing "wq", just as the submitter described. Anyway, this might be not related to vi at all, but to some library it is using; I have just checked out the HEAD and RELENG_4 sources for usr.bin/vi/, and the only thing diff -urN shows is a locale catalog addition in a Makefile. I am going to look at libncurses, which seems to be the only library referenced in the vi Makefile; has something changed in signal handling in -current's ncurses lately, so that this should work for you and not for me? G'luck, Peter -- This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. On Fri, Sep 08, 2000 at 06:40:02AM -0700, Sheldon Hearn wrote: > The following reply was made to PR misc/21089; it has been noted by GNATS. > > On Thu, 07 Sep 2000 02:50:34 MST, lfrigault@teaser.fr wrote: > > > >Number: 21089 > > >Category: misc > > >Synopsis: vi silently corrupt open file on SIGINT when entering :wq in > command mode > > As a datapoint, I don't see this behaviour in the development branch. > In fact, SIGINT doesn't even kill vi when it's in command state! It > just aborts out of command-state, as expected. > > Can anyone else confirm the results reported? > > Ciao, > Sheldon. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-bugs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 8:20:28 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D81A337B443; Fri, 8 Sep 2000 08:20:27 -0700 (PDT) Received: (from nra@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA92644; Fri, 8 Sep 2000 08:20:27 -0700 (PDT) (envelope-from nra@FreeBSD.org) Date: Fri, 8 Sep 2000 08:20:27 -0700 (PDT) From: Message-Id: <200009081520.IAA92644@freefall.freebsd.org> To: STRICKLIN@WWW.COM, nra@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/21119: SOMEONE NAMED HELO LUKE.WWWCOM,USING WEB-MAILER 3.0 TO ESND ME E-MAIL IN THE NAME OF MAILER-DAEMON Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: SOMEONE NAMED HELO LUKE.WWWCOM,USING WEB-MAILER 3.0 TO ESND ME E-MAIL IN THE NAME OF MAILER-DAEMON State-Changed-From-To: open->closed State-Changed-By: nra State-Changed-When: Fri Sep 8 08:20:11 PDT 2000 State-Changed-Why: Invalid PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=21119 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 8:37:48 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from c003.sfo.cp.net (c003-h010.c003.sfo.cp.net [209.228.14.119]) by hub.freebsd.org (Postfix) with SMTP id 16F9937B43E for ; Fri, 8 Sep 2000 08:37:46 -0700 (PDT) Received: (cpmta 2521 invoked from network); 8 Sep 2000 08:37:45 -0700 Date: 8 Sep 2000 08:37:45 -0700 Message-ID: <20000908153745.2520.cpmta@c003.sfo.cp.net> X-Sent: 8 Sep 2000 15:37:45 GMT Received: from [170.143.5.55] by mail.www.com with HTTP; 08 Sep 2000 08:37:45 PDT Content-Type: text/plain; charset=unicode-1-1-utf-8 Content-Disposition: inline Mime-Version: 1.0 To: UNKNOWN@www.com, SENDER@www.com From: stricklin@www.com Cc: STRICKLIN@WWW.COM, nra@FreeBSD.org, freebsd-bugs@FreeBSD.org X-Mailer: Web Mail 3.0 Subject: Re: misc/21119: SOMEONE NAMED HELO LUKE.WWWCOM,USING WEB-MAILER 3.0 TO ESND ME E-MAIL IN THE NAME OF MAILER-DAEMON Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Synopsis: SOMEONE NAMED HELO LUKE.WWWCOM,USING WEB-MAILER 3.0 TO ESND ME E-MAIL IN THE NAME OF MAILER-DAEMON > > State-Changed-From-To: open->closed > State-Changed-By: nra > State-Changed-When: Fri Sep 8 08:20:11 PDT 2000 > State-Changed-Why: > Invalid PR. > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=21119 ______________________________________________________ Listen to your favorite music while you work! - http://www.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 8:40: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C0FDF37B424 for ; Fri, 8 Sep 2000 08:40:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA95864; Fri, 8 Sep 2000 08:40:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 8 Sep 2000 08:40:02 -0700 (PDT) Message-Id: <200009081540.IAA95864@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Laurent Frigault Subject: Re: misc/21089: vi silently corrupt open file on SIGINT when entering :wq in command mode Reply-To: Laurent Frigault Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/21089; it has been noted by GNATS. From: Laurent Frigault To: Sheldon Hearn Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/21089: vi silently corrupt open file on SIGINT when entering :wq in command mode Date: Fri, 8 Sep 2000 17:32:24 +0200 On Fri, Sep 08, 2000 at 03:33:40PM +0200, Sheldon Hearn wrote: > > >Number: 21089 > > >Category: misc > > >Synopsis: vi silently corrupt open file on SIGINT when entering :wq in > command mode > > As a datapoint, I don't see this behaviour in the development branch. > In fact, SIGINT doesn't even kill vi when it's in command state! It > just aborts out of command-state, as expected. > > Can anyone else confirm the results reported? If you enter : SIGINT has no effect If you enter :w The file is corrupted on SIGINT and you have a message : ================================= +=+=+=+=+=+=+=+ :w Interrupted Press any key to continue: ================================= and the file is save corrupted but you can re-write it with :wq If you enter :wq The file is save corrupted on SIGINT and vi terminate silently I have reproduced the problem under : FreeBSD victor.teaser.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Wed Aug 9 16:34:08 CEST 2000 lwa@victor.teaser.fr:/usr/src/sys/compile/VICTOR i386 Hope, this helps Laurent -- Laurent Frigault | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 12:20:10 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5A75537B507 for ; Fri, 8 Sep 2000 12:20:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA31990; Fri, 8 Sep 2000 12:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from icc.cgu.chel.su (gw.csu.ru [195.54.14.5]) by hub.freebsd.org (Postfix) with ESMTP id 21A8237B43E for ; Fri, 8 Sep 2000 12:11:13 -0700 (PDT) Received: from mail.cgu.chel.su (mail.cgu.chel.su [195.54.14.68]) by icc.cgu.chel.su (8.9.3/8.9.2) with ESMTP id BAA87136 for ; Sat, 9 Sep 2000 01:10:32 +0600 (ESS) (envelope-from ilia@jane.cgu.chel.su) Received: (from uucp@localhost) by mail.cgu.chel.su (8.9.3/8.8.6) with UUCP id WAA59953 for FreeBSD-gnats-submit@freebsd.org; Fri, 8 Sep 2000 22:07:11 +0600 (ESS) Received: (from ilia@localhost) by jane.cgu.chel.su (8.11.0/8.9.2) id e88G1pm00650; Fri, 8 Sep 2000 22:01:51 +0600 (ESS) (envelope-from ilia) Message-Id: <200009081601.e88G1pm00650@jane.cgu.chel.su> Date: Fri, 8 Sep 2000 22:01:51 +0600 (ESS) From: Ilia Chipitsine Reply-To: ilia@jane.cgu.chel.su To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: gnu/21128: a proposed patch for uucp package Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21128 >Category: gnu >Synopsis: a proposed patch for uucp package >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Fri Sep 08 12:20:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Ilia Chipitsine >Release: FreeBSD 4.1-STABLE i386 >Organization: Chelyabinsk State University >Environment: pretty regular, nothing special but _picky_ modem >Description: some modems (for example, the one I currently own) have "black list", I hate to say, but I've now idea how to tell a modem to dial a number which it doesn't like to dial. it simply says "BLACKLISTED", so I want uucp package to understand that modem response. >How-To-Repeat: to purchase a modem with a "black list" feature >Fix: *** gnu/libexec/uucp/sample/dial.sample.orig Fri Sep 8 21:51:34 2000 --- gnu/libexec/uucp/sample/dial.sample Fri Sep 8 21:51:58 2000 *************** *** 34,39 **** --- 34,40 ---- chat-fail ERROR chat-fail NO\sDIALTONE chat-fail NO\sCARRIER + chat-fail BLACKLISTED # When the call is over, we make sure we hangup the modem. # You don't need this stuff, if you modem can handle DTR drop properly >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 13:40:15 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 665DC37B443 for ; Fri, 8 Sep 2000 13:40:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id NAA43669; Fri, 8 Sep 2000 13:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from mail11.disney.com (mail11.disney.com [208.246.35.55]) by hub.freebsd.org (Postfix) with ESMTP id 7E40C37B424 for ; Fri, 8 Sep 2000 13:38:14 -0700 (PDT) Received: from pain.corp.disney.com (pain.corp.disney.com [153.7.231.100]) by mail11.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e88KnJ203704 for ; Fri, 8 Sep 2000 13:49:20 -0700 (PDT) Received: from louie.fa.disney.com by pain.corp.disney.com with ESMTP for FreeBSD-gnats-submit@freebsd.org; Fri, 8 Sep 2000 13:38:39 -0700 Received: from plio.fan.fa.disney.com (plio.fan.fa.disney.com [153.7.118.2]) by louie.fa.disney.com (8.9.2/8.9.2) with ESMTP id NAA28598 for ; Fri, 8 Sep 2000 13:38:08 -0700 (PDT) (envelope-from pirzyk@fa.disney.com) Received: from snoopy.fan.fa.disney.com (snoopy.fan.fa.disney.com [172.30.228.110]) by plio.fan.fa.disney.com (8.9.2/8.9.2) with ESMTP id NAA28440 for ; Fri, 8 Sep 2000 13:38:07 -0700 (PDT) (envelope-from pirzyk@fa.disney.com) Received: (from pirzyk@localhost) by snoopy.fan.fa.disney.com (8.9.3/8.9.3) id NAA00820; Fri, 8 Sep 2000 13:38:07 -0700 (PDT) (envelope-from pirzyk@fa.disney.com) Message-Id: <200009082038.NAA00820@snoopy.fan.fa.disney.com> Date: Fri, 8 Sep 2000 13:38:07 -0700 (PDT) From: Jim.Pirzyk@disney.com Reply-To: Jim.Pirzyk@disney.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/21132: kern.hostid 31bit field and not a 32bit field Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21132 >Category: kern >Synopsis: setting kern.hostid to 2887705710 fails. >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 08 13:40:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Jim Pirzyk >Release: FreeBSD 4.1-RELEASE i386 >Organization: >Environment: Any standard 4.1 enviroment >Description: kern.hostid can only be set up to LONG_MAX >How-To-Repeat: sysctl -w kern.hostid=2887705710 >Fix: *** sbin/sysctl/sysctl.c.orig Fri Sep 8 12:55:12 2000 --- sbin/sysctl/sysctl.c Fri Sep 8 13:03:46 2000 *************** *** 121,127 **** { int len, i, j; void *newval = 0; ! int intval, newsize = 0; quad_t quadval; int mib[CTL_MAXNAME]; char *cp, *bufp, buf[BUFSIZ]; --- 122,128 ---- { int len, i, j; void *newval = 0; ! unsigned int intval, newsize = 0; quad_t quadval; int mib[CTL_MAXNAME]; char *cp, *bufp, buf[BUFSIZ]; *************** *** 167,173 **** switch (kind & CTLTYPE) { case CTLTYPE_INT: ! intval = (int) strtol(newval, NULL, 0); newval = &intval; newsize = sizeof intval; break; --- 168,174 ---- switch (kind & CTLTYPE) { case CTLTYPE_INT: ! intval = (unsigned int) strtoul(newval, NULL, 0); newval = &intval; newsize = sizeof intval; break; *** sys/kern/kern_mib.c.orig Fri Sep 8 12:17:20 2000 --- sys/kern/kern_mib.c Fri Sep 8 12:29:55 2000 *************** *** 186,194 **** SYSCTL_STRING(_kern, KERN_NISDOMAINNAME, domainname, CTLFLAG_RW, &domainname, sizeof(domainname), "Name of the current YP/NIS domain"); ! long hostid; /* Some trouble here, if sizeof (int) != sizeof (long) */ ! SYSCTL_INT(_kern, KERN_HOSTID, hostid, CTLFLAG_RW, &hostid, 0, "Host ID"); /* * This is really cheating. These actually live in the libc, something --- 186,194 ---- SYSCTL_STRING(_kern, KERN_NISDOMAINNAME, domainname, CTLFLAG_RW, &domainname, sizeof(domainname), "Name of the current YP/NIS domain"); ! unsigned long hostid; /* Some trouble here, if sizeof (int) != sizeof (long) */ ! SYSCTL_UINT(_kern, KERN_HOSTID, hostid, CTLFLAG_RW, &hostid, 0, "Host ID"); /* * This is really cheating. These actually live in the libc, something *** sys/kern/kern_xxx.c.orig Fri Sep 8 12:35:33 2000 --- sys/kern/kern_xxx.c Fri Sep 8 12:36:17 2000 *************** *** 103,109 **** struct ogethostid_args *uap; { ! *(long *)(p->p_retval) = hostid; return (0); } #endif /* COMPAT_43 || COMPAT_SUNOS */ --- 103,109 ---- struct ogethostid_args *uap; { ! *(unsigned long *)(p->p_retval) = hostid; return (0); } #endif /* COMPAT_43 || COMPAT_SUNOS */ *************** *** 111,117 **** #ifdef COMPAT_43 #ifndef _SYS_SYSPROTO_H_ struct osethostid_args { ! long hostid; }; #endif /* ARGSUSED */ --- 111,117 ---- #ifdef COMPAT_43 #ifndef _SYS_SYSPROTO_H_ struct osethostid_args { ! unsigned long hostid; }; #endif /* ARGSUSED */ *** sys/sys/kernel.h.orig Fri Sep 8 12:18:01 2000 --- sys/sys/kernel.h Fri Sep 8 12:18:12 2000 *************** *** 55,61 **** /* Global variables for the kernel. */ /* 1.1 */ ! extern long hostid; extern char hostname[MAXHOSTNAMELEN]; extern int hostnamelen; extern char domainname[MAXHOSTNAMELEN]; --- 55,61 ---- /* Global variables for the kernel. */ /* 1.1 */ ! extern unsigned long hostid; extern char hostname[MAXHOSTNAMELEN]; extern int hostnamelen; extern char domainname[MAXHOSTNAMELEN]; >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 15: 0: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A826937B443 for ; Fri, 8 Sep 2000 15:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA56091; Fri, 8 Sep 2000 15:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 1F34A37B423; Fri, 8 Sep 2000 14:54:25 -0700 (PDT) Message-Id: <20000908215425.1F34A37B423@hub.freebsd.org> Date: Fri, 8 Sep 2000 14:54:25 -0700 (PDT) From: campt@miralink.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21139: IBM DNES drives need 'quirk table' entry. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21139 >Category: kern >Synopsis: IBM DNES drives need 'quirk table' entry. >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Fri Sep 08 15:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Tracy Camp >Release: 3.1 and 4.0 >Organization: Miralink Corp >Environment: 4.0-RELEASE with generic >Description: IBM DNES drives do not support more than 64 tagged queued commands and the default settings for maxtags is 255 which is problematic. Under heavy write loads this leads to a system crash. >How-To-Repeat: Install a DNES drive and perform disk operations. >Fix: Add quirk entry in cam/cam_xpt.c for this drive (see below) that limits maxtags to 32. { /* DNES docs state on page 203 that this device only * supports 64 queued commands. 9gig and 18gig devices P/N * DNES-318350 and DNES-309170. campt@miralink.com */ { T_DIRECT, SIP_MEDIA_FIXED, "IBM", "DNES*","*"}, /*quirks*/0, */mintags*/2,/*maxtags*/32 } >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 15:10: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 96AC837B424 for ; Fri, 8 Sep 2000 15:10:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA58785; Fri, 8 Sep 2000 15:10:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 8 Sep 2000 15:10:03 -0700 (PDT) Message-Id: <200009082210.PAA58785@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Chris D. Faulhaber" Subject: Re: kern/21139: IBM DNES drives need 'quirk table' entry. Reply-To: "Chris D. Faulhaber" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21139; it has been noted by GNATS. From: "Chris D. Faulhaber" To: campt@miralink.com Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/21139: IBM DNES drives need 'quirk table' entry. Date: Fri, 8 Sep 2000 18:05:07 -0400 (EDT) On Fri, 8 Sep 2000 campt@miralink.com wrote: > IBM DNES drives do not support more than 64 tagged queued commands and > the default settings for maxtags is 255 which is problematic. Under heavy > write loads this leads to a system crash. > >How-To-Repeat: > Install a DNES drive and perform disk operations. > >Fix: > Add quirk entry in cam/cam_xpt.c for this drive (see below) that limits maxtags to 32. > > { > /* DNES docs state on page 203 that this device only > * supports 64 queued commands. 9gig and 18gig devices P/N > * DNES-318350 and DNES-309170. campt@miralink.com > */ > { T_DIRECT, SIP_MEDIA_FIXED, "IBM", "DNES*","*"}, > /*quirks*/0, */mintags*/2,/*maxtags*/32 > } > Beware, the above entry also encompasses this drive: da0: Fixed Direct Access SCSI-3 device which works fine without the entry. ----- Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 15:10:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2E96A37B443 for ; Fri, 8 Sep 2000 15:10:06 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA58798; Fri, 8 Sep 2000 15:10:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 8 Sep 2000 15:10:05 -0700 (PDT) Message-Id: <200009082210.PAA58798@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Tracy Camp Subject: Re: kern/21139: IBM DNES drives need 'quirk table' entry. Reply-To: Tracy Camp Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21139; it has been noted by GNATS. From: Tracy Camp To: "Chris D. Faulhaber" Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/21139: IBM DNES drives need 'quirk table' entry. Date: Fri, 8 Sep 2000 15:08:11 -0700 (PDT) On Fri, 8 Sep 2000, Chris D. Faulhaber wrote: > On Fri, 8 Sep 2000 campt@miralink.com wrote: > > > IBM DNES drives do not support more than 64 tagged queued commands and > > the default settings for maxtags is 255 which is problematic. Under heavy > > write loads this leads to a system crash. > > >How-To-Repeat: > > Install a DNES drive and perform disk operations. > > >Fix: > > Add quirk entry in cam/cam_xpt.c for this drive (see below) that limits maxtags to 32. > > > > { > > /* DNES docs state on page 203 that this device only > > * supports 64 queued commands. 9gig and 18gig devices P/N > > * DNES-318350 and DNES-309170. campt@miralink.com > > */ > > { T_DIRECT, SIP_MEDIA_FIXED, "IBM", "DNES*","*"}, > > /*quirks*/0, */mintags*/2,/*maxtags*/32 > > } > > > > Beware, the above entry also encompasses this drive: > > da0: Fixed Direct Access SCSI-3 device > > which works fine without the entry. Just read what they tell me in the docs. I've been using the DNES-309170W SA30 and see the problem, there is also a 309170W with a diffrent firmware that has the same behavior. I turned off tagged queueing alltogether in my application and got much improved stability so I'm at least convinced its necissary, but hey - your call. :) The manual refrenced is a nice 230 some page pdf available from IBM. Maybe I've misread it. t. > > ----- > Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org > -------------------------------------------------------- > FreeBSD: The Power To Serve - http://www.FreeBSD.org > > Tracy Camp Product Development Miralink Corp.PDX Portland OR 503-223-3140 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 15:20: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 27AB037B422 for ; Fri, 8 Sep 2000 15:20:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA59856; Fri, 8 Sep 2000 15:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 8 Sep 2000 15:20:02 -0700 (PDT) Message-Id: <200009082220.PAA59856@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Justin T. Gibbs" Subject: Re: kern/21139: IBM DNES drives need 'quirk table' entry. Reply-To: "Justin T. Gibbs" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21139; it has been noted by GNATS. From: "Justin T. Gibbs" To: campt@miralink.com Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/21139: IBM DNES drives need 'quirk table' entry. Date: Fri, 08 Sep 2000 16:16:03 -0600 >IBM DNES drives do not support more than 64 tagged queued commands and >the default settings for maxtags is 255 which is problematic. Under heavy >write loads this leads to a system crash. The problem here is the system crash, not that the table starts out your drive with a tag count of 255. CAM should automatically reduce the count to the maximum supported by the device. Can you give some details about the panic you are seeing? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Sep 8 15:40: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 616C537B507 for ; Fri, 8 Sep 2000 15:40:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA61976; Fri, 8 Sep 2000 15:40:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 8 Sep 2000 15:40:02 -0700 (PDT) Message-Id: <200009082240.PAA61976@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Tracy Camp Subject: Re: kern/21139: IBM DNES drives need 'quirk table' entry. Reply-To: Tracy Camp Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/21139; it has been noted by GNATS. From: Tracy Camp To: "Justin T. Gibbs" Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/21139: IBM DNES drives need 'quirk table' entry. Date: Fri, 8 Sep 2000 15:34:24 -0700 (PDT) On Fri, 8 Sep 2000, Justin T. Gibbs wrote: > >IBM DNES drives do not support more than 64 tagged queued commands and > >the default settings for maxtags is 255 which is problematic. Under heavy > >write loads this leads to a system crash. > > The problem here is the system crash, not that the table starts > out your drive with a tag count of 255. CAM should automatically > reduce the count to the maximum supported by the device. Can > you give some details about the panic you are seeing? A message along the lines of : (da2:ahc0:0:3:0): tagged openings now 64 Followed shortly thereafter by a system freeze/hang. Perhaps the word 'crash' was used too quickly here. What seems to be happening is that the drive stops responding which effectively is a 'crash' from my standpoint. Its been awhile since we dealt with this actually and I just now thought about reporting this back. Sorry if this isn't much use, I don't do kernel stuff normally but am one of the few that can work in C at all here. Tracy Camp Product Development Miralink Corp.PDX Portland OR 503-223-3140 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 0: 4: 4 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 52AB037B440 for ; Sat, 9 Sep 2000 00:04:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA22483; Sat, 9 Sep 2000 00:00:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from fun.ee.lbl.gov (fun.ee.lbl.gov [131.243.1.81]) by hub.freebsd.org (Postfix) with ESMTP id AFDE637B43F for ; Fri, 8 Sep 2000 23:54:54 -0700 (PDT) Received: (from leres@localhost) by fun.ee.lbl.gov (8.11.0/8.11.0) id e896r7S00931; Fri, 8 Sep 2000 23:53:07 -0700 (PDT) Message-Id: <200009090653.e896r7S00931@fun.ee.lbl.gov> Date: Fri, 08 Sep 2000 23:53:07 -0700 From: Craig Leres To: FreeBSD-gnats-submit@freebsd.org Cc: leres@ee.lbl.gov (Craig Leres) X-Send-Pr-Version: 3.2 Subject: bin/21142: [PATCH] avoid errors from "make objlink" when NOOBJ is defined Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21142 >Category: bin >Synopsis: [PATCH] avoid errors from "make objlink" when NOOBJ is defined >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 00:00:02 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Craig Leres >Release: FreeBSD 4.1-RELEASE i386 >Organization: Lawrence Berkeley National Laboratory >Environment: >Description: If NOOBJ is defined, make does not try to make an obj directory. However it still tries to make an objlink. >How-To-Repeat: fun 401 % cd /usr/src/share/dict fun 402 % make obj objlink No /usr/obj/usr/src/share/dict to link to - do a make obj. >Fix: Context diffs to share/mk/bsd.obj.mk are appended. This Make objlink work like obj (a noop when NOOBJ is defined). =================================================================== RCS file: RCS/bsd.obj.mk,v retrieving revision 1.1 diff -c -r1.1 bsd.obj.mk *** bsd.obj.mk 2000/09/09 06:42:52 1.1 --- bsd.obj.mk 2000/09/09 06:49:56 *************** *** 79,84 **** --- 79,87 ---- .endif .if !target(objlink) + .if defined(NOOBJ) + objlink: + .else objlink: _SUBDIR @if test -d ${CANONICALOBJDIR}/; then \ rm -f ${.CURDIR}/obj; \ *************** *** 86,91 **** --- 89,95 ---- else \ echo "No ${CANONICALOBJDIR} to link to - do a make obj."; \ fi + .endif .endif # >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 0:43:16 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 51FB437B50B for ; Sat, 9 Sep 2000 00:43:14 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA27175; Sat, 9 Sep 2000 00:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 2687E37B505; Sat, 9 Sep 2000 00:37:16 -0700 (PDT) Message-Id: <20000909073716.2687E37B505@hub.freebsd.org> Date: Sat, 9 Sep 2000 00:37:16 -0700 (PDT) From: alm@SlewSys.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21143: `#define schedsofttty' et al. should not be in ipl_funcs.c Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21143 >Category: kern >Synopsis: `#define schedsofttty' et al. should not be in ipl_funcs.c >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 00:40:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Andrew L. Moore >Release: 5.0-CURRENT Tue Sep 5 >Organization: SlewSys Research >Environment: FreeBSD qi.slewsys.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Sep 5 00:10:50 PDT 2000 alm@qi.slewsys.org:/usr/src/sys/compile/SLEWSYS i386 >Description: `#define schedsofttty' et al. should not be in ipl_funcs.c. These are pre-processor directives, so either they should move to or they should be redefined, e.g., as void schedsofttty(void) {}; >How-To-Repeat: Try building a kernel with the cy device. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 1: 0:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 82EE937B618 for ; Sat, 9 Sep 2000 01:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id BAA28918; Sat, 9 Sep 2000 01:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from fun.ee.lbl.gov (fun.ee.lbl.gov [131.243.1.81]) by hub.freebsd.org (Postfix) with ESMTP id 2A5BE37B59E for ; Sat, 9 Sep 2000 00:55:06 -0700 (PDT) Received: (from leres@localhost) by fun.ee.lbl.gov (8.11.0/8.11.0) id e897rNT01780; Sat, 9 Sep 2000 00:53:23 -0700 (PDT) Message-Id: <200009090753.e897rNT01780@fun.ee.lbl.gov> Date: Sat, 09 Sep 2000 00:53:23 -0700 From: Craig Leres To: FreeBSD-gnats-submit@freebsd.org Cc: leres@ee.lbl.gov (Craig Leres) X-Send-Pr-Version: 3.2 Subject: bin/21144: [PATCH] fetch(1): don't bonk if ftp SIZE isn't supproted; add LIST feature Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21144 >Category: bin >Synopsis: [PATCH] fetch(1): don't bonk if ftp SIZE isn't supproted; add LIST feature >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 01:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Craig Leres >Release: FreeBSD 4.1-RELEASE i386 >Organization: Lawrence Berkeley National Laboratory >Environment: >Description: If you try to grab a ftp file and the server does not support the SIZE command, fetch(1) gets confused and exits. The "old" version of fetch could cope with this. Also, fetch(1) cannot retreive a ftp directory listing; attempts to do so result in a ftp protocol error. >How-To-Repeat: fun 436 % fetch -v ftp://ftp.rs.internic.net/domain/named.root looking up ftp.rs.internic.net connecting to ftp.rs.internic.net:21 fetch: named.root: Syntax error, command unrecognized [Too bad fetch can't show us the protocol dialogue; that would be sweet!] fun 433 % ftp ftp.rs.internic.net Connected to ftp.rs.internic.net. 220 rs FTP server (InterNIC Public FTP Server - Login with username anonymous) ready. Name (ftp.rs.internic.net:leres): ftp 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /domain 250 CWD command successful. ftp> quote SIZE named.root 500 'SIZE named.root': command not understood. ftp> [Here's how the fetch that came with 3.2-RELEASE works; note the useful debugging info...] ee 66 % uname -r 3.2-RELEASE ee 67 % fetch ftp://ftp.rs.internic.net/domain/named.root fetch: domain/named.root: cannot get remote modification time Receiving named.root: 2 Kbytes 2769 bytes transfered in 0.8 seconds (3.52 Kbytes/s) ee 68 % ,ch,ch -v fetch -v ftp://ftp.rs.internic.net/domain/named.root Sending: USER anonymous rs FTP server (InterNIC Public FTP Server - Login with username anonymous) ready. Guest login ok, send ident as password. Sending: PASS leres@ee.lbl.gov Guest login ok, access restrictions apply. Sending: TYPE I Type set to I. Sending: CWD domain CWD command successful. Sending SIZE named.root 'SIZE named.root': command not understood. Sending MDTM named.root 'MDTM named.root': command not understood. fetch: domain/named.root: cannot get remote modification time Sending: PORT 131,243,1,10,192,18 PORT command successful. Sending: RETR named.root Binary data connection for named.root (131.243.1.10,49170) (2769 bytes). Receiving named.rootSending: QUIT Binary Transfer complete. Goodbye. Receiving named.root: 2 Kbytes 2769 bytes transfered in 3.8 seconds (722 bytes/s) [Here's an unsuccessful attempt to get a directory listing] fun 450 % fetch -v ftp://ftp.ee.lbl.gov/ looking up ftp.ee.lbl.gov connecting to ftp.ee.lbl.gov:21 fetch: fetch.out: Syntax error in parameters or arguments >Fix: The appended context diff to lib/libfetch/ftp.c makes these changes: - Ignore a syntax/protocol error when fetching a file - Detecting that the filename is empty and do a LIST instead of a RETR I submitted a similar patch for the 3.0-RELEASE version of fetch: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9250 Since the current version of fetch looks like a rewrite, you can probbaly close the old report. =================================================================== RCS file: RCS/ftp.c,v retrieving revision 1.1 diff -c -r1.1 ftp.c *** ftp.c 2000/09/08 09:48:25 1.1 --- ftp.c 2000/09/09 07:17:17 *************** *** 451,457 **** /* make the server initiate the transfer */ if (verbose) _fetch_info("initiating transfer"); ! e = _ftp_cmd(cd, "%s %s", oper, _ftp_filename(file)); if (e != FTP_OPEN_DATA_CONNECTION) goto ouch; --- 451,460 ---- /* make the server initiate the transfer */ if (verbose) _fetch_info("initiating transfer"); ! if (*_ftp_filename(file) != '\0') ! e = _ftp_cmd(cd, "%s %s", oper, _ftp_filename(file)); ! else ! e = _ftp_cmd(cd, "%s", oper); if (e != FTP_OPEN_DATA_CONNECTION) goto ouch; *************** *** 541,547 **** /* make the server initiate the transfer */ if (verbose) _fetch_info("initiating transfer"); ! e = _ftp_cmd(cd, "%s %s", oper, _ftp_filename(file)); if (e != FTP_OPEN_DATA_CONNECTION) goto ouch; --- 544,553 ---- /* make the server initiate the transfer */ if (verbose) _fetch_info("initiating transfer"); ! if (*_ftp_filename(file) != '\0') ! e = _ftp_cmd(cd, "%s %s", oper, _ftp_filename(file)); ! else ! e = _ftp_cmd(cd, "%s", oper); if (e != FTP_OPEN_DATA_CONNECTION) goto ouch; *************** *** 782,787 **** --- 788,794 ---- fetchXGetFTP(struct url *url, struct url_stat *us, char *flags) { int cd; + register char *cp; if (_ftp_use_http_proxy()) return fetchXGetHTTP(url, us, flags); *************** *** 793,806 **** /* change directory */ if (_ftp_cwd(cd, url->doc) == -1) return NULL; ! /* stat file */ ! if (us && _ftp_stat(cd, url->doc, us) == -1 ! && fetchLastErrCode != FETCH_UNAVAIL) ! return NULL; ! ! /* initiate the transfer */ ! return _ftp_transfer(cd, "RETR", url->doc, "r", url->offset, flags); } /* --- 800,824 ---- /* change directory */ if (_ftp_cwd(cd, url->doc) == -1) return NULL; + + cp = url->doc + strlen(url->doc) - 1; + if (cp >= url->doc && *cp == '/') { + if (us) { + us->size = -1; + us->atime = us->mtime = 0; + } + /* list the directory */ + return _ftp_transfer(cd, "LIST", url->doc, "r", url->offset, flags); + } else { + /* stat file */ + if (us && _ftp_stat(cd, url->doc, us) == -1 + && fetchLastErrCode != FETCH_UNAVAIL + && fetchLastErrCode != FETCH_PROTO) + return NULL; ! /* initiate the transfer */ ! return _ftp_transfer(cd, "RETR", url->doc, "r", url->offset, flags); ! } } /* >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 4:36:38 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from poseidon.dcs.napier.ac.uk (poseidon.dcs.napier.ac.uk [146.176.161.4]) by hub.freebsd.org (Postfix) with ESMTP id A4A6F37B424 for ; Sat, 9 Sep 2000 04:36:34 -0700 (PDT) Received: from artemis (artemis [146.176.161.5]) by poseidon.dcs.napier.ac.uk (8.9.3/8.9.3) with SMTP id MAA19526; Sat, 9 Sep 2000 12:34:53 +0100 (BST) Date: Sat, 9 Sep 2000 12:33:00 +0100 (BST) From: Robin Carey X-Sender: bsc4093@artemis To: "Rashid N. Achilov" Cc: bugs@FreeBSD.ORG Subject: RE: cons25 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 8 Sep 2000, Rashid N. Achilov wrote: > What is a "standard" type and what is a "non-standard", and who established, that these types are > "standard", but these is "non-standard"? For FreeBSD cons25 is a standard terminal type, and I > don't see a reason to change it to something else. I'm not aware of who it is that is responsible for standardising terminal-types. But the "ansi" terminal-type sounds a lot more "standard" (seeing as it comes from a standards organisation) to me, than "cons25". Plus, it's in the termcap database on the system I'm currently using to send you this E-mail (SunOS 5.7). As I've already mentioned, "cons25" isn't. I'd bet that "ansi" is more prevalent in the termcap databases of the various other free/commercial operating systems, than "cons25" ! :) > If you need it, you can immediately afterfinishing install edit the /etc/ttys file to your favorite > terminal type (for me this is pc3r - full and right support for Russian locale, only one bug with > 'Del' key) and restart system or ask administrators of other systems to add cons25 in their > terminal databases. Yep! Think I'll do that ! :) Cheers ... > -- > With Best Regards. > Rashid N. Achilov (RNA1-RIPE), Brainbench ID: 28514 > Granch Ltd. lead engineer, e-mail: achilov@granch.ru > tel/fax (383-2) 24-2363 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 7:10:19 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 09C9C37B42C for ; Sat, 9 Sep 2000 07:10:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA75583; Sat, 9 Sep 2000 07:10:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 91D4337B424; Sat, 9 Sep 2000 07:00:39 -0700 (PDT) Message-Id: <20000909140039.91D4337B424@hub.freebsd.org> Date: Sat, 9 Sep 2000 07:00:39 -0700 (PDT) From: dl@leo.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21148: multiple crashes while using vinum Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21148 >Category: kern >Synopsis: multiple crashes while using vinum >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 07:10:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Daniel Lang >Release: 4.1-STABLE >Organization: TU Muenchen >Environment: FreeBSD atleo4.leo.org 4.1-STABLE FreeBSD 4.1-STABLE #0: Fri Sep 8 10:24:40 CEST 2000 root@atleo2.leo.org:/usr/obj/usr/src/sys/ATLEO4 i386 >Description: The machine crashed repeatedly after a vinum raid5 was set up and used heavily. Hardware: Dell Poweredge 6100/200 4xPPro SMP machine, with 3 Adaptec SCSI controllers and one Promise Fasttrack ATA100 IDE controller... see dmesg: dmesg output: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.1-STABLE #0: Fri Sep 8 10:24:40 CEST 2000 root@atleo2.leo.org:/usr/obj/usr/src/sys/ATLEO4 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (198.95-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbff real memory = 536870912 (524288K bytes) avail memory = 518316032 (506168K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 4, version: 0x00040011, at 0xfec08000 cpu2 (AP): apic id: 1, version: 0x00040011, at 0xfec08000 cpu3 (AP): apic id: 2, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 14, version: 0x000f0011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc0401000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 fxp0: port 0xff80-0xff9f mem 0xfe900000-0xfe9fffff,0xfe2ff000-0xfe2fffff irq 10 at device 11.0 on pci0 fxp0: Ethernet address 00:a0:c9:99:47:2c ahc0: port 0xfc00-0xfcff mem 0xfeaff000-0xfeafffff irq 11 at device 12.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs isab0: at device 14.0 on pci0 eisa0: on isab0 mainboard0: on eisa0 slot 0 isa0: on isab0 chip0: <> mem 0xfffffc00-0xffffffff,0xfffffc00-0xffffffff,0xfffffc00-0xffffffff,0xfffffc00-0xffffffff,0xfffffc00-0xffffffff,0xfec01000-0xfec013ff at device 15.0 on pci0 chip1: at device 20.0 on pci0 pcib1: on motherboard pci1: on pcib1 ahc1: port 0xec00-0xecff mem 0xfe1ff000-0xfe1fffff irq 5 at device 11.0 on pci1 ahc1: Using left over BIOS settings ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: port 0xe800-0xe8ff mem 0xfe1fe000-0xfe1fefff irq 5 at device 12.0 on pci1 ahc2: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: Host Adapter Bios disabled. Using default SCSI device parameters atapci0: port 0xe480-0xe4bf,0xe4f0-0xe4f3,0xe4e8-0xe4ef,0xe4f4-0xe4f7,0xe4f8-0xe4ff mem 0xfe1a0000-0xfe1bffff irq 9 at device 13.0 on pci1 ata2: at 0xe4f8 on atapci0 ata3: at 0xe4e8 on atapci0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: parallel port not found. APIC_IO: routing 8254 via IOAPIC #0 intpin 2 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default IPv6 packet filtering initialized, default to accept, logging limited to 100 packets/entry IPsec: Initialized Security Association Processing. IP Filter: v3.4.8 initialized. Default = pass all, Logging = enabled SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! ad0: 73308MB [148945/16/63] at ata2-master using UDMA100 ad1: 73308MB [148945/16/63] at ata2-slave using UDMA100 ad2: 73308MB [148945/16/63] at ata3-master using UDMA100 ad3: 73308MB [148945/16/63] at ata3-slave using UDMA100 Waiting 3 seconds for SCSI devices to settle pt0 at ahc1 bus 0 target 6 lun 0 pt0: Fixed Processor SCSI-2 device pt0: 3.300MB/s transfers sa0 at ahc2 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 4.545MB/s transfers (4.545MHz, offset 15) ses0 at ahc1 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device da2 at ahc1 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 8683MB (17783112 512 byte sectors: 64H 32S/T 8683C) da3 at ahc1 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 8683MB (17783112 512 byte sectors: 64H 32S/T 8683C) da0 at ahc1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4095MB (8388315 512 byte sectors: 64H 32S/T 4095C) da1 at ahc1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4095MB (8388315 512 byte sectors: 64H 32S/T 4095C) ch0 at ahc2 bus 0 target 6 lun 1 ch0: Removable Changer SCSI-2 device ch0: 4.545MB/s transfers (4.545MHz, offset 15) ch0: 0 slots, 1 drive, 1 picker, 0 portals Mounting root from ufs:/dev/da0s1a WARNING: / was not properly dismounted vinum: loaded vinum: reading configuration from /dev/ad3s1e vinum: updating configuration from /dev/ad2s1e vinum: updating configuration from /dev/ad1s1e vinum: updating configuration from /dev/ad0s1e cd0 at ahc2 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present Kernel Config file: machine i386 #cpu I386_CPU #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident ATLEO4 maxusers 256 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options INET #InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security options MROUTING options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPV6FIREWALL #firewall for IPv6 options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPV6FIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT #divert sockets options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging options IPSTEALTH #support for stealth forwarding options TCPDEBUG #options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN options TCP_RESTRICT_RST #restrict emission of TCP RST options NETATALK #Appletalk protocol options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=3000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev options NETGRAPH # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): options NCPU=4 # number of CPUs options NBUS=3 # number of busses options NAPIC=1 # number of IO APICs options NINTR=24 # number of INTs device isa device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices #device ata0 at isa? port IO_WD1 irq 14 #device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives #options ATA_STATIC_ID #Static device numbering options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers #device ahb # EISA AHA1742 family device ahc0 # AHA2940 and onboard AIC7xxx devices device ahc1 # AHA2940 and onboard AIC7xxx devices device ahc2 # AHA2940 and onboard AIC7xxx devices # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device ch # SCSI media changers device cd # CD device pass # Passthrough device (direct SCSI access) device pt # SCSI processor type device ses # SCSI SES/SAF-TE driver # disks # the first ahc0 ist the external controller, which we use as last bus # the first internal ahc1 is the first we use with the SCA disks # the second internal ahc2 has the CD-ROM and the Archive Python device scbus0 at ahc1 device scbus1 at ahc2 device scbus2 at ahc0 device da0 at scbus0 target 0 device da1 at scbus0 target 1 device da2 at scbus0 target 2 device da3 at scbus0 target 3 # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 options MAXCONS=12 # number of virtual consoles options SC_NORM_ATTR="(FG_LIGHTGREY|BG_BLACK)" options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" options SC_KERNEL_CONS_ATTR="(FG_WHITE|BG_BLUE)" options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)" # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device fxp # Intel EtherExpress PRO/100B (82557, 82558) device tx # SMC 9432TX (83c170 ``EPIC'') device vx # 3Com 3c590, 3c595 (``Vortex'') device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device ste # Sundance ST201 (D-Link DFE-550TX) device tl # Texas Instruments ThunderLAN device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device sl 1 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty 256 # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device gif 4 # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) pseudo-device vn pseudo-device snp 4 # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Ethernet, requires mii device aue # ADMtek USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet VINUM statements according to instructions on www.vinumvm.org: Problem: Subsequent crashes (kernel panics) during heavy disk-access on a vinum device. FreeBSD: 4.1-STABLE, no changes to the sources Vinum list: one raid5 volume from 4 ATA drives atleo4:/usr/src#vinum list 4 drives: D d1 State: up Device /dev/ad0s1e Avail: 0/73304 MB (0%) D d2 State: up Device /dev/ad1s1e Avail: 0/73304 MB (0%) D d3 State: up Device /dev/ad2s1e Avail: 0/73304 MB (0%) D d4 State: up Device /dev/ad3s1e Avail: 0/73304 MB (0%) 1 volumes: V leoata State: up Plexes: 1 Size: 214 GB 1 plexes: P leoata.p0 R5 State: up Subdisks: 4 Size: 214 GB 4 subdisks: S leoata.p0.s0 State: up PO: 0 B Size: 71 GB S leoata.p0.s1 State: up PO: 512 kB Size: 71 GB S leoata.p0.s2 State: up PO: 1024 kB Size: 71 GB S leoata.p0.s3 State: up PO: 1536 kB Size: 71 GB The history file reflects the creation of the volume which didn't cause any problems: History file in: /var/log/vinum_history (not /var/tmp !): [..] 6 Sep 2000 17:41:13.473942 *** vinum started *** 6 Sep 2000 17:41:13.475950 create -v vinum.init.leoata drive d1 device /dev/ad0e drive d2 device /dev/ad1e drive d3 device /dev/ad2e drive d4 device /dev/ad3e volume leoata plex org raid5 512k sd length 150127097s drive d1 sd length 150127097s drive d2 sd length 150127097s drive d3 sd length 150127097s drive d4 6 Sep 2000 17:41:13.491734 *** Created devices *** [..] 6 Sep 2000 17:50:55.914542 *** vinum started *** 6 Sep 2000 17:50:55.916405 init -w leoata.p0 [..] /var/log/messages from the same period: [..] Sep 6 17:41:13 atleo4 /kernel: vinum: drive d1 is up Sep 6 17:41:13 atleo4 /kernel: vinum: drive d2 is up Sep 6 17:41:13 atleo4 /kernel: vinum: drive d3 is up Sep 6 17:41:13 atleo4 /kernel: vinum: drive d4 is up Sep 6 17:41:13 atleo4 /kernel: vinum: removing 1515 blocks of partial stripe at the en d of leoata.p0 Sep 6 17:50:55 atleo4 /kernel: vinum: leoata.p0.s2 is initializing by force Sep 6 17:50:55 atleo4 /kernel: vinum: leoata.p0 is initializing Sep 6 17:50:55 atleo4 /kernel: vinum: leoata.p0.s0 is initializing by force Sep 6 17:50:56 atleo4 /kernel: vinum: leoata.p0.s1 is initializing by force Sep 6 17:50:56 atleo4 /kernel: vinum: leoata.p0.s3 is initializing by force [..] Sep 6 21:08:09 atleo4 /kernel: vinum: leoata.p0.s0 is initialized by force Sep 6 21:08:10 atleo4 /kernel: vinum: leoata.p0.s0 is initialized Sep 6 21:08:10 atleo4 /kernel: vinum: leoata.p0.s1 is initialized by force Sep 6 21:08:10 atleo4 /kernel: vinum: leoata.p0.s1 is initialized Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0.s2 is initialized by force Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0.s2 is initialized Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0.s3 is initialized by force Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0.s0 is up Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0.s1 is up Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0.s2 is up Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0.s3 is up Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0 is up Sep 6 21:08:32 atleo4 /kernel: vinum: leoata is up Sep 6 21:08:32 atleo4 /kernel: vinum: leoata.p0.s3 is up [..] newfs, mount, etc worked. Crash anlysis: 4 crashes total within two days!! The machine was did not crash before vinum was used on it. I'm pretty sure, that the modules and kernel are compiled with debugging symbols, that is, configured with -g (CONFIGARGS= -g), and makeoptions DEBUG=-g in the kernel config. atleo4:/var/crash#file /modules/vinum.ko /modules/vinum.ko: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped atleo4:/var/crash#file kernel.1 kernel.1: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically link ed, not stripped atleo4:/var/crash#file kernel.2 kernel.2: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically link ed, not stripped atleo4:/var/crash#file kernel.3 kernel.3: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically link ed, not stripped atleo4:/var/crash#file kernel.4 kernel.4: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically link ed, not stripped But I don't seem to get a proper analysis with your .gdbinit.* files, and gdb says: no debugging symbols found ??? Maybe there is something I missed, but what ??? However... Crash 1: atleo4:/var/crash#gdb -k kernel.1 vmcore.1 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... SMP 4 cpus IdlePTD 4284416 initial pcb at 3608e0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc23266ca stack pointer = 0x10:0xff806f00 frame pointer = 0x10:0xff806f1c 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 = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 syncing disks... Fatal trap 12: page fault while in kernel mode mp_lock = 00000003; cpuid = 0; lapic.id = 00000000 fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0273971 stack pointer = 0x10:0xff806d20 frame pointer = 0x10:0xff806d24 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 = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000003; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 Uptime: 1h18m17s dumping to dev #da/0x20001, offset 1048576 dump 512 ... --- #0 0xc016b6b8 in boot () .gdbinit:4: Error in sourced command file: Attempt to extract a component of a value that is not a structure. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This may be because of missing debugging symbols ?? Stacktrace: (kgdb) bt #0 0xc016b6b8 in boot () #1 0xc016ba70 in poweroff_wait () #2 0xc02d9baf in trap_fatal () #3 0xc02d9845 in trap_pfault () #4 0xc02d93df in trap () #5 0xc0273971 in acquire_lock () #6 0xc0277660 in softdep_update_inodeblock () #7 0xc0272c5d in ffs_update () #8 0xc027a931 in ffs_sync () #9 0xc01993f3 in sync () #10 0xc016b48b in boot () #11 0xc016ba70 in poweroff_wait () #12 0xc02d9baf in trap_fatal () #13 0xc02d9845 in trap_pfault () #14 0xc02d93df in trap () #15 0xc23266ca in ?? () #16 0xc019136b in biodone () #17 0xc02af030 in ad_interrupt () #18 0xc02ab3e6 in ata_intr () #19 0xc02e202d in intr_mux () Crash 2: [..] SMP 4 cpus IdlePTD 4284416 initial pcb at 3608e0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 fault virtual address = 0xc3608010 fault code = supervisor read, page not present instruction pointer = 0x8:0xc232a112 stack pointer = 0x10:0xff806ee8 frame pointer = 0x10:0xff806ef0 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 = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 syncing disks... Fatal trap 12: page fault while in kernel mode mp_lock = 00000003; cpuid = 0; lapic.id = 00000000 fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0273971 stack pointer = 0x10:0xff806d08 frame pointer = 0x10:0xff806d0c 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 = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000003; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 Uptime: 14h5m17s [..] #0 0xc016b6b8 in boot () #1 0xc016ba70 in poweroff_wait () #2 0xc02d9baf in trap_fatal () #3 0xc02d9845 in trap_pfault () #4 0xc02d93df in trap () #5 0xc0273971 in acquire_lock () #6 0xc0277660 in softdep_update_inodeblock () #7 0xc0272c5d in ffs_update () #8 0xc027a931 in ffs_sync () #9 0xc01993f3 in sync () #10 0xc016b48b in boot () #11 0xc016ba70 in poweroff_wait () #12 0xc02d9baf in trap_fatal () #13 0xc02d9845 in trap_pfault () #14 0xc02d93df in trap () #15 0xc232a112 in ?? () #16 0xc2326bfc in ?? () #17 0xc019136b in biodone () #18 0xc02af030 in ad_interrupt () #19 0xc02ab3e6 in ata_intr () #20 0xc02e202d in intr_mux () Crash 3: This one is different ... SMP 4 cpus IdlePTD 4272128 initial pcb at 360920 panicstr: ffs_valloc: dup alloc panic messages: --- panic: ffs_valloc: dup alloc mp_lock = 00000001; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 syncing disks... 166 38 19 5 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 giving up on 2 buffers Uptime: 11h42m59s [..] #0 0xc016b6bc in boot () #1 0xc016ba74 in poweroff_wait () #2 0xc0270030 in ffs_valloc () #3 0xc02817ca in ufs_mkdir () #4 0xc02827d5 in ufs_vnoperate () #5 0xc019c28a in mkdir () #6 0xc02d9f09 in syscall2 () #7 0xc02c845b in Xint0x80_syscall () #8 0x804efc7 in ?? () #9 0x80494fd in ?? () [..] Crash 4: SMP 4 cpus IdlePTD 4272128 initial pcb at 360920 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 03000002; cpuid = 3; lapic.id = 02000000 fault virtual address = 0xc32c9010 fault code = supervisor read, page not present instruction pointer = 0x8:0xc232a112 stack pointer = 0x10:0xff81bee8 frame pointer = 0x10:0xff81bef0 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 = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 03000002; cpuid = 3; lapic.id = 02000000 boot() called on cpu#3 syncing disks... Fatal trap 12: page fault while in kernel mode mp_lock = 03000003; cpuid = 3; lapic.id = 02000000 fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc027397d stack pointer = 0x10:0xff81bd00 frame pointer = 0x10:0xff81bd04 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 = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 03000003; cpuid = 3; lapic.id = 02000000 boot() called on cpu#3 Uptime: 3h23m29s [..] (kgdb) bt #0 0xc016b6bc in boot () #1 0xc016ba74 in poweroff_wait () '#2 0xc02d9bdf in trap_fatal () #3 0xc02d9875 in trap_pfault () #4 0xc02d940f in trap () #5 0xc027397d in acquire_lock () #6 0xc0277b52 in softdep_fsync_mountdev () #7 0xc027bc9a in ffs_fsync () #8 0xc027a9c6 in ffs_sync () #9 0xc01993e7 in sync () #10 0xc016b48f in boot () #11 0xc016ba74 in poweroff_wait () #12 0xc02d9bdf in trap_fatal () #13 0xc02d9875 in trap_pfault () #14 0xc02d940f in trap () #15 0xc232a112 in ?? () #16 0xc2326bfc in ?? () #17 0xc019135f in biodone () #18 0xc02af068 in ad_interrupt () #19 0xc02ab41e in ata_intr () #20 0xc02e205d in intr_mux () [..] Of course this could be a ATA problem, but I already had two crashes in a previous configuration while trying to set up a stripe with two SCSI disks. A detailed description of these previous problems has been sent to Greg Lehey on August 16 2000. >How-To-Repeat: Tricky, this some sort of unique hardware configuration. On this configuration it seems to be sufficient to transfer huge amounts of data to the vinum device (around 100GB have been transferred in total, with interruptions of the crashes. The largest portion during uptime may be around 50GB). The data was transferred via NFS. The filesystem uses SOFTUPDATES, the first crash corrupted it in severe way, so that fsck had to be run manually (producing lots of 'unexpected softupdates inconsistency' errors). But I guess thats just a side-effect. >Fix: Nope. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 7:40: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C901137B423 for ; Sat, 9 Sep 2000 07:40:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA78325; Sat, 9 Sep 2000 07:40:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from md5.follo.net (isdn-09.follo.net [195.204.140.98]) by hub.freebsd.org (Postfix) with ESMTP id 874B437B423 for ; Sat, 9 Sep 2000 07:35:14 -0700 (PDT) Received: (from des@localhost) by md5.follo.net (8.11.0/8.11.0) id e89EXh342945; Sat, 9 Sep 2000 16:33:43 +0200 (CEST) (envelope-from des) Message-Id: <200009091433.e89EXh342945@md5.follo.net> Date: Sat, 9 Sep 2000 16:33:43 +0200 (CEST) From: des@ofug.org Reply-To: des@ofug.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: misc/21150: 'make includes' clobbers some headers Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21150 >Category: misc >Synopsis: 'make includes' clobbers some headers >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 07:40:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Dag-Erling Smorgrav >Release: FreeBSD 5.0-CURRENT i386 >Organization: >Environment: src/include/Makefile rev. 1.110 or newer >Description: Running 'make includes' with SHARED unset or set to 'copies' clobbers 48 headers in /usr/src/include/{isofs,ufs,dev}. The 'copies' target removes those directories entirely, and new copies of the headers must then be installed, causing false negatives when checking dependencies for source code that includes them. The reason for removing the directories is allegedely to remove symlinks placed there by the 'symlinks' target. >How-To-Repeat: # cd /usr/src # make includes SHARED=copies or # cd /usr/src/include # make all install SHARED=copies >Fix: Use find(1) to locate and remove symlinks in /usr/src/include instead of mindlessly clobbering everything that moves and some of what doesn't. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 7:45:56 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C467E37B424; Sat, 9 Sep 2000 07:45:55 -0700 (PDT) Received: (from des@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id HAA79050; Sat, 9 Sep 2000 07:45:55 -0700 (PDT) (envelope-from des@FreeBSD.org) Date: Sat, 9 Sep 2000 07:45:55 -0700 (PDT) From: Message-Id: <200009091445.HAA79050@freefall.freebsd.org> To: des@FreeBSD.org, freebsd-bugs@FreeBSD.org, ru@FreeBSD.org Subject: Re: misc/21150: 'make includes' clobbers some headers Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: 'make includes' clobbers some headers Responsible-Changed-From-To: freebsd-bugs->ru Responsible-Changed-By: des Responsible-Changed-When: Sat Sep 9 07:45:38 PDT 2000 Responsible-Changed-Why: You broke it, you fix it. http://www.freebsd.org/cgi/query-pr.cgi?pr=21150 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 12:20:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C663137B422 for ; Sat, 9 Sep 2000 12:20:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA13237; Sat, 9 Sep 2000 12:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Sat, 9 Sep 2000 12:20:01 -0700 (PDT) Message-Id: <200009091920.MAA13237@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Gerhard Sittig Subject: Re: bin/21017: mtree's "no such file" message at job's end Reply-To: Gerhard Sittig Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/21017; it has been noted by GNATS. From: Gerhard Sittig To: FreeBSD-gnats-submit@freebsd.org Cc: Subject: Re: bin/21017: mtree's "no such file" message at job's end Date: Sat, 9 Sep 2000 20:14:07 +0200 On Thu, Sep 07, 2000 at 21:08 +0200, Gerhard Sittig wrote: >=20 > In the end I can only see two reasons for mtree's failure: > - readlink(2) barfs on broken symlinks under not known yet > conditions (after "long" runs?) and does so unpredictably > - mtree fails to chdir(2) to the new directory and therefor fails > to read _any_ file there with a relative pathname Obviously I haven't seen the third opportunity: - mtree(1) (or fts(3) used by mtree) should either chdir(2) and readlink(2) with a relative path or stay in the -p base and readlink(2) with a pathname relative to the basedir. see below > Once I can find another spare moment I will try to dump the > relevant info of the readlink invocation's environment (current > dir, fts' root + path + filename, fts' already provided slink > and access failure info, etc). After applying the patch cited below (inspired by Jos Backus' hint) and running another session I got these results: ----------------------------------------------------------------- $ cd /usr/src/usr.sbin/mtree $ cvs diff -u=20 cvs diff: Diffing . Index: compare.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.sbin/mtree/compare.c,v retrieving revision 1.15.2.1 diff -u -r1.15.2.1 compare.c --- compare.c 2000/06/28 02:33:17 1.15.2.1 +++ compare.c 2000/09/09 14:02:49 @@ -64,6 +64,7 @@ extern int lineno; =20 static char *ftype __P((u_int)); +static char *rlink_check __P((char *, FTSENT *)); =20 #define INDENTNAMELEN 8 #define LABEL \ @@ -298,7 +299,7 @@ } #endif /* RMD160 */ =20 - if (s->flags & F_SLINK && strcmp(cp =3D rlink(name), s->slink)) { + if (s->flags & F_SLINK && strcmp(cp =3D rlink_check(name, p), s->slink)) { LABEL; (void)printf("%slink ref (%s, %s)\n", tab, cp, s->slink); } @@ -353,6 +354,44 @@ return ("unknown"); } /* NOTREACHED */ +} + +char * +rlink_check(name, p) + char *name; + FTSENT *p; +{ +#if 1 + FILE *f; + char *buf; + + if (errno) { + warn("nonzero errno before readlink(2)"); + } + + f =3D fopen("/var/tmp/mtree.log", "a"); + if (f) { + buf =3D getcwd(NULL, 0); + fprintf(f, "cwd=3D%s\n", buf); + free(buf); buf =3D NULL; + + fprintf(f, "name=3D%s\n", name); + + fprintf(f, "fts_info=3D%hu\n", p->fts_info); + fprintf(f, "fts_accpath=3D%s\n", p->fts_accpath); + fprintf(f, "fts_path=3D%s\n", p->fts_path); + fprintf(f, "fts_name=3D%s\n", p->fts_name); + fprintf(f, "fts_level=3D%h\n", p->fts_level); + fprintf(f, "fts_errno=3D%d\n", p->fts_errno); + + fprintf(f, "\n"); + fclose(f); + } else { + warn("logfile problem in rlink_check()"); + } +#endif + + return(rlink(name)); } =20 char * $ strings /usr/obj/usr/src/usr.sbin/mtree/mtree | grep rlink logfile problem in rlink_check() $ truss /usr/obj/usr/src/usr.sbin/mtree/mtree \ -K $KEYS -p /usr -x -X $DB/_usr.ex < $DB/_usr.db \ 2>&1 >/dev/null | tail -100 read(0x3,0xbfbff16c,0x400) =3D 0 (0x0) close(3) =3D 0 (0x0) open("./compat/linux/usr/lib/python1.5/site-packages/rpmmodule.so",0,027757= 772554) =3D 3 (0x3) read(0x3,0xbfbff16c,0x400) =3D 1024 (0x400) =2E.. read(0x3,0xbfbff16c,0x400) =3D 1024 (0x400) read(0x3,0xbfbff16c,0x400) =3D 168 (0xa8) read(0x3,0xbfbff16c,0x400) =3D 0 (0x0) close(3) =3D 0 (0x0) open("./compat/linux/usr/lib/python1.5/site-packages/rpmmodule.so",0,027757= 772554) =3D 3 (0x3) read(0x3,0xbfbff16c,0x400) =3D 1024 (0x400) =2E.. read(0x3,0xbfbff16c,0x400) =3D 1024 (0x400) read(0x3,0xbfbff16c,0x400) =3D 168 (0xa8) read(0x3,0xbfbff16c,0x400) =3D 0 (0x0) close(3) =3D 0 (0x0) open("/var/tmp/mtree.log",521,0666) =3D 3 (0x3) lseek(3,0x0,2) =3D 0 (0x0) sigaction(SIGSYS,0xbfbff4b8,0xbfbff4a0) =3D 0 (0x0) __getcwd(0xd2da400,0x3fc) =3D 0 (0x0) sigaction(SIGSYS,0xbfbff4a0,0x0) =3D 0 (0x0) fstat(3,0xbfbff1b0) =3D 0 (0x0) write(3,0xd2de000,142) =3D 142 (0x8e) close(3) =3D 0 (0x0) readlink("X11",0x804f160,1023) ERR#2 'No such file or directory' mtree: write(2,0xbfbfeda8,7) =3D 7 (0x7) line 1361949: X11write(2,0xbfbfedd8,17) =3D 17 (0x11) : write(2,0xbfbfed98,2) =3D 2 (0x2) No such file or directory write(2,0xbfbfed98,26) =3D 26 (0x1a) sigprocmask(0x1,0x280605a0,0xbfbff440) =3D 0 (0x0) sigprocmask(0x3,0x280605b0,0x0) =3D 0 (0x0) write(1,0xd2da000,357) =3D 357 (0x165) exit(0x1) process exit, rval =3D 256 $ file /var/tmp/mtree.log /var/tmp/mtree.log: ASCII text $ tail -100 /var/tmp/mtree.log cwd=3D/usr name=3DX11 fts_info=3D13 fts_accpath=3D./compat/linux/usr/lib/X11 fts_path=3D./compat/linux/usr/lib/X11 fts_name=3DX11 fts_level=3D fts_errno=3D0 ----------------------------------------------------------------- This means that by chance(?) the broken symlink is the first symlink at all in the /usr fs. So I went and "fixed" mtree with the following patch: BTW: Labouring on the topic and using sysmouse for transferring the reports and diffs between machines I'm *very* urged to go and make scmouse work in the _expected_ way. Has nobody ever noticed it's "broken" (I couldn't see a PR in up to and including #21086)? At the very least it's inconsistent with xterm and rather annoying. Prepare to see another PR on this very subject soon ... :> ----------------------------------------------------------------- --- compare.c 2000/06/28 02:33:17 1.15.2.1 +++ compare.c 2000/09/09 15:20:41 @@ -298,7 +298,7 @@ } #endif /* RMD160 */ - if (s->flags & F_SLINK && strcmp(cp =3D rlink(name), s->slink)) { + if (s->flags & F_SLINK && strcmp(cp =3D rlink(p->fts_accpath), s->s= link)) { LABEL; (void)printf("%slink ref (%s, %s)\n", tab, cp, s->slink); } ----------------------------------------------------------------- This patch makes mtree(1) work again. But I'm still not clear as to whether fts(3) has chdir(2) problems (or if it should chdir(2) at all) or if it's mtree(1)'s fault damaging the current directory setting somehow. Having a closer look at the compare() function everywhere fts_accpath is used and the name parameter seems to be for logging or relative pathname database creation only. So it all could have been this simple and the problem is solved and closed? But I still feel mtree should have failed for *any* symlink not residing in the -p base before. Hmmm ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net --=20 If you don't understand or are scared by any of the above ask your parents or an adult to help you. :r !ssh -l admin 192.168.11.142 cat /var/tmp/mtree.scr Script started on Sat Sep 9 16:06:02 2000 organ# pwd /usr/src/usr.sbin/mtree organ# ^D=08=08exit Script done on Sat Sep 9 16:08:31 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 12:40: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 80B2737B424 for ; Sat, 9 Sep 2000 12:40:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA16163; Sat, 9 Sep 2000 12:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 87A2837B422 for ; Sat, 9 Sep 2000 12:35:29 -0700 (PDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e89JZR409905 for ; Sat, 9 Sep 2000 21:35:27 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail3.siemens.de (8.11.0/8.11.0) with ESMTP id e89JZQk7799003 for ; Sat, 9 Sep 2000 21:35:26 +0200 (MEST) Received: (from localhost) by curry.mchp.siemens.de (8.11.0/8.11.0) id e89JZQo77336 for FreeBSD-gnats-submit@freebsd.org; Sat, 9 Sep 2000 21:35:26 +0200 (CEST) Message-Id: <200009091935.e89JZQa36439@curry.mchp.siemens.de> Date: Sat, 9 Sep 2000 21:35:26 +0200 (CEST) From: Andre Albsmeier To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21152: @monthly entry in crontab is run every day Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21152 >Category: bin >Synopsis: @monthly entry in crontab is run every day >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 12:40:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Andre Albsmeier >Release: FreeBSD 4.1-STABLE i386 >Organization: >Environment: FreeBSD 4.1-STABLE >Description: Crontab entries using @monthly are run daily >How-To-Repeat: Put an @monthly entry in crontab and wait one day >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 14:30: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CFFFD37B424 for ; Sat, 9 Sep 2000 14:30:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA30651; Sat, 9 Sep 2000 14:30:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 0473337B424; Sat, 9 Sep 2000 14:27:35 -0700 (PDT) Message-Id: <20000909212735.0473337B424@hub.freebsd.org> Date: Sat, 9 Sep 2000 14:27:35 -0700 (PDT) From: riccardo@torrini.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21154: Change the name of *_saver.ko to saver_*.ko Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21154 >Category: kern >Synopsis: Change the name of *_saver.ko to saver_*.ko >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 14:30:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Riccardo Torrini >Release: 5.0-CURRENT >Organization: >Environment: FreeBSD trudy.home.torrini.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Sep 9 10:19:55 CEST 2000 root@trudy.home.torrini.org:/usr/obj/usr/src/sys/TRUDY i386 >Description: Please change the names of the saver modules to uniform names under /modules (now /boot/kernel, but I think final version will go to /boot/modules instead) from actual *_saver.ko to saver_*.ko as interfaces (if_*.ko), sound (snd_*.ko), splash (splash_*.ko) and netgraph (ng_*.ko). >How-To-Repeat: For 5.0-CURRENT: # cd /boot/kernel && ls *_* For previous versions: # cd /modules && ls *_* >Fix: Rename during installkernel phase in the meantime, after changing line in /etc/rc.i386 from: kldstat -v | grep -q _saver || kldload ${saver}_saver to: kldstat -v | grep -q saver_ || kldload saver_${saver} >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 14:40: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D7EF037B423 for ; Sat, 9 Sep 2000 14:40:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA31935; Sat, 9 Sep 2000 14:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 517EC37B423; Sat, 9 Sep 2000 14:36:16 -0700 (PDT) Message-Id: <20000909213616.517EC37B423@hub.freebsd.org> Date: Sat, 9 Sep 2000 14:36:16 -0700 (PDT) From: riccardo@torrini.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/21155: Load average (either with uptime both top) go over 1.00 without any load Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21155 >Category: kern >Synopsis: Load average (either with uptime both top) go over 1.00 without any load >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 14:40:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Riccardo Torrini >Release: 5.0-CURRENT >Organization: >Environment: FreeBSD trudy.home.torrini.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Sep 9 10:19:55 CEST 2000 root@trudy.home.torrini.org:/usr/obj/usr/src/sys/TRUDY i386 >Description: Load average (either with uptime both top) go over 1.00 without any program running (I removed also X and tryed on console) but cpu is really free, as in top, line CPU states: 0.0% user, 0.0% nice, 5.1% system, 0.0% interrupt, 94.9% idle >How-To-Repeat: # uptime 11:30PM up 2:03, 3 users, load averages: 1.26, 1.14, 1.08 (or see first line of top) >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 17:50: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CEDBA37B423 for ; Sat, 9 Sep 2000 17:50:00 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA55405; Sat, 9 Sep 2000 17:50:00 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 2330737B423 for ; Sat, 9 Sep 2000 17:47:13 -0700 (PDT) Received: (qmail 4714 invoked by uid 0); 10 Sep 2000 00:47:11 -0000 Received: from p3ee2163a.dip.t-dialin.net (HELO speedy.gsinet) (62.226.22.58) by mail.gmx.net with SMTP; 10 Sep 2000 00:47:11 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id CAA18714 for FreeBSD-gnats-submit@freebsd.org; Sun, 10 Sep 2000 02:46:05 +0200 Message-Id: <20000910024605.R252@speedy.gsinet> Date: Sun, 10 Sep 2000 02:46:05 +0200 From: Gerhard Sittig To: FreeBSD-gnats-submit@freebsd.org In-Reply-To: <20000903211143.T252@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Sun, Sep 03, 2000 at 09:11:43PM +0200 References: <20000903211143.T252@speedy.gsinet> Subject: kern/21156: [PATCH] inconsistency in scmouse vs xterm behaviour Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21156 >Category: kern >Synopsis: [PATCH] inconsistency in scmouse vs xterm behaviour >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 09 17:50:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Gerhard Sittig >Release: FreeBSD 4.1-STABLE i386 >Organization: in private >Environment: FreeBSD 4.1-STABLE i386 >Description: FreeBSD's sysmouse feature (mouse copy'n'paste for text console) is different in behaviour from xterm (the "original", I guess) and Linux consoles (another prominent implementation) in the following respect: - When copying multiple lines empty lines are silently left out. - Continued (wrapped) lines are broken up. - When copying a complete line (by triple clicking) all the spaces at the line's end get pasted, too. >How-To-Repeat: Copy any shell script between a viewer and an editor via scmouse, The code might still be the same, but it's less readable. Copy some diff(1) -u or similar output and feed the result into patch(1), chances are the missing empty line will break the context recognition. Copy a word which is wrapped around the screen's margin. This is impossible to do via scmouse. Use scmouse for "repeating" long command lines (w/o employing the shell's history feature which I know to be in existence -- this scenario is just an example for the "need" to copy wrapped lines) and it gets even worse: The inserted newline will send incomplete commands! So you end up selecting some text up to close before the lines wrap and type the missing parts. I've been bitten by this several times. Especially when transferring code snippets or reports between separate machines by means of the mouse clipboard it's annoying. And since xterm seemed to be the inspiration scmouse should be changed to show the same behaviour. Otherwise switching between text mode and X sessions will make users angry due to permanent annoyance. :> The trailing spaces when copying complete single lines are just a minor annoyance. Fixing these would break copying spaces only as well as copying text and some additional spaces, unless the logic is extended to tell these two situations apart (spaces only, letters and spaces). What I would *love* to see is the chance to start selecting with a double or triple click and to _continue_ selecting wordwise or linewise by _dragging_ the mouse. Extending selection by button3 clicks is not a viable alternative on notebooks. :( And neither does it take into consideration whether selection was initially done for whole words or lines. The latter aspect is not dealt with by this patch. It would mean to keep more than just a "we're selecting" bit but instead have a state "we're selecting whole characters, whole words, or whole lines". Then selection would start by any click (actually a button1 down) in character mode, could be switched to other modes with more clicks (1down shortly after the previous up) and no motion yet, and any motion (above a certail epsilon) would extend until button1 release / the up event. Extension by downing button2 would be an additional feature for those lucky enough to have a (usable) third button. :) >Fix: ----------------------------------------------------------------- --- scmouse.c 2000/09/09 23:46:47 1.1 +++ scmouse.c 2000/09/09 23:56:59 @@ -336,14 +336,15 @@ to = start - 1; } for (p = from, i = blank = 0; p <= to; ++p) { - cut_buffer[i] = sc_vtb_getc(&scp->vtb, p); + cut_buffer[i++] = c = sc_vtb_getc(&scp->vtb, p); /* remember the position of the last non-space char */ - if (!IS_SPACE_CHAR(cut_buffer[i++])) + if (!IS_SPACE_CHAR(c)) blank = i; /* the first space after the last non-space */ /* trim trailing blank when crossing lines */ - if ((p % scp->xsize) == (scp->xsize - 1)) { + if (((p % scp->xsize) == (scp->xsize - 1)) && (IS_SPACE_CHAR(c))) { cut_buffer[blank] = '\r'; - i = blank + 1; + blank++; + i = blank; } } cut_buffer[i] = '\0'; ----------------------------------------------------------------- Storing the current character in c is just for my own sake (wouldn't like to struggle against the fact when the index is incremented and when it's not yet:). Checking for spaces at the screen edge before breaking lines will keep wrapped words together. Pointing blank to the space after the one which just got replaced by carriage return will keep empty lines intact. 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. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Sep 9 18: 6:35 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5AEB037B422; Sat, 9 Sep 2000 18:06:34 -0700 (PDT) Received: (from grog@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id SAA58198; Sat, 9 Sep 2000 18:06:34 -0700 (PDT) (envelope-from grog@FreeBSD.org) Date: Sat, 9 Sep 2000 18:06:34 -0700 (PDT) From: Message-Id: <200009100106.SAA58198@freefall.freebsd.org> To: dl@leo.org, grog@FreeBSD.org, freebsd-bugs@FreeBSD.org, grog@FreeBSD.org Subject: Re: kern/21148: multiple crashes while using vinum Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: multiple crashes while using vinum State-Changed-From-To: open->feedback State-Changed-By: grog State-Changed-When: Sat Sep 9 17:41:25 PDT 2000 State-Changed-Why: Submitter did not supply the required information. Responsible-Changed-From-To: freebsd-bugs->grog Responsible-Changed-By: grog Responsible-Changed-When: Sat Sep 9 17:41:25 PDT 2000 Responsible-Changed-Why: grog supports Vinum. http://www.freebsd.org/cgi/query-pr.cgi?pr=21148 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message