Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Tue, Jan 18, 2000 at 02:48:25AM -0800, Frank Mayhar wrote: Interestingly, I rebuilt world with the latest pccardd changes and, suddenly, the 589D started working perfectly. Unfortunately, the 574BT doesn't work at all now. It appears to configure properly, but it doesn't transmit or receive. My 574BT works if you hardcode the pccardd IRQ to 9. I did this by editing rc.pccard and replaced the pccard line with: pccardd -i 9 -f ${pccard_conf} It works fine for me. I think there's something wrong with pccardd, and that's why it keeps using IRQs I don't even have specified in pccard.conf. I should do more research on this, though. --Will To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
Warner Losh wrote: In message [EMAIL PROTECTED] Will Andrews writes: : On Tue, Jan 18, 2000 at 02:48:25AM -0800, Frank Mayhar wrote: : Interestingly, I rebuilt world with the latest pccardd changes and, : suddenly, the 589D started working perfectly. Unfortunately, the : 574BT doesn't work at all now. It appears to configure properly, but : it doesn't transmit or receive. : My 574BT works if you hardcode the pccardd IRQ to 9. I did this by : editing rc.pccard and replaced the pccard line with: : : pccardd -i 9 -f ${pccard_conf} : : It works fine for me. I think there's something wrong with pccardd, and : that's why it keeps using IRQs I don't even have specified in : pccard.conf. I should do more research on this, though. Are you sure that pccard_conf isn't set to /etc/pccard.conf.sample? I've *NEVER* seen pccardd use interrupts that it wasn't told about, and I've tried many times to reproduce this. Just for the record, it turned out that the problem I saw with the 574BT was cured by moving pcic0 from irq 11 (which the PCI bus had appropriated) to irq 10. I put the 574 on my last free IRQ, 3. (Don't you hate laptops?) Many, many thanks to Matt Dodd and Warner Losh for their help, patience, suggestions and code! They were terrific. Now I'm looking forward to the newcard cardbus support so I can finally use the 575BT which came with the laptop. (Tapping fingers impatiently. :-) -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
In message [EMAIL PROTECTED] Will Andrews writes: : On Tue, Jan 18, 2000 at 02:48:25AM -0800, Frank Mayhar wrote: : Interestingly, I rebuilt world with the latest pccardd changes and, : suddenly, the 589D started working perfectly. Unfortunately, the : 574BT doesn't work at all now. It appears to configure properly, but : it doesn't transmit or receive. : : My 574BT works if you hardcode the pccardd IRQ to 9. I did this by : editing rc.pccard and replaced the pccard line with: : : pccardd -i 9 -f ${pccard_conf} : : It works fine for me. I think there's something wrong with pccardd, and : that's why it keeps using IRQs I don't even have specified in : pccard.conf. I should do more research on this, though. Are you sure that pccard_conf isn't set to /etc/pccard.conf.sample? I've *NEVER* seen pccardd use interrupts that it wasn't told about, and I've tried many times to reproduce this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
In message [EMAIL PROTECTED] Frank Mayhar writes: : Now I'm looking forward to the newcard cardbus support so I can finally use : the 575BT which came with the laptop. (Tapping fingers impatiently. :-) Hope you are tapping something soft :-) Wouldn't want you to hurt yourself, or have others hurt you from the annoying racket :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Monday, 17 January 2000 at 8:24:20 -0800, Frank Mayhar wrote: Sorry for the delay on this reply; I was going over some old email and came across this only a week late. Jonathan Chen wrote: With what little pccard/ethernet programming experiences I've had, this problem seems to be caused by the interrupt for the card getting lost somewhere before getting processed by the handler. The reason you still get traffic is because of the watchdog. (Try uncommenting the commented out lines in sys/dev/ep/if_ep.c in the function ep_if_watchdog(), you should start seeing lots of kernel messages saying "ep: watchdog".) After looking briefly at the ep files, I saw something that doesn't seem right. In sys/dev/ep/if_ep_pccard.c around line 176, there's a comment that says "Fake IRQ must be 3". Now maybe the card requires it, or maybe the original author just didn't have anything on IRQ 3, I don't know. So, I'd suggest turning off com2 or whatever you have on irq3, -or- change the "fake irq" to something else you do have free on the next line (ie, 0x3000- 0xa000 if you have IRQ10 free). If this works, great... if not, I hope Warner gets some more free time. ;) According to the docs, this "Fake IRQ must be 3" is legitimate. The IRQ programmed into the resource config register in window 0 _must_ be 3: "any other value will disable the IRQ line drivers." (Quoted from the doc. As for the other problem with collisions, I did a search on the word collision on sys/dev/ep/if_ep.c, and found only one mention at around line 620. The comment says "TXS_MAX_COLLISION - we shouldn't get here". I suspect it does get there, so I suggest putting a printf there to find out. I also suspect that the card may require a reset or some other stuff if and when it "gets there". If that's the case, someone else with the specs on the 589 cards can look that up and do it. I can state pretty categorically that, at least in my case, we're _not_ getting here. As I said in an earlier email, I'm still having interrupt problems with the 589 (I have a 3C589D) and the 574BT. I haven't tracked it down yet, but I'm hunting. I do know, at least, that I'm not receiving _any_ interrupts from either card. So far I don't know why. The fact it's appearing with two different cards which work for other people tends to point away from the cards and towards some common factor, such as your laptop. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
Greg Lehey wrote: The fact it's appearing with two different cards which work for other people tends to point away from the cards and towards some common factor, such as your laptop. True. Interestingly, I rebuilt world with the latest pccardd changes and, suddenly, the 589D started working perfectly. Unfortunately, the 574BT doesn't work at all now. It appears to configure properly, but it doesn't transmit or receive. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Tue, 18 Jan 2000, Frank Mayhar wrote: Interestingly, I rebuilt world with the latest pccardd changes and, suddenly, the 589D started working perfectly. Unfortunately, the 574BT doesn't work at all now. It appears to configure properly, but it doesn't transmit or receive. Ok, I need the output of 'dmesg', 'ifconfig -a', your kernel config, and 'ident /sys/dev/ep/*'. I suspect you'll find that the 574BT may be in the 'OACTIVE' state as indicated in the flags section of ifconfig. Please try tcpdumping on ep0 and on another box (using the MAC address of the 574) and seeing if any traffic is visable. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
Sorry for the delay on this reply; I was going over some old email and came across this only a week late. Jonathan Chen wrote: With what little pccard/ethernet programming experiences I've had, this problem seems to be caused by the interrupt for the card getting lost somewhere before getting processed by the handler. The reason you still get traffic is because of the watchdog. (Try uncommenting the commented out lines in sys/dev/ep/if_ep.c in the function ep_if_watchdog(), you should start seeing lots of kernel messages saying "ep: watchdog".) After looking briefly at the ep files, I saw something that doesn't seem right. In sys/dev/ep/if_ep_pccard.c around line 176, there's a comment that says "Fake IRQ must be 3". Now maybe the card requires it, or maybe the original author just didn't have anything on IRQ 3, I don't know. So, I'd suggest turning off com2 or whatever you have on irq3, -or- change the "fake irq" to something else you do have free on the next line (ie, 0x3000- 0xa000 if you have IRQ10 free). If this works, great... if not, I hope Warner gets some more free time. ;) According to the docs, this "Fake IRQ must be 3" is legitimate. The IRQ programmed into the resource config register in window 0 _must_ be 3: "any other value will disable the IRQ line drivers." (Quoted from the doc. As for the other problem with collisions, I did a search on the word collision on sys/dev/ep/if_ep.c, and found only one mention at around line 620. The comment says "TXS_MAX_COLLISION - we shouldn't get here". I suspect it does get there, so I suggest putting a printf there to find out. I also suspect that the card may require a reset or some other stuff if and when it "gets there". If that's the case, someone else with the specs on the 589 cards can look that up and do it. I can state pretty categorically that, at least in my case, we're _not_ getting here. As I said in an earlier email, I'm still having interrupt problems with the 589 (I have a 3C589D) and the 574BT. I haven't tracked it down yet, but I'm hunting. I do know, at least, that I'm not receiving _any_ interrupts from either card. So far I don't know why. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
In message [EMAIL PROTECTED] Jonathan Chen writes: : "Fake IRQ must be 3". Now maybe the card requires it, or maybe the : original author just didn't have anything on IRQ 3, I don't know. So, I'd : suggest turning off com2 or whatever you have on irq3, -or- change the : "fake irq" to something else you do have free on the next line (ie, : 0x3000- 0xa000 if you have IRQ10 free). If this works, great... if not, I : hope Warner gets some more free time. ;) I don't think this is the problem. The pccard interface has one interrupt pin that is mapped by the pcic bridge (or some other pccard/cardbus bridge) to the main bus of the system. I didn't change that from the 3.x driver... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Friday, 7 January 2000 at 23:46:49 +1100, Darren Reed wrote: In some email I received from Warner Losh, sie wrote: In message [EMAIL PROTECTED] Josef Karthauser writes: : My 3c589d works just fine now, along with suspend/resume :) (under 4.0). The issue with the 3c589d is with its speed. It is falling back to the timeout routine to send data rather than getting an interrupt when the tx has happened (or something like this, I'm reporting second hand stuff). Whatever it is, results in ping times being 1000ms then 10ms then 1000ms then 10ms...when it responds. This doesn't look typical of the problems we've been discussing. First, they appear to occur more with -CURRENT, and secondly they don't affect the ping times. What I've been seeing is that everything is fine until a collision occurs, after which something times out and it takes a 1 second timeout before it continues. It's easiest to see with long ftp transfers. i.e. it's a mistake to use FreeBSD 3.x with the 3c589d. Mine worked fine under 3.x. The problem seems to have crept in in about October last year (1999). On Friday, 7 January 2000 at 12:52:28 -0800, Mike Smith wrote: The issue with the 3c589d is with its speed. It is falling back to the timeout routine to send data rather than getting an interrupt when the tx has happened (or something like this, I'm reporting second hand stuff). Whatever it is, results in ping times being 1000ms then 10ms then 1000ms then 10ms...when it responds. This is typical for interrupt misconfiguration for this driver. When you get the interrupt configuration right, it works fine. (No, getting the interrupt configuration right is not a trivial task.) That may be the answer for Darren's problem. It's definitely not the case for the ones we have been discussing on -mobile. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
[[ Moved to just current ]] In message [EMAIL PROTECTED] Greg Lehey writes: : That may be the answer for Darren's problem. It's definitely not the : case for the ones we have been discussing on -mobile. There are definitely known issues with the ep0 driver. Right now it doesn't interrupt quite right on Rx packets. That's the majority of the problems in current driver, at least with the 3c589D that I have. I see only about 150kBps from the card. I've not had time to deal with looking for this problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Sun, Jan 09, 2000 at 09:26:45PM -0700, Warner Losh wrote: [[ Moved to just current ]] In message [EMAIL PROTECTED] Greg Lehey writes: : That may be the answer for Darren's problem. It's definitely not the : case for the ones we have been discussing on -mobile. There are definitely known issues with the ep0 driver. Right now it doesn't interrupt quite right on Rx packets. That's the majority of the problems in current driver, at least with the 3c589D that I have. I see only about 150kBps from the card. I've not had time to deal with looking for this problem. With what little pccard/ethernet programming experiences I've had, this problem seems to be caused by the interrupt for the card getting lost somewhere before getting processed by the handler. The reason you still get traffic is because of the watchdog. (Try uncommenting the commented out lines in sys/dev/ep/if_ep.c in the function ep_if_watchdog(), you should start seeing lots of kernel messages saying "ep: watchdog".) After looking briefly at the ep files, I saw something that doesn't seem right. In sys/dev/ep/if_ep_pccard.c around line 176, there's a comment that says "Fake IRQ must be 3". Now maybe the card requires it, or maybe the original author just didn't have anything on IRQ 3, I don't know. So, I'd suggest turning off com2 or whatever you have on irq3, -or- change the "fake irq" to something else you do have free on the next line (ie, 0x3000- 0xa000 if you have IRQ10 free). If this works, great... if not, I hope Warner gets some more free time. ;) As for the other problem with collisions, I did a search on the word collision on sys/dev/ep/if_ep.c, and found only one mention at around line 620. The comment says "TXS_MAX_COLLISION - we shouldn't get here". I suspect it does get there, so I suggest putting a printf there to find out. I also suspect that the card may require a reset or some other stuff if and when it "gets there". If that's the case, someone else with the specs on the 589 cards can look that up and do it. (I'll have to admit, I looked only briefly, and know virtually nothing about how the pccard stuff works on freebsd, have no ep card, nor ever looked at the documentation for it, so what just said may be completely wrong -- don't be surprised if it doesn't work.) -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\Jonathan Chen [EMAIL PROTECTED] /_/// ) The surest protection against temptation is cowardice. --MT ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In message [EMAIL PROTECTED] Brian Somers writes: : Also, with a 3c589c, hot plugging is like playing Russian Roulette : with five of the six chambers full at the moment. Just booting with : a pccard inserted sometimes crashes the machine. I think most : peoples view of the current pccard stuff would be that it's far : inferior to RELENG_3. OK. I'm *VERY* interested in this. I've not seen these problems and would like to track them down. I've seen minor little things from time to time, but nothing as major as this. Please contact me off the list so that we can get this one killed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppbus in 4.0-stable? (was: Re: 4.0 code freeze scheduled for Jan 15th)
Hi committers! On Wed, Jan 05, 2000 at 11:44:06AM -0800, Jordan K. Hubbard wrote: And given that we've already slipped from December 15th, I think you can treat this as a pretty hard deadline, to be further slipped only grudgingly and in response to clear and dire need. 10 days, folks! Make 'em count.. :) As usual, the last wheel of the coach: ppbus. You may or may not know new-ppbus is now available for the newbus interfaces. It would make it really easier to maintain it if submitted before the -stable jump. http://www.freebsd.org/~nsouch/ppbus.html reports the improvements. Regression tests shows the newppbus is quite solid... but now I can't rely on a wild commit which would force everybody to test it :) So, please try it! And we'll decide. Thanks in advance, and sorry for being so late :( Nicholas. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
-On [2107 00:01], Poul-Henning Kamp ([EMAIL PROTECTED]) wrote: In message [EMAIL PROTECTED], Steve Ames writes: On the other hand, there are *plenty* of things already in 4.0 that really need to get out there and get a workout by a larger audience. Delaying *them* is a big mistake. *shudder* I really, really dislike the idea of -RELEASE actually being a wide beta so that some code can get a workout. Who said anything about -RELEASE being a beta ? Some parts of a release will always be new, but the majority of it is the same code we released as 3.X, 2.X and even 1.X. We need for people to stop thinking of FreeBSD as commercial software which comes in "natural number" style enumerable packets. While I agree with the sentiment Poul-Henning, the fact that Walnut Creek actually packages a given CVS tag as being the 4.0-RELEASE or whatever as a CD-ROM product gives it a commercial taste, no denying that. FreeBSD style is "real number", it is a continuously evolving quantity which every now and then passes a natural number on the way to infinity. We can now spot a milestone called 4.0 and that's very nice, but we are not going to stop, because the road goes on past 4.0. I think everyone knows that and acknowledges that, but the only thing I tasted from the multitude of mails I just read and evaluated was that people are satisfied with 4.0, but just want IPv6 support to be there, in it's most finished state as possible, and not some half-rushed thinghy which is there, but which is unusable. I think that that is only fair. BUT! Given Shin's RFC on his KAME patches and the answers he got, it almost looks like I was one of the very, very few to actually review his patches (until I got sick and all that). From those demanding IPv6 support in FreeBSD I have yet to see active testing and feedback to Shin. It seems people think the developers are here to do everything. Well, this is your wake-up call guys, it doesn't work that way. We only have the ability to use CVS on the sourcetree directly and we will do a lot of stuff out of ourselves, but we need the community to test, tinker and blow-up stuff and then report this back to the community with general ideas of how and what if you are not that much of a coder, or with patches if you can whoop them up. FreeBSD's Quality Assurance is something in which we all take place. Not just Walnut Creek or any of the committers. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|bart.nl] Documentation nutter. *BSD: Technical excellence at its best... The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai ...fools rush in where Daemons fear to tread. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
At 4:14 PM -0800 2000/1/6, Randy Bush wrote: my point is that we can only wait politely and appreciatively for the kame folk to continue their work to a point where it is more fully rounded. until then, we should not forget that other features are also driving the 4.0 release train. I'd like to point out that if full IPv6 or IPSec support isn't ready for us within this timeframe, I highly doubt that it's going to be ready for anyone else in that same timeframe. On that basis, if anyone else ships with any support for IPv6 or IPSec, it's likely to be incomplete, buggy, and probably cause more problems than it's worth. If there is not even a snowball's chance in Hell that these things will be ready in the timeframe we're going to do 4.0-RELEASE in, then we should go ahead and not wait for them, and instead integrate them in under 4.1-RELEASE, or whenever they're actually ready. If there is something that kinda, semi, sorta works today, then it should either be a port or you should at least be able to get the source and put it on the system and get it to compile and install yourself, right? How is this any different than if we ship sendmail 8.9.3 as the default MTA today, but if you want to go get and use postfix instead, you're welcome to do so? -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On 07-Jan-00 Jordan K. Hubbard wrote: It's a feature freeze, sorry. I still expect the loose-ends that are in place as of that date to be tied up afterwards. Doesn't this statement make the entire thread about IPv6 + PC-Card support entirely moot? Feature freezes don't mean we can't improve those two areas, right? Right? :-) If so, the entire thread could die right about now and I'd be happy. :) -- Will Andrews [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In some email I received from Randy Bush, sie wrote: 4.0-RELEASE sounds like it will start becoming available at about the same time as other OS's make new releases *with* IPv6/IPSec. You work it out whether or not FreeBSD will win or lose from those two being there or not there. what if the choice is o release at the same time with lots-o-features but not all of v6 o release _considerably later_ with all of v6, well most of it? where's your competitive advanatge in the latter? You don't have to re-release the same year pushing IPv6. Some have suggested 4.1 for IPv6 - bah. That'd be like how RedHat tried to make a big deal out of 6.y (see what I mean ?) vs someone else's new X. Then again, it seems FreeBSD releases are driven by marchitecture rather than architecture. mmm, theregister Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In some email I received from Warner Losh, sie wrote: In message [EMAIL PROTECTED] Josef Karthauser writes: : My 3c589d works just fine now, along with suspend/resume :) (under 4.0). The issue with the 3c589d is with its speed. It is falling back to the timeout routine to send data rather than getting an interrupt when the tx has happened (or something like this, I'm reporting second hand stuff). Whatever it is, results in ping times being 1000ms then 10ms then 1000ms then 10ms...when it responds. i.e. it's a mistake to use FreeBSD 3.x with the 3c589d. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In freebsd-current [EMAIL PROTECTED] wrote: Maybe I am wrong, but it seems to me that there is already quite a bit of IPv6 and IPSec stuff in the tree. Most of the kernel stuff is there (albeit seriously lacking documentation). To me this is not *too* critical right now. I see the point for the research community though. It's not just the research community. RIPE, ARIN and APNIC assign "official" (ie. non 6bone) sTLA space. I've spoken to many people and the demand for IPv6 grows. The only limiting factor is the implementation. Someone already mentioned in this thread that Sun will release SunOS 5.8/Solaris 8 with IPv6 (it's in beta at the moment). I strongly suggest to not release 4.0 till the IPv6 import has been finished. Beside the need for IPv6 it would be wrong to ship a release with a half- complete implementation. my 0.02 (euro cents of course ;-) -tb (2001:0650::/35) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In some email I received from Poul-Henning Kamp, sie wrote: [...] In the meantime please enjoy: NTFS filesytem Netware support Jail facility Tons of new device drivers Netgraph etc, etc Isn't that just that very incomplete list worth a release ? In light of IPv6 missing, at the start of the 21st century, when just about every other major OS is getting ready to include it in their next release ? I'd say no. btw, Apple have announced IPv6 support in MacOS-X. Anyway, I'm now sorry I brought this issue up. Maybe I should have stayed quiet and not gotten people worked up about this and let FreeBSD go ahead and release 4.0 without IPv6. At last then the other BSD's might have been able to grab some market share. Like I said in a post elsewhere, the people driving FreeBSD seem more interested in goals other than those which are significant milestones for FreeBSD and the Internet. Apologies, Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Whatever it is, results in ping times being 1000ms then 10ms then 1000ms then 10ms...when it responds. i.e. it's a mistake to use FreeBSD 3.x with the 3c589d. FWIW, I'm using the 3c589d with 3.2-STABLE + PAO, and it's working just fine. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Yikes! Seems fifi got out of the cage again. How did she figure out the combination for the lock * From: David Greenman [EMAIL PROTECTED] * p.s. pardon the lack of capital letters but my paws can't quite reach * the shift key and the alphabet keys at the same time * *If that is true, then how were you able to push the paren keys? The tail, I guess. It's not easy but it's doable. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Fri, Jan 07, 2000 at 05:48:09AM -0800, Satoshi Asami wrote: Yikes! Seems fifi got out of the cage again. How did she figure out the combination for the lock I'm not sure, but I suspect she factored your private key. Maybe if you didn't keep putting them in the INDEX commit logs... -- Matthew Hunt [EMAIL PROTECTED] * Stay close to the Vorlon. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
... I strongly suggest to not release 4.0 till the IPv6 import has been finished. Beside the need for IPv6 it would be wrong to ship a release with a half- complete implementation. I expect every person that has made similiar statements here and bore all the developers with the additional workload of reading them to download 4.0-current, enable INETV6 and start applying every patch that the KAME group posts to the -committers list and have complete review feedback within 48 hours of such patches being posted. If you, the users, are not ready to do this, STOP asking those to be the folks so described: ``We the willing have been doing so much with so little for so long that we are now qualified to do anything with absolutely nothing at all''. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Rodney W. Grimes wrote: [complaining that people just complain instead of doing the work] If you, the users, are not ready to do this, STOP asking those to be the folks so described: ``We the willing have been doing so much with so little for so long that we are now qualified to do anything with absolutely nothing at all''. Rod, please, I can only speak for myself, but I already run IPv6 on my 3.x machines and my 4.0-current development box is running with INET6 enabled. While probably not everybody who complained is actually doing some work, there are people who do it and complain because they realize how important it is. Thanks -tb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
You know, the people reading this list are *not* the typical FreeBSD users. The fact that releases occur at all is a concession to the realities of the world - WCCDROM needs to pay it's bills by selling CDROMs, and their business pressures require new updates on time and to be as stable as possible (to minimize tech support). You have no idea how expensive it was for them to slip the date a month as it already has to include the features that will go into 4.0. Additionally, despite what you think, I'd bet 99+% of the FreeBSD users in the world could give a rats *ss about IPv6. I run many FreeBSD systems and not one of the ISPs I deal with has announced any plans to move to IPv6 yet. I don't see much, if any, market pressure to move yet, and I suspect that v4 will be perfectly adequate to the needs of a vast majority of FreeBSD users for at least the next year, if not longer. If you want v6, run current, don't make the people waiting for 4.0 wait longer. This is much more likely to cause lost users than no v6. -- Dave Cornejo - Dogwood Media, Fremont, California General Magician Registered Be Developer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Doesn't this statement make the entire thread about IPv6 + PC-Card support entirely moot? Feature freezes don't mean we can't improve those two areas, right? Right? :-) PC-card, perhaps, but I think IPv6 still needs "improvement" far less that it needs significant integration. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
I think you'd do far better to stop bitching and simply start helping. The people I've heard yell the very loudest in this discussion are also the people who: a) Have not helped Yoshinobu Inoue to any great extent during his calls for patch testing. b) Have not volunteered to help with the integration, merely retreating into calls that release should happen "when it's finished" and conveniently side-stepping the fact that somebody has to finish it first. In other words, this is a clear-cut case of back-seat driving by people who aren't even willing to climb into the front seat and drive foward the issue they're complaining about, they just want to yell from the relative safety of the back seat. Cut it out! If you, Darren, want to find something useful to do then go maintain your ipfilter code and stop relying on others to do it for you in FreeBSD. I've already made this point in private email and I won't elaborate further on it here. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Personally, I think the timeline laid down - 25(?) days from now until 4.0 release is too aggressive. Given that the announcement (to me) seemed to be rather autocratic and possibly driven by marketting factors ("we need 4.0 out now regardless" ?) than by the general stability and maturity of -current. Well, that's the impression I get from an announcement encouraging people to do heavy testing in the next 10 days. I would encourage Jordan and others to have a rethink about the timeframe for 4.0 and what plans they have for it feature wise. The 4.0 release has been scheduled for Q1 2000 since at least June last year. This has been a generally known fact since then. The feature freeze was announced for Dec 15th (but was largely suspended in order to accomodate new work and reality in general). Unfortunately, the 3.0 release made it very clear that simply sliding the release date indefinitely for "technical" reasons results in the release never happening. The alternative is this - people that for whatever reason haven't noticed that the release has been looming ever closer suddenly realise that it's right over their shoulder and burst out in surprise. To give you some idea, Solaris8 will have been in *beta* for ~9 months when it is released and will support IPv6 (telnet, inetd services, NFS) and IPSec when it is released around March. FreeBSD is no less an OS than Solaris is, when it comes to completeness. I'd love to have Sun's resources, not to mention their mechanisms for motivating their developers. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Thu, 6 Jan 2000, Julian Elischer wrote: I agree with this.. I think that 4.0 is clsoe but it's just not there yet. I think it needs IPV6 to have reached a better milestone, and certainly the stuff that warner is doing (and others) needs to be a little further down the track. I agree. Why rush 4.0-RELEASE out the door if it's "not there yet"? One possibility is to make our 4.0-current something like 3.9-RELEASE, and when everything has been added, release 4.0-RELEASE. 3.9-RELEASE would be a lot like 4.0-REL, only with some missing parts (such as IPV6 you just mentioned). That way, 3.9-REL would bear all the shortcomings of a release ending in 0, and when 4.0-REL comes out, it would be less buggy than most *.0 releases. (It would really be at the level of a *.1 release then.) - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Curious , what is elischer.org ? 8) -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Thu, Jan 06, 2000 at 02:32:47AM -0800, Amancio Hasty wrote: Curious , what is elischer.org ? 8) According to www.elischer.org, this is the temporary home page for the Elischer family's internet enterprises and Family stuff. -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
At 5:25 AM -0500 2000/1/6, Donn Miller wrote: I agree. Why rush 4.0-RELEASE out the door if it's "not there yet"? One possibility is to make our 4.0-current something like 3.9-RELEASE, and when everything has been added, release 4.0-RELEASE. No, I disagree. There's too much in 4.0-CURRENT that has changed from 3.x-STABLE, and there needs to be a major version bump. I'd prefer to release 4.0-CURRENT sooner, and then perhaps follow-up with a 4.1-CURRENT soon thereafter to pick up IPv6 and all the other things that we had hoped to put into 4.0-CURRENT, but just couldn't make it in time. More releases more often are better than indefinitely holding up releases waiting for just that one last thing to be finished. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Thu, 6 Jan 100, Darren Reed wrote: For what it's worth, I think releasing 4.0 *without* IPv6 support is a mistake. Why ? Because in 12 months FreeBSD 5.0 will be released *with* IPv6 support (I'd count IPv6 as being a big enough change to signify a major release number change). If that doesn't happen, then FreeBSD is chasing the wrong goals, IMHO. I agree entirely -- releasing without IPv6 and IPsec would be a great mistake. At least in the research community, I know of a lot of people relying on FreeBSD 4.0 to be the answer to their problem of locating an open source freely licensable next generation networking platform. Both at TIS and on CAIRN, the DARPA test network, the assumption is that we will jump to FreeBSD 4.0 for experimental networking work as soon as it is released--people are sick of patching Kame on top of FreeBSD, and want it integrated so that they can concentrate on their own experiments (i.e., multicast work, new routing protocols, ad hoc networks, queueing techniques, wireless network technologies, extremely high bandwidth, etc). I can tell you right not that announcing that we don't have decent (i.e., largely complete) out of the box support for IPsec and IPv6 would result in serious disillusionment :-). And as out-there as the research stuff may seem, it's not bad to have on our platform. I'd really hate to see CAIRN switch to Linux as it's backbone router platform :-). CAIRN is a primary testbed spot for a number of new networking technologies that presumably will be quite popular in the near future--by having FreeBSD be the platform of choice for CAIRN, we guarantee those technologies will be available for FreeBSD, helping to maintain our technological lead. The big question at December IETF at the FreeBSD dinner was "When will IPv6 and IPsec be in the tree--we need them". And I think there's a difference between holding up the release indefinitely, and saying "we're waiting on IPv6 and IPsec, and will release once it is ready" -- it's not a plethora of features, rather, two very specific features from a stable source base (Kame) that is well tested, and with developers clearly interested in a timely and successful integration. Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
I agree. Why rush 4.0-RELEASE out the door if it's "not there yet"? One possibility is to make our 4.0-current something like 3.9-RELEASE, and when everything has been added, release 4.0-RELEASE. 3.9-RELEASE would be a lot like 4.0-REL, only with some missing parts (such as IPV6 you just mentioned). That way, 3.9-REL would bear all the shortcomings of a release ending in 0, and when 4.0-REL comes out, it would be less buggy than most *.0 releases. (It would really be at the level of a *.1 release then.) I don't think anything is being rushed out the door. _FEATURE_ freeze is January 15th. That means that any new features to be added to 4.0 have to be in the source repository by January 15th... now once a feature is in, I'm sure _AMPLE_ time will be given to get every 4.0 feature working completely before 4.0 becomes -RELEASE. My question is how much time are developers/testers being given between feature freeze (9 days from now) and release to get all code working and stable? FWIW, I'd call IPv6 a feature... releasing half a feature looks pretty rushed. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On 06-Jan-00 Andreas Klemm wrote: On Thu, Jan 06, 2000 at 12:55:06PM +0100, Brad Knowles wrote: More releases more often are better than indefinitely holding up releases waiting for just that one last thing to be finished. Second that. And to follow on that... FreeBSD 4.0 will become the new STABLE. Are you sure about that 3-stable did not start until well after 3.0-RELEASE. I would expect the same thing with 4.0. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In message [EMAIL PROTECTED] Eivind Eklund writes: : I believe putting down RELENG_4 without having a finished IPv6 and : functional laptop support (I'm not sure what state this is in right : now) would be a bad idea. The laptop support is approx that of 3.x. The fe device is no longer supported as a pccard. The sn device has been added. The YE_DATA floppy device isn't supported, but could be if some is motivated to fix it. There may be a few lingering hot plug issues in the old code's migration to newbus. The newcard stuff as I've been calling it won't be stable in time, but might be functional. I'd always counted on Q1 2000 being late march rather than february. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Thu, Jan 06, 2000 at 09:09:22AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Eivind Eklund writes: : I believe putting down RELENG_4 without having a finished IPv6 and : functional laptop support (I'm not sure what state this is in right : now) would be a bad idea. The laptop support is approx that of 3.x. The fe device is no longer supported as a pccard. The sn device has been added. The YE_DATA floppy device isn't supported, but could be if some is motivated to fix it. There may be a few lingering hot plug issues in the old code's migration to newbus. How much benefit would you be getting by having 4.0 ship with newcard instead of what's there now? E.g, by having 4.0-PAO relate to newcard rather than what's in presently? Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In message [EMAIL PROTECTED] Eivind Eklund writes: : On Thu, Jan 06, 2000 at 09:09:22AM -0700, Warner Losh wrote: : The laptop support is approx that of 3.x. The fe device is no longer : supported as a pccard. The sn device has been added. The YE_DATA : floppy device isn't supported, but could be if some is motivated to : fix it. There may be a few lingering hot plug issues in the old : code's migration to newbus. There's also preliminary support for ata flash and ata cdroms that is new, as well as linksys support (although I think the linksys stuff is in 3.x now). I have hardware for fdc and fe changes, but not the time right now. Xircom has preliminary support as well, but that is broken at the moment. : How much benefit would you be getting by having 4.0 ship with newcard : instead of what's there now? E.g, by having 4.0-PAO relate to newcard : rather than what's in presently? I'm not sure that there is a huge advantage to having 4.0 ship with a fully functional newcard. As it stands now, there will likely be a PAO 4.0 release which brings forward much of the PAO3 functionality that hasn't yet been merged. In the 4.1 timeframe I think we'll see a more agressive move to newcard and by 4.2 see the differences between regular FreeBSD and PAO diminish quite a bit. However, that's just a guess. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Thu, Jan 06, 2000 at 09:09:22AM -0700, Warner Losh wrote: : I believe putting down RELENG_4 without having a finished IPv6 and : functional laptop support (I'm not sure what state this is in right : now) would be a bad idea. The laptop support is approx that of 3.x. The fe device is no longer supported as a pccard. `ep' is also broken for what is becoming a very popular Ethernet 10/100Mbit card -- the 3Com 3c574TX (and rebadged versions). `ep' is seriously wounded for some with 3c589d cards as it isn't getting interrupts and only works via the watchdog timer. `xe' is also broken in 4.0-C, awaiting new functions for getting CIS information. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Hi, Maybe I am wrong, but it seems to me that there is already quite a bit of IPv6 and IPSec stuff in the tree. Most of the kernel stuff is there (albeit seriously lacking documentation). To me this is not *too* critical right now. I see the point for the research community though. Also, regarding what makes a *.0 release, I would say stability is the main thing. More complete features will come with the .1 .2 etc. releases. Look at the 3.x history: we just got some major features in the late 3.x (netgraph in 3.4) this does not mean that 3.0 was a bad release. If I can be sure that the IPSec and IPv6 userland stuff and documentation will be in 4.1 for sure, I would advocate for the feature freeze now. There are quite a few things that are good in 4.0 and that I really want to use in my production boxes (the new ata driver for example). To me getting what is already there in a *blessed* form is what is important. Rather than a full, complete IPv6 feature in 4.0, I would rather see that the 4.x-STABLE branch keeps track of the Kame mods in it by default and soon so that when 4.1-RELEASE is around IPv6 is in. Does that make sense ? Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In message [EMAIL PROTECTED] Alex writes: : - Better laptop (PC card) support, possibly Cardbus (Warner Losh) Won't happen by Jan 15th unless someone my boss comes into my office today and tells me to work on nothing else except pccard/cardbus for the next 9 days. The old pccard code will be it. There are a number of bugs in the old pccard support right now: o xe broken and waiting for some minor hacking on sys/pccard files. o ep relying on its timeout routine o ep broken for newer cards o fdc support for ye_data not there o fe not working due to no conversion to newbus o ISDN support for pccard unknown status o aic pccard support from 2.x not present afaik. o sio eject while active may result in hangs. Not sure if this is still true. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Thu, Jan 06, 2000 at 10:24:21AM -0800, Jordan K. Hubbard wrote: There are many people who use freebsd in the real world that have been counti ng on 4.0 including support for ipsec and ipv6, ipsec more importantly. We would be willing to wait an additional couple of months for this functionality, ple Sadly, you've picked a particular bit of technology that we've been waiting more than a year for. If I had any assurance that a couple of months would make a difference for KAME, I might even contemplate that as a strong option, but they don't work to those kinds of schedules. Based on past experience, it could easily be another year before the KAME group is ready with everything you're asking for. Should we wait a year? Clearly not, and we have to make our schedules independently of the long-term project groups or we'll never release anything. - Jordan That is true, and has always been true. Things get done when people are ready to get them done and not before. Rob To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
We are not going to repeat the 3.0 mess. IPV6 and IPSEC are important, but not important enough to delay the already-delayed 4.0 release. 4.1 is not too late for these babies. True... 4.1 is not too late. However a good part of IPv6 and IPSEC are already present and the primary committer has already expressed his opinion on what can and can't be done by 1/15. On the other hand, there are *plenty* of things already in 4.0 that really need to get out there and get a workout by a larger audience. Delaying *them* is a big mistake. *shudder* I really, really dislike the idea of -RELEASE actually being a wide beta so that some code can get a workout. LAbel it beta and more people will use it than currently do anyway. Any reason not to release and ship a 4.0-beta? -CURRENT = development which scares people. Beta means most bugs already ironed out and looking for test by larger audience. -RELEASE should not be a beta, ever. -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
(Note: trimmed to just the -current list.) Matthew Dillon wrote: On the other hand, there are *plenty* of things already in 4.0 that really need to get out there and get a workout by a larger audience. Delaying *them* is a big mistake. On the _other_ other hand (:-), having pccard ep0 broken in 4.0-RELEASE is a mistake, IMHO. At the very _least_, the 589D's should work, and it would be Really Nice if the 574BTs worked, too. Of course, no one should expect full cardbus support until 4.1 or 4.2, given Warner's work situation. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In some email I received from Matthew Dillon, sie wrote: [...] We are not going to repeat the 3.0 mess. IPV6 and IPSEC are important, but not important enough to delay the already-delayed 4.0 release. 4.1 is not too late for these babies. [...] Well, let me put it this way. 4.0-RELEASE sounds like it will start becoming available at about the same time as other OS's make new releases *with* IPv6/IPSec. You work it out whether or not FreeBSD will win or lose from those two being there or not there. For the short term the impact will be nill , zero , nada... Is not like companies get hold of a new technology and instantly start deploying it -- it will take some time ;specially, nowdays after a lot of companies are getting somewhat of a relief from Y2K work or scare With respect to FreeBSD people can always get an upgrade or cvsup . They want more ? Talk to JKH I am sure is willing to strike a sweet deal 8) -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In message [EMAIL PROTECTED], Steve Ames writes: On the other hand, there are *plenty* of things already in 4.0 that really need to get out there and get a workout by a larger audience. Delaying *them* is a big mistake. *shudder* I really, really dislike the idea of -RELEASE actually being a wide beta so that some code can get a workout. Who said anything about -RELEASE being a beta ? Some parts of a release will always be new, but the majority of it is the same code we released as 3.X, 2.X and even 1.X. We need for people to stop thinking of FreeBSD as commercial software which comes in "natural number" style enumerable packets. FreeBSD style is "real number", it is a continuously evolving quantity which every now and then passes a natural number on the way to infinity. We can now spot a milestone called 4.0 and that's very nice, but we are not going to stop, because the road goes on past 4.0. I'm sorry you you can't have ${insert pet feature here} in 4.0 if it is not ready yet. That's too bad, check in later. In the meantime please enjoy: NTFS filesytem Netware support Jail facility Tons of new device drivers Netgraph etc, etc Isn't that just that very incomplete list worth a release ? FreeBSD-4.0 because now the time is right! Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Thu, 6 Jan 2000, Josef Karthauser wrote: On Fri, Jan 07, 2000 at 08:00:46AM +1100, Darren Reed wrote: btw, I completely agree with the need to have good pccard/pcmcia support. For the first time there was a real reason for me to ditch FreeBSD on an Intel platform box (my laptop) and go with NetBSD where my 3c589d works just fine. My 3c589d works just fine now, along with suspend/resume :) (under 4.0). And these are also working perfectly for me as well under -current on a ThinkPad 770. Tom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In message [EMAIL PROTECTED] Frank Mayhar writes: : On the _other_ other hand (:-), having pccard ep0 broken in 4.0-RELEASE is a : mistake, IMHO. At the very _least_, the 589D's should work, and it would be : Really Nice if the 574BTs worked, too. Of course, no one should expect full : cardbus support until 4.1 or 4.2, given Warner's work situation. I think that Matt Dodd will be working on this. We's waiting for hardware that is on order before he can complete fixing this. I strongly suspect that he'll be able to fix it within a few hours of the arrival of the hardware. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
FreeBSD releases. So thats moot. The point im trying to make is regardless of the state IPv6 is in, leaving it out of a major release is a no no IMO. If you believe this is really an issue, then you should be scolding the KAME folks and not the rest of us. They knew when the deadlines were, just like the rest of you. And in fact, if you cared at all about it, rather than waiting until _now_ and whining about it, you could have noticed that they were falling behind and offered to _help_ them with their work in order to make the deadling. Now everyone is perfectly aware of the fact that -core tries to keep releases and FreeBSD in general as stable as possible. Actually, -core don't do this at all. It's the responsibility of the entire developer team to do it, and it's one that many of you seem to enjoy shirking. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Yes, this is a very good point. Jordan, which is it? On Fri, 7 Jan 2000, Peter Jeremy wrote: On 2000-Jan-07 01:43:09 +1100, Steve Ames [EMAIL PROTECTED] wrote: _FEATURE_ freeze is January 15th. Not quite - Jordan specifically stated _CODE_ freeze (see the Subject:). Maybe I misunderstood Jordan's original announcement, but this was also a surprise for me. Jordan originally stated that there'd be a feature freeze from 15th December 1999. I got the impression that this was going to be in effect for several months and would allow any code updates, but prevent the introduction of new features. This would then be followed by a _CODE_ freeze sometime in 2000Q1, leading to 4.0-RELEASE late in 2000Q1. (My understanding of the difference is that during the code freeze, only changes that demonstrably fix known bugs, without deleterious side effects, are allowed). A few weeks ago, I saw comments that it had slipped a month, followed a few days ago by Jordan's announcement of a code freeze. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
It's a feature freeze, sorry. I still expect the loose-ends that are in place as of that date to be tied up afterwards. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
Get IPv6 into the tree. Now. Thank you. Start helping and stop asking. Now. Thank you. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
* From: "Jordan K. Hubbard" [EMAIL PROTECTED] * How do you think things "get included" in the OS? Do you think one * just moves the KAME bits into a directory next to /usr/src, goes away * for 24 hours to let them bits do their thing, and then comes back to * find that nature has done the rest of the work? Sorry, it might work * that way for hamsters but it doesn't work that way for code! Somebody dear mr. hubbard, please do not insult hamsters. it doesn't work that way for hamsters either. we are fully aware of our surroundings and plan our lives accordingly. in fact, satoshi is out picking oranges now so i have full access to his computer. (ooohh nude hamster pics) that said, i don't think you need to push back the release date. sincerely, fifi p.s. pardon the lack of capital letters but my paws can't quite reach the shift key and the alphabet keys at the same time To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
On Thu, Jan 06, 2000 at 04:17:52PM -0800, Jordan K. Hubbard wrote: Get IPv6 into the tree. Now. Thank you. Start helping and stop asking. Now. Thank you. State specifically what is needed. Now. Thank you. Part of the lack of help may be the result of people clueless as to where to start. -- Christian Kuhtz Architecture, BellSouth.net [EMAIL PROTECTED] -wk, [EMAIL PROTECTED] -hm Atlanta, GA "Speaking for myself only." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
On Thu, Jan 06, 2000 at 04:32:21PM -0800, Mike Smith wrote: Get IPv6 into the tree. Now. Thank you. I don't know quite what makes you think that we came down in the last shower of rain, but has it ever occurred to you that we're not _completely_ stupid? Sure it has. I think I'm not assuming that everyone's completely stupid. So, that said, stick your flame thrower where it came from and assume for one second that I'm not completely stupid and follow your own proposed lead. Do you _always_ assume that anyone other than yourself is a complete moron? Where did this and all that other stuff come from? What makes you think that we don't want this code integrated, or that we don't care about it? Have you bothered to actually read those sides of this discussion that have come from the release engineering team? Yes. As a matter of fact, I have. So, where is the email which specifically states the reasons why it will not be integrated? I apparently missed something in this flurry of email. Nobody is trying to insult anyone here. Quit taking things personal. Just because people are lurking doesn't mean they're not paying attention. Cheers, Chris -- Christian Kuhtz Architecture, BellSouth.net [EMAIL PROTECTED] -wk, [EMAIL PROTECTED] -hm Atlanta, GA "Speaking for myself only." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
On Thu, Jan 06, 2000 at 04:17:52PM -0800, Jordan K. Hubbard wrote: Get IPv6 into the tree. Now. Thank you. Start helping and stop asking. Now. Thank you. State specifically what is needed. Now. Thank you. Part of the lack of help may be the result of people clueless as to where to start. First, you need a time machine. Second, you should go back to when the KAME folks started talking about their integration work (that's about eight or ten months now). Third, you should start working with them on the integration process. Fourth, and this is probably more important since the first three are probably beyond your reach right now - start paying attention. If you hadn't been asleep at the wheel, you'd already know all this, and the entire issue would be moot because you'd be helping already. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
Do you _always_ assume that anyone other than yourself is a complete moron? Where did this and all that other stuff come from? You have to ask this? What makes you think that we don't want this code integrated, or that we don't care about it? Have you bothered to actually read those sides of this discussion that have come from the release engineering team? Yes. As a matter of fact, I have. Then I'm puzzled as to which parts you haven't understood. So, where is the email which specifically states the reasons why it will not be integrated? I apparently missed something in this flurry of email. I'm sorry. I thought you'd been keeping up to date. There's a perfectly good mail archive provided by the Project for your use; I suggest that you'd be best served by using it to locate all the mail that you've read and forgotten or otherwise misunderstood. Discussion on the state of the KAME integration has been going on for over a year now, and the work itself for well over six months. I'm not about to do your research for you; I have other work to do in order to avoid being randomly flamed by someone else like yourself. Nobody is trying to insult anyone here. Quit taking things personal. Just because people are lurking doesn't mean they're not paying attention. In your case, you're not lurking and still not paying attention. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
On Thu, Jan 06, 2000 at 07:04:16PM -0500, Christian Kuhtz wrote: [EMAIL PROTECTED] -wk, [EMAIL PROTECTED] -hm ^^^ Damnit! I've asked for some features in GCC, GNU grep, and GNU diff. I want them *NOW* in time for 4.0-RELEASE. So where the fsck are they??? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Thu, Jan 06, 2000 at 04:27:27PM -0800, fifi - the hamster - asami wrote: dear mr. hubbard, please do not insult hamsters. it doesn't work that way for hamsters either. we are fully aware of our surroundings and plan our lives accordingly. in fact, satoshi is out picking oranges now so i have full access to his computer. (ooohh nude hamster pics) http://www.realhamster.com - mark :-) -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
Get IPv6 into the tree. Now. Thank you. I don't know quite what makes you think that we came down in the last shower of rain, but has it ever occurred to you that we're not _completely_ stupid? Do you _always_ assume that anyone other than yourself is a complete moron? What makes you think that we don't want this code integrated, or that we don't care about it? Have you bothered to actually read those sides of this discussion that have come from the release engineering team? Wouldn't it be much more sensible of you to assume that there are good and valid reasons for things being the way they are? Wouldn't it be much more sensible of you to enquire as to what these reasons are, or perhaps to even have paid attention to all the discussions and progress that have gone on over the last few months (or even just stayed up to date in the last week, where the whole matter has been discussed)? Or are you just too lazy? Too lazy to pay attention? Too lazy to actually participate in this process? Too lazy to do anything other than to wait until it's too late to do anything, and then randomly sling blame around? What _do_ you think you achieve with this? How do you think that insulting the people that are actually trying to do the work while you sit on the sidelines is going to help the process? It's been said before, and I'm sure it'll be said again; if you can't or won't offer support or assistance, the very least you can do is avoid being actively destructive. Take a few moments to think about what it is that you and we want to achieve, and how best to get there. And take a hint; insulting us is not how to go about it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
* From: "Jordan K. Hubbard" [EMAIL PROTECTED] * How do you think things "get included" in the OS? Do you think one * just moves the KAME bits into a directory next to /usr/src, goes away * for 24 hours to let them bits do their thing, and then comes back to * find that nature has done the rest of the work? Sorry, it might work * that way for hamsters but it doesn't work that way for code! Somebody dear mr. hubbard, please do not insult hamsters. it doesn't work that way for hamsters either. we are fully aware of our surroundings and plan our lives accordingly. in fact, satoshi is out picking oranges now so i have full access to his computer. (ooohh nude hamster pics) that said, i don't think you need to push back the release date. sincerely, fifi p.s. pardon the lack of capital letters but my paws can't quite reach the shift key and the alphabet keys at the same time If that is true, then how were you able to push the paren keys? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
Get IPv6 into the tree. Now. Thank you. I don't know quite what makes you think that we came down in the last shower of rain, but has it ever occurred to you that we're not _completely_ stupid? Do you _always_ assume that anyone other than yourself is a complete moron? What makes you think that we don't want this code integrated, or that we don't care about it? Have you bothered to actually read those sides of this discussion that have come from the release engineering team? Wouldn't it be much more sensible of you to assume that there are good and valid reasons for things being the way they are? Wouldn't it be much more sensible of you to enquire as to what these reasons are, or perhaps to even have paid attention to all the discussions and progress that have gone on over the last few months (or even just stayed up to date in the last week, where the whole matter has been discussed)? Or are you just too lazy? Too lazy to pay attention? Too lazy to actually participate in this process? Too lazy to do anything other than to wait until it's too late to do anything, and then randomly sling blame around? What _do_ you think you achieve with this? How do you think that insulting the people that are actually trying to do the work while you sit on the sidelines is going to help the process? It's been said before, and I'm sure it'll be said again; if you can't or won't offer support or assistance, the very least you can do is avoid being actively destructive. Take a few moments to think about what it is that you and we want to achieve, and how best to get there. And take a hint; insulting us is not how to go about it. Mike, I think this is just a bit over the top and doesn't belong in our mailing lists. Please stop doing that. It really isn't fair to blame the FreeBSD developer base at large, and users as well for the slowness of the integration. The KAME team has never asked for integration help as far as I can recall and the primary reason for the delay was actually due to their attentions being focused on NetBSD (with the justification that they were about to freeze for a release). This all said, I don't think we are that far away from having a functional IPv6 implementation in FreeBSD. Most (all?) of the stack is there and what is needed now is the completion of support in the various system utilities. I think this part of the merger could be completed in an amount of time that is measured in weeks if the KAME developers can find the time to put into it right now. If not, then this whole discussion is a waste of bandwidth and everyone should just stop gritching over it. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Mike Smith wrote: In some email I received from Steve Ames, sie wrote: *shudder* I really, really dislike the idea of -RELEASE actually being a wide beta so that some code can get a workout. LAbel it beta and more people will use it than currently do anyway. Any reason not to release and ship a 4.0-beta? -CURRENT = development which scares people. Beta means most bugs already ironed out and looking for test by larger audience. -RELEASE should not be a beta, ever. What do you think 3.0-RELEASE was ? This seems to be how FreeBSD works now. It's how FreeBSD's users seem to want it to work, since they have utterly refused to cooperate with any other arrangement. Those of us behind the release-engineering effort have tried everything realistic that's been suggested (and a great many other things); history speaks for itself as to the results. Alpha, Beta, 4.0, are all just semantic labels anyhow. Every product, or at least every producer of software, develops their own terminology for how software is released to "customers." In the FreeBSD world, it has evolved that .0 means "ready to run, but not in production" and .1 or .2 means "now ready for prime time." While this may differ from whatever other system you are used to, it doesn't make it wrong, just different. Release 4.0 won't be a beta, it will just be a .0 release. Thank everyone that unlike most web browsers, we at least do .0 releases. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.0 code freeze scheduled for Jan 15th
And given that we've already slipped from December 15th, I think you can treat this as a pretty hard deadline, to be further slipped only grudgingly and in response to clear and dire need. 10 days, folks! Make 'em count.. :) The code freeze will last for 15 days, during which time the 4.0 snapshot server (current.freebsd.org) will be cranking out its daily snapshots (and, in the last half of the release cycle, ISO images as well). There will be an additional 10 days following 4.0-RELEASE before the final CD images are made, it being our goal to get the bugs worked out of the net release before the CDs are made in the future. This will result in some additional lag to CD customers, but they'll also get a product with the sharp edges filed off in return for the delay and I think it's worth-while since CDs are a lot harder to update than FTP sites. :-) If someone would care to volunteer an Alpha which has good network connectivity and enough "oomph" to create a full release every night, I'd also be happy to drag the Alpha architecture into this process of doing some actual release QA by porting my snapshot building scripts over and starting them up. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
:This is a cryptographically signed message in MIME format. : :--ms7B55930FA2AAFE9EE4D45CA1 :Content-Type: text/plain; charset=us-ascii :Content-Transfer-Encoding: 7bit : : :Stupid question: will the latest PAO stuff be integrated with 4.0? : : :-dpg :--ms7B55930FA2AAFE9EE4D45CA1 :Content-Type: application/x-pkcs7-signature; name="smime.p7s" :Content-Transfer-Encoding: base64 :Content-Disposition: attachment; filename="smime.p7s" :Content-Description: S/MIME Cryptographic Signature : :MIIKLgYJKoZIhvcNAQcCoIIKHzCCChsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC :B7owggSEMIID7aADAgECAhAV4oOYVg1pE0gVFzzXJ4WbMA0GCSqGSIb3DQEBBAUAMIHMMRcw :FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y :... :... lots of junk removed :... What is all ^^^ this junk? Can you post without adding all of this? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message