From owner-freebsd-stable Sun Mar 10 11:36:39 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA15658 for stable-outgoing; Sun, 10 Mar 1996 11:36:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA15652 for ; Sun, 10 Mar 1996 11:36:37 -0800 (PST) Received: from neon.nwpros.com (neon.nwpros.com [205.229.128.3]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id LAA22744 for ; Sun, 10 Mar 1996 11:36:36 -0800 Received: (from gclarkii@localhost) by neon.nwpros.com (8.6.12/8.6.12) id NAA12628 for freebsd-stable@freebsd.org; Sun, 10 Mar 1996 13:35:34 -0600 From: Gary Clark II Message-Id: <199603101935.NAA12628@neon.nwpros.com> Subject: libtelnet needs to be bumped! To: freebsd-stable@freebsd.org Date: Sun, 10 Mar 1996 13:35:34 -0600 (CST) X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just got bit somehow with telnetd telling me something like encrypt_debug_?? not defined. This is in stables libtelnet and not releases. Should we not bump it 2.1 vice 2.0? Gary -- Gary Clark II (N5VMF) | Director of Operations | Good service at gclarkii@Neon.NWPros.COM | Network Pros, Inc. | low rates!! FreeBSD FAQ at ftp.FreeBSD.ORG in ~pub/FreeBSD/docs/freebsd-faq.ascii From owner-freebsd-stable Sun Mar 10 22:00:30 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA02460 for stable-outgoing; Sun, 10 Mar 1996 22:00:30 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA02440 for ; Sun, 10 Mar 1996 22:00:24 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id HAA01379; Mon, 11 Mar 1996 07:50:08 +0200 (SAT) Message-Id: <199603110550.HAA01379@grumble.grondar.za> To: Gary Clark II cc: freebsd-stable@freebsd.org Subject: Re: libtelnet needs to be bumped! Date: Mon, 11 Mar 1996 07:50:07 +0200 From: Mark Murray Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gary Clark II wrote: > Hi, > > I just got bit somehow with telnetd telling me something like encrypt_debug_? ? > not defined. This is in stables libtelnet and not releases. Should we > not bump it 2.1 vice 2.0? Sure, if that is the case. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-stable Mon Mar 11 06:58:58 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA13020 for stable-outgoing; Mon, 11 Mar 1996 06:58:58 -0800 (PST) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA13015 for ; Mon, 11 Mar 1996 06:58:53 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.7.4/8.6.12) id WAA03189 for freebsd-stable@freebsd.org; Mon, 11 Mar 1996 22:59:03 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-stable@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-stable@freebsd.org Date: 11 Mar 96 14:52:43 GMT From: peter@jhome.DIALix.COM (Peter Wemm) Message-ID: Organization: DIALix Services, Perth, Australia. References: <199603101935.NAA12628@neon.nwpros.com> Subject: Re: libtelnet needs to be bumped! Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk gclarkii@neon.nwpros.com (Gary Clark II) writes: >Hi, >I just got bit somehow with telnetd telling me something like encrypt_debug_?? >not defined. This is in stables libtelnet and not releases. Should we >not bump it 2.1 vice 2.0? >Gary Have you ever installed the compat2x distribution? It's been known to cause this kind of problem.. Also, removing a symbol is a 'major' revision bump, not a minor. Which library used to define the symbol in question? Is it possible that some other library (eg: libkrb) has changed at some point to define the new symbol, and libtelnet now refers to it (meaning libkrb should be bumped, not libtelnet). Or perhaps one of the libraries refered to a global symbol in the executable itself, and the executable changed to not define the symbol anymore and the library had not been installed yet.. If this is the case, no version bumps are needed. -Peter >-- >Gary Clark II (N5VMF) | Director of Operations | Good service at >gclarkii@Neon.NWPros.COM | Network Pros, Inc. | low rates!! > FreeBSD FAQ at ftp.FreeBSD.ORG in > ~pub/FreeBSD/docs/freebsd-faq.ascii From owner-freebsd-stable Mon Mar 11 23:27:32 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA10327 for stable-outgoing; Mon, 11 Mar 1996 23:27:32 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA10319 Mon, 11 Mar 1996 23:27:30 -0800 (PST) Message-Id: <199603120727.XAA10319@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: The continueing 2842/eisaconf argument In-reply-to: Your message of "Sat, 09 Mar 1996 12:40:23 MST." <199603091940.MAA21251@phaeton.artisoft.com> Date: Mon, 11 Mar 1996 23:27:29 -0800 From: "Justin T. Gibbs" Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You'rre probably right that most people aren't that interested in this discussion, so I'll make this my last note on this subject and let the source code speak for itself when I get to writing it. >The *only* reason you need the BIOS is to determine the per slot CMOS >area size. Other than that, all EISA information is accessable as a >memory reference from protected mode. > >I think the ability to access/manipulate EISA data is a lot closer >than the ever-out-of-reach-VM86(). If nothing else, the ram area >size *could* be passed via the boot code. Okay, provide the code. 8-) >> It has to be up to each driver to request and then interpret this >> information if it makes sense for them to do so. Many cards could >> care less about what's up in configuration space. The 3c579 is one, >> the 2842 is another. If we have to support EISA devices that don't >> want configuration data we can also support VLB devices that doesn't >> use configuration space information with no additional complexity. >> Its really a question of capability and use. > >I think this assumes you use real mode/VM86 BIOS calls to get the >configuration data per EISA slot. That way you would have a built >in stop for non-EISA cards. If you access via memory reference, as >I would hope would be done, since VM86() seems too far off, then >the stop isn't there. You seem to think that the eisaconf code could read the data and make any sense of it on its own. It can't. The ECU has the luxury of eisa configuration files to parse and tell it how to interpret the data. In FreeBSD, the device driver will have to know, so unless you want to compile eisa configuration files into the kernel you will always have to push eisa configuration space manipulation down into the driver (it calling the eisa configuration space manipulation API provided by eisaconf). >> The 2742 and the 2842 will continue to get most of the information >> about the card in the exact same way regardless of the availibility >> of configuration space data. You're also not talking about >> stub code, but an additional probe that iterates through the slot >> address space since the 2842 can't reference the eisa code in your >> model since you don't want to have to have eisa0 in your config file. > >Excuse me. You are saying that iterating through the slot address >space is the only way to detect if the card is present or not? I >know it is the method that happens to be used currently. I wasn't >aware that the card was otherwise undetectable. How else do you find them? How else do you find the 2842? >> Having the config file is simply a way of aiding the ECU >> in telling you where conflicts are or restricing your configuration >> settings. Once the ECU session is over, there's nothing their to >> tell FreeBSD about these ISA devices. > >I will agree with the caveat the we are talking about the *current* >ECU code. I believe the information that it does not have an EISA ID >is sufficient to indicate the cards existance and the need to probe >fixed cards with potentially invasive probes, at least the first >time the hardware is auto-configured. I can't parse this. I don't think AMI is going to be dropping me a new version of their ECU software anytime soon. Without the EISA ID or a "saved to disk" current configuration file, I don't think the ECU knows anything about the card. Remember that the ECU keys off the EISAID found at each slot to determine the eisa configuration file to read in so it can interpret the configuration space for the device. The ID for the last configured device is also stored up there so it can be matched to the device in the current slot. Other than the stored ID, I don't believe that there is any other data stored in a common format for the ECU to interpret... just a series of port addresses and data values to write out during initialization fothe EISA bus which could affect any of a number of different types of settings on the card. >> You can switch the dip switches on your 2842 all day, and FreeBSD will >> still find it. You can also move your 2742 from slot to slot all day >> and FreeBSD will still find it. Relocating the card doesn't prevent >> you from booting from it in either case so long as the card's bios is >> enabled. Booting is a BIOS issue. I can make a 2742 not bootable >> by disabling its BIOS too. > >It does if I relocate something over top of its address space because >it didn't have a graph entry warning me it was there. If you can't even get to the BIOS, FreeBSD can't help you. Someone who does this ends up calling Adaptec's technical support line who in turn will refer them back to page one of the user guide where it tells you in bold print to set the ID to be the same as for the slot its in if you install it in an EISA system. This has nothing to do with this discussion since FreeBSD cannot create or fix this situation. >> The 2742 is just as non-relocatable as the 2842. The 2742 locks out is irq >> register after the first time its written to (by the EISA configuration >> just after POST). > >This is irrelevant. EISA supports resetting this, in any case, or the >card would be impossible to reconfigure with the Adaptec tools. > >The point is that even if an EISA space card has only one potential >space utilization topology, it is intrinsically *different* from an >ISA card because the slot configuration data (which is only present >on real EISA and is not used currently) can be consulted to determine >allowable potential topologies. Only by asking the device to interpret the data for you. I can give you the same information for a 2842 and export it to eisaconf the same way the 2742 does and it doesn't matter that the 2842 never looked at configuration space. Your still thinking that eisconf can do the relocation without consulting each driver... It can't. >> Most EISA cards can't relocate their I/O range, but the >> Buslogic cards can relocate relocate their registers through a range of ISA >> compatibily areas. The point is that the way you deal with registering >> relocatability has to be generic so you can deal with devices that vary in >> their degrees of flexibility regardless of their bus type. > >I agree completely. But while the per slot data provides this information >for true EISA cards, it does not do so for VLB cards pretending to be >EISA cards. The configuration space doesn't tell you "all the possible places I can be set to." It tells you what registers on the card were set with what bits during boot. Nothing more. The driver still has to be the one to interpret the data. >This is seriously damning of my idea to use the EISA tag as a negative >indicator. It means that there *would* need to be probe code for VLB >cards that pretend to be EISA cards. > >But it does not mean that the probe would have to take the form of a >slot iteration. How else do you find them? I'll lend you my 2842 tech ref so you can tell me another way. :-) >BTW: I'm curious: how does the thing avoid slot configuration conflicts >in a real EISA system? How is the VLB "fake-EISA" data exported so as >to not conflict with the real thing? What if I plug two of these things >into two VLB slots in the same machine? People who don't read the installation instructions get hosed. Its not unlike most PC hardware. >> Not all EISA devices are relocatable in the same ways. I can find >> plenty of EISA devices that have the same relocation deficiencies >> as the 2842. This is not a valid argument. > >No, but all *real* EISA devices are detectably relocatable using the >slot configuration data that doesn't exist for VLB devices pretending >to be EISA devices. As I've pointed out before, it doesn't matter where the driver gets the data as long as there is a facility for it to inform the configuration manager of what capabilities it has. >This is what I meant when I said the configuration process would have >to dereference this data through the driver so that the VLB card >driver could fake the information that wouldn't exist if the config >attempted to access it directly without the indirection. I think >this will be a bigger problem than card detection. It has to go through the driver anyway. >> Not all EISA cards are relocatable after their first initialization. >> We have to deal with these anyway. > >We can. But to deal at all, we have to have an idea of the relocatability, >as noted above, and VLB cards pretending to be EISA don't give that. Sure they do. THe driver says that you can change its irq to X,Y, and Z, but that its baseaddress is fixed. This is exactly the same info that you get from the 2742. What information can't I give and why can't I? >I agree with this... my point is that EISA configuration should be >autonomously seperable from the rest of the configuration. The bus >attach should be on a per bus basis, and the lines shouldn't be >blurred by probes that cross over allowed boundries. I think it >should work on the order of SCSI bus attachment, per bus. > >I think it has to for the DEC Alpha AXP/PCI boxes: their ISA is >bridged from the PCI, not vice versa, and I know PReP/CHRP require >this, so machines based on the Motorolla chips have the same issue. >I expect there to be Intel based hardware with the same issues >soon (if it doesn't already exist somewhere). This is easy to do regardless of the fact that the 2842 is treated as an eisaconf device since as far as I know, there are no VL Alpha machines. >Yes. And bus existance is seperable for the purposes of causing a >bus attach to occur, and you don't need to attach an EISA bus (or >have the code taking space in the kernel) when you don't have an >EISA bus on your machine. When you don't have an eisabus or a 2842, the module is unloaded. >Then you must make registration variant so that the EISA code registers >the card as an ISA card. > >This defeats the ability to seperate out (and discard) the EISA bus >attach code on machines without an EISA bus, in all cases. Again, if you don't have a 2842 or an eisa motherboard, the module is unloaded. >Requiring the EISA code to probe it prevents discarding the EISA >bus attach, or only performing the bus attach when the bus exists. 8-(. If the EISA probe turns up false, there is no 2842. How does this prevent discarding the EISA lkm after its probe? > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-stable Wed Mar 13 23:34:06 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA06028 for stable-outgoing; Wed, 13 Mar 1996 23:34:06 -0800 (PST) Received: from wsantee.oz.net (wsantee.oz.net [204.118.240.207]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA06023 for ; Wed, 13 Mar 1996 23:33:52 -0800 (PST) Received: (from wsantee@localhost) by wsantee.oz.net (8.6.12/8.6.12) id XAA01371 for stable@freebsd.org; Wed, 13 Mar 1996 23:32:11 -0800 From: Wes Santee Message-Id: <199603140732.XAA01371@wsantee.oz.net> Subject: Commit messages To: stable@freebsd.org Date: Wed, 13 Mar 1996 23:32:10 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 'Lo all. Is there a mailing list for receiving CVS commit messages for the -stable branch only? Did a 'lists' command at majordomo@freebsd.org, but didn't see anything that fit the bill. Cheers, -- ( -Wes Santee | ) ( (backup) | No one told you when to run... ) ( http://www.oz.net/~wsantee \------------------------------- ) ( For PGP Key, email w/Subject: "Send PGP Key" Powered by FreeBSD ) From owner-freebsd-stable Thu Mar 14 06:41:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA09743 for stable-outgoing; Thu, 14 Mar 1996 06:41:15 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA09736 Thu, 14 Mar 1996 06:41:13 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199603141441.GAA09736@freefall.freebsd.org> Subject: Re: Commit messages To: wsantee@wsantee.oz.net (Wes Santee) Date: Thu, 14 Mar 1996 06:41:13 -0800 (PST) Cc: stable@FreeBSD.org In-Reply-To: <199603140732.XAA01371@wsantee.oz.net> from "Wes Santee" at Mar 13, 96 11:32:10 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Wes Santee wrote: > > 'Lo all. > > Is there a mailing list for receiving CVS commit messages for the > -stable branch only? Did a 'lists' command at majordomo@freebsd.org, > but didn't see anything that fit the bill. no, ther is not. and the cvs-meister will have to vet what i am saying here: commits to the -stable branch are just that commits to a branch rather than commits to a cvs module. the cvs commit messages are generated be each commit to a module. that's why there is not a cvs-stable list. jmb From owner-freebsd-stable Thu Mar 14 07:19:33 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA11299 for stable-outgoing; Thu, 14 Mar 1996 07:19:33 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA11293 for ; Thu, 14 Mar 1996 07:19:31 -0800 (PST) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id HAA02908 for ; Thu, 14 Mar 1996 07:18:55 -0800 Received: by Sisyphos id AA15941 (5.67b/IDA-1.5 for stable@FreeBSD.org); Thu, 14 Mar 1996 16:15:24 +0100 Message-Id: <199603141515.AA15941@Sisyphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Thu, 14 Mar 1996 16:15:23 +0100 In-Reply-To: "Jonathan M. Bresler" "Re: Commit messages" (Mar 14, 6:41) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "Jonathan M. Bresler" Subject: Re: Commit messages Cc: stable@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mar 14, 6:41, "Jonathan M. Bresler" wrote: } Subject: Re: Commit messages } Wes Santee wrote: } > } > 'Lo all. } > } > Is there a mailing list for receiving CVS commit messages for the } > -stable branch only? Did a 'lists' command at majordomo@freebsd.org, } > but didn't see anything that fit the bill. } } no, ther is not. and the cvs-meister will have to vet what } i am saying here: commits to the -stable branch are just } that commits to a branch rather than commits to a cvs } module. the cvs commit messages are generated be each } commit to a module. that's why there is not a cvs-stable } list. Well, your technical explanation is one thing, but the expectations of people running -stable is another. But it might be possible to make both ends meet and have the commit message mailer send it to a cvs-stable list, if RELENG_2_1_0 is affected. I guess, people running -stable would love such a mail list. (No, I'm none of them, but I have talked with a few in the past ... :) Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se From owner-freebsd-stable Thu Mar 14 17:41:56 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA18402 for stable-outgoing; Thu, 14 Mar 1996 17:41:56 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA18393 for ; Thu, 14 Mar 1996 17:41:52 -0800 (PST) Received: (from jkh@localhost) by time.cdrom.com (8.7.4/8.6.9) id RAA26986 for stable@freebsd.org; Thu, 14 Mar 1996 17:41:44 -0800 (PST) Date: Thu, 14 Mar 1996 17:41:44 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199603150141.RAA26986@time.cdrom.com> To: stable@freebsd.org Subject: nslookup still references iso_ntoa() Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Which appears to have been nuked from even stable? I'm confused. I just switched the /usr/src pointer on my current box to point to my stable tree (which I duly updated first) and did a make world - it fell over in dig as dig tried to borrow debug.c from nslookup, which contains a call to the now non-existant iso_ntoa(). Jordan From owner-freebsd-stable Fri Mar 15 04:46:23 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA26937 for stable-outgoing; Fri, 15 Mar 1996 04:46:23 -0800 (PST) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA26929 for ; Fri, 15 Mar 1996 04:46:15 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.7.4/8.6.12) id UAA17207 for freebsd-stable@freebsd.org; Fri, 15 Mar 1996 20:47:04 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-stable@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-stable@freebsd.org Date: 15 Mar 96 12:40:17 GMT From: peter@jhome.DIALix.COM (Peter Wemm) Message-ID: Organization: DIALix Services, Perth, Australia. References: , <199603141515.AA15941@Sisyphos> Subject: Re: Commit messages Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk se@ZPR.Uni-Koeln.DE (Stefan Esser) writes: >On Mar 14, 6:41, "Jonathan M. Bresler" wrote: >} Subject: Re: Commit messages >} Wes Santee wrote: >} > >} > 'Lo all. >} > >} > Is there a mailing list for receiving CVS commit messages for the >} > -stable branch only? Did a 'lists' command at majordomo@freebsd.org, >} > but didn't see anything that fit the bill. >} >} no, ther is not. and the cvs-meister will have to vet what >} i am saying here: commits to the -stable branch are just >} that commits to a branch rather than commits to a cvs >} module. the cvs commit messages are generated be each >} commit to a module. that's why there is not a cvs-stable >} list. > >Well, your technical explanation is one thing, >but the expectations of people running -stable >is another. > >But it might be possible to make both ends meet >and have the commit message mailer send it to a >cvs-stable list, if RELENG_2_1_0 is affected. > >I guess, people running -stable would love such >a mail list. (No, I'm none of them, but I have >talked with a few in the past ... :) > >Regards, STefan Well, if there was enough demand for it, I guess I could whip something up to do it... (It wouldn't be too hard, just a few lines of perl) Note that I personally dislike the idea, but I'm happy to go along with what people want. IMHO, if we do this, then we're going to have problems with people that are running -stable not knowing what's in the pipeline in -current, and we'll start to see wheels being reinvented... -Peter >-- > Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 > Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 > ============================================================================== > http://www.zpr.uni-koeln.de/~se From owner-freebsd-stable Fri Mar 15 08:07:09 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA07244 for stable-outgoing; Fri, 15 Mar 1996 08:07:09 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA07235 for ; Fri, 15 Mar 1996 08:07:05 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id DAA25382 for stable@freebsd.org; Sat, 16 Mar 1996 03:07:02 +1100 From: michael butler Message-Id: <199603151607.DAA25382@asstdc.scgt.oz.au> Subject: adding a new drive .. To: stable@freebsd.org Date: Sat, 16 Mar 1996 03:07:02 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] Content-Type: text Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After the tragedies of last week, I thought it best to ask here .. there is an apparent bug lurking .. I have a shiny new 4 gig Quantum Atlas (XP34300). I want to add it to a -stable system which already has two other SCSI devices. Having been through the exercise of recovering a clobbered partition table (courtesy of a nasty bug in the 2.1R install disk :-(), I now find that when I try to set up a partition table on another machine (with no other attached drives :-)), it refuses to write the partition table .. it collapses with an I/O error. I've formatted the drive twice and verified it. I've used a DOS disk to install a dummy partition table with no problem yet the BSD install disk hangs with the HD light on. The 2.0.5 installation disk does the same thing. Is this (possibly) related to the fact that the SCSI controller is an Adaptec 1542 or is something else wrong ? I currently have a pricey door-stop :-( michael From owner-freebsd-stable Fri Mar 15 08:07:49 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA07296 for stable-outgoing; Fri, 15 Mar 1996 08:07:49 -0800 (PST) Received: from DATAPLEX.NET (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA07286 for ; Fri, 15 Mar 1996 08:07:46 -0800 (PST) Received: from 199.183.109.242 by DATAPLEX.NET with SMTP (MailShare 1.0fc5); Fri, 15 Mar 1996 10:07:50 -0600 Message-ID: Date: 15 Mar 1996 10:07:24 -0600 From: "Richard Wackerbarth" Subject: Re(2): Commit messages To: "freebsd-stable@FreeBSD.ORG" , "Peter Wemm" X-Mailer: Mail*Link PT/Internet 1.6.0 Sender: owner-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Note that I personally dislike the idea, but I'm happy to go along with > what people want. IMHO, if we do this, then we're going to have problems > with people that are running -stable not knowing what's in the pipeline in > -current, and we'll start to see wheels being reinvented... I disagree with your concern. Just a "gut" feel, but I don't think that many of the "stable" users are really generating any changes. I suspect that they are, at most, simply beta testing someone elses changes. A filtered list would greatly help them to track the changes. From owner-freebsd-stable Fri Mar 15 11:54:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA26076 for stable-outgoing; Fri, 15 Mar 1996 11:54:15 -0800 (PST) Received: from idiom.com (idiom.com [140.174.82.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA26071 for ; Fri, 15 Mar 1996 11:54:09 -0800 (PST) Received: (from muir@localhost) by idiom.com (8.6.12/8.6.12) id LAA13929 for freebsd-stable@freebsd.org; Fri, 15 Mar 1996 11:53:56 -0800 Date: Fri, 15 Mar 1996 11:53:56 -0800 From: David Muir Sharnoff Message-Id: <199603151953.LAA13929@idiom.com> To: freebsd-stable@freebsd.org Subject: Is stable supposed to compile right now? Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It doesn't for me. Here's what I did... On my 2.1-RELEASE system, I ... sup'ed the cvs tree. did a cvs checkout -r RELENG_2_1_0. I did a make install in /usr/src/include and /usr/src/share. Here's the errors I get from the second run of make -k in /usr/src: ===> lib/libc "Makefile", line 19: Could not find /usr/src/lib/libc/gen/Makefile.inc Fatal errors encountered -- cannot continue *** Error code 1 (continuing) ===> gnu/usr.bin/cvs/cvs cc -O -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -DHAVE_CONFIG_H -c client.c client.c: In function `update_entries': client.c:1098: storage size of `context' isn't known *** Error code 1 (continuing) cc -O -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -DHAVE_CONFIG_H -c update.c update.c: In function `patch_file': update.c:1228: storage size of `context' isn't known *** Error code 1 (continuing) `all' not remade because of errors. ===> sbin/nfsd cc -O -DNFS -c nfsd.c nfsd.c:84: libutil.h: No such file or directory *** Error code 1 (continuing) `all' not remade because of errors. ===> share/doc/usd/13.viref # Build index.so, side-effect of building the paper. (cd /usr/src/share/doc/usd/13.viref/../../../../usr.bin/vi/USD.doc/vi.ref; soelim vi.ref) | tbl | groff -Thp -t -s -me -o1- > /dev/null groff: can't find `DESC' file groff:fatal error: invalid device `hp' *** Error code 3 (continuing) `all' not remade because of errors. ===> usr.bin/tn3270/mset cd /usr/src/usr.bin/tn3270/mset/../tools/mkastosc; make /usr/src/usr.bin/tn3270/mset/../tools/mkastosc/obj/mkastosc /usr/src/usr.bin/tn3270/mset/../ctlr/hostctlr.h /usr/src/usr.bin/tn3270/mset/../ctlr/function.h < /usr/src/usr.bin/tn3270/mset/../ctlr/unix.kbd > astosc.OUT /usr/src/usr.bin/tn3270/mset/../tools/mkastosc/obj/mkastosc: not found *** Error code 2 (continuing) `all' not remade because of errors. ===> secure/lib/libtelnet cc -O -DHAS_CGETENT -DENCRYPTION -DAUTHENTICATION -DKRB4 -I/usr/include/kerberosIV -DDES_ENCRYPTION -c kerberos.c -o kerberos.o kerberos.c:62: des.h: No such file or directory kerberos.c:63: krb.h: No such file or directory *** Error code 1 (continuing) cc -p -O -DHAS_CGETENT -DENCRYPTION -DAUTHENTICATION -DKRB4 -I/usr/include/kerberosIV -DDES_ENCRYPTION -c kerberos.c -o kerberos.po kerberos.c:62: des.h: No such file or directory kerberos.c:63: krb.h: No such file or directory *** Error code 1 (continuing) cc -fpic -DPIC -O -DHAS_CGETENT -DENCRYPTION -DAUTHENTICATION -DKRB4 -I/usr/include/kerberosIV -DDES_ENCRYPTION -c kerberos.c -o kerberos.so kerberos.c:62: des.h: No such file or directory kerberos.c:63: krb.h: No such file or directory *** Error code 1 (continuing) `all' not remade because of errors. ===> secure/libexec/telnetd cc -O -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -I/usr/src/secure/libexec/telnetd/../../lib -DAUTHENTICATION -DENCRYPTION -o telnetd authenc.o global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o -L/usr/src/secure/libexec/telnetd/../../lib/libtelnet -lutil -ltermcap -ltelnet -ldes -lkrb state.o: Undefined symbol `_auth_request' referenced from text segment *** Error code 1 (continuing) `all' not remade because of errors. ===> secure/usr.bin/telnet cc -O -DTERMCAP -DKLUDGELINEMODE -DUSE_TERMIO -DENV_HACK -I/usr/src/secure/usr.bin/telnet/../../lib -DAUTHENTICATION -DENCRYPTION -DKRB4 -o telnet authenc.o commands.o main.o network.o ring.o sys_bsd.o telnet.o terminal.o tn3270.o utilities.o -L/usr/src/secure/usr.bin/telnet/../../lib/libtelnet -ltermcap -ltelnet -ldes -lkrb authenc.o: Undefined symbol `_encrypt_output' referenced from text segment *** Error code 1 (continuing) `all' not remade because of errors. The other problem that I have is that the new ipfw doesn't appear to work. Since there is now a default rule to drop all packets, a non-functional ipfw is a show-stopper. -Dave From owner-freebsd-stable Fri Mar 15 13:01:11 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA00468 for stable-outgoing; Fri, 15 Mar 1996 13:01:11 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA00237 for ; Fri, 15 Mar 1996 12:59:48 -0800 (PST) Received: from mail.jrihealth.com ([204.249.32.3]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id MAA27028 for ; Fri, 15 Mar 1996 12:58:26 -0800 Received: from library.pride.net (danp@library.pride.net [204.249.32.4]) by mail.jrihealth.com (8.3/8.6.6.Beta9) with SMTP id QAA19665; Fri, 15 Mar 1996 16:00:19 -0500 Date: Fri, 15 Mar 1996 16:00:31 -0500 (EST) From: Dan Polivy To: freebsd-stable@freebsd.org Subject: subscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dan +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | JRI HIS MIS Systems Administrator/Tech Support | |////////////////////////////////////////////////////////////////| | danp@busstop.org dpolivy@jri.org danp@library.pride.net | |\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\| | Check out JRI's Homepage at http://www.jri.org | |////////////////////////////////////////////////////////////////| | For More Info about JRI Health, call 617.457.8150, | | EMail health@jri.org or check out http://www.jri.org/jrihealth | |\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\| | Check out my NEW [Moving] WWW page (still under construction) | | currently located at: http://server1.pride.net/~danp | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ From owner-freebsd-stable Fri Mar 15 13:29:13 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA02668 for stable-outgoing; Fri, 15 Mar 1996 13:29:13 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA02655 for ; Fri, 15 Mar 1996 13:29:03 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id NAA27429 for ; Fri, 15 Mar 1996 13:28:55 -0800 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA12100; Fri, 15 Mar 1996 14:29:59 -0700 Date: Fri, 15 Mar 1996 14:29:59 -0700 From: Nate Williams Message-Id: <199603152129.OAA12100@rocky.sri.MT.net> To: David Muir Sharnoff Cc: freebsd-stable@freebsd.org Subject: Re: Is stable supposed to compile right now? In-Reply-To: <199603151953.LAA13929@idiom.com> References: <199603151953.LAA13929@idiom.com> Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On my 2.1-RELEASE system, I ... > > sup'ed the cvs tree. did a cvs checkout -r RELENG_2_1_0. > I did a make install in /usr/src/include and /usr/src/share. You have to do a 'make world'. Make install in /usr/src/includes doesn't pick up enough of the include file and other dependencies to do the right thing. > Here's the errors I get from the second run of make -k in /usr/src: > > ===> lib/libc > "Makefile", line 19: Could not find /usr/src/lib/libc/gen/Makefile.inc > Fatal errors encountered -- cannot continue > *** Error code 1 (continuing) That file exists on my -stable box. > ===> gnu/usr.bin/cvs/cvs > cc -O -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -DHAVE_CONFIG_H -c client.c > client.c: In function `update_entries': > client.c:1098: storage size of `context' isn't known > *** Error code 1 (continuing) > cc -O -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -DHAVE_CONFIG_H -c update.c > update.c: In function `patch_file': > update.c:1228: storage size of `context' isn't known > *** Error code 1 (continuing) > `all' not remade because of errors. This is because you didn't use a make world (more specifically, 'make includes' which re-does *all* of the necessary includes). [ The others are related to not doing a make world. ] > The other problem that I have is that the new ipfw doesn't appear to > work. Since there is now a default rule to drop all packets, a > non-functional ipfw is a show-stopper. That is a function of the new IPFW. You *must* be on the console the first time you use it, OR you must add some default rules immediately after the network is configured to allow certain packets in. Nate From owner-freebsd-stable Fri Mar 15 15:19:34 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA10496 for stable-outgoing; Fri, 15 Mar 1996 15:19:34 -0800 (PST) Received: from idiom.com (idiom.com [140.174.82.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA10477 for ; Fri, 15 Mar 1996 15:19:23 -0800 (PST) Received: (from muir@localhost) by idiom.com (8.6.12/8.6.12) id PAA21485; Fri, 15 Mar 1996 15:19:07 -0800 Date: Fri, 15 Mar 1996 15:19:07 -0800 From: David Muir Sharnoff Message-Id: <199603152319.PAA21485@idiom.com> To: Nate Williams Cc: freebsd-stable@freebsd.org Subject: Re: Re: Is stable supposed to compile right now? Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * You have to do a 'make world'. Make install in /usr/src/includes * doesn't pick up enough of the include file and other dependencies to do * the right thing. Okay, thanks. * > The other problem that I have is that the new ipfw doesn't appear to * > work. Since there is now a default rule to drop all packets, a * > non-functional ipfw is a show-stopper. * * That is a function of the new IPFW. You *must* be on the console the * first time you use it, OR you must add some default rules immediately * after the network is configured to allow certain packets in. Dman, I just figured out what I was doing wrong last night. "accept" != "allow". Damn. Could someone please nuke the bug report I submitted on the subject: bin/1077? I still think the default rule should need to be compiled in, but as long as ipfw works, I can deal with it. -Dave From owner-freebsd-stable Sat Mar 16 09:17:59 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA19475 for stable-outgoing; Sat, 16 Mar 1996 09:17:59 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA19468 for ; Sat, 16 Mar 1996 09:17:54 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id SAA22535; Sat, 16 Mar 1996 18:00:29 +0100 (MET) Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.7.5/8.7.3) with SMTP id RAA01081; Sat, 16 Mar 1996 17:39:31 +0100 (MET) Date: Sat, 16 Mar 1996 17:39:31 +0100 (MET) From: Andreas Klemm To: Peter Wemm cc: freebsd-stable@freebsd.org Subject: Re: Commit messages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 15 Mar 1996, Peter Wemm wrote: > Well, if there was enough demand for it, I guess I could whip something > up to do it... (It wouldn't be too hard, just a few lines of perl) > > Note that I personally dislike the idea, but I'm happy to go along with > what people want. > IMHO, if we do this, then we're going to have problems > with people that are running -stable not knowing what's in the pipeline in > -current, and we'll start to see wheels being reinvented... You're right, people who want to get the source repository for -stable should also receive -current to prevent this. The ones who want only the newest stable source have already the possibility to sup -stable. -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< "Ich bleibe bei der Aussage und trotze den Flames. :-)" Ulli Horlacher 02/96 From owner-freebsd-stable Sat Mar 16 13:26:35 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA02315 for stable-outgoing; Sat, 16 Mar 1996 13:26:35 -0800 (PST) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA02304 for ; Sat, 16 Mar 1996 13:26:32 -0800 (PST) Received: from tahoma.cwu.edu (skynyrd@tahoma.cwu.edu [198.104.67.25]) by pahtoh.cwu.edu (8.6.13/8.6.9) with ESMTP id NAA07076; Sat, 16 Mar 1996 13:26:29 -0800 Received: (from skynyrd@localhost) by tahoma.cwu.edu (8.6.13/8.6.9) id NAA28896; Sat, 16 Mar 1996 13:26:22 -0800 Date: Sat, 16 Mar 1996 13:26:21 -0800 (PST) From: Chris Timmons To: michael butler cc: stable@freebsd.org Subject: Re: adding a new drive .. In-Reply-To: <199603151607.DAA25382@asstdc.scgt.oz.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When you say it collapses with an I/O error, do you mean that the system panics? What are the errors you are seeing? I had a problem with a 4gb disk when I was trying to use 3 or 4 slices; the installation would crash with an 'init died' message and SCSI errors, followed by a panic. This with 2.1-R and the 2.2-960130-SNAP. When I put my partitions in two slices it worked fine. Ultimately though I just went ahead and used 'dangerously dedicated' mode on the disk which works for me but comes with enough caveats to impress even the surgeon general! If it does look like the same problem, you probably want two slices - the first one 32M to contain a single 32M partition for /. Then the second slice could be the rest of the disk and contain partitions for swap, /usr, /usr/local, /usr/users, and so on as you please. Hope this helps, -c On Sat, 16 Mar 1996, michael butler wrote: > After the tragedies of last week, I thought it best to ask here .. there is > an apparent bug lurking .. > > I have a shiny new 4 gig Quantum Atlas (XP34300). I want to add it to a > -stable system which already has two other SCSI devices. Having been through > the exercise of recovering a clobbered partition table (courtesy of a nasty > bug in the 2.1R install disk :-(), I now find that when I try to set up a > partition table on another machine (with no other attached drives :-)), it > refuses to write the partition table .. it collapses with an I/O error. > > I've formatted the drive twice and verified it. I've used a DOS disk to > install a dummy partition table with no problem yet the BSD install disk > hangs with the HD light on. The 2.0.5 installation disk does the same thing. > > Is this (possibly) related to the fact that the SCSI controller is an > Adaptec 1542 or is something else wrong ? I currently have a pricey > door-stop :-( > > michael > From owner-freebsd-stable Sat Mar 16 14:41:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA06009 for stable-outgoing; Sat, 16 Mar 1996 14:41:15 -0800 (PST) Received: from DATAPLEX.NET (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA06004 for ; Sat, 16 Mar 1996 14:41:12 -0800 (PST) Received: from 199.183.109.242 by DATAPLEX.NET with SMTP (MailShare 1.0fc5); Sat, 16 Mar 1996 16:41:16 -0600 Message-ID: Date: 16 Mar 1996 16:40:32 -0600 From: "Richard Wackerbarth" Subject: Re(2): Commit messages To: "Andreas Klemm" , "freebsd-stable@freebsd.org" , "Peter Wemm" X-Mailer: Mail*Link PT/Internet 1.6.0 Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm wrote: > On 15 Mar 1996, Peter Wemm wrote: > > Well, if there was enough demand for it, I guess I could whip something > > up to do it... (It wouldn't be too hard, just a few lines of perl) > > > > Note that I personally dislike the idea, but I'm happy to go along with > > what people want. > > > IMHO, if we do this, then we're going to have problems > > with people that are running -stable not knowing what's in the pipeline in > > -current, and we'll start to see wheels being reinvented... > > You're right, people who want to get the source repository for -stable > should also receive -current to prevent this. > > The ones who want only the newest stable source have already the > possibility to sup -stable. I think that you are missing the point. Even if I use sup or CTM to get the sources, it is very useful to know what/why things were changed. The commit messages are the best documentation readily available. However, if I am not interested in -current, I hate to wade through all the changes that have absolutely no value to me in order to find the few that do apply to the -stable branch.