Re: SURVEY: Sound cards that work under FreeBSD
Here's the information about the sound card I am working with: 1) The sound card make and model/chipset. Please be as specific as you can with board rev numbers if possible. Please include wether the card is ISA or PCI. My sound card is a SBPCI128 by Creative Labs. 2) FreeBSD version(s) it was tested with. List *all* versions of FreeBSD for which you can verify that the sound card does/doesn't work (don't include -BETA or -SNAP releases but dates on -STABLE and -CURRENT branches are welcome). I only used the card with FreeBSD 3.2 3) Appropriate lines from your kernel config file / PNP setup. i.e. what did you have to do to get this card working? Did you need patches not committed to a particular branch (if so URLs would be welcome)? Do you use OSS drivers instead? The only line I had to add to my kernel config file was: device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 (This causes a message "pcm0 not found" to appear at boot time but just ignoring it seems to be o.k. - allthough I would prefer not to see it, at all.) 4) Sample dmesg output for properly configured device. Show the world what boot messages relate to the device after properly configured. These are the messages that appear previous to the message "pcm0 not found": es1: AudioPCI ES1370 rev 0x01 int a irq 5 on pci0.9.0 pcm1: using I/O space register mapping at 0xe400 5) Miscellaneous notes. State anything "not obvious" to the casual FreeBSD user. Good examples might be, "volume is 0 by default, use mixer(1) to adjust at boot time," or "sh MAKEDEV snd1 for the 1st device, not snd0." I had to build the audio device snd1: # cd /dev # sh MKDEV snd1 and to use the mixer to set the volume to another value than 0. I use the following script /usr/local/etc/rc.d/mixer.sh at boot time: #!/bin/sh /usr/sbin/mixer vol 60:60 pcm 60:60 cd 60:60 6) Is it OK to publish your e-mail address / name as the contributor of this information? You may type in an anti-spam version of your e-mail address below if you would like that option instead. Well, I guess, I should not be listed as the contributor, because I catched these information out of the mailing lists and would prefer the original poster to appear as the contributor. Cheers, Dirk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I've had great results with the Tyan 1836DLUAN/Thunder 100's. I've got several boxes with 1GB of RAM and dual 450's humming along. For comparison one system with less memory and a SuperMicro board but identical system software has had a couple of wierd spontaneous reboots over the last few months. Cool... Is 1GB of ram really needed? We used to run a 64 meg system then 128 meg and then 384 meg, it doesn't seem to do much even for a heavily loaded ISP Server. Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. The real problem was poor CGI programming. I made them fix them. Now it toodles along with ridiculously low loads. All the websites and the mysql db fit in core. ;-) That's true too Seems like FreeBSD can handle a real high load without problems... Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: usb keyboard setup -or- HELP!
Check out the ukbd man page man 4 ukbd It should give you all the information you need. The PS/2 connector should be recognised by the ums driver and it should give you a mouse that you can attach as described in the ums man page. Let me know if this does not work for you, so we can improve the man pages. Thanks. Nick On Fri, 23 Jul 1999, Jim Bryant wrote: hi, i'm running 4.0-current on a dual p2-333 box. i run X, and am looking for help in setting up a usb keyboard for use with FreeBSD/Xfree86. if anyone has this running, i could use the help in setting it up. also, this keyboard has a ps2 mouse connector. does the mouse get recognized as a usb mouse? jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- Inet: [EMAIL PROTECTED]AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, Jul 22, 1999 at 10:58:59PM -0700, John Polstra wrote: In article [EMAIL PROTECTED], Dominic Mitchell [EMAIL PROTECTED] wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also "using masses of weird shared objects" but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Ooh! Cunning! Concerning "masses of weird shared objects," you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. Very right. I didn't say it was a bad thing, just confused me for a while when I first saw it... However, I still (personally) prefer the idea of a filesystem interface... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
We (KAME) are using 3.2-RELEASE and 2.2.8-RELEASE because we can't base our IPv6 development on top of moving target. FreeBSD 3.x-STABLE and 4.x are moving target (which moves very quickly) and are unusable as base version for us - if we need to chase two moving things (IPv6 and FreeBSD) we are doomed. Problem being is that the 2.2.x branch has been declared obsolete and dead by the Project. If serious development work is being done CURRENT has always been the targetted platform. But let's not nitpick about decissions make months earlier. However, 3.2-STABLE isn't that fast moving forward, and I doubt, based on earlier discussions about touching the 3.x branch, that Jordan will allow IPv6 to be entered into the 3.x branch (however TPTB may judge otherwise). So 4.x seems like the only alternative left... I can't tell KAME users like: "Oh, if you would like to apply KAME diffs you'll need to fetch FreeBSD 4.x of June 1st". KAME needs to stick to x.y-RELEASE either, KAME have no choice anyways. And I am still working on that =) Thanks for the effort! There has been NRL/INRIA/KAME integration work going on (basically to avoid "4 BSDs and 3 IPv6 = 12 choices" nightmare by making one IPv6 stack). There are, mainly, some (or too many) management issues there. We will be resolving management issues issue very soon, hopefully by next week. That's good new ITOJUN-san, but I hope you can understand that after seeing OpenBSD deploy IPv6 and NetBSD-CURRENT getting the IPv6 code merged by you, that FreeBSD (read the userbase/developers) is anxious to also incorporate this. I talked with [EMAIL PROTECTED] several times about IPv6/IPsec integration, and the reaction was that: FreeBSD can wait till unified-ipv6 is made available, since: - IPv6 is not that urgent task and - it will be messy if FreeBSD integrates KAME first, then switch to unified-ipv6. (making a big change twice for IPv6 is questionable route) So we are in the current situation. (or maybe I was not pushing hard enough) NetBSD merged in KAME code last month, because NetBSD will have feature freeze for 1.5 soon and needed IPv6 code earlier than that. If I miss 1.5, it will not be able to be merged until 1.6 (planned to be sometime late 2000, I heard). NetBSD will be switching to unified codebase whenever it is made available (so NetBSD decided to make a big change twice). There's incomplete "unified" codebase there, which is not very ready for public consumption. Anyway please hold till the managment issue is resolved, I believe I can give you a good news. Let me ask one question: if a few of us got the 3.x kit of kame up to 4.x level and it got all commited would it make the `merged' stack easier to integrate into CURRENT or does the stack-project prefer to use a clean codebase? I myself think the first, which allows our driver writers time to adjust to IPv6 changes, get a lot of still-present bugs out and basically restabilize the system before the next IPv6 changes. Not to mention allow people to test/work with IPv6 already. Here's my question: how much patch rejection you saw when you tried to apply KAME/FreeBSD32 patch onto 4.0? Were there many of these, or very few? If they are very few, and core@freebsd is okay, I think KAME can be merged into 4.0 tree first, then FreeBSD can switch from KAME to unified whenever it becomes ready (just like NetBSD does). Hopefully KAME and unified-ipv6 will not be that different, except for dual-stack tcp part (KAME code used separate tcp4/tcp6 for a long time, due to maintenance and stability reasons. The way unified code does dual-stack tcp is different from what KAME does). Userland part can be reused without trouble. There are, however, several drawbacks in doing that: - Now we have multiple KAME/FreeBSD[34] repository, one is in KAME site and one is in freefall.freebsd.org. Synchronizing those tree is a big problem. KAME already have problems synchronizing code between platforms we support, the merge will increase the problem. - Manpower issues. We need to continue providing KAME/FreeBSD32 anyways, for people who wants more stable IPv6/IPsec systems. We can't just tell everybody to switch to 4.0 and chase FreeBSD-current. - We need some more FreeBSD commit privs for other KAME guys. (this is a easy part) - again, two big changes for IPv6? Impacts on IPv4 stability? itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: InterMezzo: Project for kernel/FS hackers
On Thu, 22 Jul 1999, Nik Clayton wrote: Hi chaps, Not entirely sure which list to post this too, so I figured that -hackers was probably most appropriate. Has anyone had the chance to look at InterMezzo, website at http://www.inter-mezzo.org/ It's main claim to fame is that it allows disconnected operation. For example, you could have a server export a home directory to a laptop, then unplug the laptop from the network, and go and edit/add/delete files from the home directory stored on the laptop. When the laptop is then plugged back in to the network, the filesystem automatically (as far as possible) integrates the changes). Coda (which already has a FreeBSD port) also does this, as well as a few other things. However, Coda is much more heavyweight than InterMezzo, and therefore easier to understand -- in particular, Coda seems to have (according to one of the Coda developers) a marked preference for exporting whole filesystems, InterMezzo allows you to export individual directory trees. Anyway, if any aspiring kernel hackers are looking for a project, that might be a fun one. The only implementation at the moment is for Linux. Cheers, What I'd actually like to see is a port of Inter-mezzo to use the Arla kernel module, which is far more portable/etc, and is also under a BSD license (both Coda and Inter-mezzo are under GPL). I have worked a fair amount with the Arla module to build some user-land file system code, but have no experience with Inter-mezzo. I do have experience with the Coda module, and can say they are quite similar (although the Arla code seems more thread-aware and RPC-like). I have hopes that we can integrate the Arla module into the base FreeBSD distribution, as OpenBSD has done, as it is looking quite stable and makes userfs programming a lot easier. OpenBSD has also integrated the Arla userland support for AFS, which might also be nice to integrate into the base distribution at some point, but is perhaps less useful than integrating the kernel module as the userland code can easily be made a package. As to your comments on Coda: Coda requires custom storage on the server, and cannot export a regular file system. I'm not sure how Inter-Mezzo handles these things: they might require the storage of log/version information on the server somewhere to aid in reintegrating disconnected changes, but again I don't know all that much about it. What I do know is that Coda desperately requires simplification and a fresh code base, so it seems like a step forwards. :-) Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
As Alex Zepeda wrote ... On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I know a lot of people like the ASUS P2B boards, but I've noticed a tendency for the systems to reset occasionally when plugging in a keyboard. I've seen this with both FreeBSD and NT, so I'm considering it a property of the board. If this is a PS/2 style keyboard, don't plug and unplug them when the host is powered up. The PS/2 style stuf seems to be very sensitive to that PS/2 or DIN plug, does not matter. [Un]plugging keyboards is a bad idea on a live system. I've seen keyboard fuses (on the mainboard) blown etc And that would be the most benificial of the possible breakage you can get yourself into. Wilko -- | / 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
Paper: Kernel-Supported Speculative Process Execution for Transparent File System Prefetching
-- Title Kernel-Supported Speculative Process Execution for Transparent File System Prefetching CMU 15-712 Software Systems Authors Ted Pham and Robert Watson Date May 7, 1999 Abstract This paper explores the feasibility of an operating system kernel performing speculative execution of user processes during system idle time to generate file system prefetches. We discuss the implementation, and how the use of existing FreeBSD kernel primitives may be leveraged to provide this through minimal modifications to the underlying operating system. We evaluate the effectiveness of the technique, and improvements that would allow us to realize the potential performance increase. URL http://www.watson.org/~robert/15-712/project/ -- We're still continuing work on this, and have not had a chance to do a full evaluation or wring all of the bugs out. However, I thought people might be interested in taking a look. Our source code will be available in a month or so once we've had a chance to fix a few more things up. This work is based on a paper by F Chang, "Automatic I/O Hint Generation through Speculative Execution", which appeared in Proceedings of the 3rd Symposium on Operating Systems Design and Implementation, February 1999. The basic idea was to generate file system prefetches based on a speculative thread that executed the code ahead of time, and tried to guess what reads would occur. They did this by performing a binary modification to the base program to create and maintain the thread. We wondered if it would not be more efficient and general to implement this in the OS kernel, and did so based on 4.0-CURRENT of FreeBSD (around May). What they had and what we did not have was RAID disk arrays to run their code against: they had far disk bandwidth than we did, although presumably around the same latency. The paper is not great, as it was largely written extremely early in the morning, but I think it gets across the design goals and intent. Once we've revamped the code a little and gotten it to work a bit better, presumably a published paper will turn up somewhere. Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
[Hijacked from cvs-committers and cvs-all] On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote: I observed some kind of denial of service on -STABLE: I was playing with the new nmap and did a 'nmap -sU printfix'. inetd was running as "inetd -l" and started sucking all the CPU time even the nmap had been terminated long ago. What does "sucking all the CPU time" mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I suspect that the latter is true. /var/log/messages file showed zillions of the following lines being added continously: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you "last message repeated X times". Unfortunately, the alternation of the messages makes this impossible. David Malone had a few ideas on "clever" handling of UDP. While what he suggests might help reduce the number of messages you receive under legitimate use, it won't help against DoS, since the sender of packets can simply randomize the origin addresses. Maybe you got an idea... I know exactly why you see what you see when you do what you do. All I can say is "don't do that", because I can't think of a why to cater for what you're doing in a sensible fashion. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, Jul 23, 1999 at 02:29:19PM +0200, Sheldon Hearn wrote: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you "last message repeated X times". Unfortunately, the alternation of the messages makes this impossible. You could turn on wrapping and log them at a level at which syslog will ignore them. I'm not sure how much this would help with inetd chewing CPU time, but... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23 Jul 1999 13:50:45 +0100, David Malone wrote: You could turn on wrapping and log them at a level at which syslog will ignore them. I'm not sure how much this would help with inetd chewing CPU time, but... If, indeed, inetd is really "chewing CPU time". Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: [Hijacked from cvs-committers and cvs-all] On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote: I observed some kind of denial of service on -STABLE: I was playing with the new nmap and did a 'nmap -sU printfix'. inetd was running as "inetd -l" and started sucking all the CPU time even the nmap had been terminated long ago. What does "sucking all the CPU time" mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I suspect that the latter is true. It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. /var/log/messages file showed zillions of the following lines being added continously: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you "last message repeated X times". Unfortunately, the alternation of the messages makes this impossible. David Malone had a few ideas on "clever" handling of UDP. While what he suggests might help reduce the number of messages you receive under legitimate use, it won't help against DoS, since the sender of packets can simply randomize the origin addresses. Maybe you got an idea... I know exactly why you see what you see when you do what you do. All I can say is "don't do that", because I can't think of a why to cater for what you're doing in a sensible fashion. I think, I didn't describe the problem clearly so I will try again :-) 1. I run 'nmap -sU printfix' on the 192.168.17.100 machine. 2. After nmap has finished it shows me the open ports. 3. We wait , e.g. 1 minute 4. inetd, which runs with -l, continues logging to syslogd and never stops. Here is a top snapshot taken one minute later: last pid: 4040; load averages: 0.96, 0.56, 0.29 up 0+06:19:27 14:56:00 36 processes: 2 running, 34 sleeping CPU states: 54.3% user, 0.0% nice, 41.9% system, 3.9% interrupt, 0.0% idle Mem: 8500K Active, 37M Inact, 12M Wired, 3428K Cache, 7592K Buf, 532K Free Swap: 49M Total, 49M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 3748 root 58 0 956K 704K RUN 0:20 44.97% 44.97% inetd 122 root 2 0 848K 576K select 3:10 36.47% 36.47% syslogd 127 root 2 0 1588K 1228K select 0:05 0.00% 0.00% named 200 root 2 0 876K 524K select 0:02 0.00% 0.00% lpd 132 root 2 -52 1236K 732K select 0:02 0.00% 0.00% xntpd In case we start inetd without -l, it doesn't log to syslogd anymore and therefore consumes all the CPU for itself: last pid: 4397; load averages: 1.59, 1.10, 0.55up 0+06:22:14 14:58:47 111 processes: 2 running, 109 sleeping CPU states: 61.2% user, 0.0% nice, 38.0% system, 0.8% interrupt, 0.0% idle Mem: 10M Active, 30M Inact, 14M Wired, 3776K Cache, 7592K Buf, 3688K Free Swap: 49M Total, 49M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 4043 root 104 0 956K 740K RUN 1:33 97.66% 97.61% inetd 122 root 2 0 848K 576K select 3:16 0.00% 0.00% syslogd 127 root 2 0 1588K 1228K select 0:05 0.00% 0.00% named Remember that nmap has finished already a long time ago. I think, inetd is stuck in some loop which can be terminated only by killing and restarting it. -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote: But when inetd is run without -l it get 100%. Are you avoiding my question on purpose? :-) On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: What does "sucking all the CPU time" mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I don't care how the usage is split over syslog and inetd. What I want to know is whether their combined usage of the CPU causes a serious problem for other CPU-bound processes. After all, you _have_ asked the inetd+syslog pair to do a lot of work. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23-Jul-1999 at 13:50:45 +0100, David Malone wrote: On Fri, Jul 23, 1999 at 02:29:19PM +0200, Sheldon Hearn wrote: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you "last message repeated X times". Unfortunately, the alternation of the messages makes this impossible. You could turn on wrapping and log them at a level at which syslog will ignore them. I'm not sure how much this would help with inetd chewing CPU time, but... I think, I expressed myself wrong. Not the logging appears problematic but the fact that inetd seems to be stuck in an endless loop even long time after the nmap has finished. -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Sheldon Hearn [EMAIL PROTECTED] writes:
I know exactly why you see what you see when you do what you do. All I
can say is "don't do that", because I can't think of a why to cater for
what you're doing in a sensible fashion.
I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, Jul 23, 1999 at 03:06:02PM +0200, Andre Albsmeier wrote: It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. Interesting - does it still answer requests during this time? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:09:12 +0200, Sheldon Hearn wrote: On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote: But when inetd is run without -l it get 100%. Are you avoiding my question on purpose? :-) Sorry. The machine wasn't stressed by other programs so it was "the only significant user of CPU and so showed up at close to 100% CPU usage". But when I logged into it to kill and restart inetd the machine was responding very slow. On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: What does "sucking all the CPU time" mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I don't care how the usage is split over syslog and inetd. What I want to know is whether their combined usage of the CPU causes a serious problem for other CPU-bound processes. Yes. After all, you _have_ asked the inetd+syslog pair to do a lot of work. Why? I start nmap, it scans the ports and inetd has for sure a lot of logging work to do. But at some time, the scan is finished but inetd continues to consume CPU time endlessly. Maybe I am just confused and this behaviour is normal ... -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23-Jul-1999 at 14:16:19 +0100, David Malone wrote: On Fri, Jul 23, 1999 at 03:06:02PM +0200, Andre Albsmeier wrote: It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. Interesting - does it still answer requests during this time? Yes. I can still log in via the network and kill and restart inetd. Just found another syslog message (I didn't see it before because it disappeared in all the loge messages): Jul 23 15:20:51 daemon.err printfix inetd[5323]: chargen/udp server failing (looping), service terminated -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23 Jul 1999 14:16:19 +0100, David Malone wrote: But when inetd is run without -l it get 100%. Interesting - does it still answer requests during this time? Yeah. What we really need to know is how many packets inetd actually received. The manpage excerpt that DES showed us indicates that nmap doesn't stop sending packets immediately unless it gets an ICMP message back. We know that inetd doesn't send ICMP messages back. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:16:14 +0200, Dag-Erling Smorgrav wrote:
Sheldon Hearn [EMAIL PROTECTED] writes:
I know exactly why you see what you see when you do what you do. All I
can say is "don't do that", because I can't think of a why to cater for
what you're doing in a sensible fashion.
I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.
Comes in private email. It's about 130KB after which tcpdump crashed with:
zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp
But when I restart tcpdump again (while inetd still is going wild)
it is quiet.
-Andre
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Andre Albsmeier [EMAIL PROTECTED] writes: Comes in private email. It's about 130KB after which tcpdump crashed with: zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp Weird. Very weird. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:35:48 +0200, Dag-Erling Smorgrav wrote: Andre Albsmeier [EMAIL PROTECTED] writes: Comes in private email. It's about 130KB after which tcpdump crashed with: zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp Weird. Very weird. Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. It should be reproducible very easily by running "nmap -sU target_machine" where target_machine has the internal inetd services enabled. I attach my inetd.conf in case it might be interesting (nothing special in it): # $Id: inetd.conf,v 1.33.2.1 1999/07/21 19:28:25 sheldonh Exp $ # # Internet server configuration database # # @(#)inetd.conf 5.4 (Berkeley) 6/30/90 # ftp stream tcp nowait root/usr/libexec/ftpd ftpd telnet stream tcp nowait root/usr/libexec/telnetdtelnetd shell stream tcp nowait root/usr/libexec/rshd rshd login stream tcp nowait root/usr/libexec/rlogindrlogind finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd #exec stream tcp nowait root/usr/libexec/rexecd rexecd #uucpd stream tcp nowait root/usr/libexec/uucpd uucpd #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd # run comsat as root to be able to print partial mailbox contents w/ biff, # or use the safer tty:tty to just print that new mail has been received. #comsat dgram udp waittty:tty /usr/libexec/comsat comsat ntalk dgram udp waittty:tty /usr/libexec/ntalkd ntalkd #tftp dgram udp waitnobody /usr/libexec/tftpd tftpd /tftpboot #bootps dgram udp waitroot/usr/libexec/bootpd bootpd # # "Small servers" -- used to be standard on, but we're more conservative # about things due to Internet security concerns. Only turn on what you # need. # daytime stream tcp nowait rootinternal daytime dgram udp waitrootinternal timestream tcp nowait rootinternal time dgram udp waitrootinternal echostream tcp nowait rootinternal echodgram udp waitrootinternal discard stream tcp nowait rootinternal discard dgram udp waitrootinternal chargen stream tcp nowait rootinternal chargen dgram udp waitrootinternal # # Kerberos authenticated services # #klogin stream tcp nowait root/usr/libexec/rlogindrlogind -k #eklogin stream tcp nowait root/usr/libexec/rlogindrlogind -k -x #kshell stream tcp nowait root/usr/libexec/rshd rshd -k #kipstream tcp nowait root/usr/libexec/kipd kipd # # CVS servers - for master CVS repositories only! # #cvspserver stream tcp nowait root/usr/bin/cvscvs pserver #cvsstream tcp nowait root/usr/bin/cvscvs kserver # # RPC based services (you MUST have portmapper running to use these) # rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd rusersd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.rusersd rpc.rusersd walld/1 dgram rpc/udp wait root /usr/libexec/rpc.rwalld rpc.rwalld #pcnfsd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.pcnfsd rpc.pcnfsd #rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad sprayd/1dgram rpc/udp wait root /usr/libexec/rpc.sprayd rpc.sprayd # # example entry for the optional pop3 server # #pop3 stream tcp nowait root/usr/local/libexec/popper popper # # example entry for the optional imap4 server # #imap4 stream tcp nowait root/usr/local/libexec/imapdimapd # # Return error for all "ident" requests # #auth stream tcp nowait rootinternal # # example entry for the optional ident server # authstream tcp waitkmem:kmem /usr/local/sbin/identd identd -w -t120 # # example entry for the optional qmail MTA # #smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd # # Enable the following two entries to enable samba startup from inetd # (from the Samba documentation). # #netbios-ssn stream tcp nowait root /usr/local/sbin/smbd smbd #netbios-ns dgram udp wait root /usr/local/sbin/nmbd nmbd To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Andre Albsmeier [EMAIL PROTECTED] writes: Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. Weird. I'm unable to reproduce it; my test box responds to UDP queries but does not log them (though it logs TCP queries). I'll update to the latest inetd and try again. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, Jul 23, 1999 at 03:57:19PM +0200, Dag-Erling Smorgrav wrote: Andre Albsmeier [EMAIL PROTECTED] writes: Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. Weird. I'm unable to reproduce it; my test box responds to UDP queries but does not log them (though it logs TCP queries). I'll update to the latest inetd and try again. I can reproduce it using version 1.63, ktracing shows: 3052 inetdCALL sigprocmask(0x1,0x82001) 3052 inetdRET sigprocmask 0 3052 inetdCALL sigprocmask(0x3,0) 3052 inetdRET sigprocmask 532481/0x82001 3052 inetdCALL gettimeofday(0xbfbfd5e4,0) 3052 inetdRET gettimeofday 0 3052 inetdCALL write(0xc,0xbfbfd60c,0x1a) 3052 inetdRET write -1 errno 39 Destination address required 3052 inetdCALL select(0x14,0xbfbfd750,0,0,0) 3052 inetdRET select 2 3052 inetdCALL sigprocmask(0x1,0x82001) 3052 inetdRET sigprocmask 0 3052 inetdCALL sigprocmask(0x3,0) 3052 inetdRET sigprocmask 532481/0x82001 3052 inetdCALL gettimeofday(0xbfbfd6f4,0) 3052 inetdRET gettimeofday 0 3052 inetdCALL write(0xe,0xbfbfd708,0x4) 3052 inetdRET write -1 errno 39 Destination address required 3052 inetdCALL sigprocmask(0x1,0x82001) 3052 inetdRET sigprocmask 0 3052 inetdCALL sigprocmask(0x3,0) 3052 inetdRET sigprocmask 532481/0x82001 It also seems to leave several hung processes around which are serveing disgard and echo. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Alex Zepeda wrote: On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I know a lot of people like the ASUS P2B boards, but I've noticed a tendency for the systems to reset occasionally when plugging in a keyboard. I've seen this with both FreeBSD and NT, so I'm considering it a property of the board. If this is a PS/2 style keyboard, don't plug and unplug them when the host is powered up. The PS/2 style stuf seems to be very sensitive to that sort of thing. If it was a USB keyboard doing that... then that would be odd. Yes, it is a PS/2 keyboard, but these are the only MB's that I have run into this problem with other than some AIX boxes years ago that would blow a fuse when disconnecting the keyboard from a running system. This isn't that big a problem. I only have keyboard installed while building the systems. Thereafter they are serial console only. Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Fri, 23 Jul 1999, Kris Kennaway wrote: On Thu, 22 Jul 1999, Ronald G. Minnich wrote: Are you saying that as an ordinary user I can mount something on top of /tmp, for example? If the vfs.usermount sysctl is 1, and you have appropriate access to the thing you're trying to mount (block device, etc). OK, so let's say it is 1. Let's say I have "appropriate access" to /tmp. I mount my own fs on /tmp. I now have read/write access to everything anyone writes to /tmp. Or, let's say I don't have "appropriate access" to /tmp. Pick some other place. I mount my file system there for my files. Now everyone who wants can look for these user mounts and walk them at will. My private stuff is quite public. User mounts are neat. But user mounts that modify the global name space of the machine are not neat. User mounts should be part of a private name space. But thanks for the note. I just now realized that if I add a private name space to v9fs (which is easy), and then turn on user mounts, user processes can have private name spaces on freebsd! thanks ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
FreeBSD can wait till unified-ipv6 is made available, since: - IPv6 is not that urgent task and - it will be messy if FreeBSD integrates KAME first, then switch to unified-ipv6. Both of these remain true. I certainly see and understand the "marketing value" of having an early IPv6 implementation, but I don't see this as mainstream interest so much as interest on the part of various researchers and early-adopters, all of which can go to the KAME site and grab the patches to 3.2-stable if they want to play now, today. If we haven't done a good enough job of making that clear and are suffering from defections to other *BSDs because of this, then we just need to get the word out better. :-) It's not like nothing is available at all, simply not "officially" and officially we have an obligation to pick the best, most technically correct route, something which I believe we have already done. Two merges sounds like a nightmare, and we're not suffering from NetBSD's release constraints here. :) - We need some more FreeBSD commit privs for other KAME guys. (this is a easy part) Yes, this is certainly the easy part. As always, just let us know if there's anything we can do. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
I've found the problem - it looks like a bug in the code for matching internal service names to /etc/service names. The code says: if ((bi-bi_socktype == sep-se_socktype strcmp(bi-bi_service, sep-se_service) == 0) || matchservent(bi-bi_service, sep-se_service, sep-se_proto)) It should probably say: if (bi-bi_socktype == sep-se_socktype ((strcmp(bi-bi_service, sep-se_service) == 0) || matchservent(bi-bi_service, sep-se_service, sep-se_proto))) It was running the tcp service instead of the udp service. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
:"David E. Cross" wrote: : : Well, I just -STABLED the server to see if it fixed it, but I was certainly : running out. the server had only 3000-ish mbuf chains, and it would go through : them all in a day. : : Well, have you tried increasing the number of available mbufs and see if :you reach a point of stability? Assuming you have enough physical ram you :could do 15k mbufs on -Stable without a problem. Check LINT for the :nmbclusters option if you need help with it. : :Good luck, : :Doug Well, the cache shouldn't eat up *that* many mbufs! The problem is likely to be real. There is a good chance the leakage is in nfs_serv.c, which I fixed for -current. I do not think those changes have been backported to -STABLE. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
: lot of things FreeBSD is 'better' at, and a lot of those : things can easily fluctuate on a daily or weekly basis," : said Fuller, who maintains a Linux vs BSD Web page. : "Thus, any definitive narrow statement that can be made : is usually obsolete before anyone hears it.". : : Perfect! : : Thank you, my fans! Please leave your monetary contributions in the hat : on your way out; : :Where is the hat? I saw Julian running off with it a couple of e-mails :ago. : :Nick Do I get a discount for having the same first name? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
On Fri, Jul 23, 1999 at 09:06:01AM -0700, Matthew Dillon wrote: There is a good chance the leakage is in nfs_serv.c, which I fixed for -current. I do not think those changes have been backported to -STABLE. julian 1999/06/30 15:05:20 PDT Modified files:(Branch: RELENG_3) sys/nfs nfs_serv.c nfs_subs.c nfs_syscalls.c nfsm_subs.h Log: MFC: Bring in NFS cleanups by Matt. . . . David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
: : I do not think those changes have been backported to -STABLE. : :julian 1999/06/30 15:05:20 PDT : : Modified files:(Branch: RELENG_3) :sys/nfs nfs_serv.c nfs_subs.c nfs_syscalls.c : nfsm_subs.h : Log: : MFC: Bring in NFS cleanups by Matt. :. : David. Whup! So much for that idea! -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
boot problems (fwd)
After the System Halted error, i get another error message. "DAC960: system BIOS fatal Error - INT 15H function 87H Copy extended Memory ) failed." -- Forwarded message -- Date: Fri, 23 Jul 1999 10:54:52 + (GMT) From: Andrew Willis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: boot problems Perhaps someone can help me with this...I just bought a new computer. (2) pII 400 chips (1) Intel 1440GX (Dual CPU PIII) motherboard (2) 256 MB SDRAM (1) Mylex Raid 960 model 150 adapter (3) Quantum Atlas IV 9.1 GB Ultra2 SCSI (1) CDROM 40x (1) Floppy 1.44 (1) Server case with redundant power supply I wanted to install FreeBSD as a web server, but every time i try and boot off the first install disk kern.flp 3.2-RELEASE, the machine halts with a hex dump. The machine has an onboard scsi (Adaptec AIC-7896). OpenBSD 2.5 and FreeBSD 2.2.8 will boot, but they dont recognize the disk controller. I was told FreeBSD supports the Mylex raid. Someone please help me with this...I have tried two different floppies as well. Im using dd if=kern.flp of=/dev/fd0 on a sun ultra 5 to make the disk image. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
In message [EMAIL PROTECTED] Dirk GOUDERS writes: : My sound card is a SBPCI128 by Creative Labs. Nice card... I have one too. Plays mp3 well :-). Also plays video sound well and xgalaga works with sound!... NOTE: The SBPC64 doesn't work without an external patch... Be careful. : I only used the card with FreeBSD 3.2 I've used mine on -CURRENT for about 9 months or so, but part of that time I had to get the driver from somewhere else. : The only line I had to add to my kernel config file was: : : device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 : : (This causes a message "pcm0 not found" to appear at boot time but : just ignoring it seems to be o.k. - allthough I would prefer : not to see it, at all.) device pcm0 does the trick for me. I think that will work in 3.2. -current fixes the problem with psm0 not found. : I had to build the audio device snd1: : : # cd /dev : # sh MKDEV snd1 When you upgrade to 4.0 or -current, you'll have to undo that stuff... : and to use the mixer to set the volume to another value than 0. : I use the following script /usr/local/etc/rc.d/mixer.sh at boot time: : : #!/bin/sh : /usr/sbin/mixer vol 60:60 pcm 60:60 cd 60:60 Cool. I've always brought up xmixer to do this Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
Matthew Dillon wrote: : lot of things FreeBSD is 'better' at, and a lot of those : things can easily fluctuate on a daily or weekly basis," : said Fuller, who maintains a Linux vs BSD Web page. : "Thus, any definitive narrow statement that can be made : is usually obsolete before anyone hears it.". : : Perfect! : : Thank you, my fans! Please leave your monetary contributions in the hat : on your way out; : :Where is the hat? I saw Julian running off with it a couple of e-mails :ago. He was going to cut off the point and use it as a funnel into his BSD Toy fund. Or was that the wrong hat (or the wrong Julian?) Do I get a discount for having the same first name? Nope, you get charged double for attempting to share in the Matt-light. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
At 10:35 AM 7/23/99 -0400, Adrian Filipi-Martin wrote: On Thu, 22 Jul 1999, Alex Zepeda wrote: On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I know a lot of people like the ASUS P2B boards, but I've noticed a tendency for the systems to reset occasionally when plugging in a keyboard. I've seen this with both FreeBSD and NT, so I'm considering it a property of the board. If this is a PS/2 style keyboard, don't plug and unplug them when the host is powered up. The PS/2 style stuf seems to be very sensitive to that sort of thing. If it was a USB keyboard doing that... then that would be odd. Yes, it is a PS/2 keyboard, but these are the only MB's that I have run into this problem with other than some AIX boxes years ago that would blow a fuse when disconnecting the keyboard from a running system. This isn't that big a problem. I only have keyboard installed while building the systems. Thereafter they are serial console only. I've seen it on an SBC (with a KB connector on board). it IS a problem if they want to do maintanence without bringing down the system. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
|At 10:35 AM 7/23/99 -0400, Adrian Filipi-Martin wrote: |On Thu, 22 Jul 1999, Alex Zepeda wrote: | | On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: | |I know a lot of people like the ASUS P2B boards, but I've noticed a | tendency for the systems to reset occasionally when plugging in a |keyboard. | I've seen this with both FreeBSD and NT, so I'm considering it a property | of the board. | | If this is a PS/2 style keyboard, don't plug and unplug them when the host | is powered up. The PS/2 style stuf seems to be very sensitive to that | sort of thing. If it was a USB keyboard doing that... then that would be | odd. | | Yes, it is a PS/2 keyboard, but these are the only MB's that I have |run into this problem with other than some AIX boxes years ago that would |blow a fuse when disconnecting the keyboard from a running system. | | This isn't that big a problem. I only have keyboard installed |while building the systems. Thereafter they are serial console only. | |I've seen it on an SBC (with a KB connector on board). it IS a problem if |they want to do maintanence without bringing down the system. blush I fried two P6 ASUS motherboards this way, sorta along these lines, "hmm, keyboard seems to be dead, maybe try it in this machine" Russell | |Dennis | | |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
Missing ld.so in 3.2?
Greetings, I have a 3.2 install from CD-ROM and I am trying to run a commerical program, i.e. I don't have the source, and it is giving me the following error: [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed header from script. Bad header=Couldn't open /usr/libexec/ld.so This is an error in the applications error log. I looked on my 3.1 box and there is a file /usr/libexec/ld.so but on my 3.2 box the file does not exist. Should it? Does the company of the software have to recompile for 3.2? Any insight would be greatly appreciated. Thank you, Matthew Hagerty To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
blush I fried two P6 ASUS motherboards this way, sorta along these lines, "hmm, keyboard seems to be dead, maybe try it in this machine" We did the same thing on two Asus P6 MB as well! We replaced the fuse near the keyboard and both motherboards are working perfectly now. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing ld.so in 3.2?
On Fri, 23 Jul 1999, Matthew Hagerty wrote: Greetings, I have a 3.2 install from CD-ROM and I am trying to run a commerical program, i.e. I don't have the source, and it is giving me the following error: [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed header from script. Bad header=Couldn't open /usr/libexec/ld.so This is an error in the applications error log. I looked on my 3.1 box and there is a file /usr/libexec/ld.so but on my 3.2 box the file does not exist. Should it? Does the company of the software have to recompile for 3.2? Any insight would be greatly appreciated. Thank you, Matthew Hagerty I think u must read following: http://www.freebsd.org/releases/3.2R/errata.html Rgdz, Osokin Sergey aka oZZ, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New patch fpr uipc_socket.c - any objections?
Object now or forever hold your peace! Patch included again for
reference.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: uipc_socket.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.60
diff -u -r1.60 uipc_socket.c
--- uipc_socket.c 1999/06/17 23:54:47 1.60
+++ uipc_socket.c 1999/07/22 23:08:38
@@ -413,7 +413,8 @@
register struct mbuf *m;
register long space, len, resid;
int clen = 0, error, s, dontroute, mlen;
- int atomic = sosendallatonce(so) || top;
+ int atomic = sosendallatonce(so) || top;/* required atomicy */
+ int try_atomic = atomic;/* requested atomicy */
if (uio)
resid = uio-uio_resid;
@@ -518,6 +519,7 @@
mlen = MCLBYTES;
len = min(min(mlen, resid), space);
} else {
+ try_atomic = 1; /* try to optimize */
nopages:
len = min(min(mlen, resid), space);
/*
@@ -541,7 +543,7 @@
top-m_flags |= M_EOR;
break;
}
- } while (space 0 atomic);
+ } while (space 0 try_atomic);
if (dontroute)
so-so_options |= SO_DONTROUTE;
s = splnet(); /* XXX */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
Well, backing out now is not really an option... But given my past history with NFS, and knowledge of this site I think I have a fair idea where the leak is... I think it is in the nfsv3 "commit" handler. Why do I think this? Simple, this problem started when a user started running a large job on out origin 2k, prior to that our server had been up for 30-ish days sans any problems, since his start it requires a boot-a-day (mbuf clusters are up to 8k). Also supporting this is the fact that the clusters are used at a fairly constant rate. Now (following that hunch), I did a tcpdump against that host for tcp traffic, and noticed a fairly steady stream of "commit" NFS traffic. I realize none of this is a smoking gun, but that is where my "hunch" lies. How is mbuf cluster cleanyup done? If I knew I might have a shot in heck at locating this problem. BTW: updated netstat -m for the machine: 4855/5344 mbufs in use: 4848 mbufs allocated to data 7 mbufs allocated to packet headers 4774/4850/8704 mbuf clusters in use (current/peak/max) 10368 Kbytes allocated to network (97% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines That's alot of buffer ;) -- David Cross | email: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rndcontrol and SMP
[EMAIL PROTECTED] wrote:
! warn("");
That should (probably) be `warn(NULL);', otherwise you'd get something
like `rndcontrol: : error' rather than the (probably) desired
`rndcontrol: error'. (Or so my simple test showed, at least...)
--
Ben Smithurst| PGP: 0x99392F7D
[EMAIL PROTECTED] | key available from keyservers and
| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
mbuf leakage
Well, it doesn't appear to be commit() :(. Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters? I have a feeling that seeing the data in them would speak volumes of information. Preferably a way to see them without DDB/panic would be ideal. -- David Cross | email: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rndcontrol and SMP
/* * XXX the data is 16-bit due to a historical botch, so we use * magic 16's instead of ICU_LEN and can't support 24 interrupts * under SMP. */ intr = *(int16_t *)data; if (cmd != MEM_RETURNIRQ (intr 0 || intr = 16)) return (EINVAL); What is needed to make this support a more sensible number of IRQs? Mainly changing the ioctl and its clients (rndcontrol only?) to supply more bits. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
deny ktrace without read permissions?
PR bin/3546 asks that `ktrace(1)' not be allowed on files that do not have read permissions for the user attempting to execute them. The intent of this change is to prevent a user from seeing how an executable with '--x--x--x' perms works by ktrace'ing its execution. My question to the -hackers is: is this a useful semantic? Would it break anything if added? A patch to "/sys/kern/kern_exec.c" that adds this functionality is attached for those who would like to play with the change. Regards, Koshy Index: /sys/kern/kern_exec.c === RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.99 diff -u -r1.99 kern_exec.c --- kern_exec.c 1999/04/27 11:15:55 1.99 +++ kern_exec.c 1999/07/24 10:35:09 @@ -26,6 +26,8 @@ * $Id: kern_exec.c,v 1.99 1999/04/27 11:15:55 phk Exp $ */ +#include "opt_ktrace.h" + #include sys/param.h #include sys/systm.h #include sys/sysproto.h @@ -48,6 +50,9 @@ #include sys/sysctl.h #include sys/vnode.h #include sys/buf.h +#ifdef KTRACE +#include sys/ktrace.h +#endif #include vm/vm.h #include vm/vm_param.h @@ -650,6 +655,7 @@ struct vnode *vp = imgp-vp; struct vattr *attr = imgp-attr; int error; + int mode; /* Get file attributes */ error = VOP_GETATTR(vp, attr, p-p_ucred, p); @@ -677,9 +683,14 @@ return (ENOEXEC); /* -* Check for execute permission to file based on current credentials. +* Check for execute permission to file based on current credentials. */ - error = VOP_ACCESS(vp, VEXEC, p-p_ucred, p); + mode = VEXEC; +#ifdef KTRACE + if (p-p_traceflag KTRFAC_MASK) + mode |= VREAD; +#endif + error = VOP_ACCESS(vp, mode, p-p_ucred, p); if (error) return (error); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
On Friday, 23 July 1999 at 22:12:29 -0700, [EMAIL PROTECTED] wrote: PR bin/3546 asks that `ktrace(1)' not be allowed on files that do not have read permissions for the user attempting to execute them. The intent of this change is to prevent a user from seeing how an executable with '--x--x--x' perms works by ktrace'ing its execution. My question to the -hackers is: is this a useful semantic? Yes, I think so. Would it break anything if added? Not that I can think of. But that doesn't mean anything. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
In article 19990722111605.c49...@palmerharvey.co.uk, Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Concerning masses of weird shared objects, you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
usb keyboard setup -or- HELP!
hi, i'm running 4.0-current on a dual p2-333 box. i run X, and am looking for help in setting up a usb keyboard for use with FreeBSD/Xfree86. if anyone has this running, i could use the help in setting it up. also, this keyboard has a ps2 mouse connector. does the mouse get recognized as a usb mouse? jim -- All opinions expressed are mine, if you| I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered! - #1, The Prisoner -- Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
David E. Cross wrote: Well, I just -STABLED the server to see if it fixed it, but I was certainly running out. the server had only 3000-ish mbuf chains, and it would go through them all in a day. Well, have you tried increasing the number of available mbufs and see if you reach a point of stability? Assuming you have enough physical ram you could do 15k mbufs on -Stable without a problem. Check LINT for the nmbclusters option if you need help with it. Good luck, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, 22 Jul 1999, John Polstra wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. This means you can't add in a new module without recompiling the static library, correct? That seems to defeat the purpose of PAM being modular for the static case :-( Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SURVEY: Sound cards that work under FreeBSD
Here's the information about the sound card I am working with: 1) The sound card make and model/chipset. Please be as specific as you can with board rev numbers if possible. Please include wether the card is ISA or PCI. My sound card is a SBPCI128 by Creative Labs. 2) FreeBSD version(s) it was tested with. List *all* versions of FreeBSD for which you can verify that the sound card does/doesn't work (don't include -BETA or -SNAP releases but dates on -STABLE and -CURRENT branches are welcome). I only used the card with FreeBSD 3.2 3) Appropriate lines from your kernel config file / PNP setup. i.e. what did you have to do to get this card working? Did you need patches not committed to a particular branch (if so URLs would be welcome)? Do you use OSS drivers instead? The only line I had to add to my kernel config file was: device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 (This causes a message pcm0 not found to appear at boot time but just ignoring it seems to be o.k. - allthough I would prefer not to see it, at all.) 4) Sample dmesg output for properly configured device. Show the world what boot messages relate to the device after properly configured. These are the messages that appear previous to the message pcm0 not found: es1: AudioPCI ES1370 rev 0x01 int a irq 5 on pci0.9.0 pcm1: using I/O space register mapping at 0xe400 5) Miscellaneous notes. State anything not obvious to the casual FreeBSD user. Good examples might be, volume is 0 by default, use mixer(1) to adjust at boot time, or sh MAKEDEV snd1 for the 1st device, not snd0. I had to build the audio device snd1: # cd /dev # sh MKDEV snd1 and to use the mixer to set the volume to another value than 0. I use the following script /usr/local/etc/rc.d/mixer.sh at boot time: #!/bin/sh /usr/sbin/mixer vol 60:60 pcm 60:60 cd 60:60 6) Is it OK to publish your e-mail address / name as the contributor of this information? You may type in an anti-spam version of your e-mail address below if you would like that option instead. Well, I guess, I should not be listed as the contributor, because I catched these information out of the mailing lists and would prefer the original poster to appear as the contributor. Cheers, Dirk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD: the stealth OS?
There's a lot of things that Linux is 'better' at, and a lot of things FreeBSD is 'better' at, and a lot of those things can easily fluctuate on a daily or weekly basis, said Fuller, who maintains a Linux vs BSD Web page. Thus, any definitive narrow statement that can be made is usually obsolete before anyone hears it.. Perfect! Thank you, my fans! Please leave your monetary contributions in the hat on your way out; Where is the hat? I saw Julian running off with it a couple of e-mails ago. Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I've had great results with the Tyan 1836DLUAN/Thunder 100's. I've got several boxes with 1GB of RAM and dual 450's humming along. For comparison one system with less memory and a SuperMicro board but identical system software has had a couple of wierd spontaneous reboots over the last few months. Cool... Is 1GB of ram really needed? We used to run a 64 meg system then 128 meg and then 384 meg, it doesn't seem to do much even for a heavily loaded ISP Server. Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. The real problem was poor CGI programming. I made them fix them. Now it toodles along with ridiculously low loads. All the websites and the mysql db fit in core. ;-) That's true too Seems like FreeBSD can handle a real high load without problems... Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: usb keyboard setup -or- HELP!
Check out the ukbd man page man 4 ukbd It should give you all the information you need. The PS/2 connector should be recognised by the ums driver and it should give you a mouse that you can attach as described in the ums man page. Let me know if this does not work for you, so we can improve the man pages. Thanks. Nick On Fri, 23 Jul 1999, Jim Bryant wrote: hi, i'm running 4.0-current on a dual p2-333 box. i run X, and am looking for help in setting up a usb keyboard for use with FreeBSD/Xfree86. if anyone has this running, i could use the help in setting it up. also, this keyboard has a ps2 mouse connector. does the mouse get recognized as a usb mouse? jim -- All opinions expressed are mine, if you| I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered! - #1, The Prisoner -- Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
* ito...@iijlab.net (ito...@iijlab.net) [990722 16:17]: Are you just teasing or are you serious? Well, according to what was discussed earlier he is serious. But from prolonged exposure to the kame lists I (think I) know that the FreeBSD ipv6 stuff is only available for 3.x and below. We (KAME) are using 3.2-RELEASE and 2.2.8-RELEASE because we can't base our IPv6 development on top of moving target. FreeBSD 3.x-STABLE and 4.x are moving target (which moves very quickly) and are unusable as base version for us - if we need to chase two moving things (IPv6 and FreeBSD) we are doomed. Problem being is that the 2.2.x branch has been declared obsolete and dead by the Project. If serious development work is being done CURRENT has always been the targetted platform. But let's not nitpick about decissions make months earlier. However, 3.2-STABLE isn't that fast moving forward, and I doubt, based on earlier discussions about touching the 3.x branch, that Jordan will allow IPv6 to be entered into the 3.x branch (however TPTB may judge otherwise). So 4.x seems like the only alternative left... And I am still working on that =) There has been NRL/INRIA/KAME integration work going on (basically to avoid 4 BSDs and 3 IPv6 = 12 choices nightmare by making one IPv6 stack). There are, mainly, some (or too many) management issues there. We will be resolving management issues issue very soon, hopefully by next week. That's good new ITOJUN-san, but I hope you can understand that after seeing OpenBSD deploy IPv6 and NetBSD-CURRENT getting the IPv6 code merged by you, that FreeBSD (read the userbase/developers) is anxious to also incorporate this. There's incomplete unified codebase there, which is not very ready for public consumption. Anyway please hold till the managment issue is resolved, I believe I can give you a good news. Let me ask one question: if a few of us got the 3.x kit of kame up to 4.x level and it got all commited would it make the `merged' stack easier to integrate into CURRENT or does the stack-project prefer to use a clean codebase? I myself think the first, which allows our driver writers time to adjust to IPv6 changes, get a lot of still-present bugs out and basically restabilize the system before the next IPv6 changes. Not to mention allow people to test/work with IPv6 already. I would love to hear your reactions to the above, kind regards, -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, Jul 22, 1999 at 10:58:59PM -0700, John Polstra wrote: In article 19990722111605.c49...@palmerharvey.co.uk, Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Ooh! Cunning! Concerning masses of weird shared objects, you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. Very right. I didn't say it was a bad thing, just confused me for a while when I first saw it... However, I still (personally) prefer the idea of a filesystem interface... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
We (KAME) are using 3.2-RELEASE and 2.2.8-RELEASE because we can't base our IPv6 development on top of moving target. FreeBSD 3.x-STABLE and 4.x are moving target (which moves very quickly) and are unusable as base version for us - if we need to chase two moving things (IPv6 and FreeBSD) we are doomed. Problem being is that the 2.2.x branch has been declared obsolete and dead by the Project. If serious development work is being done CURRENT has always been the targetted platform. But let's not nitpick about decissions make months earlier. However, 3.2-STABLE isn't that fast moving forward, and I doubt, based on earlier discussions about touching the 3.x branch, that Jordan will allow IPv6 to be entered into the 3.x branch (however TPTB may judge otherwise). So 4.x seems like the only alternative left... I can't tell KAME users like: Oh, if you would like to apply KAME diffs you'll need to fetch FreeBSD 4.x of June 1st. KAME needs to stick to x.y-RELEASE either, KAME have no choice anyways. And I am still working on that =) Thanks for the effort! There has been NRL/INRIA/KAME integration work going on (basically to avoid 4 BSDs and 3 IPv6 = 12 choices nightmare by making one IPv6 stack). There are, mainly, some (or too many) management issues there. We will be resolving management issues issue very soon, hopefully by next week. That's good new ITOJUN-san, but I hope you can understand that after seeing OpenBSD deploy IPv6 and NetBSD-CURRENT getting the IPv6 code merged by you, that FreeBSD (read the userbase/developers) is anxious to also incorporate this. I talked with c...@freebsd.org several times about IPv6/IPsec integration, and the reaction was that: FreeBSD can wait till unified-ipv6 is made available, since: - IPv6 is not that urgent task and - it will be messy if FreeBSD integrates KAME first, then switch to unified-ipv6. (making a big change twice for IPv6 is questionable route) So we are in the current situation. (or maybe I was not pushing hard enough) NetBSD merged in KAME code last month, because NetBSD will have feature freeze for 1.5 soon and needed IPv6 code earlier than that. If I miss 1.5, it will not be able to be merged until 1.6 (planned to be sometime late 2000, I heard). NetBSD will be switching to unified codebase whenever it is made available (so NetBSD decided to make a big change twice). There's incomplete unified codebase there, which is not very ready for public consumption. Anyway please hold till the managment issue is resolved, I believe I can give you a good news. Let me ask one question: if a few of us got the 3.x kit of kame up to 4.x level and it got all commited would it make the `merged' stack easier to integrate into CURRENT or does the stack-project prefer to use a clean codebase? I myself think the first, which allows our driver writers time to adjust to IPv6 changes, get a lot of still-present bugs out and basically restabilize the system before the next IPv6 changes. Not to mention allow people to test/work with IPv6 already. Here's my question: how much patch rejection you saw when you tried to apply KAME/FreeBSD32 patch onto 4.0? Were there many of these, or very few? If they are very few, and c...@freebsd is okay, I think KAME can be merged into 4.0 tree first, then FreeBSD can switch from KAME to unified whenever it becomes ready (just like NetBSD does). Hopefully KAME and unified-ipv6 will not be that different, except for dual-stack tcp part (KAME code used separate tcp4/tcp6 for a long time, due to maintenance and stability reasons. The way unified code does dual-stack tcp is different from what KAME does). Userland part can be reused without trouble. There are, however, several drawbacks in doing that: - Now we have multiple KAME/FreeBSD[34] repository, one is in KAME site and one is in freefall.freebsd.org. Synchronizing those tree is a big problem. KAME already have problems synchronizing code between platforms we support, the merge will increase the problem. - Manpower issues. We need to continue providing KAME/FreeBSD32 anyways, for people who wants more stable IPv6/IPsec systems. We can't just tell everybody to switch to 4.0 and chase FreeBSD-current. - We need some more FreeBSD commit privs for other KAME guys. (this is a easy part) - again, two big changes for IPv6? Impacts on IPv4 stability? itojun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: InterMezzo: Project for kernel/FS hackers
On Thu, 22 Jul 1999, Nik Clayton wrote: Hi chaps, Not entirely sure which list to post this too, so I figured that -hackers was probably most appropriate. Has anyone had the chance to look at InterMezzo, website at http://www.inter-mezzo.org/ It's main claim to fame is that it allows disconnected operation. For example, you could have a server export a home directory to a laptop, then unplug the laptop from the network, and go and edit/add/delete files from the home directory stored on the laptop. When the laptop is then plugged back in to the network, the filesystem automatically (as far as possible) integrates the changes). Coda (which already has a FreeBSD port) also does this, as well as a few other things. However, Coda is much more heavyweight than InterMezzo, and therefore easier to understand -- in particular, Coda seems to have (according to one of the Coda developers) a marked preference for exporting whole filesystems, InterMezzo allows you to export individual directory trees. Anyway, if any aspiring kernel hackers are looking for a project, that might be a fun one. The only implementation at the moment is for Linux. Cheers, What I'd actually like to see is a port of Inter-mezzo to use the Arla kernel module, which is far more portable/etc, and is also under a BSD license (both Coda and Inter-mezzo are under GPL). I have worked a fair amount with the Arla module to build some user-land file system code, but have no experience with Inter-mezzo. I do have experience with the Coda module, and can say they are quite similar (although the Arla code seems more thread-aware and RPC-like). I have hopes that we can integrate the Arla module into the base FreeBSD distribution, as OpenBSD has done, as it is looking quite stable and makes userfs programming a lot easier. OpenBSD has also integrated the Arla userland support for AFS, which might also be nice to integrate into the base distribution at some point, but is perhaps less useful than integrating the kernel module as the userland code can easily be made a package. As to your comments on Coda: Coda requires custom storage on the server, and cannot export a regular file system. I'm not sure how Inter-Mezzo handles these things: they might require the storage of log/version information on the server somewhere to aid in reintegrating disconnected changes, but again I don't know all that much about it. What I do know is that Coda desperately requires simplification and a fresh code base, so it seems like a step forwards. :-) Robert N M Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
As Alex Zepeda wrote ... On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I know a lot of people like the ASUS P2B boards, but I've noticed a tendency for the systems to reset occasionally when plugging in a keyboard. I've seen this with both FreeBSD and NT, so I'm considering it a property of the board. If this is a PS/2 style keyboard, don't plug and unplug them when the host is powered up. The PS/2 style stuf seems to be very sensitive to that PS/2 or DIN plug, does not matter. [Un]plugging keyboards is a bad idea on a live system. I've seen keyboard fuses (on the mainboard) blown etc And that would be the most benificial of the possible breakage you can get yourself into. Wilko -- | / 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
Paper: Kernel-Supported Speculative Process Execution for Transparent File System Prefetching
-- Title Kernel-Supported Speculative Process Execution for Transparent File System Prefetching CMU 15-712 Software Systems Authors Ted Pham and Robert Watson Date May 7, 1999 Abstract This paper explores the feasibility of an operating system kernel performing speculative execution of user processes during system idle time to generate file system prefetches. We discuss the implementation, and how the use of existing FreeBSD kernel primitives may be leveraged to provide this through minimal modifications to the underlying operating system. We evaluate the effectiveness of the technique, and improvements that would allow us to realize the potential performance increase. URL http://www.watson.org/~robert/15-712/project/ -- We're still continuing work on this, and have not had a chance to do a full evaluation or wring all of the bugs out. However, I thought people might be interested in taking a look. Our source code will be available in a month or so once we've had a chance to fix a few more things up. This work is based on a paper by F Chang, Automatic I/O Hint Generation through Speculative Execution, which appeared in Proceedings of the 3rd Symposium on Operating Systems Design and Implementation, February 1999. The basic idea was to generate file system prefetches based on a speculative thread that executed the code ahead of time, and tried to guess what reads would occur. They did this by performing a binary modification to the base program to create and maintain the thread. We wondered if it would not be more efficient and general to implement this in the OS kernel, and did so based on 4.0-CURRENT of FreeBSD (around May). What they had and what we did not have was RAID disk arrays to run their code against: they had far disk bandwidth than we did, although presumably around the same latency. The paper is not great, as it was largely written extremely early in the morning, but I think it gets across the design goals and intent. Once we've revamped the code a little and gotten it to work a bit better, presumably a published paper will turn up somewhere. Robert N M Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
[Hijacked from cvs-committers and cvs-all] On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote: I observed some kind of denial of service on -STABLE: I was playing with the new nmap and did a 'nmap -sU printfix'. inetd was running as inetd -l and started sucking all the CPU time even the nmap had been terminated long ago. What does sucking all the CPU time mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I suspect that the latter is true. /var/log/messages file showed zillions of the following lines being added continously: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you last message repeated X times. Unfortunately, the alternation of the messages makes this impossible. David Malone had a few ideas on clever handling of UDP. While what he suggests might help reduce the number of messages you receive under legitimate use, it won't help against DoS, since the sender of packets can simply randomize the origin addresses. Maybe you got an idea... I know exactly why you see what you see when you do what you do. All I can say is don't do that, because I can't think of a why to cater for what you're doing in a sensible fashion. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, Jul 23, 1999 at 02:29:19PM +0200, Sheldon Hearn wrote: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you last message repeated X times. Unfortunately, the alternation of the messages makes this impossible. You could turn on wrapping and log them at a level at which syslog will ignore them. I'm not sure how much this would help with inetd chewing CPU time, but... David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23 Jul 1999 13:50:45 +0100, David Malone wrote: You could turn on wrapping and log them at a level at which syslog will ignore them. I'm not sure how much this would help with inetd chewing CPU time, but... If, indeed, inetd is really chewing CPU time. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: [Hijacked from cvs-committers and cvs-all] On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote: I observed some kind of denial of service on -STABLE: I was playing with the new nmap and did a 'nmap -sU printfix'. inetd was running as inetd -l and started sucking all the CPU time even the nmap had been terminated long ago. What does sucking all the CPU time mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I suspect that the latter is true. It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. /var/log/messages file showed zillions of the following lines being added continously: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you last message repeated X times. Unfortunately, the alternation of the messages makes this impossible. David Malone had a few ideas on clever handling of UDP. While what he suggests might help reduce the number of messages you receive under legitimate use, it won't help against DoS, since the sender of packets can simply randomize the origin addresses. Maybe you got an idea... I know exactly why you see what you see when you do what you do. All I can say is don't do that, because I can't think of a why to cater for what you're doing in a sensible fashion. I think, I didn't describe the problem clearly so I will try again :-) 1. I run 'nmap -sU printfix' on the 192.168.17.100 machine. 2. After nmap has finished it shows me the open ports. 3. We wait , e.g. 1 minute 4. inetd, which runs with -l, continues logging to syslogd and never stops. Here is a top snapshot taken one minute later: last pid: 4040; load averages: 0.96, 0.56, 0.29 up 0+06:19:27 14:56:00 36 processes: 2 running, 34 sleeping CPU states: 54.3% user, 0.0% nice, 41.9% system, 3.9% interrupt, 0.0% idle Mem: 8500K Active, 37M Inact, 12M Wired, 3428K Cache, 7592K Buf, 532K Free Swap: 49M Total, 49M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 3748 root 58 0 956K 704K RUN 0:20 44.97% 44.97% inetd 122 root 2 0 848K 576K select 3:10 36.47% 36.47% syslogd 127 root 2 0 1588K 1228K select 0:05 0.00% 0.00% named 200 root 2 0 876K 524K select 0:02 0.00% 0.00% lpd 132 root 2 -52 1236K 732K select 0:02 0.00% 0.00% xntpd In case we start inetd without -l, it doesn't log to syslogd anymore and therefore consumes all the CPU for itself: last pid: 4397; load averages: 1.59, 1.10, 0.55up 0+06:22:14 14:58:47 111 processes: 2 running, 109 sleeping CPU states: 61.2% user, 0.0% nice, 38.0% system, 0.8% interrupt, 0.0% idle Mem: 10M Active, 30M Inact, 14M Wired, 3776K Cache, 7592K Buf, 3688K Free Swap: 49M Total, 49M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 4043 root 104 0 956K 740K RUN 1:33 97.66% 97.61% inetd 122 root 2 0 848K 576K select 3:16 0.00% 0.00% syslogd 127 root 2 0 1588K 1228K select 0:05 0.00% 0.00% named Remember that nmap has finished already a long time ago. I think, inetd is stuck in some loop which can be terminated only by killing and restarting it. -Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote: But when inetd is run without -l it get 100%. Are you avoiding my question on purpose? :-) On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: What does sucking all the CPU time mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I don't care how the usage is split over syslog and inetd. What I want to know is whether their combined usage of the CPU causes a serious problem for other CPU-bound processes. After all, you _have_ asked the inetd+syslog pair to do a lot of work. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23-Jul-1999 at 13:50:45 +0100, David Malone wrote: On Fri, Jul 23, 1999 at 02:29:19PM +0200, Sheldon Hearn wrote: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you last message repeated X times. Unfortunately, the alternation of the messages makes this impossible. You could turn on wrapping and log them at a level at which syslog will ignore them. I'm not sure how much this would help with inetd chewing CPU time, but... I think, I expressed myself wrong. Not the logging appears problematic but the fact that inetd seems to be stuck in an endless loop even long time after the nmap has finished. -Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Sheldon Hearn sheld...@uunet.co.za writes:
I know exactly why you see what you see when you do what you do. All I
can say is don't do that, because I can't think of a why to cater for
what you're doing in a sensible fashion.
I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, Jul 23, 1999 at 03:06:02PM +0200, Andre Albsmeier wrote: It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. Interesting - does it still answer requests during this time? David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:09:12 +0200, Sheldon Hearn wrote: On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote: But when inetd is run without -l it get 100%. Are you avoiding my question on purpose? :-) Sorry. The machine wasn't stressed by other programs so it was the only significant user of CPU and so showed up at close to 100% CPU usage. But when I logged into it to kill and restart inetd the machine was responding very slow. On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: What does sucking all the CPU time mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I don't care how the usage is split over syslog and inetd. What I want to know is whether their combined usage of the CPU causes a serious problem for other CPU-bound processes. Yes. After all, you _have_ asked the inetd+syslog pair to do a lot of work. Why? I start nmap, it scans the ports and inetd has for sure a lot of logging work to do. But at some time, the scan is finished but inetd continues to consume CPU time endlessly. Maybe I am just confused and this behaviour is normal ... -Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23-Jul-1999 at 14:16:19 +0100, David Malone wrote: On Fri, Jul 23, 1999 at 03:06:02PM +0200, Andre Albsmeier wrote: It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. Interesting - does it still answer requests during this time? Yes. I can still log in via the network and kill and restart inetd. Just found another syslog message (I didn't see it before because it disappeared in all the loge messages): Jul 23 15:20:51 daemon.err printfix inetd[5323]: chargen/udp server failing (looping), service terminated -Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23 Jul 1999 14:16:19 +0100, David Malone wrote: But when inetd is run without -l it get 100%. Interesting - does it still answer requests during this time? Yeah. What we really need to know is how many packets inetd actually received. The manpage excerpt that DES showed us indicates that nmap doesn't stop sending packets immediately unless it gets an ICMP message back. We know that inetd doesn't send ICMP messages back. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:16:14 +0200, Dag-Erling Smorgrav wrote:
Sheldon Hearn sheld...@uunet.co.za writes:
I know exactly why you see what you see when you do what you do. All I
can say is don't do that, because I can't think of a why to cater for
what you're doing in a sensible fashion.
I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.
Comes in private email. It's about 130KB after which tcpdump crashed with:
zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp
But when I restart tcpdump again (while inetd still is going wild)
it is quiet.
-Andre
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Andre Albsmeier andre.albsme...@mchp.siemens.de writes: Comes in private email. It's about 130KB after which tcpdump crashed with: zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp Weird. Very weird. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:35:48 +0200, Dag-Erling Smorgrav wrote: Andre Albsmeier andre.albsme...@mchp.siemens.de writes: Comes in private email. It's about 130KB after which tcpdump crashed with: zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp Weird. Very weird. Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. It should be reproducible very easily by running nmap -sU target_machine where target_machine has the internal inetd services enabled. I attach my inetd.conf in case it might be interesting (nothing special in it): # $Id: inetd.conf,v 1.33.2.1 1999/07/21 19:28:25 sheldonh Exp $ # # Internet server configuration database # # @(#)inetd.conf 5.4 (Berkeley) 6/30/90 # ftp stream tcp nowait root/usr/libexec/ftpd ftpd telnet stream tcp nowait root/usr/libexec/telnetdtelnetd shell stream tcp nowait root/usr/libexec/rshd rshd login stream tcp nowait root/usr/libexec/rlogindrlogind finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd #exec stream tcp nowait root/usr/libexec/rexecd rexecd #uucpd stream tcp nowait root/usr/libexec/uucpd uucpd #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd # run comsat as root to be able to print partial mailbox contents w/ biff, # or use the safer tty:tty to just print that new mail has been received. #comsat dgram udp waittty:tty /usr/libexec/comsat comsat ntalk dgram udp waittty:tty /usr/libexec/ntalkd ntalkd #tftp dgram udp waitnobody /usr/libexec/tftpd tftpd /tftpboot #bootps dgram udp waitroot/usr/libexec/bootpd bootpd # # Small servers -- used to be standard on, but we're more conservative # about things due to Internet security concerns. Only turn on what you # need. # daytime stream tcp nowait rootinternal daytime dgram udp waitrootinternal timestream tcp nowait rootinternal time dgram udp waitrootinternal echostream tcp nowait rootinternal echodgram udp waitrootinternal discard stream tcp nowait rootinternal discard dgram udp waitrootinternal chargen stream tcp nowait rootinternal chargen dgram udp waitrootinternal # # Kerberos authenticated services # #klogin stream tcp nowait root/usr/libexec/rlogindrlogind -k #eklogin stream tcp nowait root/usr/libexec/rlogindrlogind -k -x #kshell stream tcp nowait root/usr/libexec/rshd rshd -k #kipstream tcp nowait root/usr/libexec/kipd kipd # # CVS servers - for master CVS repositories only! # #cvspserver stream tcp nowait root/usr/bin/cvscvs pserver #cvsstream tcp nowait root/usr/bin/cvscvs kserver # # RPC based services (you MUST have portmapper running to use these) # rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd rusersd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.rusersd rpc.rusersd walld/1 dgram rpc/udp wait root /usr/libexec/rpc.rwalld rpc.rwalld #pcnfsd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.pcnfsd rpc.pcnfsd #rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad sprayd/1dgram rpc/udp wait root /usr/libexec/rpc.sprayd rpc.sprayd # # example entry for the optional pop3 server # #pop3 stream tcp nowait root/usr/local/libexec/popper popper # # example entry for the optional imap4 server # #imap4 stream tcp nowait root/usr/local/libexec/imapdimapd # # Return error for all ident requests # #auth stream tcp nowait rootinternal # # example entry for the optional ident server # authstream tcp waitkmem:kmem /usr/local/sbin/identd identd -w -t120 # # example entry for the optional qmail MTA # #smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd # # Enable the following two entries to enable samba startup from inetd # (from the Samba documentation). # #netbios-ssn stream tcp nowait root /usr/local/sbin/smbd smbd #netbios-ns dgram udp wait root /usr/local/sbin/nmbd nmbd To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Andre Albsmeier andre.albsme...@mchp.siemens.de writes: Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. Weird. I'm unable to reproduce it; my test box responds to UDP queries but does not log them (though it logs TCP queries). I'll update to the latest inetd and try again. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, Jul 23, 1999 at 03:57:19PM +0200, Dag-Erling Smorgrav wrote: Andre Albsmeier andre.albsme...@mchp.siemens.de writes: Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. Weird. I'm unable to reproduce it; my test box responds to UDP queries but does not log them (though it logs TCP queries). I'll update to the latest inetd and try again. I can reproduce it using version 1.63, ktracing shows: 3052 inetdCALL sigprocmask(0x1,0x82001) 3052 inetdRET sigprocmask 0 3052 inetdCALL sigprocmask(0x3,0) 3052 inetdRET sigprocmask 532481/0x82001 3052 inetdCALL gettimeofday(0xbfbfd5e4,0) 3052 inetdRET gettimeofday 0 3052 inetdCALL write(0xc,0xbfbfd60c,0x1a) 3052 inetdRET write -1 errno 39 Destination address required 3052 inetdCALL select(0x14,0xbfbfd750,0,0,0) 3052 inetdRET select 2 3052 inetdCALL sigprocmask(0x1,0x82001) 3052 inetdRET sigprocmask 0 3052 inetdCALL sigprocmask(0x3,0) 3052 inetdRET sigprocmask 532481/0x82001 3052 inetdCALL gettimeofday(0xbfbfd6f4,0) 3052 inetdRET gettimeofday 0 3052 inetdCALL write(0xe,0xbfbfd708,0x4) 3052 inetdRET write -1 errno 39 Destination address required 3052 inetdCALL sigprocmask(0x1,0x82001) 3052 inetdRET sigprocmask 0 3052 inetdCALL sigprocmask(0x3,0) 3052 inetdRET sigprocmask 532481/0x82001 It also seems to leave several hung processes around which are serveing disgard and echo. David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Thu, 22 Jul 1999, Alex Zepeda wrote: On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I know a lot of people like the ASUS P2B boards, but I've noticed a tendency for the systems to reset occasionally when plugging in a keyboard. I've seen this with both FreeBSD and NT, so I'm considering it a property of the board. If this is a PS/2 style keyboard, don't plug and unplug them when the host is powered up. The PS/2 style stuf seems to be very sensitive to that sort of thing. If it was a USB keyboard doing that... then that would be odd. Yes, it is a PS/2 keyboard, but these are the only MB's that I have run into this problem with other than some AIX boxes years ago that would blow a fuse when disconnecting the keyboard from a running system. This isn't that big a problem. I only have keyboard installed while building the systems. Thereafter they are serial console only. Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Fri, 23 Jul 1999, Vincent Poy wrote: On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I've had great results with the Tyan 1836DLUAN/Thunder 100's. I've got several boxes with 1GB of RAM and dual 450's humming along. For comparison one system with less memory and a SuperMicro board but identical system software has had a couple of wierd spontaneous reboots over the last few months. Cool... Is 1GB of ram really needed? We used to run a 64 meg system then 128 meg and then 384 meg, it doesn't seem to do much even for a heavily loaded ISP Server. Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. The real problem was poor CGI programming. I made them fix them. Now it toodles along with ridiculously low loads. All the websites and the mysql db fit in core. ;-) That's true too Seems like FreeBSD can handle a real high load without problems... If you can believe it they drove the system load up to 114 with their horrible Perl CGI's. Ammazingly, I could type sudo apachectl stop and wait 30 seconds or so for it to run. 114 and I didn't need to reboot the system. I was pleasantly surprised. Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
boot problems
Perhaps someone can help me with this...I just bought a new computer. (2) pII 400 chips (1) Intel 1440GX (Dual CPU PIII) motherboard (2) 256 MB SDRAM (1) Mylex Raid 960 model 150 adapter (3) Quantum Atlas IV 9.1 GB Ultra2 SCSI (1) CDROM 40x (1) Floppy 1.44 (1) Server case with redundant power supply I wanted to install FreeBSD as a web server, but every time i try and boot off the first install disk kern.flp 3.2-RELEASE, the machine halts with a hex dump. The machine has an onboard scsi (Adaptec AIC-7896). OpenBSD 2.5 and FreeBSD 2.2.8 will boot, but they dont recognize the disk controller. I was told FreeBSD supports the Mylex raid. Someone please help me with this...I have tried two different floppies as well. Im using dd if=kern.flp of=/dev/fd0 on a sun ultra 5 to make the disk image. Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
On Fri, 23 Jul 1999, Kris Kennaway wrote: On Thu, 22 Jul 1999, Ronald G. Minnich wrote: Are you saying that as an ordinary user I can mount something on top of /tmp, for example? If the vfs.usermount sysctl is 1, and you have appropriate access to the thing you're trying to mount (block device, etc). OK, so let's say it is 1. Let's say I have appropriate access to /tmp. I mount my own fs on /tmp. I now have read/write access to everything anyone writes to /tmp. Or, let's say I don't have appropriate access to /tmp. Pick some other place. I mount my file system there for my files. Now everyone who wants can look for these user mounts and walk them at will. My private stuff is quite public. User mounts are neat. But user mounts that modify the global name space of the machine are not neat. User mounts should be part of a private name space. But thanks for the note. I just now realized that if I add a private name space to v9fs (which is easy), and then turn on user mounts, user processes can have private name spaces on freebsd! thanks ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
FreeBSD can wait till unified-ipv6 is made available, since: - IPv6 is not that urgent task and - it will be messy if FreeBSD integrates KAME first, then switch to unified-ipv6. Both of these remain true. I certainly see and understand the marketing value of having an early IPv6 implementation, but I don't see this as mainstream interest so much as interest on the part of various researchers and early-adopters, all of which can go to the KAME site and grab the patches to 3.2-stable if they want to play now, today. If we haven't done a good enough job of making that clear and are suffering from defections to other *BSDs because of this, then we just need to get the word out better. :-) It's not like nothing is available at all, simply not officially and officially we have an obligation to pick the best, most technically correct route, something which I believe we have already done. Two merges sounds like a nightmare, and we're not suffering from NetBSD's release constraints here. :) - We need some more FreeBSD commit privs for other KAME guys. (this is a easy part) Yes, this is certainly the easy part. As always, just let us know if there's anything we can do. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
I've found the problem - it looks like a bug in the code for matching internal service names to /etc/service names. The code says: if ((bi-bi_socktype == sep-se_socktype strcmp(bi-bi_service, sep-se_service) == 0) || matchservent(bi-bi_service, sep-se_service, sep-se_proto)) It should probably say: if (bi-bi_socktype == sep-se_socktype ((strcmp(bi-bi_service, sep-se_service) == 0) || matchservent(bi-bi_service, sep-se_service, sep-se_proto))) It was running the tcp service instead of the udp service. David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
:David E. Cross wrote: : : Well, I just -STABLED the server to see if it fixed it, but I was certainly : running out. the server had only 3000-ish mbuf chains, and it would go through : them all in a day. : : Well, have you tried increasing the number of available mbufs and see if :you reach a point of stability? Assuming you have enough physical ram you :could do 15k mbufs on -Stable without a problem. Check LINT for the :nmbclusters option if you need help with it. : :Good luck, : :Doug Well, the cache shouldn't eat up *that* many mbufs! The problem is likely to be real. There is a good chance the leakage is in nfs_serv.c, which I fixed for -current. I do not think those changes have been backported to -STABLE. -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: FreeBSD: the stealth OS?
: lot of things FreeBSD is 'better' at, and a lot of those : things can easily fluctuate on a daily or weekly basis, : said Fuller, who maintains a Linux vs BSD Web page. : Thus, any definitive narrow statement that can be made : is usually obsolete before anyone hears it.. : : Perfect! : : Thank you, my fans! Please leave your monetary contributions in the hat : on your way out; : :Where is the hat? I saw Julian running off with it a couple of e-mails :ago. : :Nick Do I get a discount for having the same first name? -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: mbuf leakage in NFSv3 writes, possbile?
On Fri, Jul 23, 1999 at 09:06:01AM -0700, Matthew Dillon wrote: There is a good chance the leakage is in nfs_serv.c, which I fixed for -current. I do not think those changes have been backported to -STABLE. julian 1999/06/30 15:05:20 PDT Modified files:(Branch: RELENG_3) sys/nfs nfs_serv.c nfs_subs.c nfs_syscalls.c nfsm_subs.h Log: MFC: Bring in NFS cleanups by Matt. . . . David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
: : I do not think those changes have been backported to -STABLE. : :julian 1999/06/30 15:05:20 PDT : : Modified files:(Branch: RELENG_3) :sys/nfs nfs_serv.c nfs_subs.c nfs_syscalls.c : nfsm_subs.h : Log: : MFC: Bring in NFS cleanups by Matt. :. : David. Whup! So much for that idea! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
boot problems (fwd)
After the System Halted error, i get another error message. DAC960: system BIOS fatal Error - INT 15H function 87H Copy extended Memory ) failed. -- Forwarded message -- Date: Fri, 23 Jul 1999 10:54:52 + (GMT) From: Andrew Willis awil...@omega.honk.org To: freebsd-hackers@freebsd.org Subject: boot problems Perhaps someone can help me with this...I just bought a new computer. (2) pII 400 chips (1) Intel 1440GX (Dual CPU PIII) motherboard (2) 256 MB SDRAM (1) Mylex Raid 960 model 150 adapter (3) Quantum Atlas IV 9.1 GB Ultra2 SCSI (1) CDROM 40x (1) Floppy 1.44 (1) Server case with redundant power supply I wanted to install FreeBSD as a web server, but every time i try and boot off the first install disk kern.flp 3.2-RELEASE, the machine halts with a hex dump. The machine has an onboard scsi (Adaptec AIC-7896). OpenBSD 2.5 and FreeBSD 2.2.8 will boot, but they dont recognize the disk controller. I was told FreeBSD supports the Mylex raid. Someone please help me with this...I have tried two different floppies as well. Im using dd if=kern.flp of=/dev/fd0 on a sun ultra 5 to make the disk image. Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf leakage in NFSv3 writes, possbile?
Ok, here are some real stats w is the read-only machine, it services everything that s (the read-write machine) does... in fact it services more. *w crossd $ strings -a /kernel | grep \^___maxusers ___maxusers 96 *w crossd $ uname -a FreeBSD w.cs.rpi.edu 3.2-STABLE FreeBSD 3.2-STABLE #1: Tue Jun 29 09:36:32 EDT 1999 r...@w.cs.rpi.edu:/usr/src/sys/compile/WOBBLE i386 *w crossd $ uptime 1:43PM up 24 days, 2:08, 3 users, load averages: 0.00, 0.00, 0.00 *w crossd $ netstat -m 106/2688 mbufs in use: 85 mbufs allocated to data 21 mbufs allocated to packet headers 64/426/2048 mbuf clusters in use (current/peak/max) 1188 Kbytes allocated to network (11% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines *s crossd $ uname -a FreeBSD s.cs.rpi.edu 3.2-STABLE FreeBSD 3.2-STABLE #0: Thu Jul 22 18:12:21 EDT 1999 r...@phoenix.cs.rpi.edu:/usr/src/sys/compile/STAGGER i386 *s crossd $ strings -a /kernel | grep \^___maxusers ___maxusers 512 *s crossd $ uptime 1:43PM up 19:23, 2 users, load averages: 0.02, 0.01, 0.00 *s crossd $ netstat -m 3629/4096 mbufs in use: 3621 mbufs allocated to data 8 mbufs allocated to packet headers 3550/3660/8704 mbuf clusters in use (current/peak/max) 7832 Kbytes allocated to network (96% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines -- 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
Re: Proposed substitution for ACLs
In article 37882150.87a93...@newsguy.com, Daniel C. Sobral d...@newsguy.com wrote: Do whatever you want: as a fs layer. That would be good advice, if FS layers worked. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposed substitution for ACLs
:In article 37882150.87a93...@newsguy.com, :Daniel C. Sobral d...@newsguy.com wrote: : : Do whatever you want: as a fs layer. : :That would be good advice, if FS layers worked. : :John :-- : John Polstra j...@polstra.com : John D. Polstra Co., Inc.Seattle, Washington USA Maybe the best thing to do is to wait until FS layers are fixed later this year. -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: SURVEY: Sound cards that work under FreeBSD
In message 199907230710.jaa04...@musashi.et.bocholt.fh-ge.de Dirk GOUDERS writes: : My sound card is a SBPCI128 by Creative Labs. Nice card... I have one too. Plays mp3 well :-). Also plays video sound well and xgalaga works with sound!... NOTE: The SBPC64 doesn't work without an external patch... Be careful. : I only used the card with FreeBSD 3.2 I've used mine on -CURRENT for about 9 months or so, but part of that time I had to get the driver from somewhere else. : The only line I had to add to my kernel config file was: : : device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 : : (This causes a message pcm0 not found to appear at boot time but : just ignoring it seems to be o.k. - allthough I would prefer : not to see it, at all.) device pcm0 does the trick for me. I think that will work in 3.2. -current fixes the problem with psm0 not found. : I had to build the audio device snd1: : : # cd /dev : # sh MKDEV snd1 When you upgrade to 4.0 or -current, you'll have to undo that stuff... : and to use the mixer to set the volume to another value than 0. : I use the following script /usr/local/etc/rc.d/mixer.sh at boot time: : : #!/bin/sh : /usr/sbin/mixer vol 60:60 pcm 60:60 cd 60:60 Cool. I've always brought up xmixer to do this Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD: the stealth OS?
Matthew Dillon wrote: : lot of things FreeBSD is 'better' at, and a lot of those : things can easily fluctuate on a daily or weekly basis, : said Fuller, who maintains a Linux vs BSD Web page. : Thus, any definitive narrow statement that can be made : is usually obsolete before anyone hears it.. : : Perfect! : : Thank you, my fans! Please leave your monetary contributions in the hat : on your way out; : :Where is the hat? I saw Julian running off with it a couple of e-mails :ago. He was going to cut off the point and use it as a funnel into his BSD Toy fund. Or was that the wrong hat (or the wrong Julian?) Do I get a discount for having the same first name? Nope, you get charged double for attempting to share in the Matt-light. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
At 10:35 AM 7/23/99 -0400, Adrian Filipi-Martin wrote: On Thu, 22 Jul 1999, Alex Zepeda wrote: On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: I know a lot of people like the ASUS P2B boards, but I've noticed a tendency for the systems to reset occasionally when plugging in a keyboard. I've seen this with both FreeBSD and NT, so I'm considering it a property of the board. If this is a PS/2 style keyboard, don't plug and unplug them when the host is powered up. The PS/2 style stuf seems to be very sensitive to that sort of thing. If it was a USB keyboard doing that... then that would be odd. Yes, it is a PS/2 keyboard, but these are the only MB's that I have run into this problem with other than some AIX boxes years ago that would blow a fuse when disconnecting the keyboard from a running system. This isn't that big a problem. I only have keyboard installed while building the systems. Thereafter they are serial console only. I've seen it on an SBC (with a KB connector on board). it IS a problem if they want to do maintanence without bringing down the system. Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
|At 10:35 AM 7/23/99 -0400, Adrian Filipi-Martin wrote: |On Thu, 22 Jul 1999, Alex Zepeda wrote: | | On Thu, 22 Jul 1999, Adrian Filipi-Martin wrote: | |I know a lot of people like the ASUS P2B boards, but I've noticed a | tendency for the systems to reset occasionally when plugging in a |keyboard. | I've seen this with both FreeBSD and NT, so I'm considering it a property | of the board. | | If this is a PS/2 style keyboard, don't plug and unplug them when the host | is powered up. The PS/2 style stuf seems to be very sensitive to that | sort of thing. If it was a USB keyboard doing that... then that would be | odd. | | Yes, it is a PS/2 keyboard, but these are the only MB's that I have |run into this problem with other than some AIX boxes years ago that would |blow a fuse when disconnecting the keyboard from a running system. | | This isn't that big a problem. I only have keyboard installed |while building the systems. Thereafter they are serial console only. | |I've seen it on an SBC (with a KB connector on board). it IS a problem if |they want to do maintanence without bringing down the system. blush I fried two P6 ASUS motherboards this way, sorta along these lines, hmm, keyboard seems to be dead, maybe try it in this machine Russell | |Dennis | | |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
Missing ld.so in 3.2?
Greetings, I have a 3.2 install from CD-ROM and I am trying to run a commerical program, i.e. I don't have the source, and it is giving me the following error: [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed header from script. Bad header=Couldn't open /usr/libexec/ld.so This is an error in the applications error log. I looked on my 3.1 box and there is a file /usr/libexec/ld.so but on my 3.2 box the file does not exist. Should it? Does the company of the software have to recompile for 3.2? Any insight would be greatly appreciated. Thank you, Matthew Hagerty To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
blush I fried two P6 ASUS motherboards this way, sorta along these lines, hmm, keyboard seems to be dead, maybe try it in this machine We did the same thing on two Asus P6 MB as well! We replaced the fuse near the keyboard and both motherboards are working perfectly now. Tim To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Missing ld.so in 3.2?
On Fri, 23 Jul 1999, Matthew Hagerty wrote: Greetings, I have a 3.2 install from CD-ROM and I am trying to run a commerical program, i.e. I don't have the source, and it is giving me the following error: [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed header from script. Bad header=Couldn't open /usr/libexec/ld.so This is an error in the applications error log. I looked on my 3.1 box and there is a file /usr/libexec/ld.so but on my 3.2 box the file does not exist. Should it? Does the company of the software have to recompile for 3.2? Any insight would be greatly appreciated. Thank you, Matthew Hagerty I think u must read following: http://www.freebsd.org/releases/3.2R/errata.html Rgdz, Osokin Sergey aka oZZ, o...@etrust.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Missing ld.so in 3.2?
Install the compat22 dist; you have an old a.out binary there. Greetings, I have a 3.2 install from CD-ROM and I am trying to run a commerical program, i.e. I don't have the source, and it is giving me the following error: [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed header from script. Bad header=Couldn't open /usr/libexec/ld.so This is an error in the applications error log. I looked on my 3.1 box and there is a file /usr/libexec/ld.so but on my 3.2 box the file does not exist. Should it? Does the company of the software have to recompile for 3.2? Any insight would be greatly appreciated. Thank you, Matthew Hagerty To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Missing ld.so in 3.2?
:Install the compat22 dist; you have an old a.out binary there. : : Greetings, : : I have a 3.2 install from CD-ROM and I am trying to run a commerical : program, i.e. I don't have the source, and it is giving me the following error: : : [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed header from : script. Bad header=Couldn't open /usr/libexec/ld.so :... Btw, the netscape4.5.us port needs this too, along with half a dozen libraries in /usr/lib/aout/. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
