Compiling 3.4 Problems
When compiling 3.4-RELEASE I find that whilst linking in src/bin/csh, the linker complains about not finding the following symbols: s_strlen s_strcmp vis_str short2str This all takes place during my attempt to do a make buildworld with the 3_4_0_RELEASE sources. Regards eT P.S. please reply to me as I am not subscribed to -current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problems
It seems Peter Jeremy wrote: On 2000-Jan-06 10:38:51 +1100, I wrote: ["dd if=/dev/rad0c of=/dev/null bs=64k" dies with an error] I did some poking around and found that there are two bugs which conspire together to cause this: 1) diskstrategy() does not detect dscheck() returning EOF, instead passing a zero-length request to the underlying driver. 2) The ata-disk driver doesn't check for (and ignore) zero-length requests, instead passing them onto the disk. See kern/15956 for details and patches. Thanks! I'll take a look at it! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
installing over the wire with a tulip card...
Umm- I know I've done this before, but maybe this is something stupid I've forgotten I went home to my shiny new 400Mhz intel with the 40GB IBM drive in hand.. I'd pulled a couple of the 4.0 snapshot floppy sets off off current.freebsd.org... boot the floppies- they see the de0 card I have in the probe messages (which is connected to the DSL modem ...), but only present sl0/ppp0 as network install media. What have I forgotten that makes me a bonehead here? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipfw optimizations
Hi, i am looking at (minor) optimizations of the ipfw code in order to reduce the running time in the common cases. I have a few ideas (mostly along the lines of optimizing for the most commonly-used rules). An obvious candidate is the 'match all' rule (all from any to any), but can people suggest other common usage of rules in ipfw ? cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [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: So, tell me again why we can't read audio CDs in SCSI drives?
In message [EMAIL PROTECTED], Matthe w Jacob writes: Hmm! Better hold the 4.0 Code Freeze until this sorts out! "No" -- 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
Lint still broken in -current (due to cpp).
I tried lint again since David O'Brien committed the new /usr/bin/cpp, but it turns out that lint is hardwried to use /usr/libexec/cpp. I changed it to use /usr/bin/cpp, and it works, but gives some error messages. Is this still on the list of things to fix, or should I get more details and send-pr? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lint still broken in -current (due to cpp).
On Fri, 07 Jan 2000 11:22:17 GMT, David Malone wrote: I tried lint again since David O'Brien committed the new /usr/bin/cpp, but it turns out that lint is hardwried to use /usr/libexec/cpp. I changed it to use /usr/bin/cpp, and it works, but gives some error messages. I submitted a patch on the cvs-all list yesterday. No feedback yet. Ciao, Sheldon. On Mon, 03 Jan 2000 19:48:09 PST, "David E. O'Brien" wrote: Modified files: usr.bin Makefile gnu/usr.bin/cc Makefile gnu/usr.bin/cc/cpp Makefile Removed files: usr.bin/cpp Makefile cpp.notraditional.sh cpp.sh Log: Turn on a new /usr/bin/cpp that is a true binary rather than a shell script wrapper. /usr/bin/cpp knows about all the GCC predefined symbols and has the functionality of the previous EGCS 1.1.2 /usr/libexec/cpp. I think lint(1) might work with this given the following small patch. Ciao, Sheldon. Index: xlint.c === RCS file: /home/ncvs/src/usr.bin/xlint/xlint/xlint.c,v retrieving revision 1.7 diff -u -d -r1.7 xlint.c --- xlint.c 1999/01/25 11:25:24 1.7 +++ xlint.c 2000/01/06 14:03:29 @@ -321,7 +321,6 @@ libsrchpath = xcalloc(1, sizeof (char *)); appcstrg(cppflags, "-lang-c"); - appcstrg(cppflags, "-undef"); appcstrg(cppflags, "-$"); appcstrg(cppflags, "-C"); appcstrg(cppflags, "-Wcomment");
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: HEADS UP! wormcontrol and sys/dvdio.h users
Thus spake Soren Schmidt ([EMAIL PROTECTED]): Could wormcontrol at least stay as the wd* drivers stay? Sure, I dont se why not, but it adds to the confusion... ok. nice. ata* doesn't work for me at the moment, thus I'm using the wd drivers. What is your problem ?? I posted this to the -current ml 3 weeks ago, when I wanted to switch. See the "ata: Mount root failure: 6"-thread. I just don't know, what's wrong. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GDB Problems !
Pascal Hofstee [EMAIL PROTECTED] writes: just noticed this again. And considering 4.0 is coming up soon, I really Compiling this program with -ggdb will give normal results (a list of i = 0, upto i = 9). However when running the program through gdb Every Value you can print is completely Bogus, which makes debugging impossible. For the record, I'm seeing the same problem. DES -- Dag-Erling Smorgrav - [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 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: HEADS UP! wormcontrol and sys/dvdio.h users
It seems Alexander Langer wrote: ata* doesn't work for me at the moment, thus I'm using the wd drivers. What is your problem ?? I posted this to the -current ml 3 weeks ago, when I wanted to switch. See the "ata: Mount root failure: 6"-thread. Hmm, that one, I thought (wrongly) that it got solved. Seems to me to be a bootblock/loader/fstab/MAKEDEV inconsistency somehow. -Søren 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
some problem with atapi-all.c
I tried the ATA_ENABLE_ATAPI_DMA option, it gave: ../../dev/ata/atapi-all.c: In function `atapi_attach': ../../dev/ata/atapi-all.c:150: syntax error before `)' -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some problem with atapi-all.c
It seems Fritz Heinrichmeyer wrote: I tried the ATA_ENABLE_ATAPI_DMA option, it gave: ../../dev/ata/atapi-all.c: In function `atapi_attach': ../../dev/ata/atapi-all.c:150: syntax error before `)' fixed. -Søren 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: So, tell me again why we can't read audio CDs in SCSI drives?
Jordan K. Hubbard [EMAIL PROTECTED] wrote: Any other SCSI CD owners here currently using tosha? I'd be quite interested to know if this is drive-specific. Works for me. 4.0-CURRENT from December 19, Toshiba CD-ROM XM-3601TA 0175, tosha-0.6. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing over the wire with a tulip card...
Why can't the driver enable the card instead. I can not shut the PNP OS settings off on my mobo because of a Compaq "hack". Because of that my Asante 10 does not start up - it does get detected though. Under Linux, it detects that the card has not been enabled by the BIOS and then it does it for me. That would be a really great feature for the FreeBSD driver as well. It would probably be nice with Sound Cards too. Tom Veldhouse [EMAIL PROTECTED] On Fri, 7 Jan 2000, Adam wrote: Is this the pnp-os switch in bios thing? On Fri, 7 Jan 2000, Matthew Jacob wrote: Umm- I know I've done this before, but maybe this is something stupid I've forgotten I went home to my shiny new 400Mhz intel with the 40GB IBM drive in hand.. I'd pulled a couple of the 4.0 snapshot floppy sets off off current.freebsd.org... boot the floppies- they see the de0 card I have in the probe messages (which is connected to the DSL modem ...), but only present sl0/ppp0 as network install media. What have I forgotten that makes me a bonehead here? 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP ** chownchgrp moved again
This is a heads up to let you know that you need to rm -f /sbin/chwon /bin/chgrp after your next `make world'. Additionally you need to install a new /dev/MAKEDEV (mergmaster(8) will assist you in this). A while back I moved the install location for chown and chgrp from /usr/sbin and /usr/bin to /sbin and /bin. This was because of MAKEDEV(8)'s dependence on them, and thus forced /usr to be mounted for correct operation of MAKEDEV(8). Of course that is bad since you could easily be trying to create the device node to even mount /usr. This week, I have added chown-like functionality to mknod(8) and restored chown chgrp back to their previous locations. MAKEDEV has been updated to use the new functionality of mknod(8). However, do to this moving around of chown chgrp's install location, you may easily have stale versions in /sbin and /bin. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems with DGA on XFree86 (broken?)
Hi, Does anybody successfully using any DGA-based programs on recently recompiled Xfree 3.3.5? I have a problem with it and for me it seems broken. For example standart XFree86 test program 'dga' returns following error on my two -current machines (Mach64 and CT 65554 servers recompiled yesterday). Other DGA applications doesn't work too. bash-2.03# /usr/X11R6/bin/dga X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 78 (X_CreateColormap) Serial number of failed request: 12 Current serial number in output stream: 269 bash-2.03# Sincerely, Maxim P.S. Of course I'm running -current rebuilt several days ago. 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: ** HEADS UP ** chownchgrp moved again
This week, I have added chown-like functionality to mknod(8) and restored chown chgrp back to their previous locations. MAKEDEV has been updated to use the new functionality of mknod(8). Thanks for doing this David! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lint still broken in -current (due to cpp).
On Fri, Jan 07, 2000 at 01:29:27PM +0200, Sheldon Hearn wrote: I think lint(1) might work with this given the following small patch. I agree that lint might should continue to use /usr/libexec/cpp rather than switch to /usr/bin/cpp. But not knowing anything about our lint, I can't really say. -- -- 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
... 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: So, tell me again why we can't read audio CDs in SCSI drives?
Around Yesterday, "Kenneth D. Merry" wrote : Many of the opinions I've seen recently are that you jitter correction isn't necessary for most newer CDROM drives. If you want jitter correction, you can port cdd to CAM. cdda2wav does jitter correction - -P sectors --set-overlap sets the initial number of overlap sectors for jit- ter correction Khetan Gajjar. --- [EMAIL PROTECTED] * [EMAIL PROTECTED]* PGP Key, contact UUNET South Africa * FreeBSD enthusiast * details and other http://www.uunet.co.za/ * http://www.freebsd.org/ * information at System Administration * http://link.os.org.za/ * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing over the wire with a tulip card...
This shouldn't be a PNP-OS issue because this is a PCI card- the card is seen during booting- which means it's getting detected. I don't know why 'ifconfig -l' doesn't see it though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
Hi Luigi, i am looking at (minor) optimizations of the ipfw code in order to reduce the running time in the common cases. I have a few ideas (mostly along the lines of optimizing for the most commonly-used rules). An obvious candidate is the 'match all' rule (all from any to any), but can people suggest other common usage of rules in ipfw ? One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). - then eventually you could be doing the same thing by IP protocol number, but it might not be worth it (with regard to the amount of work required). I think that it is a better way to optimize ipfw than optimize the "match all" rule, since in any security conscious this is likely to be a deny rule, and who cares if it takes a little longer to deny a packet ? My goal usually is to accept legitimate packets as early as possible, reject really obvious stuff also fairly early and then handle the less common stuff. At last there is my match all deny rule, but it does not get exercised that often. One advantage of having a compiled ruleset for each interface would speed up quite a bit the processing by not going over rules that are not applicable. I looked once at doing that on the 3.x-STABLE ipfw, and even if it did not seem to be *too* complicated to do, I did not have the time to go further. Any thoughts ? Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing over the wire with a tulip card...
I wouldn't think so. However, the problem disappears when the PNP OS setting is set to OFF on another box - and it reappears when I turn it back on. When Linux boots - it says something to the extent that the card has not been initialized by the BIOS - and then it does it - this is when the driver detects it. Oddly, it does have an IRQ under FreeBSD - it just doesn't work [with PNP OS on]. I used to get this problem [Not PNP OS related though] with "auto" under the interfaces section of /etc/rc.conf. Overriding that with "lo0 de0" has not fixed the problem. I had to get a different card for my box without the option to run PNP OS off, a PNIC II based Linksys card. Tom Veldhouse [EMAIL PROTECTED] On Fri, 7 Jan 2000, Matthew Jacob wrote: This shouldn't be a PNP-OS issue because this is a PCI card- the card is seen during booting- which means it's getting detected. I don't know why 'ifconfig -l' doesn't see it though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing over the wire with a tulip card...
Hmm. Very interesting and subtle. I'll check this out. Gawd, PCs are *s* lame On Fri, 7 Jan 2000, Thomas Veldhouse wrote: I wouldn't think so. However, the problem disappears when the PNP OS setting is set to OFF on another box - and it reappears when I turn it back on. When Linux boots - it says something to the extent that the card has not been initialized by the BIOS - and then it does it - this is when the driver detects it. Oddly, it does have an IRQ under FreeBSD - it just doesn't work [with PNP OS on]. I used to get this problem [Not PNP OS related though] with "auto" under the interfaces section of /etc/rc.conf. Overriding that with "lo0 de0" has not fixed the problem. I had to get a different card for my box without the option to run PNP OS off, a PNIC II based Linksys card. Tom Veldhouse [EMAIL PROTECTED] On Fri, 7 Jan 2000, Matthew Jacob wrote: This shouldn't be a PNP-OS issue because this is a PCI card- the card is seen during booting- which means it's getting detected. I don't know why 'ifconfig -l' doesn't see it though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). one skipto rule is enough to switch between two rulesets depending on direction, so this is not really worthwhile. I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) The problem with current rule format is that you can detect a non-match very early, but in order to have a real match you have to test all the fields (addresses, ports, interfaces, ...) and even if this only means testing flags, it is still some 8-10 tests and 8-10 jumps. cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [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: ipfw optimizations
In message [EMAIL PROTECTED], Luigi Rizzo writes: One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). one skipto rule is enough to switch between two rulesets depending on direction, so this is not really worthwhile. I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) I still think we should split the current "one huge list of rules" into several lists: Two lists per interface: one list of rules for inbound packets one list of rules for outbound packets Two lists for the IP stack: one list of rules for incoming packets one list of rules for outgoing packets One list for forwarding of packets. in theory one could also: Two lists for the UDP stack: one list of rules for incoming packets one list of rules for outgoing packets Two lists for the TCP stack: one list of rules for incoming packets one list of rules for outgoing packets -- 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: ipfw optimizations
I still think we should split the current "one huge list of rules" into several lists: Two lists per interface: one list of rules for inbound packets one list of rules for outbound packets Two lists for the IP stack: one list of rules for incoming packets one list of rules for outgoing packets One list for forwarding of packets. aren't these three classes combined in some H-shaped way ? cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
In message [EMAIL PROTECTED], Luigi Rizzo writes: I still think we should split the current "one huge list of rules" into several lists: Two lists per interface: one list of rules for inbound packets one list of rules for outbound packets Two lists for the IP stack: one list of rules for incoming packets one list of rules for outgoing packets One list for forwarding of packets. aren't these three classes combined in some H-shaped way ? Could be, the forwarding branch could be a good place to hook up natd(8) for instance... -- 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
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: ipfw optimizations
One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). one skipto rule is enough to switch between two rulesets depending on direction, so this is not really worthwhile. I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) It doesn't matter, it has to do the lookup on a per-interface basis. On my firewall box, I have 11 interfaces. Two ethernet, one loopback, 4 slip, and 4 tunnel. I could easily see a speedup from using per-interface lists. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New kernel no longer boots on one of my machines... ata, other problems
Matthew Dillon writes: | Well guys, I tried upgrading one of my older machines today to the | latest 4.0. It was running an older 4.0 kernel (Nov 29 1999). I ran into a similar problem when upgrading my server at home. It is an old 486 with an Intel Saturn chipset. I found the IDE drive via ad0 and failed the mount with error 6 or whatever. I then put the same drive in a machine with a P5 Intel TX chipset. In this setup ad0 was found and it mounted the rootfs with no trouble. Since this is a machine that needs to be up I switched to the wd driver which worked like charm except for re-enabling it. So in my configuration it is not a MAKDEV/fstab stale issue (I rebuild all of that) and it works with a PCI driver but not with the Saturn ISA driver. My successful boot and probe is: wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): IBM-DTTA-351350, multi-block-16 wd0: 12897MB (26414640 sectors), 26205 cyls, 16 heads, 63 S/T, 512 B/S Now I recall in discussions about pcmcia stuff and the various patches flying around that there was a 32/16 bit access mode issue. Also I think while the pcmcia was in 32 bit mode hard disk access stopped working and maybe flash (since my external IDE hard drive work then it didn't then it did again). I think this correlated to when it was switched to 16 bit then it started working again. Anyways more work and lots of testing needs to be done. Even though I like the new ata stuff and use it on all machines (except for one) this is scary since a bunch of 4.0 users could get screwed with older good hardware. Tonight I will try to define ATA_16BIT_ONLY in my kernel and try to boot with ata. This may have to be set in GENERIC for installs to work ... or the ata driver learn how to figure this out automatically on the fly. BTW this almost hosed me. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world failure (libcrypt)
Hi, I'm seeing the following error, and don't see any fixes in the cvs repository yet. I am however, about an hour behind since I get my updates from a standard mirror. My sources are current as of about an hour ago... If this is already fixed, just ignore Thanks, John ln -sf libutil.so.2 /usr/obj/usr/src/i386/usr/lib/libutil.so cd /usr/src/lib; make depend; make all; make install === csu/i386-elf === libcom_err === libcom_err/doc === msun === libmd === libcrypt === ../secure/lib/libcrypt make: don't know how to make crypt-shs.c. Stop *** Error code 2 Stop in /usr/src/lib. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
In message [EMAIL PROTECTED], Luigi Rizzo writes: One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). one skipto rule is enough to switch between two rulesets depending on direction, so this is not really worthwhile. I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) I still think we should split the current "one huge list of rules" into several lists: Two lists per interface: one list of rules for inbound packets one list of rules for outbound packets ... I use to think this was the way to do it too, until I went and figured out how to do the exact same thing using the current setup. What we have now is actually more flexiable than this proposed configuration in that it allows a superset of this, plus you don't have to duplicate rules in multiple sets, ie: ipfw add 1000 deny ip from 10.0.0.0/8 to any ipfw add 1001 deny ip from any to 10.0.0.0/8 covers all interfaces, I don't have to add those and the 6 others to every interface rule set like we do on the Ciscos. The skipto situation may be slightly ineffecient due to the number of comparisons needed, perhaps adding the ability to dispatch more directly rather than a chain of skipto's, though I can't come up with a simple syntax for this off the top of my head. :-( -- 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: ipfw optimizations
Hi, One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). I often do this manually in long rule sets by using things like ipfw add 1000 skipto 1 from any to any via de0 ipfw add 1001 skipto 2 from any to any via de1 ... ipfw add 1 skipto 15000 from any to any in via de0 #process outbound on de0 rules here ipfw add 15000 blah blah # processing inbound on de0 rules here [...] Anotherwords, don't burden the ipfw with code that can easily be done by an intellegent user, and some more examples/documentation... Yep, and there happens to be a rule that you would like to be tested in every case, but you don't want to test it at the begining (before the switch) but sometime in the middle. With your scheme (which is the only reasonable one currently), you have to duplicate that rule for every branch. This is fine, but if now you need to modify the rule somewhat, don't forget to modify it everywhere. This can rapidly become a maintenance nightmare. What I was proposing is that the per-interface switch be done implicitely by ipfw. So if you do: ipfw add allow ip from joe to bob via de0 ipfw add allow ip from arthur to joe in recv de0 ipfw add allow ip from john to any You get the proper rule tree generated: - ed0 RX: allow ip from joe to bob allow ip from arhur to joe allow ip from john to any - ed0 TX: allow ip from joe to bob allow ip from john to any - ed1 (TX or RX) allow ip from john to any By the way, in terms of optimization you will save: - 2 * number of interfaces rules (the skiptos) that have to be tested for most packets - 2 tests for each rule after (you don't need to retest the interface nor the direction, it has been. If you go further in that logic and implement a per protocol switch, you reduce the number of test even more. To answer a previous question about the number of interfaces, I use FreeBSD as a gateway with 2 ethernet interfaces and 3 tunnel interfaces (ipsec) to remote locations. I guess that most cases where you really worry about ipfw is in gateways where a minimum of 2 interfaces seems reasonable. Again, I am not saying that you can not implement a similar behaviour with ipfw as it is now, I am just saying that if you want to optimize it, you want to reduce the number of test you perform for each rule. What I am proposing is one way of doing it (and as a side effect, it makes managing a tree like set of rule easier). Patrick. matched already) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
On Fri, Jan 07, 2000 at 11:37:02AM -0700, Nate Williams wrote: One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). one skipto rule is enough to switch between two rulesets depending on direction, so this is not really worthwhile. I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) It doesn't matter, it has to do the lookup on a per-interface basis. On my firewall box, I have 11 interfaces. Two ethernet, one loopback, 4 slip, and 4 tunnel. I could easily see a speedup from using per-interface lists. I haven't looked at the firewalling-code in the kernel, but couldn't you gain exactly this speedup by issuing this stuff manually? Add a bunch of "skipto" rules at the very beginning of your ruleset and have them branch to rule 5000, 1, 15000 etc. and then setup your per-interface rules beginning at exactly these rules. In fact, isn't that what Linux' "ipchains" are all about? You split up the rules and branch to one of your rulesets at the beginning. I've never seen anything special in this feature, since ipfw does that as well (you just don't have magical names for your rules but numbers instead). bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IPv6 testing...willing to help
I have a DEC Alpha at home running 4.0-current and am willing to help out with the testing. I am not the worlds greatest coder, but am willing to do what I can -- E-Mail: William Woods [EMAIL PROTECTED] Date: 07-Jan-00 Time: 12:09:03 FreeBSD 3.4 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
3c589d problem
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.) -- \\ 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: ipfw optimizations
I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) It doesn't matter, it has to do the lookup on a per-interface basis. On my firewall box, I have 11 interfaces. Two ethernet, one loopback, 4 slip, and 4 tunnel. i meant, if you only have 2-3 interfaces which are used 90% of the times, then you really have 1-2 extra rules to look for. But, in any case, it seems reasonably clear that a 'switch' statement would simplify rule writing in a number of situations, and i agree with Rod that the way ipfw does (having all rules potentially applicable for all cases) is very very flexible and probably more convenient than per-interface lists in many cases. cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem exposed with sym driver
On Fri, 7 Jan 2000, Michael Reifenberger wrote: Hi, after enabling the sym-driver I get drive-lockups after some time of accessing the disks hanging on the sym-driver. It seems that at least on disk hangs up (steady disk light) until a bus-reset "(noperiph:sym0:0:-1:-1): SCSI BUS reset detected" occurs. A difference between ncr and sym-driver is that the sym-driver probes the disks as (excerpt from dmesg_sym.txt): da1 at sym0 bus 0 target 1 lun 0 da1: IBM DDRS-39130D DC1B Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8715MB (1785 512 byte sectors: 255H 63S/T C) whereas the ncr-driver probes as (excerpt from dmesg_ncr.txt): da1 at ncr0 bus 0 target 1 lun 0 da1: IBM DDRS-39130D DC1B Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8715MB (1785 512 byte sectors: 255H 63S/T C) Usually the IBM-FAQ suspects a cabling/termination Problem if one has a Problem at 40MHZ. Any SCSI related FAQ will suggest the same, in my opinion. But some SCSI devices may have larger margin than some others regarding cabling / termination problems and can be able to accomodate tiny problems. Some other devices may just fail in same situations. But I have the 4 disks in a external case from kingston with a proper kable and terminator and furthermore LVD-drives should have a better signal quality. Furthermore I have zero problems at 20MHZ. FYI, I have seen UltraWide SCSI Buses (single-ended) that continued work reasonnably well with a terminator just missing (was intentionnal for testing purpose). As a strangeness, only a single disk (had 4 on the BUS) required to decrease speed at 33 MB/s (16.? MHz wide) for it to work apparently (seems actually) well. As you can see, even a serious BUS problem may, in some situations, allow the SCSI system to work by just lowering speed of some devices on the bus. You can see in neg_before.txt the output of a 'camcontrol neg' which look right, in neg_after.txt the output of the same command after the disk hang up and the bus reseted. neg_ncr.txt contains the output using the ncr-driver. BTW: I have the same problems with the ncr-driver when using the kernel-config parameter: SCSI_NCR_DFLT_SYNC=10 And now the question: Whats going wrong? Probably something related to the SCSI BUS (or devices), but not to software drivers, in my opinion. If it is the HW, how can it be proven? Are it the IBM-disks? Kabel?... Is it the Software? If I want to live with 40MB/s is there a knob to pre-set the speed in the kernel-config or at boot-time? For the sym driver, you just have to configure SCSI devices accordingly in the NVRAM. The sym driver hears from you by reading the NVRAM when it is able to understand its layout and your kernel log messages let me think it was able to read the controller NVRAM. (Ctrl/C at boot-up for the SYMBIOS SDMS BIOS, and then configure your device settings). Any clues? Regards, Gérard. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New kernel no longer boots on one of my machines... ata, other problems
Matthew Dillon wrote: Well guys, I tried upgrading one of my older machines today to the latest 4.0. It was running an older 4.0 kernel (Nov 29 1999). .. HELP! Whats happening!!! :-( :-( :-( At the moment I am stymied. I switched to a GENERIC kernel and got the same results, so it isn't anything weird that I have done in my own kernel config. I was hoping that someone would have an idea. -Matt I also have one of those old Pentiums, with an Intel motherboard and a Mercury chipset. And I have similar problems with CURRENT of a few days ago. When I configure my kernel to use the new ata driver, it hangs when booting. I plan to reproduce this problem this weekend, with a more recent CURRENT. I think the problem is caused by the RZ1000 EIDE controller on this type of motherboard. I suspect that the new ata driver deals with interrupts in ways somewhat different from the old wd driver. According to the Intel documentation, interrupts during data transfers may cause data corruption. This RZ1000 issue has been discussed on this list a few weeks ago, without a real solution. Kind regards, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing over the wire with a tulip card...
On Fri, Jan 07, 2000 at 09:48:22AM -0800, Matthew Jacob wrote: This shouldn't be a PNP-OS issue because this is a PCI card- the card is seen during booting- which means it's getting detected. I don't know why 'ifconfig -l' doesn't see it though. I had an identical problem with de0 and 3.4 installation disks. Setting the PNP-OS to NO in BIOS resolved the issue. -- Nathan Dorfman [EMAIL PROTECTED] The statements and opinions in my Unix Admin @ Frontline Communicationspublic posts are mine, not FCC's. "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
(don't you love all that quoting...) I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) It doesn't matter, it has to do the lookup on a per-interface basis. On my firewall box, I have 11 interfaces. Two ethernet, one loopback, 4 slip, and 4 tunnel. i meant, if you only have 2-3 interfaces which are used 90% of the times, then you really have 1-2 extra rules to look for. But, in any case, it seems reasonably clear that a 'switch' statement would simplify rule writing in a number of situations, and i agree with Rod that the way ipfw does (having all rules potentially applicable for all cases) is very very flexible and probably more convenient than per-interface lists in many cases. Yes I agree, I love ipfw functionality. You were asking for ideas on how to optimize ipfw. What I suggested is that in its INTERNAL representation of the rules, ipfw could split the rules on a per interface/direction basis. This means that you will not look at the rules that are known to not apply to your interface AND direction, hence saving some time. Again I am not asking for modification of the "user interface" of ipfw which is nice and to the point. As you and Rod mention, the ability to have rules applicable to all interfaces in one shot is great. What I was thinking about is when you build the "per-interface" list of rules, use what is provided in the interface part of the rule to determine where it belongs: ipfw add allow ip from joe to bob in recv ed0 = this rule is to be added only in the inbound list for interface ed0 ipfw add allow ip from joe to bob via ed0 = this rule is to be added to both inbound and outbound lists for i/f ed0 ipfw add allow ip from joe to bob = this rule is to be added to the inbound and outbound lists for all i/fs In the future we could also use negative logic to add a rule to all interfaces except the one mentioned... Also as I said earlier, you don't have to do anymore interface checking when it is implemented this way. The fact that you use such or such list is enough. Also to respond to some comments from Rod, this scheme duplicates the rules, but it does so behind the scene, so it does not add more complexity to the way you configure ipfw. Actually it remains completely compatible with the current behaviour of ipfw. Is that SO unreasonable Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Adaptec AAC-364 RAID controller support
I see from the FreeBSD driver database at http://www.posi.net/freebsd/drivers that support for the Adaptec AAC-364 RAID controller (aka Dell PERC 2) has been proposed, but it is stalled waiting on documentation from Adaptec. For what it's worth, you can add us to the list of people who have these cards and would very much like to use them under FreeBSD. Is there someone at Adaptec I could contact to "encourage" them to release the documentation we require? At the very least, it might be worthwhile to let them know there's interest in using their cards with FreeBSD. Once the development is able to proceed, I'd be happy to lend a hand where possible, even if only to test development versions of the driver. We're currently running different arrays with: 1) DPT SmartRAID IV 2) AMI MegaRAID Enterprise 1200 3) Vinum (raid 10) The Adaptec card looks like it might provide a superior solution. What's best way to proceed when trying to get documentation support from vendors? -- Brad Chisholm SAS Institute, Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adaptec AAC-364 RAID controller support
I see from the FreeBSD driver database at http://www.posi.net/freebsd/drivers that support for the Adaptec AAC-364 RAID controller (aka Dell PERC 2) has been proposed, but it is stalled waiting on documentation from Adaptec. For what it's worth, you can add us to the list of people who have these cards and would very much like to use them under FreeBSD. Is there someone at Adaptec I could contact to "encourage" them to release the documentation we require? At the very least, it might be worthwhile to let them know there's interest in using their cards with FreeBSD. I've tried most of the avenues available to me so far; things were looking sort-of OK until they acquired DPT, at which point the entire division had some sort of falling seizure. If you're a sizeable Dell customer, I do believe that there are two people at Dell that have access to the requisite information as well as authorisation to release it. You may consider that avenue of approach as well. We're currently running different arrays with: 1) DPT SmartRAID IV 2) AMI MegaRAID Enterprise 1200 3) Vinum (raid 10) The Adaptec card looks like it might provide a superior solution. The aac-364 is likely to offer similar performance to the AMI MegaRAID Enterprise 1500 and the Mylex eXtremeRAID 1164 controllers, both of which we're currently supporting. I'm hesitant to pursue the Adaptec controller particularly aggressively just now given the availability of documented and functional alternatives (although I'd happy work on a driver should documentation come my way). What's best way to proceed when trying to get documentation support from vendors? I've typically had the best results with a friendly contact inside the organisation; once you have someone that actually knows how the organisation works you have a chance of tracking down the relevant people to get the information you need. -- \\ 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: Adaptec AAC-364 RAID controller support
At 2:29 PM -0800 2000/1/7, Mike Smith wrote: The aac-364 is likely to offer similar performance to the AMI MegaRAID Enterprise 1500 and the Mylex eXtremeRAID 1164 controllers, both of which we're currently supporting. I'd be very interested to see a comparison of these controllers against the DPT SmartRAID V and SmartRAID VI controllers, drivers for which I believe should be available (or available very shortly). -- 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: ipfw optimizations
No, this is completly reasonable now that I understand what it is your proposing. Even the memory footprint is minimal if pointers to the actual rules is all we store in the per interface list, my largest set duplicated over 8 interfaces would only be 3200 rules. Stored as pointers to rules this would be all of 12.8kbytes, certainly not enough to worry about :-). Good I felt like I was stupid for a while here ;-) Come up with some patches and I'll be glad to test and review them for you... I'll get on that as soon as I am done with that paying job I am doing now :(. Which probably means sometime next week. (don't you hate to have these bills to pay ?) Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __sigisempty() undefined if cc -g used.
In an effort to chase down a libc_r bug, I compiled libc_r with CFLAGS=-g
(and later CFLAGS=-g3), but ran into linker problems as a result.
blitz:~ gcc poll.c -pthread
/usr/lib/libc_r.so: undefined reference to `__sigisempty'
Even the simplest of C programs will get this linker error if using the
-pthread option.
So, __sigisempty is an inline function, defined in
/usr/include/sys/signalvar.h:
extern __inline int
__sigisempty(sigset_t *set)
{
int i;
for (i = 0; i _SIG_WORDS; i++) {
if (set-__bits[i])
return (0);
}
return (1);
}
It doesn't make much sense to have an "extern" inline function, gcc probably
was confused by this, change "extern" to "static" and try again.
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: __sigisempty() undefined if cc -g used.
On Fri, Jan 07, 2000 at 07:36:11PM -0500, Luoqi Chen wrote:
In an effort to chase down a libc_r bug, I compiled libc_r with CFLAGS=-g
(and later CFLAGS=-g3), but ran into linker problems as a result.
blitz:~ gcc poll.c -pthread
/usr/lib/libc_r.so: undefined reference to `__sigisempty'
Even the simplest of C programs will get this linker error if using the
-pthread option.
So, __sigisempty is an inline function, defined in
/usr/include/sys/signalvar.h:
extern __inline int
__sigisempty(sigset_t *set)
{
int i;
for (i = 0; i _SIG_WORDS; i++) {
if (set-__bits[i])
return (0);
}
return (1);
}
It doesn't make much sense to have an "extern" inline function, gcc probably
was confused by this, change "extern" to "static" and try again.
Yep, that fixed it. Thanks!
I just committed the change.
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
world broken in dialog
...
install -c -o root -g wheel -m 444 README /usr/share/examples/dialog
install: README: No such file or directory
*** Error code 71
The following patch fixed the problem:
--- gnu/usr.bin/dialog/TESTS/Makefile.orig Fri Jan 7 22:35:43 2000
+++ gnu/usr.bin/dialog/TESTS/Makefile Fri Jan 7 22:36:09 2000
@@ -5,7 +5,7 @@
beforeinstall:
.for file in ${FILES}
- ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 444 ${file} \
+ ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/${file} \
${DESTDIR}/usr/share/examples/dialog
.endfor
--
Vladimir Silyaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 testing...willing to help
These are my results: % ifconfig -a xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80:1::250:daff:fe20:495b prefixlen 64 inet 24.218.93.188 netmask 0xfc00 broadcast 24.218.95.255 ether 00:50:da:20:49:5b media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10bas P full-duplex 10baseT/UTP 100baseTX hw-loopback sl0: flags=c010POINTOPOINT,LINK2,MULTICAST mtu 552 sl1: flags=c010POINTOPOINT,LINK2,MULTICAST mtu 552 ppp0: flags=8010POINTOPOINT,MULTICAST mtu 1500 ppp1: flags=8010POINTOPOINT,MULTICAST mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 fe80:6::1 prefixlen 64 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 gif0: flags=8010POINTOPOINT,MULTICAST mtu 1280 inet6 fe80:7::250:daff:fe20:495b prefixlen 64 gif1: flags=8010POINTOPOINT,MULTICAST mtu 1280 inet6 fe80:8::250:daff:fe20:495b prefixlen 64 gif2: flags=8010POINTOPOINT,MULTICAST mtu 1280 inet6 fe80:9::250:daff:fe20:495b prefixlen 64 gif3: flags=8010POINTOPOINT,MULTICAST mtu 1280 inet6 fe80:a::250:daff:fe20:495b prefixlen 64 faith0: flags=8002BROADCAST,MULTICAST mtu 1500 ds0: flags=8008LOOPBACK,MULTICAST mtu 65532 % netstat -rn -f inet6 Routing tables Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::@xl0/64 link#1UC xl0 fe80::250:daff:fe20:495b@xl0 0:50:da:20:49:5b UHLWlo0 fe80::@lo0/64 fe80::1@lo0 Uc lo0 fe80::@gif0/64fe80::250:daff:fe20:495b@gif0 Uc gif0 fe80::250:daff:fe20:495b@gif0 ::1 UH lo0 fe80::@gif1/64fe80::250:daff:fe20:495b@gif1 Uc gif1 fe80::250:daff:fe20:495b@gif1 ::1 UH lo0 fe80::@gif2/64fe80::250:daff:fe20:495b@gif2 Uc gif2 fe80::250:daff:fe20:495b@gif2 ::1 UH lo0 fe80::@gif3/64fe80::250:daff:fe20:495b@gif3 Uc gif3 fe80::250:daff:fe20:495b@gif3 ::1 UH lo0 ff01::/32 ::1 U lo0 ff02::@xl0/32 link#1UC xl0 ff02::@lo0/32 fe80::1@lo0 UC lo0 ff02::@gif0/32fe80::250:daff:fe20:495b@gif0 UC gif0 ff02::@gif1/32fe80::250:daff:fe20:495b@gif1 UC gif1 ff02::@gif2/32fe80::250:daff:fe20:495b@gif2 UC gif2 ff02::@gif3/32fe80::250:daff:fe20:495b@gif3 UC gif3 % traceroute6 fe80:1::250:daff:fe20:495b traceroute to fe80:1::250:daff:fe20:495b (fe80:1::250:daff:fe20:495b), 30 hops max, 12 byte packets 1 fe80::250:daff:fe20:495b 0.171 ms 0.144 ms 0.091 ms % ping6 fe80:1::250:daff:fe20:495b PING6(56=40+8+8 bytes) fe80::250:daff:fe20:495b -- fe80:1::250:daff:fe20:495b 16 bytes from fe80::250:daff:fe20:495b, icmp_seq=0 hlim=64 time=0.178 ms 16 bytes from fe80::250:daff:fe20:495b, icmp_seq=1 hlim=64 time=0.129 ms 16 bytes from fe80::250:daff:fe20:495b, icmp_seq=2 hlim=64 time=0.138 ms 16 bytes from fe80::250:daff:fe20:495b, icmp_seq=3 hlim=64 time=0.133 ms ^C --- fe80:1::250:daff:fe20:495b ping6 statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.129/0.144/0.178 ms To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __sigisempty() undefined if cc -g used.
On Fri, 7 Jan 2000, Luoqi Chen wrote:
In an effort to chase down a libc_r bug, I compiled libc_r with CFLAGS=-g
(and later CFLAGS=-g3), but ran into linker problems as a result.
blitz:~ gcc poll.c -pthread
/usr/lib/libc_r.so: undefined reference to `__sigisempty'
Even the simplest of C programs will get this linker error if using the
-pthread option.
So, __sigisempty is an inline function, defined in
/usr/include/sys/signalvar.h:
sys/signalvar.h should not be used outside of the kernel. Especially
not kernel inline functions in it. User servicable parts should be
in signal.h.
extern __inline int
^^
Bug. This also breaks compiling the kernel with -O. You apparently
clobbered -O in CFLAGS by setting CFLAGS=-g. -g normally needs to be
added to CC to avoid breaking CFLAGS (CC='cc -g').
__sigisempty(sigset_t *set)
{
int i;
for (i = 0; i _SIG_WORDS; i++) {
if (set-__bits[i])
return (0);
}
return (1);
}
It doesn't make much sense to have an "extern" inline function, gcc probably
was confused by this, change "extern" to "static" and try again.
`extern' makes sense (see gcc.info), and is extensively used in Linux,
but usually it does the same things `static' except it breaks compiling
with -O. It prevents zillions of copies of the function being produced
(non-inline) in certain cases where inlining is not done (e.g., with
-O). A normal non-inline extern version of the function must be
provided to handle these cases. Sloppy use of `extern inline' doesn't
provide the extern function. Forcing use of the extern version may
be useful for profiling and similar instrumentation
(-finstrument-functions?), and for debugging.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
