Re: Question regarding Xaccel
It was given about a year ago and is now out of date. XiG promised to update their web site, but evidently this just hasn't happened yet. - Jordan on Xinside site (www.xig.com) it says... FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD core team. Why was that advice given... -Gena To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question regarding Xaccel
I sent an inquiry to Xinside about FreeBSD 3.x and the desktop X server, and the reply was that 3.x will be supported by year's end in version 5.1. The only issue the reply mentioned was aout vs. elf. The replier also said that I could run the current version under 3.x using compat22. --Archit (My first post to a freebsd mailing list, if I am breaking etiquette, please let me know) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: location of the function(recvfrom,socket...)
On Thu, 19 Aug 1999, jin biao wrote: Could you tell me where is the code of the functions(sendto, recvfrom,socket,bind...) located at FreeBSD source tree. narcissus% pwd /sys narcissus% find . | xargs grep -a ^sendto ./kern/uipc_syscalls.c:sendto(p, uap) narcissus% The others are there too. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question regarding Xaccel
Well, I know of at least someone who is using XiG on 3.2-STABLE. And he says it works without a problem. Nick On Fri, 20 Aug 1999, Jordan K. Hubbard wrote: It was given about a year ago and is now out of date. XiG promised to update their web site, but evidently this just hasn't happened yet. - Jordan on Xinside site (www.xig.com) it says... FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD core team. Why was that advice given... -Gena To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to add a new domain to a domain name server
Hi, My name is estee, i am new in Freebsd. Can anyone help me to solve this problem? I want to add a new domain name in domain name server(freebsd), how i do it? Thanks in advance, please help, this is urgent... Warmest regards, Estee To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to add a new domain to a domain name server
My name is estee, i am new in Freebsd. Can anyone help me to solve this problem? I want to add a new domain name in domain name server(freebsd), how i do it? Thanks in advance, please help, this is urgent... Well no doubt the FreeBSD box is running BIND...so the configuration file for named is either /etc/namedb/named.conf for version 8.x or /etc/namedb/named.boot if you have a 4.x version take a look at the man page for named and the files in /etc/namedb for more info. The book DNS BIND from O'Reilly is very good too. Regards, Cillian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Brian McGovern [EMAIL PROTECTED] wrote: However, when I start running data, I get silo overflows. At which end? What else is the box getting SILO overflows doing? PIO access to disks or network cards is good for disrupting interrupt latencies. PLIP is virtually guaranteed to disrupt anything that cares about interrupt latencies. Anything very fast on the ISA bus is also likely to clag the system (simply because the ISA bus is sooo slow). Actually, the box with the silo overflows is doing 'not much'. Things like sendmail and the other daemons are running (no net connection, tho, so I know nothing is coming in/out), but otherwise, its a login, a copy of PPP, the clock tick interrupts, and the sio interrupts and corresponding network processing. I think it reports an average of 99.9% idle (the occational "blip" on the stats). Mike Smith [EMAIL PROTECTED] wrote: interrupt response time on your system is sufficiently poor that the time between the interrupt trigger at either 8 or 14 (I forget) characters in the FIFO This can be configured in the UART. The driver switches between two FIFO levels depending on speed (look at the FIFO_RX_... macros), but I'm not sure of the absolute levels. You could try reducing the trigger level (this should make the SILO overflows go away, but at the cost of more interrupts). In order to debug this, you will need to use a logic analyser to trap the case where the interrupt is not handled quickly enough, A slightly less invasive method, that will probably give you some clues, is to instrument the hard interrupt entry points (defined via INTR() in i386/isa/icu_vector.s or i386/isa/apic_vector.s), as well as the siointr() function. Some background: FreeBSD (should) only disable interrupts for very short periods. Due to the (lack of) speed accessing the ICUs, the SPL levels are held in software rather than in the ICU. This means that an interrupt arrives in the kernel fairly quickly after it's raised in hardware. The kernel checks the SPL mask to determine whether the interrupt can be treated immediately. If not, it sets a flag and calls the interrupt handler when the SPL level is dropped. You could add code to check the time (eg by reading the TSC) and SPL mask on interrupt and then check the time when siointr in invoked. If the time is excessive, the SPL mask will give you some idea of what was in progress. Peter My short term "punt" is to use a desktop system. If I keep seeing the problem there, I'll debug it some more. If it "goes away", I'll know it was the laptop being quirky. -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Change to /sys/net/if.c /sys/dev/syscons/syscons.c
Hi, change to /sys/net/if.c which will print out "xxN: promiscuous mode disabled" msg to match its equiv. "xxN: promiscuous mode enabled" msg works on all my interfaces even if tcpdump is run multiple times etc. However it does not print out the disabled msg for tun0 interface for some mysterious reason.. (another interesting thing was if tun0 == kld and I try a tcpdump, tpcdump doesn't recognise tun0 at all !) patch against 3.2-STABLE (synced few minutes ago) *** if.cFri Aug 20 14:42:44 1999 --- if.c.bakFri Aug 20 14:50:42 1999 *** *** 790,797 if (--ifp-if_pcount 0) return (0); ifp-if_flags = ~IFF_PROMISC; + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", + ifp-if_name, ifp-if_unit); } ifr.ifr_flags = ifp-if_flags; error = (*ifp-if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)ifr); --- 790,795 Beware, next suggestion is pure vapourware :P I hacked the /sys/dev/syscons/syscons.c file to display kernel messages in a different colour (bright green if you want to know), I think it would be cool if we could change this either via OPTIONS KERNMSGCOLOR=FOO in kernel conf file or via sysctl perhaps.. ..as I warned you, ultimate in vapour ware :P - Cillian as a sidenote: Anyone else out there wonder why Linux console is so crap? ie: can only scroll up on *current* console, boot messages from kernel are messy and full of ad banners, kernel messages are in boring plain-text colour.. Enough hot air from me for today.. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
On Fri, 20 Aug 1999 15:09:59 +0100, Cillian Sharkey wrote: + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", + ifp-if_name, ifp-if_unit); You're the second person other than me to request this. :-) So are there any _objections_ to having the kernel match promiscuous "enabled" messages with "disabled" counterparts? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
+ log(LOG_INFO, "%s%d: promiscuous mode disabled\n", + ifp-if_name, ifp-if_unit); You're the second person other than me to request this. :-) Yes, i've seen it suggested before alright.. So are there any _objections_ to having the kernel match promiscuous "enabled" messages with "disabled" counterparts? I don't have any objections, so developers speak up and have your say !! apart from the tun0 problem that I described in previous messages the suggested change seems to work perfectly.. - Cillian PS: any thoughts on the other vapourware idea :P ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
On Fri, Aug 20, 1999 at 03:29:45PM +0200, Sheldon Hearn wrote: On Fri, 20 Aug 1999 15:09:59 +0100, Cillian Sharkey wrote: + log(LOG_INFO, "%s%d: promiscuous mode disabled\n", + ifp-if_name, ifp-if_unit); You're the second person other than me to request this. :-) The third, in fact! So are there any _objections_ to having the kernel match promiscuous "enabled" messages with "disabled" counterparts? I think, the "disabled" messages output should be put under `if (verbose)'. -- 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-hackers" in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
I think, the "disabled" messages output should be put under `if (verbose)'. Maybe..there was a lot of talk on another mailing list (-current I think?) about boot messages, level of verbosity etc. etc. so perhaps we should wait until this has been decided.. ? - Cillian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
On Fri, 20 Aug 1999 15:55:45 +0100, Cillian Sharkey wrote: Maybe..there was a lot of talk on another mailing list (-current I think?) about boot messages, level of verbosity etc. etc. so perhaps we should wait until this has been decided.. ? This has nothing to do with the boot messages, though, surely? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
On TCP sequence numbers
A topic that Mark and I have been discussing a little, is the algorithms that FreeBSD uses for generating initial TCP sequence numbers - that being with reference to the predictability of these numbers. (Work on this has been somewhere in Mark's todo list for a while.) This topic raises a few questions: How good, or how bad are the initial sequence numbers that FreeBSD uses? (It seems that we could improve them a little.) How unpredictable do we need to make the sequence numbers? Some testing with nmap shows that Linux is generating sequence numbers that are far more unpredictable than ours are. (Linux is, however, also using a 1MHz clock, as opposed to the 250kHz clock as outlined in the RFC.) We are only using a PRNG, as opposed to the entropy pool supplied by devrandom to generate sequence numbers (warning here - devrandom is only supported in the i386 port of FreeBSD). My testing indicates that we can improve the entropy input into our sequence numbers by using devrandom. However, this is VERY dependent on the entropy sources that you feed into the pool via rndcontrol(8). Another question that comes in to this is - how good a tool is nmap for evaluating the predictability of the sequence numbers we generate? Ideally, I would like to do some improvements to our sequence number generation. Thoughts? Geoff. -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: [EMAIL PROTECTED] URL: http://www.is.co.za To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: On TCP sequence numbers
Another question that comes in to this is - how good a tool is nmap for evaluating the predictability of the sequence numbers we generate? Ideally, I would like to do some improvements to our sequence number generation. Thoughts? What is OpenBSD like in this regard ? AFAIR it has various algorithms for randomizing sequence numbers I think.. [Correct me if I'm wrong !] - Cillian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question regarding Xaccel
It is just as well that I did not know that - I am running it on 3.2, and have run it on all the 3.0-series. A word to the wise, if you want to run it on 3.2 install from the 3.1 CD and then upgrade by source. When I installed straight from the 3.2 cd it did not work because I needed to install compat22, and then when I did install compat22 Xsetup kept on crashing on a floating point exception. I did not have the time or inclination to find out if it was a bug in compat22. -Kip On Fri, 20 Aug 1999, Nick Hibma wrote: Well, I know of at least someone who is using XiG on 3.2-STABLE. And he says it works without a problem. Nick On Fri, 20 Aug 1999, Jordan K. Hubbard wrote: It was given about a year ago and is now out of date. XiG promised to update their web site, but evidently this just hasn't happened yet. - Jordan on Xinside site (www.xig.com) it says... FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD core team. Why was that advice given... -Gena To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to add a new domain to a domain name server
As Estee Goh wrote ... Hi, My name is estee, i am new in Freebsd. Can anyone help me to solve this problem? I want to add a new domain name in domain name server(freebsd), how i do it? Thanks in advance, please help, this is urgent... Suggest you buy the book "DNS BIND" by Albitz Liu. Published by O'Reilly. This explains not only your question but the background of DNS as well. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Async NFS exports?
I asked this on stable but didn't get a response... Would I get any performance increases by mounting NFS exported partition as Async? Would my soul be tormented in purgatory for doing it? Just to be clear... I am wondering if mounting (on the NFS _server_) a partition (that is exportable) as async will have any performance benefits to the NFS clients? -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question regarding Xaccel
I sent an inquiry to Xinside about FreeBSD 3.x and the desktop X server, and the reply was that 3.x will be supported by year's end in version 5.1. The only issue the reply mentioned was aout vs. elf. The replier also said that I could run the current version under 3.x using compat22. I am one of satisfied Xaccel DS 5.0.2 users running under -current. Voodoo3 works great! Tammy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
setting up -STABLE for hack contest
Hi As the subject says i'm waiting for suggestions how to make a stable box very secure :) I would like to know how to change login screen and make it difficult to guess what operating system is running, etc. TIA _ Lauri To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare: porting kernel modules to FreeBSD
It seems Gary Jennejohn wrote: Mark Huizer writes: Hi there, I had a look recently at the code for one of the kernel modules that VMWare requires (driver-only.tar), and it looks like something that should be portable to FreeBSD, although there is some messy stuff in it (assembly that seems to be using Linux specific stuff, brrr..) But anyway: it looks feasable. Is anyone already working on this, or are some people interested in helping with this? As far as I can see, the linux emulation is good enough to run the vmware program, "all" you need to do is implement /dev/vmmon and /dev/vmnet, given the fact that the code is written really unportable, so there is some rewriting to be done. Then with the KLD's vmmon,vmnet and linux you should be able to run vmware. Soren mentioned that he might look into it a few weeks ago, but that's the last thing I remember seeing. Yup, I have the files here, and have given it a quick look, doesn't look to difficult to do, but I havn't had time yet to get into the matter.. It will probably be awhile before I do have the time though, but if nobody else does it I'll get to it sooner or later... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setting up -STABLE for hack contest
On Fri, 20 Aug 1999, Lauri Laupmaa wrote: I would like to know how to change login screen and make it difficult to guess what operating system is running, etc. Change the "default" entry in /etc/gettytab. On a 3.2-STABLEsustem (from the 19990812 snapshot), the default line looks like: default:\ :cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200: You can change it to something like this for fun: default:\ :cb:ce:ck:lc:fd#1000:im=\r\nOpenVMS\r\n\r\n:sp#1200: It is also trivial to hack login(1) to say "Username:" to instead of "login:". As you might have guessed, I did this to a FreeBSD 3.0 system about nine months ago. Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody cobbled together a getpwent() that uses libradius?
On Fri, 20 Aug 1999, Jaye Mathisen wrote: While whatever happens with PAM and LDAP, and all those great things, I would like to validate passwords via Radius... It would be most convenient if it was just in getpwent()... This is the wrong place to put it - see the pam_radius module. Bloating libc with promiscuous knowledge of authentication services helps no-one. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Serial cable
Hi, Rich: Can you find a serial cable for me? I need to connect two PCs together via RS232 ports. Thanks. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody cobbled together a getpwent() that uses libradius?
I completely missed that radius was working with pam. A check of radius related stuff in the man pages didn't show anything related to PAM, and the pam.conf page doesn't show anything related to radius. Should've checked the libs though. Thanks. On Fri, 20 Aug 1999, Kris Kennaway wrote: On Fri, 20 Aug 1999, Jaye Mathisen wrote: While whatever happens with PAM and LDAP, and all those great things, I would like to validate passwords via Radius... It would be most convenient if it was just in getpwent()... This is the wrong place to put it - see the pam_radius module. Bloating libc with promiscuous knowledge of authentication services helps no-one. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody cobbled together a getpwent() that uses libradius?
On Fri, 20 Aug 1999, Jaye Mathisen wrote: While whatever happens with PAM and LDAP, and all those great things, I would like to validate passwords via Radius... It would be most convenient if it was just in getpwent()... I beg to differ. It's extremely easy to use pam_radius module. No changes in sources - just edit /etc/pam.conf. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody cobbled together a getpwent() that uses libradius?
On Fri, 20 Aug 1999, Jaye Mathisen wrote: I completely missed that radius was working with pam. A check of radius related stuff in the man pages didn't show anything related to PAM, and ...they are on their way - check RELENG_3, i.e. STABLE. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
[ Caveat: I'm making this up as I go along ] On Fri, Aug 20, 1999 at 01:13:06PM -0500, a little birdie told me that Steve Ames remarked I asked this on stable but didn't get a response... Would I get any performance increases by mounting NFS exported partition as Async? Would my soul be tormented in purgatory for doing it? Just to be clear... I am wondering if mounting (on the NFS _server_) a partition (that is exportable) as async will have any performance benefits to the NFS clients? As a first guess, probably not unless you have a large number of active clients. Any modern hard disc will outperform ethernet/fast ethernet, especially for larger read/writes. For large numbers of smaller operations, or when there is a large number of simultaneous outstanding requests from clients, maybe. I'd say watch the disc itself (iostat is your friend), and if it's pegged (especially large numbers of tps) async might buy you some increase. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
:I asked this on stable but didn't get a response... Would I get any :performance increases by mounting NFS exported partition as Async? : :Would my soul be tormented in purgatory for doing it? : :Just to be clear... I am wondering if mounting (on the NFS _server_) a :partition (that is exportable) as async will have any performance :benefits to the NFS clients? : :-Steve w/NFSv3 I doubt mounting the exported partitions async will increase performance much. I would not use an async mount - if this is an NFS server it needs to be as reliable as possible and async mounting the partition is going to hurt if the machine crashes. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
help! - strange vn behaviour
I'll cc: hackers and see if this rings a bell for anyone :| .. Andrew Btw, can you explain why this happens? $ partitionsize=256 $ sects=`/bin/expr $partitionsize '*' 64 '-' 1` $ vnconfig -e -s labels -S $partitionsize"m" /dev/vn0 $ disklabel -w -r vn0 auto disklabel: /dev/rvn0c: Device not configured $ disklabel vn0 disklabel: ioctl DIOCGDINFO: Inappropriate ioctl for device $ disklabel /dev/vn0 # /dev/vn0: type: unknown disk: amnesiac label: fictitious flags: bytes/sector: 4096 sectors/track: 32 tracks/cylinder: 8 sectors/cylinder: 256 cylinders: 256 sectors/unit: 65536 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c:655360unused0 0 # (Cyl. 0-255) - Now, if I do a - $ vnconfig -u /dev/vn0c echo "woohoo!" vnconfig: VNIOCDETACH: Device not configured $ vnconfig -u /dev/vn0 echo "woohoo!" woohoo! ... The vn device _is_ configured but not useable via /dev/vn0[abc..z] ?? Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Serial cable
On Fri, Aug 20, 1999 at 03:12:48PM -0400, Zhihui Zhang wrote: Hi, Rich: Can you find a serial cable for me? I need to connect two PCs together via RS232 ports. Aha! Remote Kernel Debugging aren't we? Probably you did not intend this mail to go to the mailing list :) Regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
:I asked this on stable but didn't get a response... Would I get any :performance increases by mounting NFS exported partition as Async? : :Would my soul be tormented in purgatory for doing it? : :Just to be clear... I am wondering if mounting (on the NFS _server_) a :partition (that is exportable) as async will have any performance :benefits to the NFS clients? : :-Steve Ok, I've run some more tests. Basically you want to run NFSv3 under CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network this will give you unsaturated write performance in the ballpark of 9 MBytes/sec. Saturated write performance, that is where you write more then the client-side buffer cache can handle, will stabilize at 2.5 MBytes/sec. I have a patch for CURRENT which will increase the saturated write performance to 4.5 MBytes/sec (basically by moving the nfs_commit() from nfs_writebp() to nfs_doio() so it can be asynchronized). Hopefully that patch will go in soon but there's a pretty big backlog of patches that haven't gone in yet, some over a week and a half old, so... In anycase, even without the patch if you run a couple of nfsiod's and do not saturated the buffer cache you should get optimal performance. Backing-porting the patch for nfs_commit to STABLE is possible but is not likely to help much because the major performance restriction in STABLE is related to buffer cache management, not NFS. OS #nfsiod's unsaturated saturated write perf. write perf. ( . 100BASETX .. ) CURRENT 0 9 MBytes/sec2.5 MBytes/sec CURRENT 4 9 MBytes/sec4.5 MBytes/sec(w/patch) STABLE 0 3 MBytes/sec3 MBytes/sec(1) STABLE 4 4 MBytes/sec3 MBytes/sec(1) note(1): saturated performance under STABLE is extremely inconsistant -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
Emm, I guess that answers my earlier question/mail: Why?--- basil# uname -a FreeBSD basil.dympna.com 3.2-RELEASE FreeBSD 3.2-RELEASE #7: Thu Aug 19 23:59:50 CDT 1999 [EMAIL PROTECTED]:/export/current/src/sys/compile/Basil-SMP [Dual PPro-233's] basil# cd /stripe basil# df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/vinum/stripe 1719751186511 15735200 1%/stripe basil# Bonnie -s 256 ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 10817 97.3 15805 93.1 6338 41.4 9943 97.5 15796 51.2 basil# mount_nfs -3 localhost:/stripe /mnt basil# cd /mnt basil# Bonnie -s 256 ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 4270 57.6 6639 30.6 1877 11.7 3804 55.3 6201 18.7 Matthew Dillon wrote: :I asked this on stable but didn't get a response... Would I get any :performance increases by mounting NFS exported partition as Async? : :Would my soul be tormented in purgatory for doing it? : :Just to be clear... I am wondering if mounting (on the NFS _server_) a :partition (that is exportable) as async will have any performance :benefits to the NFS clients? : :-Steve Ok, I've run some more tests. Basically you want to run NFSv3 under CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network this will give you unsaturated write performance in the ballpark of 9 MBytes/sec. Saturated write performance, that is where you write more then the client-side buffer cache can handle, will stabilize at 2.5 MBytes/sec. I have a patch for CURRENT which will increase the saturated write performance to 4.5 MBytes/sec (basically by moving the nfs_commit() from nfs_writebp() to nfs_doio() so it can be asynchronized). Hopefully that patch will go in soon but there's a pretty big backlog of patches that haven't gone in yet, some over a week and a half old, so... In anycase, even without the patch if you run a couple of nfsiod's and do not saturated the buffer cache you should get optimal performance. Backing-porting the patch for nfs_commit to STABLE is possible but is not likely to help much because the major performance restriction in STABLE is related to buffer cache management, not NFS. OS #nfsiod's unsaturated saturated write perf. write perf. ( . 100BASETX .. ) CURRENT 0 9 MBytes/sec2.5 MBytes/sec CURRENT 4 9 MBytes/sec4.5 MBytes/sec(w/patch) STABLE 0 3 MBytes/sec3 MBytes/sec(1) STABLE 4 4 MBytes/sec3 MBytes/sec(1) note(1): saturated performance under STABLE is extremely inconsistant -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anybody love qsort.c?
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
:Emm, I guess that answers my earlier question/mail: : :Why?--- : :/dev/vinum/stripe 1719751186511 15735200 1%/stripe :basil# Bonnie -s 256 : ---Sequential Output ---Sequential Input-- : -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- :MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU : 256 10817 97.3 15805 93.1 6338 41.4 9943 97.5 15796 51.2 : : :basil# mount_nfs -3 localhost:/stripe /mnt :basil# cd /mnt :basil# Bonnie -s 256 : : ---Sequential Output ---Sequential Input-- : -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- :MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU : 256 4270 57.6 6639 30.6 1877 11.7 3804 55.3 6201 18.7 Buffer copy and protocol overhead, plus the data is being cached twice: once on the server and once on the client (which happens to be the same machine). The machine becomes cpu-bound with all the extra work. This is what I get. Ignore the read numbers (the machine has a lot of memory). This is with nfsd -n 4 and nfsiod -n 4, NFSv3 UDP mount, on a duel P-III/450 running CURRENT. /dev/da0h 2338236 1235921 91525757%/usr/obj ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 9979 51.4 9154 19.0 9814 22.5 19727 99.8 103863 100.0 2163.4 43.2 localhost:/usr/obj/ 2338236 1235921 91525757%/mnt ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 3532 30.9 4164 7.6 4364 14.9 13700 99.9 75964 99.7 2779.7 162.1 As you can see, I get very similar numbers for writing. 9 MB/sec on the local filesystem and 4.3 MB/sec via a localhost: NFS mount. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pthread_set_concurrency()
Hello there, so it seems that pthread_set_concurrency() has not been implemented at least up to 3.2-stable. How could one ensure that their threads in an application can be "equally" distributed to all the processors in FreeBSD? Are there any documents on FreeBSD 3.*'s thread support(both kernel and user level)? The pthread man pages are quiet incompelete and some pthread calls have not been implemented. Thanks, Ming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
: The reason is due to the way NFSv3 issues writes. NFSv3 issues a : write but no longer assumes that the write has been synced to the : server's disk as of when the reply comes back. Instead it keeps the :.. : :If you are looking for more optimizations, you can delay NFS write :operations for some interval X, on all write buffers, entirely. : :Sun does this (it is technically called "write gathering" in the :literature). The client-side pushes a buffer out the moment it fills up. Since this corresponds to a maximally-sized NFS data packet the client will not be more efficient by delaying it. The server-side in the FreeBSD implementation *DOES* do write-clustering, as I demonstrate below. The server does a better job of write-clustering when the client is a FreeBSD-CURRENT box, though, because FreeBSD-CURRENT clients generate a more uniform data flow. The server is able to do write-clustering w/ NFSv3 mounts because data writes are not required to be synched to disk until the client requests a commit. Note that KB/t fields below. CURRENT server, CURRENT client. iostat on server while client writes apollo:/usr/src/sys/nfs# iostat da0 1 tty da0 cpu tin tout KB/t tps MB/s us ni sy in id 0 20 0.00 0 0.00 1 0 1 0 98 0 43 0.00 0 0.00 0 0 1 0 99 0 43 1.00 1 0.00 0 0 0 0100 0 42 6.86 7 0.05 0 0 10 0 90 0 43 61.80 68 4.12 1 0 25 21 53 0 43 64.00 72 4.52 0 0 18 28 54 0 43 64.00 73 4.58 0 0 21 25 54 0 42 62.29 74 4.51 0 0 24 32 45 0 43 63.23 72 4.46 0 0 22 23 54 0 43 64.00 32 1.98 0 0 9 9 82 CURRENT server, STABLE client. iostat on server while client writes apollo:/usr/src/sys/nfs# iostat da0 1 tty da0 cpu tin tout KB/t tps MB/s us ni sy in id 0 20 0.00 0 0.00 1 0 1 0 98 0 43 43.43 98 4.15 0 0 15 21 64 0 42 17.48 107 1.82 0 0 9 7 84 0 43 62.49 73 4.47 0 0 19 33 48 0 43 19.93 121 2.35 0 0 8 9 84 0 43 43.07 85 3.58 0 0 17 22 61 0 42 46.77 90 4.11 0 0 21 22 57 0 43 15.63 108 1.65 0 0 8 7 85 0 43 64.00 70 4.39 2 0 17 27 54 However, even a FreeBSD-CURRENT breaks down when its buffer cache saturates. The example below demonstrates this: CURRENT server, CURRENT client, iostat of server disks while client writes (client buffer cache not saturated) 0 43 0.00 0 0.00 0 0 0 0100 0 43 56.00 26 1.41 0 0 14 5 81 0 42 64.00 72 4.52 0 0 21 26 53 0 43 64.00 73 4.58 0 0 25 19 57 11 54 64.00 71 4.46 2 0 17 28 53 0 42 62.27 73 4.45 0 0 26 22 52 5 48 64.00 72 4.52 0 0 22 24 53 5 48 52.72 82 4.23 0 0 20 26 53 (client buffer cache saturates) 11 54 18.76 163 2.99 2 0 12 16 71 1 43 19.20 129 2.41 1 0 13 11 75 7 70 20.65 146 2.95 2 0 14 16 67 4 47 17.53 130 2.22 0 0 9 15 77 6 51 24.63 113 2.72 1 0 10 13 76 4 73 15.17 153 2.27 0 0 11 7 82 The problem that occurs on the FreeBSD server is simply that the nfsrv_commit() procedure calls fsync() on the file... on the *ENTIRE* file, for every commit rpc, rather then syncing just the offset/range requested. I am looking into ways to fix this. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I2C/SMBus/LPBB
I had sent this message to -stable about a month ago, never heard anything -- so am trying it here. -- Forwarded message -- Date: Wed, 21 Jul 1999 03:24:38 -0400 (EDT) From: Mike Nowlin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: I2C/SMBus/LPBB OK -- I give up I'm trying to get the LPBB I2C driver working on my 3.2-stable machine, CVSUP'd earlier today... I have tried about a zillion and two different config file combinations, and can not get it to work. The relevant parts of the config file are: device ppc0at isa? port? tty irq 7 controller pcf0at isa? port? irq 5 controller iicbb0 controller smbus0 device smb0at smbus? controller ppbus0 #device lpt0at ppbus? #device ppi0at ppbus? device lpbb0 at ppbus? controller iicbus0 device iic0at iicbus? device iicsmb0 at iicbus? (.As you can see, I took out the printer driver and the geek port during this hair-pulling session -- those two devices vanish, but nothing else appears.) The dmesg chunks that show up about this are: ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ... pcf0 at irq 5 on isa ... pcf0: PCF8584 I2C bus controller iicbus0: Philips I2C bus on pcf0 addr 0xaa iicsmb0: I2C to SMB bridge on iicbus0 smbus0: System Management Bus on iicsmb0 smb0: SMBus general purpose I/O on smbus0 iic0: I2C general purpose I/O on iicbus0 It seems to see the PCF8584 just fine, but it refuses to put the parallel port I2C interface in... If I remove the "controller pcf0" line, all of the I2C drivers disappear. Any ideas? --Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device_add_child??
In message [EMAIL PROTECTED] "David E. Cross" writes: : I have been writing a nasty kludge to treat a CardBus bridge as a standard : PCI bridge (with static config) you may start throwing rocks now. Ewe. Yuck. Wouldn't it be better to help the pccard/cardbus efforts :-) : I have : it to the point where I can (after the system is booted) 'pciconf -r : pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would : then just be a simple matter of 'device_add_child(dev, "pci", 5, 0);' to get : the bus to show up at PCI5: at bootup, but it seems to ignore it. following : from pcisupport.c I also tried to 'bus_generic_attach()' it after : device_add_child() finished. no go. Any suggestions? device_add_child just adds it to the tree. It doesn't probe or attach it. If you kludge adding it into the tree, you'll have to kludge attaching it. You might want to look at my pccard kludge-o-matic for examples. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare: porting kernel modules to FreeBSD
I'd like help too. /Jakob Alvermark On Thu, 19 Aug 1999, Gary Jennejohn wrote: Mark Huizer writes: Hi there, I had a look recently at the code for one of the kernel modules that VMWare requires (driver-only.tar), and it looks like something that should be portable to FreeBSD, although there is some messy stuff in it (assembly that seems to be using Linux specific stuff, brrr..) But anyway: it looks feasable. Is anyone already working on this, or are some people interested in helping with this? As far as I can see, the linux emulation is good enough to run the vmware program, all you need to do is implement /dev/vmmon and /dev/vmnet, given the fact that the code is written really unportable, so there is some rewriting to be done. Then with the KLD's vmmon,vmnet and linux you should be able to run vmware. Soren mentioned that he might look into it a few weeks ago, but that's the last thing I remember seeing. I'm interested in helping with this, though. --- Gary Jennejohn Home - ga...@muc.de Work - ga...@fkr.dec.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-emulation in the body of the message --- Teligent AB, P.O. Box 213, S-149 23 Nynäshamn, Sweden Telephone +46-(0)8 520 660 00 * Fax +46-(0)8 520 193 36 Direct +46-(0)8 520 660 32 * GSM +46-(0)70 792 16 57 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Question regarding Xaccel
It was given about a year ago and is now out of date. XiG promised to update their web site, but evidently this just hasn't happened yet. - Jordan on Xinside site (www.xig.com) it says... FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD core team. Why was that advice given... -Gena To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Question regarding Xaccel
I sent an inquiry to Xinside about FreeBSD 3.x and the desktop X server, and the reply was that 3.x will be supported by year's end in version 5.1. The only issue the reply mentioned was aout vs. elf. The replier also said that I could run the current version under 3.x using compat22. --Archit (My first post to a freebsd mailing list, if I am breaking etiquette, please let me know) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: location of the function(recvfrom,socket...)
On Thu, 19 Aug 1999, jin biao wrote: Could you tell me where is the code of the functions(sendto, recvfrom,socket,bind...) located at FreeBSD source tree. narcissus% pwd /sys narcissus% find . | xargs grep -a ^sendto ./kern/uipc_syscalls.c:sendto(p, uap) narcissus% The others are there too. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Question regarding Xaccel
Well, I know of at least someone who is using XiG on 3.2-STABLE. And he says it works without a problem. Nick On Fri, 20 Aug 1999, Jordan K. Hubbard wrote: It was given about a year ago and is now out of date. XiG promised to update their web site, but evidently this just hasn't happened yet. - Jordan on Xinside site (www.xig.com) it says... FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD core team. Why was that advice given... -Gena To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
How to add a new domain to a domain name server
Hi, My name is estee, i am new in Freebsd. Can anyone help me to solve this problem? I want to add a new domain name in domain name server(freebsd), how i do it? Thanks in advance, please help, this is urgent... Warmest regards, Estee To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How to add a new domain to a domain name server
My name is estee, i am new in Freebsd. Can anyone help me to solve this problem? I want to add a new domain name in domain name server(freebsd), how i do it? Thanks in advance, please help, this is urgent... Well no doubt the FreeBSD box is running BIND...so the configuration file for named is either /etc/namedb/named.conf for version 8.x or /etc/namedb/named.boot if you have a 4.x version take a look at the man page for named and the files in /etc/namedb for more info. The book DNS BIND from O'Reilly is very good too. Regards, Cillian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[no subject]
Brian McGovern bmcgo...@cisco.com wrote: However, when I start running data, I get silo overflows. At which end? What else is the box getting SILO overflows doing? PIO access to disks or network cards is good for disrupting interrupt latencies. PLIP is virtually guaranteed to disrupt anything that cares about interrupt latencies. Anything very fast on the ISA bus is also likely to clag the system (simply because the ISA bus is sooo slow). Actually, the box with the silo overflows is doing 'not much'. Things like sendmail and the other daemons are running (no net connection, tho, so I know nothing is coming in/out), but otherwise, its a login, a copy of PPP, the clock tick interrupts, and the sio interrupts and corresponding network processing. I think it reports an average of 99.9% idle (the occational blip on the stats). Mike Smith m...@smith.net.au wrote: interrupt response time on your system is sufficiently poor that the time between the interrupt trigger at either 8 or 14 (I forget) characters in the FIFO This can be configured in the UART. The driver switches between two FIFO levels depending on speed (look at the FIFO_RX_... macros), but I'm not sure of the absolute levels. You could try reducing the trigger level (this should make the SILO overflows go away, but at the cost of more interrupts). In order to debug this, you will need to use a logic analyser to trap the case where the interrupt is not handled quickly enough, A slightly less invasive method, that will probably give you some clues, is to instrument the hard interrupt entry points (defined via INTR() in i386/isa/icu_vector.s or i386/isa/apic_vector.s), as well as the siointr() function. Some background: FreeBSD (should) only disable interrupts for very short periods. Due to the (lack of) speed accessing the ICUs, the SPL levels are held in software rather than in the ICU. This means that an interrupt arrives in the kernel fairly quickly after it's raised in hardware. The kernel checks the SPL mask to determine whether the interrupt can be treated immediately. If not, it sets a flag and calls the interrupt handler when the SPL level is dropped. You could add code to check the time (eg by reading the TSC) and SPL mask on interrupt and then check the time when siointr in invoked. If the time is excessive, the SPL mask will give you some idea of what was in progress. Peter My short term punt is to use a desktop system. If I keep seeing the problem there, I'll debug it some more. If it goes away, I'll know it was the laptop being quirky. -Brian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Change to /sys/net/if.c /sys/dev/syscons/syscons.c
Hi, change to /sys/net/if.c which will print out xxN: promiscuous mode disabled msg to match its equiv. xxN: promiscuous mode enabled msg works on all my interfaces even if tcpdump is run multiple times etc. However it does not print out the disabled msg for tun0 interface for some mysterious reason.. (another interesting thing was if tun0 == kld and I try a tcpdump, tpcdump doesn't recognise tun0 at all !) patch against 3.2-STABLE (synced few minutes ago) *** if.cFri Aug 20 14:42:44 1999 --- if.c.bakFri Aug 20 14:50:42 1999 *** *** 790,797 if (--ifp-if_pcount 0) return (0); ifp-if_flags = ~IFF_PROMISC; + log(LOG_INFO, %s%d: promiscuous mode disabled\n, + ifp-if_name, ifp-if_unit); } ifr.ifr_flags = ifp-if_flags; error = (*ifp-if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)ifr); --- 790,795 Beware, next suggestion is pure vapourware :P I hacked the /sys/dev/syscons/syscons.c file to display kernel messages in a different colour (bright green if you want to know), I think it would be cool if we could change this either via OPTIONS KERNMSGCOLOR=FOO in kernel conf file or via sysctl perhaps.. ..as I warned you, ultimate in vapour ware :P - Cillian as a sidenote: Anyone else out there wonder why Linux console is so crap? ie: can only scroll up on *current* console, boot messages from kernel are messy and full of ad banners, kernel messages are in boring plain-text colour.. Enough hot air from me for today.. :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
On Fri, 20 Aug 1999 15:09:59 +0100, Cillian Sharkey wrote: + log(LOG_INFO, %s%d: promiscuous mode disabled\n, + ifp-if_name, ifp-if_unit); You're the second person other than me to request this. :-) So are there any _objections_ to having the kernel match promiscuous enabled messages with disabled counterparts? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
+ log(LOG_INFO, %s%d: promiscuous mode disabled\n, + ifp-if_name, ifp-if_unit); You're the second person other than me to request this. :-) Yes, i've seen it suggested before alright.. So are there any _objections_ to having the kernel match promiscuous enabled messages with disabled counterparts? I don't have any objections, so developers speak up and have your say !! apart from the tun0 problem that I described in previous messages the suggested change seems to work perfectly.. - Cillian PS: any thoughts on the other vapourware idea :P ? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
On Fri, Aug 20, 1999 at 03:29:45PM +0200, Sheldon Hearn wrote: On Fri, 20 Aug 1999 15:09:59 +0100, Cillian Sharkey wrote: + log(LOG_INFO, %s%d: promiscuous mode disabled\n, + ifp-if_name, ifp-if_unit); You're the second person other than me to request this. :-) The third, in fact! So are there any _objections_ to having the kernel match promiscuous enabled messages with disabled counterparts? I think, the disabled messages output should be put under `if (verbose)'. -- Ruslan Ermilov Sysadmin and DBA of the r...@ucb.crimea.ua United Commercial Bank, r...@freebsd.orgFreeBSD 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
I think, the disabled messages output should be put under `if (verbose)'. Maybe..there was a lot of talk on another mailing list (-current I think?) about boot messages, level of verbosity etc. etc. so perhaps we should wait until this has been decided.. ? - Cillian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
On Fri, 20 Aug 1999 15:55:45 +0100, Cillian Sharkey wrote: Maybe..there was a lot of talk on another mailing list (-current I think?) about boot messages, level of verbosity etc. etc. so perhaps we should wait until this has been decided.. ? This has nothing to do with the boot messages, though, surely? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
Sheldon Hearn wrote: On Fri, 20 Aug 1999 15:55:45 +0100, Cillian Sharkey wrote: Maybe..there was a lot of talk on another mailing list (-current I think?) about boot messages, level of verbosity etc. etc. so perhaps we should wait until this has been decided.. ? This has nothing to do with the boot messages, though, surely? Sorry, I meant kernel messages in general (of which boot messages are a part of) Basically the discussion was suggesting different levels of verbosity for the kernel as a whole, one level would be the bare mininum (ie. errors, warnings etc.) another level might include informational and another might include debug etc.. Of course as the saying goes: Nothing works in practice like a good theory. :P Cillian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
On TCP sequence numbers
A topic that Mark and I have been discussing a little, is the algorithms that FreeBSD uses for generating initial TCP sequence numbers - that being with reference to the predictability of these numbers. (Work on this has been somewhere in Mark's todo list for a while.) This topic raises a few questions: How good, or how bad are the initial sequence numbers that FreeBSD uses? (It seems that we could improve them a little.) How unpredictable do we need to make the sequence numbers? Some testing with nmap shows that Linux is generating sequence numbers that are far more unpredictable than ours are. (Linux is, however, also using a 1MHz clock, as opposed to the 250kHz clock as outlined in the RFC.) We are only using a PRNG, as opposed to the entropy pool supplied by devrandom to generate sequence numbers (warning here - devrandom is only supported in the i386 port of FreeBSD). My testing indicates that we can improve the entropy input into our sequence numbers by using devrandom. However, this is VERY dependent on the entropy sources that you feed into the pool via rndcontrol(8). Another question that comes in to this is - how good a tool is nmap for evaluating the predictability of the sequence numbers we generate? Ideally, I would like to do some improvements to our sequence number generation. Thoughts? Geoff. -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: geo...@is.co.za URL: http://www.is.co.za To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: On TCP sequence numbers
Another question that comes in to this is - how good a tool is nmap for evaluating the predictability of the sequence numbers we generate? Ideally, I would like to do some improvements to our sequence number generation. Thoughts? What is OpenBSD like in this regard ? AFAIR it has various algorithms for randomizing sequence numbers I think.. [Correct me if I'm wrong !] - Cillian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Question regarding Xaccel
It is just as well that I did not know that - I am running it on 3.2, and have run it on all the 3.0-series. A word to the wise, if you want to run it on 3.2 install from the 3.1 CD and then upgrade by source. When I installed straight from the 3.2 cd it did not work because I needed to install compat22, and then when I did install compat22 Xsetup kept on crashing on a floating point exception. I did not have the time or inclination to find out if it was a bug in compat22. -Kip On Fri, 20 Aug 1999, Nick Hibma wrote: Well, I know of at least someone who is using XiG on 3.2-STABLE. And he says it works without a problem. Nick On Fri, 20 Aug 1999, Jordan K. Hubbard wrote: It was given about a year ago and is now out of date. XiG promised to update their web site, but evidently this just hasn't happened yet. - Jordan on Xinside site (www.xig.com) it says... FreeBSD 3.x is not yet supported on the advice of some members of the FreeBSD core team. Why was that advice given... -Gena To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How to add a new domain to a domain name server
As Estee Goh wrote ... Hi, My name is estee, i am new in Freebsd. Can anyone help me to solve this problem? I want to add a new domain name in domain name server(freebsd), how i do it? Thanks in advance, please help, this is urgent... Suggest you buy the book DNS BIND by Albitz Liu. Published by O'Reilly. This explains not only your question but the background of DNS as well. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Call for testers, new driver, blah blah blah...
This is a call for testers for a new device driver for yet another PCI fast ethernet controller: the Sundance Technologies ST201. This chipset is currently being used on the D-Link DFE-550TX. The chip on the D-Link is labeled DL10050, but it's actually an ST201. I don't know what other cards use this chip; D-Link contacted me about writing a driver and sent me two sample cards, and do far theirs is the only one that I know of. The driver is set up to recognize the stock Sundance PCI vendor/device ID as well as D-Link's. The Sundance ST201 is a clone of (wait for it) the 3Com 3c90x Etherlink XL series. No, really. Honest and for true. It uses the same DMA descriptor format and operation is very similar to the 3Com cards, although the actual register layout is different. The ST201 also has only a 64-bit multicast hash filtering table where the 3Com cards have a 256-bit table. Also, the ST201 supports only an MII transceiver interface and has no built in BNC/10baseT/AUI ports like the 3Coms. One thing that is a lot like the 3Coms is the fact that packet fragment buffers can be aligned on any byte boundaries, which means that there's no copying required to assure proper payload alignment on the alpha. Performance seems good so far though I haven't really torture tested it yet. Currently, there are drivers for 3.2+ and 4.0 available. You can download them from: http://www.freebsd.org/~wpaul/Sundance/3.0 http://www.freebsd.org/~wpaul/Sundance/4.0 Both versions support FreeBSD/i386 and FreeBSD/alpha and the 4.0 version uses newbus and can be compiled as a loadable module. There's no README yet, so here are some quick instructions: - Download the version of if_ste.c and if_stereg.h for your FreeBSD installation. - Copy if_ste.c and if_stereg.h to /sys/pci - Edit /sys/conf/files and add a line that says: pci/if_ste.coptional ste0 device-driver NOTE: for FreeBSD 4.0, leave out the device-driver part. It's no longer needed. - Edit your kernel config file, e.g. /sys/i386/conf/GENERIC and add a line that says: device ste0 - Config and compile a new kernel and boot it. Note that I chose the name ste so as not to get it confused with the SCSI tape device st. I realize we use sa instead of st now, but I'll probably create a driver version for 2.2.x soon, and st is still used there. As usual, report problems or send large bags of cash to wp...@skynet.ctr.columbia.edu. I plan to merge this driver into the -current branch just as soon as I can whip up a man page for it. Share and enjoy! -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Async NFS exports?
I asked this on stable but didn't get a response... Would I get any performance increases by mounting NFS exported partition as Async? Would my soul be tormented in purgatory for doing it? Just to be clear... I am wondering if mounting (on the NFS _server_) a partition (that is exportable) as async will have any performance benefits to the NFS clients? -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Question regarding Xaccel
I sent an inquiry to Xinside about FreeBSD 3.x and the desktop X server, and the reply was that 3.x will be supported by year's end in version 5.1. The only issue the reply mentioned was aout vs. elf. The replier also said that I could run the current version under 3.x using compat22. I am one of satisfied Xaccel DS 5.0.2 users running under -current. Voodoo3 works great! Tammy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
setting up -STABLE for hack contest
Hi As the subject says i'm waiting for suggestions how to make a stable box very secure :) I would like to know how to change login screen and make it difficult to guess what operating system is running, etc. TIA _ Lauri To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: VMWare: porting kernel modules to FreeBSD
It seems Gary Jennejohn wrote: Mark Huizer writes: Hi there, I had a look recently at the code for one of the kernel modules that VMWare requires (driver-only.tar), and it looks like something that should be portable to FreeBSD, although there is some messy stuff in it (assembly that seems to be using Linux specific stuff, brrr..) But anyway: it looks feasable. Is anyone already working on this, or are some people interested in helping with this? As far as I can see, the linux emulation is good enough to run the vmware program, all you need to do is implement /dev/vmmon and /dev/vmnet, given the fact that the code is written really unportable, so there is some rewriting to be done. Then with the KLD's vmmon,vmnet and linux you should be able to run vmware. Soren mentioned that he might look into it a few weeks ago, but that's the last thing I remember seeing. Yup, I have the files here, and have given it a quick look, doesn't look to difficult to do, but I havn't had time yet to get into the matter.. It will probably be awhile before I do have the time though, but if nobody else does it I'll get to it sooner or later... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: setting up -STABLE for hack contest
On Fri, 20 Aug 1999, Lauri Laupmaa wrote: I would like to know how to change login screen and make it difficult to guess what operating system is running, etc. Change the default entry in /etc/gettytab. On a 3.2-STABLEsustem (from the 19990812 snapshot), the default line looks like: default:\ :cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200: You can change it to something like this for fun: default:\ :cb:ce:ck:lc:fd#1000:im=\r\nOpenVMS\r\n\r\n:sp#1200: It is also trivial to hack login(1) to say Username: to instead of login:. As you might have guessed, I did this to a FreeBSD 3.0 system about nine months ago. Jamie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: setting up -STABLE for hack contest
it is possible to detect operating systems from their behaviours of replying to packets. see the program queso from ports/packages. but anyway you can change the login prompt from /etc/gettytab file Evren Yurtesen yurte...@ispro.net.tr Lauri Laupmaa wrote: Hi As the subject says i'm waiting for suggestions how to make a stable box very secure :) I would like to know how to change login screen and make it difficult to guess what operating system is running, etc. TIA _ Lauri To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Anybody cobbled together a getpwent() that uses libradius?
While whatever happens with PAM and LDAP, and all those great things, I would like to validate passwords via Radius... It would be most convenient if it was just in getpwent()... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Anybody cobbled together a getpwent() that uses libradius?
On Fri, 20 Aug 1999, Jaye Mathisen wrote: While whatever happens with PAM and LDAP, and all those great things, I would like to validate passwords via Radius... It would be most convenient if it was just in getpwent()... This is the wrong place to put it - see the pam_radius module. Bloating libc with promiscuous knowledge of authentication services helps no-one. Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Serial cable
Hi, Rich: Can you find a serial cable for me? I need to connect two PCs together via RS232 ports. Thanks. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Anybody cobbled together a getpwent() that uses libradius?
I completely missed that radius was working with pam. A check of radius related stuff in the man pages didn't show anything related to PAM, and the pam.conf page doesn't show anything related to radius. Should've checked the libs though. Thanks. On Fri, 20 Aug 1999, Kris Kennaway wrote: On Fri, 20 Aug 1999, Jaye Mathisen wrote: While whatever happens with PAM and LDAP, and all those great things, I would like to validate passwords via Radius... It would be most convenient if it was just in getpwent()... This is the wrong place to put it - see the pam_radius module. Bloating libc with promiscuous knowledge of authentication services helps no-one. Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Anybody cobbled together a getpwent() that uses libradius?
On Fri, 20 Aug 1999, Jaye Mathisen wrote: While whatever happens with PAM and LDAP, and all those great things, I would like to validate passwords via Radius... It would be most convenient if it was just in getpwent()... I beg to differ. It's extremely easy to use pam_radius module. No changes in sources - just edit /etc/pam.conf. Andrzej Bialecki // ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Anybody cobbled together a getpwent() that uses libradius?
On Fri, 20 Aug 1999, Jaye Mathisen wrote: I completely missed that radius was working with pam. A check of radius related stuff in the man pages didn't show anything related to PAM, and ...they are on their way - check RELENG_3, i.e. STABLE. Andrzej Bialecki // ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
[ Caveat: I'm making this up as I go along ] On Fri, Aug 20, 1999 at 01:13:06PM -0500, a little birdie told me that Steve Ames remarked I asked this on stable but didn't get a response... Would I get any performance increases by mounting NFS exported partition as Async? Would my soul be tormented in purgatory for doing it? Just to be clear... I am wondering if mounting (on the NFS _server_) a partition (that is exportable) as async will have any performance benefits to the NFS clients? As a first guess, probably not unless you have a large number of active clients. Any modern hard disc will outperform ethernet/fast ethernet, especially for larger read/writes. For large numbers of smaller operations, or when there is a large number of simultaneous outstanding requests from clients, maybe. I'd say watch the disc itself (iostat is your friend), and if it's pegged (especially large numbers of tps) async might buy you some increase. -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Change to /sys/net/if.c /sys/dev/syscons/syscons.c
For the record, I'd love to see this made official, and under normal (not just verbose) logging. -Dave Lo and behold, Cillian Sharkey once said: Hi, change to /sys/net/if.c which will print out xxN: promiscuous mode disabled msg to match its equiv. xxN: promiscuous mode enabled msg works on all my interfaces even if tcpdump is run multiple times etc. However it does not print out the disabled msg for tun0 interface for some mysterious reason.. (another interesting thing was if tun0 == kld and I try a tcpdump, tpcdump doesn't recognise tun0 at all !) patch against 3.2-STABLE (synced few minutes ago) *** if.cFri Aug 20 14:42:44 1999 --- if.c.bakFri Aug 20 14:50:42 1999 *** *** 790,797 if (--ifp-if_pcount 0) return (0); ifp-if_flags = ~IFF_PROMISC; + log(LOG_INFO, %s%d: promiscuous mode disabled\n, + ifp-if_name, ifp-if_unit); } ifr.ifr_flags = ifp-if_flags; error = (*ifp-if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)ifr); --- 790,795 Beware, next suggestion is pure vapourware :P I hacked the /sys/dev/syscons/syscons.c file to display kernel messages in a different colour (bright green if you want to know), I think it would be cool if we could change this either via OPTIONS KERNMSGCOLOR=FOO in kernel conf file or via sysctl perhaps.. ..as I warned you, ultimate in vapour ware :P - Cillian as a sidenote: Anyone else out there wonder why Linux console is so crap? ie: can only scroll up on *current* console, boot messages from kernel are messy and full of ad banners, kernel messages are in boring plain-text colour.. Enough hot air from me for today.. :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- work: dande...@cs.utah.edu me: an...@pobox.com University of Utah CS Department http://www.angio.net/ If you haul a geek up a crack, you will bloody their fingers for a day... If you teach a geek to climb, you will bloody their fingers for life. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
:I asked this on stable but didn't get a response... Would I get any :performance increases by mounting NFS exported partition as Async? : :Would my soul be tormented in purgatory for doing it? : :Just to be clear... I am wondering if mounting (on the NFS _server_) a :partition (that is exportable) as async will have any performance :benefits to the NFS clients? : :-Steve w/NFSv3 I doubt mounting the exported partitions async will increase performance much. I would not use an async mount - if this is an NFS server it needs to be as reliable as possible and async mounting the partition is going to hurt if the machine crashes. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
: Just to be clear... I am wondering if mounting (on the NFS _server_) a : partition (that is exportable) as async will have any performance : benefits to the NFS clients? : :As a first guess, probably not unless you have a large number of active :clients. Any modern hard disc will outperform ethernet/fast ethernet, :especially for larger read/writes. For large numbers of smaller :operations, or when there is a large number of simultaneous outstanding :requests from clients, maybe. I'd say watch the disc itself (iostat is :your friend), and if it's pegged (especially large numbers of tps) async :might buy you some increase. :-- :Matthew Fuller (MF4839) |fulle...@over-yonder.net Not much if at all, whether you have a large number of clients or not, at least if you are using NFSv3 mounts. The reason is due to the way NFSv3 issues writes. NFSv3 issues a write but no longer assumes that the write has been synced to the server's disk as of when the reply comes back. Instead it keeps the buffer around and does a later commit rpc to do the sync, presumably long after the server has already synced the data. So, effectively, all NFSv3 writes are async insofar as the client's buffer cache is able to keep abrest of the write-rate. Hmm, interesting. I see another optimization I can do to fix the buffer cache saturation case in CURRENT on the client. The COMMIT rpc's aren't being issued async. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
help! - strange vn behaviour
I'll cc: hackers and see if this rings a bell for anyone :| .. Andrew Btw, can you explain why this happens? $ partitionsize=256 $ sects=`/bin/expr $partitionsize '*' 64 '-' 1` $ vnconfig -e -s labels -S $partitionsizem /dev/vn0 $ disklabel -w -r vn0 auto disklabel: /dev/rvn0c: Device not configured $ disklabel vn0 disklabel: ioctl DIOCGDINFO: Inappropriate ioctl for device $ disklabel /dev/vn0 # /dev/vn0: type: unknown disk: amnesiac label: fictitious flags: bytes/sector: 4096 sectors/track: 32 tracks/cylinder: 8 sectors/cylinder: 256 cylinders: 256 sectors/unit: 65536 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c:655360unused0 0 # (Cyl. 0-255) - Now, if I do a - $ vnconfig -u /dev/vn0c echo woohoo! vnconfig: VNIOCDETACH: Device not configured $ vnconfig -u /dev/vn0 echo woohoo! woohoo! ... The vn device _is_ configured but not useable via /dev/vn0[abc..z] ?? Andrew. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
L440GX+ Server Board
Hi all, I have a problem with a server running a FreeBSD 3.2. My Server has a L440GX+ Serber Board (intel), with network card 10/100, SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III 450Mhz (not overclocked). The NIC and SCSI are onboard. I recompiled a kernel to SMP, and it worked. The server is ok, but when I run a comand with disk access (whith vipw or mysql), the performance of server goes down. My server stays very very very slow. If I use pine to read my messages, it doesn't work. When the comand finishes, the server stays ok again. I recompiled the kernel with maxusers 128, but it doesn't work. My SCSI cable has a terminator and the scsi setup is ok (I think :) ). The dmesg command output is in attchmnt. I appreciate any help. []s, Luiz Morte da Costa Junior Analista de RedesE-mail: mo...@correionet.com.br Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-RELEASE #1: Wed Aug 18 17:42:50 EST 1999 r...@caxton.correionet.com.br:/usr/src/sys/compile/DUAL Timecounter i8254 frequency 1193182 Hz CPU: Pentium III (686-class CPU) Origin = GenuineIntel Id = 0x672 Stepping=2 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,b18,MMX,b24,b25 real memory = 536870912 (524288K bytes) config di zp0 config di ze0 config di lnc0 config di le0 config di ie0 config di fe0 config di ex0 config di ep0 config di ed0 config di cs0 config di scd0 config di mcd0 config q avail memory = 519188480 (507020K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc0366000. Preloaded userconfig_script /boot/kernel.conf at 0xc036609c. Probing for devices on PCI bus 0: chip0: Intel 82443GX host to PCI bridge rev 0x00 on pci0.0.0 chip1: Intel 82443GX host to AGP bridge rev 0x00 on pci0.1.0 ahc0: Adaptec aic7896/97 Ultra2 SCSI adapter rev 0x00 int a irq 19 on pci0.12.0 ahc0: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: Adaptec aic7896/97 Ultra2 SCSI adapter rev 0x00 int a irq 19 on pci0.12.1 ahc1: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x08 int a irq 21 on pci0.14.0 fxp0: Ethernet address 00:a0:c9:fc:17:55 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.18.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.18.1 chip3: Intel 82371AB Power management controller rev 0x02 on pci0.18.3 vga0: Cirrus Logic model 00bc VGA-compatible display device rev 0x23 on pci0.20.0 Probing for devices on PCI bus 1: chip4: PCI to PCI bridge (vendor=1011 device=0023) rev 0x06 on pci1.15.0 Probing for devices on PCI bus 2: Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): CREATIVECD4831E/1.00, removable, accel, dma, iordis acd0: drive speed 2755 - 5511KB/sec, 240KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked wt0 not found at 0x300 matcdc0 not found at 0x230 ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port adv0 not found at 0x330 bt_isa_probe: Probe failled for card at 0x330 bt_isa_probe: Probe failled for card at 0x334 bt_isa_probe: Probe failled for card at 0x230 bt_isa_probe: Probe failled for card at 0x234 bt_isa_probe: Probe failled for card at 0x130 bt_isa_probe: Probe failled for card at 0x134 bt0 not found at 0x134 aha0 not found at 0x134 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 Waiting 15 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! sa0 at ahc1 bus 0 target 4 lun 0 sa0: HP C1537A L706 Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 32) da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST39140LW
Re: Async NFS exports?
On Fri, 20 Aug 1999, Steve Ames wrote: I asked this on stable but didn't get a response... Would I get any performance increases by mounting NFS exported partition as Async? Would my soul be tormented in purgatory for doing it? Just to be clear... I am wondering if mounting (on the NFS _server_) a partition (that is exportable) as async will have any performance benefits to the NFS clients? of course it will, but it'll also potentially cause catastrophic damage to your filesystem if the machine dies for some reason. have a look at: /usr/src/sys/contrib/softupdates/README or possibly /usr/src/contrib/softupdates/README also, play with the nfs sysctl's and mout options to tune performance. sysctl -a | grep nfs good luck, -Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bri...@wintelcom.net] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Serial cable
On Fri, Aug 20, 1999 at 03:12:48PM -0400, Zhihui Zhang wrote: Hi, Rich: Can you find a serial cable for me? I need to connect two PCs together via RS232 ports. Aha! Remote Kernel Debugging aren't we? Probably you did not intend this mail to go to the mailing list :) Regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
:I asked this on stable but didn't get a response... Would I get any :performance increases by mounting NFS exported partition as Async? : :Would my soul be tormented in purgatory for doing it? : :Just to be clear... I am wondering if mounting (on the NFS _server_) a :partition (that is exportable) as async will have any performance :benefits to the NFS clients? : :-Steve Ok, I've run some more tests. Basically you want to run NFSv3 under CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network this will give you unsaturated write performance in the ballpark of 9 MBytes/sec. Saturated write performance, that is where you write more then the client-side buffer cache can handle, will stabilize at 2.5 MBytes/sec. I have a patch for CURRENT which will increase the saturated write performance to 4.5 MBytes/sec (basically by moving the nfs_commit() from nfs_writebp() to nfs_doio() so it can be asynchronized). Hopefully that patch will go in soon but there's a pretty big backlog of patches that haven't gone in yet, some over a week and a half old, so... In anycase, even without the patch if you run a couple of nfsiod's and do not saturated the buffer cache you should get optimal performance. Backing-porting the patch for nfs_commit to STABLE is possible but is not likely to help much because the major performance restriction in STABLE is related to buffer cache management, not NFS. OS #nfsiod's unsaturated saturated write perf. write perf. ( . 100BASETX .. ) CURRENT 0 9 MBytes/sec2.5 MBytes/sec CURRENT 4 9 MBytes/sec4.5 MBytes/sec(w/patch) STABLE 0 3 MBytes/sec3 MBytes/sec(1) STABLE 4 4 MBytes/sec3 MBytes/sec(1) note(1): saturated performance under STABLE is extremely inconsistant -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
:Ok, I've run some more tests. Basically you want to run NFSv3 under :CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network Oh, let me be a bit more clear: Run 3 nfsiod's on the client. Run 4 nfsd's on the server. e.g. 'nfsiod -n 3' on the client and 'nfsd -n 4' on the server. To realize maximum NFS performance both the server and client should be running CURRENT. If Non-FreeBSD clients cannot achieve good performance, the problem is with those clients and nothing you do on the server will help. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
The reason is due to the way NFSv3 issues writes. NFSv3 issues a write but no longer assumes that the write has been synced to the server's disk as of when the reply comes back. Instead it keeps the buffer around and does a later commit rpc to do the sync, presumably long after the server has already synced the data. So, effectively, all NFSv3 writes are async insofar as the client's buffer cache is able to keep abrest of the write-rate. Hmm, interesting. I see another optimization I can do to fix the buffer cache saturation case in CURRENT on the client. The COMMIT rpc's aren't being issued async. If you are looking for more optimizations, you can delay NFS write operations for some interval X, on all write buffers, entirely. Sun does this (it is technically called write gathering in the literature). The upshot of introducing this latency between request and action is that multiple writes to adjacent regions on non-buffer boundaries are batched up for processing by the NFS server. The net result is that you can do more writes, while generating less wire traffic. Be forewarned, however, that you must include synchronization primitives at the appropriate places. Among these are: 1) When a write lock is acquired, a write is issued in a region spanned by the lock, and the lock released, the lock release must also be delayed. The reason for this is that the lock is being used to ensure distributed cache coherency (actually, in effect, a lease-stall for other clients wanting to do writes). 2) When a conflicting lock is requested, you need to initate a synchronization point. This is because even though they are proxied from the same system ID, the NFS locks are on different process ID's, and some NFS servers will enforce based on this, even though the locks are, putatively, advisory, not mandatory. 3) On file deletions. Generally, this just boils down to not being able to delete an NFS file in actuality, unless you are the last closer on the file. Implementation-wise, it means that a delete operation is a request-to-sync operation. 4) Etc.. While these aren't technically necessary right now (in FreeBSD, since FreeBSD fails to implement NFS locking), omitting them now will make it nearly impossible to repair later, should NFS locking support arise from my (or someone else's) kernel patches being applied, and someone hacking up the lock and stat daemons to make the proper system calls. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sio doesn't do HW flow correctly?!?
Brian McGovern bmcgo...@cisco.com wrote: My short term punt is to use a desktop system. If I keep seeing the problem there, I'll debug it some more. If it goes away, I'll know it was the laptop being quirky. The other possibility is that the laptop's APM is putting it into some sort of sleep state and not waking it up fast enough. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
Emm, I guess that answers my earlier question/mail: Why?--- basil# uname -a FreeBSD basil.dympna.com 3.2-RELEASE FreeBSD 3.2-RELEASE #7: Thu Aug 19 23:59:50 CDT 1999 rs...@basil.dympna.com:/export/current/src/sys/compile/Basil-SMP [Dual PPro-233's] basil# cd /stripe basil# df -k . Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/vinum/stripe 1719751186511 15735200 1%/stripe basil# Bonnie -s 256 ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 10817 97.3 15805 93.1 6338 41.4 9943 97.5 15796 51.2 basil# mount_nfs -3 localhost:/stripe /mnt basil# cd /mnt basil# Bonnie -s 256 ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 256 4270 57.6 6639 30.6 1877 11.7 3804 55.3 6201 18.7 Matthew Dillon wrote: :I asked this on stable but didn't get a response... Would I get any :performance increases by mounting NFS exported partition as Async? : :Would my soul be tormented in purgatory for doing it? : :Just to be clear... I am wondering if mounting (on the NFS _server_) a :partition (that is exportable) as async will have any performance :benefits to the NFS clients? : :-Steve Ok, I've run some more tests. Basically you want to run NFSv3 under CURRENT and you want to run at least 3 nfsiod's. On a 100BaseTX network this will give you unsaturated write performance in the ballpark of 9 MBytes/sec. Saturated write performance, that is where you write more then the client-side buffer cache can handle, will stabilize at 2.5 MBytes/sec. I have a patch for CURRENT which will increase the saturated write performance to 4.5 MBytes/sec (basically by moving the nfs_commit() from nfs_writebp() to nfs_doio() so it can be asynchronized). Hopefully that patch will go in soon but there's a pretty big backlog of patches that haven't gone in yet, some over a week and a half old, so... In anycase, even without the patch if you run a couple of nfsiod's and do not saturated the buffer cache you should get optimal performance. Backing-porting the patch for nfs_commit to STABLE is possible but is not likely to help much because the major performance restriction in STABLE is related to buffer cache management, not NFS. OS #nfsiod's unsaturated saturated write perf. write perf. ( . 100BASETX .. ) CURRENT 0 9 MBytes/sec2.5 MBytes/sec CURRENT 4 9 MBytes/sec4.5 MBytes/sec(w/patch) STABLE 0 3 MBytes/sec3 MBytes/sec(1) STABLE 4 4 MBytes/sec3 MBytes/sec(1) note(1): saturated performance under STABLE is extremely inconsistant -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: anybody love qsort.c?
Christopher Seiwald writes:
But as I'm proposing a change to a fairly sensitive piece of code, I'd
like to keep the change as modest as possible.
How about this?
Index: qsort.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.7
diff -u -r1.7 qsort.c
--- qsort.c 1997/02/22 15:03:14 1.7
+++ qsort.c 1999/08/21 01:35:35
@@ -153,7 +153,7 @@
pb += es;
pc -= es;
}
- if (swap_cnt == 0) { /* Switch to insertion sort */
+ if (n = 32 swap_cnt == 0) { /* Switch to insertion sort */
for (pm = (char *)a + es; pm (char *)a + n * es; pm += es)
for (pl = pm; pl (char *)a cmp(pl - es, pl) 0;
pl -= es)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
:Emm, I guess that answers my earlier question/mail: : :Why?--- : :/dev/vinum/stripe 1719751186511 15735200 1%/stripe :basil# Bonnie -s 256 : ---Sequential Output ---Sequential Input-- : -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- :MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU : 256 10817 97.3 15805 93.1 6338 41.4 9943 97.5 15796 51.2 : : :basil# mount_nfs -3 localhost:/stripe /mnt :basil# cd /mnt :basil# Bonnie -s 256 : : ---Sequential Output ---Sequential Input-- : -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- :MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU : 256 4270 57.6 6639 30.6 1877 11.7 3804 55.3 6201 18.7 Buffer copy and protocol overhead, plus the data is being cached twice: once on the server and once on the client (which happens to be the same machine). The machine becomes cpu-bound with all the extra work. This is what I get. Ignore the read numbers (the machine has a lot of memory). This is with nfsd -n 4 and nfsiod -n 4, NFSv3 UDP mount, on a duel P-III/450 running CURRENT. /dev/da0h 2338236 1235921 91525757%/usr/obj ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 9979 51.4 9154 19.0 9814 22.5 19727 99.8 103863 100.0 2163.4 43.2 localhost:/usr/obj/ 2338236 1235921 91525757%/mnt ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 3532 30.9 4164 7.6 4364 14.9 13700 99.9 75964 99.7 2779.7 162.1 As you can see, I get very similar numbers for writing. 9 MB/sec on the local filesystem and 4.3 MB/sec via a localhost: NFS mount. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
pthread_set_concurrency()
Hello there, so it seems that pthread_set_concurrency() has not been implemented at least up to 3.2-stable. How could one ensure that their threads in an application can be equally distributed to all the processors in FreeBSD? Are there any documents on FreeBSD 3.*'s thread support(both kernel and user level)? The pthread man pages are quiet incompelete and some pthread calls have not been implemented. Thanks, Ming To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
Terry Lambert wrote: That's kind of the point. No other VFS stacking system out there plays by FreeBSD's revamped rules. I look around and I see no standards. It is still time to be experimental. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
: The reason is due to the way NFSv3 issues writes. NFSv3 issues a : write but no longer assumes that the write has been synced to the : server's disk as of when the reply comes back. Instead it keeps the :.. : :If you are looking for more optimizations, you can delay NFS write :operations for some interval X, on all write buffers, entirely. : :Sun does this (it is technically called write gathering in the :literature). The client-side pushes a buffer out the moment it fills up. Since this corresponds to a maximally-sized NFS data packet the client will not be more efficient by delaying it. The server-side in the FreeBSD implementation *DOES* do write-clustering, as I demonstrate below. The server does a better job of write-clustering when the client is a FreeBSD-CURRENT box, though, because FreeBSD-CURRENT clients generate a more uniform data flow. The server is able to do write-clustering w/ NFSv3 mounts because data writes are not required to be synched to disk until the client requests a commit. Note that KB/t fields below. CURRENT server, CURRENT client. iostat on server while client writes apollo:/usr/src/sys/nfs# iostat da0 1 tty da0 cpu tin tout KB/t tps MB/s us ni sy in id 0 20 0.00 0 0.00 1 0 1 0 98 0 43 0.00 0 0.00 0 0 1 0 99 0 43 1.00 1 0.00 0 0 0 0100 0 42 6.86 7 0.05 0 0 10 0 90 0 43 61.80 68 4.12 1 0 25 21 53 0 43 64.00 72 4.52 0 0 18 28 54 0 43 64.00 73 4.58 0 0 21 25 54 0 42 62.29 74 4.51 0 0 24 32 45 0 43 63.23 72 4.46 0 0 22 23 54 0 43 64.00 32 1.98 0 0 9 9 82 CURRENT server, STABLE client. iostat on server while client writes apollo:/usr/src/sys/nfs# iostat da0 1 tty da0 cpu tin tout KB/t tps MB/s us ni sy in id 0 20 0.00 0 0.00 1 0 1 0 98 0 43 43.43 98 4.15 0 0 15 21 64 0 42 17.48 107 1.82 0 0 9 7 84 0 43 62.49 73 4.47 0 0 19 33 48 0 43 19.93 121 2.35 0 0 8 9 84 0 43 43.07 85 3.58 0 0 17 22 61 0 42 46.77 90 4.11 0 0 21 22 57 0 43 15.63 108 1.65 0 0 8 7 85 0 43 64.00 70 4.39 2 0 17 27 54 However, even a FreeBSD-CURRENT breaks down when its buffer cache saturates. The example below demonstrates this: CURRENT server, CURRENT client, iostat of server disks while client writes (client buffer cache not saturated) 0 43 0.00 0 0.00 0 0 0 0100 0 43 56.00 26 1.41 0 0 14 5 81 0 42 64.00 72 4.52 0 0 21 26 53 0 43 64.00 73 4.58 0 0 25 19 57 11 54 64.00 71 4.46 2 0 17 28 53 0 42 62.27 73 4.45 0 0 26 22 52 5 48 64.00 72 4.52 0 0 22 24 53 5 48 52.72 82 4.23 0 0 20 26 53 (client buffer cache saturates) 11 54 18.76 163 2.99 2 0 12 16 71 1 43 19.20 129 2.41 1 0 13 11 75 7 70 20.65 146 2.95 2 0 14 16 67 4 47 17.53 130 2.22 0 0 9 15 77 6 51 24.63 113 2.72 1 0 10 13 76 4 73 15.17 153 2.27 0 0 11 7 82 The problem that occurs on the FreeBSD server is simply that the nfsrv_commit() procedure calls fsync() on the file... on the *ENTIRE* file, for every commit rpc, rather then syncing just the offset/range requested. I am looking into ways to fix this. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: pthread_set_concurrency()
implemented at least up to 3.2-stable. How could one ensure that their threads in an application can be equally distributed to all the processors in FreeBSD? You can't. Are there any documents on FreeBSD 3.*'s thread support(both kernel and user level)? FreeBSD has no kernel 'thread' support, only user level. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
device_add_child??
I have been writing a nasty kludge to treat a CardBus bridge as a standard PCI bridge (with static config) you may start throwing rocks now. I have it to the point where I can (after the system is booted) 'pciconf -r pci5:0:0 0' and get scan information (neat, huh :). Welll, I thought it would then just be a simple matter of 'device_add_child(dev, pci, 5, 0);' to get the bus to show up at PCI5: at bootup, but it seems to ignore it. following from pcisupport.c I also tried to 'bus_generic_attach()' it after device_add_child() finished. no go. Any suggestions? -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
