Re: Heads up! /etc/rc.conf.site is dead.
I think people will get used to /etc/defaults fairly quickly just a note on naming: Solaris as well as HP-UX have /etc/default, not /etc/defaults. Seeing that we're introducing a change, we might just as well move to something others use as well. regards Michael -- Michael Schuster / michael.schus...@germany.sun.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr
This doesn't fix my problem (my isn't even rename or delete related) As I writed some time before, I always get the wrong results if I generate the termcap.db in an NFSv3 mounted directory. It doesn't matter which machine is the NFS server (tried Solaris 7 and the NFS client machine itself). The generated file has *always* the wrong size (always the same: 1077760 Bytes, instead of 1245184 Bytes, which it should have). With NFSv2 the output is OK. Can anyone please test this if they have the same problem. It is quite easy: mkdir /NFS/termcap; cp /usr/src/share/termcap/* /NFS/termcap cd /NFS/termcap; make redo this with NFSv2 and v3 and compare the results. If someone else has the same problem it would be nice if he can drop me a note, so I know I'm not alone... Anyone with /usr/obj NFS mounted should have the same problems. I don't even dare to do a make release on an NFSv3 mounted chroot directory. Even if the make succeeded I wouldn't trust the results. NFSv2 seems quite stable now. Daniel Matthew Dillon schrieb: Index: nfs_vnops.c === RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v retrieving revision 1.119 diff -u -r1.119 nfs_vnops.c --- nfs_vnops.c 1999/01/27 22:45:49 1.119 +++ nfs_vnops.c 1999/02/06 01:56:23 @@ -1567,6 +1567,19 @@ } /* +* We have to flush B_DELWRI data prior to renaming +* the file. If we don't, the delayed-write buffers +* can be flushed out later after the file has gone stale +* under NFSV3. NFSV2 does not have this problem because +* ( as far as I can tell ) it flushes dirty buffers more +* often. +*/ + + VOP_FSYNC(fvp, fcnp-cn_cred, MNT_WAIT, fcnp-cn_proc); + if (tvp) + VOP_FSYNC(tvp, tcnp-cn_cred, MNT_WAIT, tcnp-cn_proc); + + /* * If the tvp exists and is in use, sillyrename it before doing the * rename of the new file over it. * XXX Can't sillyrename a directory. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Serious mbuf cluster leak..
After a while, I have determined the cause of the leak to be the following commit. Although, I can't seem to find any reason why it would cause this behavior--reverting these files fixes it. Any thoughts? fenner 1999/01/20 09:32:01 PST Modified files: sys/kern uipc_socket.c sys/netinet tcp_output.c tcp_usrreq.c tcp_var.h sys/sys protosw.h Log: Add a flag, passed to pru_send routines, PRUS_MORETOCOME. This flag means that there is more data to be put into the socket buffer. Use it in TCP to reduce the interaction between mbuf sizes and the Nagle algorithm. Based on: Justin C. Walker jus...@apple.com's description of Apple's fix for this problem. Revision ChangesPath 1.50 +4 -2 src/sys/kern/uipc_socket.c 1.32 +3 -2 src/sys/netinet/tcp_output.c 1.40 +7 -2 src/sys/netinet/tcp_usrreq.c 1.49 +18 -17src/sys/netinet/tcp_var.h 1.26 +2 -1 src/sys/sys/protosw.h I have been seeing a nasty cluster leak in both 3.0 stable and 4.0 current as of today. Until now, I thougt maybe it was something in my driver, athough after much careful looking over my code, it simply does not look possible. Also, I downgraded to current of Dec 12, and the problem dissappears. The odd thing is that the clusters that leak don't seem to be attached to mbufs. Or at least there is not a 1-1 ratio. Following is netstat output after a while of running netpipe in streaming mode. (NPtcp -s; see ftp://ftp.scl.ameslab.gov/pub/netpipe) Also, the leak only becomes apparent when the send write size is very large--several hundred K to several megabytes. Does anyone have any idea what this may be? I really am not sure where to look aside from trying prorgressively newer kernels. Also, I only have alphas to test on right now.. puck:~ netstat -m 211/416 mbufs in use: 116 mbufs allocated to data 95 mbufs allocated to packet headers 1674/1688/2048 mbuf clusters in use (current/peak/max) 3480 Kbytes allocated to network (97% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Chris Csanady To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-net in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
[no subject]
subscribe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Crippleware (was Re: adding DHCP client to src/contrib/)
Where did the -C option for install(1) come from? bde pick up on somethings I did a long time ago. Uh, no, wrong. (Speaking as the creator of `install -C'.) In defense of Steven, he was the 'original' author of -C, whether or not you used his code or not. He pushed for this long before it was part of FreeBSD. AFAIR, I used Garrett's version of -C long before Steve pushed for something quite different (-z). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: umount -f
Will it ever work as it appears it should? Currently I have (on 2.2.8) From an email from Peter Wemm: In this situation, you need to do this: umount -f -t nfs phosphorus:/phosphorus This causes umount to stat(phosphorus:/phosphorus) (which fails) rather than /mnt. Nope: m...@xxx:/tmp (1044) umount -f -t nfs phosphorus:/phosphorus umount: /phosphorus: Device busy IIRC, this depends on fixes from Lite2. It won't ever work in 2.2.8. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Heads up! /etc/rc.conf.site is dead.
-Original Message- From: Brian Somers [mailto:br...@awfulhak.org] Sent: 10 February 1999 18:47 To: RT Cc: curr...@freebsd.org Subject: Re: Heads up! /etc/rc.conf.site is dead. I kinda like the /etc./defaults directory... All default files should be placed there. Only things edited should be in /etc.. It'll make for a much smaller mess of files. I'm wondering about items like ppp examples? After mulling this over for a few days I can see that /etc/defaults is probably going to be a good thing. From your other mail, /usr/src/etc isn't any good for holding default system parameters since a) it might not be around since it's not in root. My previous suggestion of /usr/share fails this criteria as well, wasn't thinking clearly :-) b) it might not be around because there are no sources installed. If /etc/defaults is truly RO (I think the immutable flag should be set on those files to stop idle tampering) then it will solve the /etc upgrade problem or at least alleviate it greatly. Adding new knobs will be a doddle, the default file gets a new knob, with it's default setting and it'll just work. Changing the defaults for an existing setting are likewise not a problem. The local admin will still need to take a parse over the /etc settings when an upgrade is done to see if the defaults still suit the local requirements but the actuall installation of the new files can finally be automated without clobbering local settings and major changes to subsystems can take place without a lot of user intervention to upgrade the /etc/files by hand. They're going into /usr/share/examples/ppp soon. I have some other things (like tcl scripts for answering chap challenges) that will go in there, and it's a more generic place Besides, with all this activity, it'd be nice to get out of /etc altogether :-) Have another think about it. /etc/defaults does have its merits but it isn't going to work well unless everyone buys into it. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: umount -f
On Wed, Feb 10, 1999 at 01:54:53PM -0500, Mikhail Teterin m...@misha.cisco.com wrote: Nope: m...@xxx:/tmp (1044) umount -f -t nfs phosphorus:/phosphorus umount: /phosphorus: Device busy It is not, that umount hangs, it is that it cares about the device being busy despite `-f' flag. Or so it seems... send-pr? Do you have hard mount or soft mount? I have seen such behavior for hard mounts. -- Vallo Kallaste va...@matti.ee To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Wrong things posted to -current (was Re: Need Help)
On Wed, Feb 10, 1999 at 12:58:39PM +0100, andrea wrote: HI I have a trouble with FreeBSD 2.1.5 This an example of the type of question one DOES NOT ANSWER in freebsd-current. Instead, send a polite note to the poster telling him to send his question to questi...@freebsd.org, along with a quick answer (if you know it). curr...@freebsd.org presently sees more traffic than hack...@freebsd.org - it is filled with all kinds of not-really-related-to-current material. Please take care to keep our signal-to-noise ratio good - including not answering bad postings, and not posting technical questions to curr...@freebsd.org (they belong in hack...@freebsd.org and questi...@freebsd.org, depending on what level the question is at). Eivind. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: umount -f
Vallo Kallaste once stated: =On Wed, Feb 10, 1999 at 01:54:53PM -0500, Mikhail Teterin m...@misha.cisco.com wrote: = = Nope: = = m...@xxx:/tmp (1044) umount -f -t nfs phosphorus:/phosphorus = umount: /phosphorus: Device busy = = It is not, that umount hangs, it is that it cares about the device being = busy despite `-f' flag. Or so it seems... send-pr? = =Do you have hard mount or soft mount? I have seen such behavior =for hard mounts. Soft. But it should not matter, should it? -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Hi Paul, Just a few criticisms of your comments... On Thu, 11 Feb 1999 11:56:31 GMT, p...@originative.co.uk wrote: Adding new knobs will be a doddle, the default file gets a new knob, with it's default setting and it'll just work. It won't be a doddle if, as you suggested, the defaults directory is system immutable. For exactly this reason, that suggestion wasn't a good one. I hope you agree. They're going into /usr/share/examples/ppp soon. [...] Besides, with all this activity, it'd be nice to get out of /etc altogether :-) Have another think about it. /etc/defaults does have its merits but it isn't going to work well unless everyone buys into it. /etc/defaults is for default knobs that are turned on by default and may be overridden. Examples are knobs that are not turned on by default. Can you see why the ppp examples are not a candidate for buy in? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: runsocks (Was Re: gpib driver - does anybody use it?)
On Wed, 10 Feb 1999, Andre Albsmeier wrote: Hmm, just finished my 3.1 upgrade, compiled socks and runsocks seems to work now. The only thing that doesn't work is compiling the telnet included with socks5: cc -I. -I../../include -I./../../include -O -pipe -DANDRE -D__USE_FIXED_PROTOTYPES__ -DHAVE_SETUPTERM -DSOCKS -DINCLUDE_PROTOTYPES -DKLUDGELINEMODE -DSOCKS -DINCLUDE_PROTOTYPES -o telnet authenc.o commands.o main.o network.o ring.o sys_bsd.o telnet.o terminal.o tn3270.o utilities.o -L../../lib -lsocks5 -lcrypt -lncurses -Llibtelnet -ltelnet telnet.o: In function `gettermname': telnet.o(.text+0x9f2): undefined reference to `ttytype' *** Error code 1 (continuing) `all' not remade because of errors. But this doesn't bother me because always I runsocks the FreeBSD telnet. Yeah, this doesn't comple for some reason as of about 1.0r4. The port just doesn't bother trying to install it - no-one's cared enough to look at why it's broken and how to fix it. Kris - (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How to power off an ATX power supply machine on shutdown ?
Sorry if this is inappropriate for -CURRENT but I am mailing here as the answer may be to do with recent committed features to -CURRENT (intpm ??). Anyway, how do I power off a machine on shutdown ? I have apm in the kernel and it probes as apm v 1.2 but when the shutdown -p now command is run, the power is not turned off and I have to hold down the power button for 4 seconds to turn it off. Hows it done ? Do I have to run apmconf -e (The owner hasn't tried this yet) I cant give more info as it's not my machine and I only see it on weekends. /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: runsocks (Was Re: gpib driver - does anybody use it?)
On Fri, 12-Feb-1999 at 00:04:08 +1030, Kris Kennaway wrote: On Wed, 10 Feb 1999, Andre Albsmeier wrote: Hmm, just finished my 3.1 upgrade, compiled socks and runsocks seems to work now. The only thing that doesn't work is compiling the telnet included with socks5: cc -I. -I../../include -I./../../include -O -pipe -DANDRE -D__USE_FIXED_PROTOTYPES__ -DHAVE_SETUPTERM -DSOCKS -DINCLUDE_PROTOTYPES -DKLUDGELINEMODE -DSOCKS -DINCLUDE_PROTOTYPES -o telnet authenc.o commands.o main.o network.o ring.o sys_bsd.o telnet.o terminal.o tn3270.o utilities.o -L../../lib -lsocks5 -lcrypt -lncurses -Llibtelnet -ltelnet telnet.o: In function `gettermname': telnet.o(.text+0x9f2): undefined reference to `ttytype' *** Error code 1 (continuing) `all' not remade because of errors. But this doesn't bother me because always I runsocks the FreeBSD telnet. Yeah, this doesn't comple for some reason as of about 1.0r4. The port just doesn't bother trying to install it - no-one's cared enough to look at why it's broken and how to fix it. It works with 2.2.x. The problem has something to do with ncurses. In 2.2.x the termcap lib is found by configure. In 3.x, the ncurses is used, IIRC. With the termcap lib, ttytpe can be resolved; with ncurses not. BTW, runsocks works really. I think it was to late at night when I tried it the first time. Don't know what I did wrong ... -Andre Kris - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
What I don't like from the new rc.conf approach is the name rc.conf ;-). I think that the old sysconfig should come back. Then, there would be a /etc/defaults/sysconfig (R/O), and a /etc/sysconfig (storing the site-specific config). These files would contain _only_ variable assignments. The /etc/rc.conf script would be R/O too; it would read /etc/defaults/sysconfig and /etc/sysconfig in turn. Furthermore, both sysconfigs could be splitted into several files (net, nfs, time, console, isdn, etc.). In this case, another directory should be created under /etc (named siteconfig, for example), which would be the site-specific counterpart of /etc/defaults. My 0.02 euro, -- JMA --- José Mª Alcaide | mailto:j...@we.lc.ehu.es Universidad del País Vasco | mailto:j...@es.freebsd.org Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 --- Go ahead... make my day. - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to power off an ATX power supply machine on shutdown ?
Matthew Thyer wrote: Anyway, how do I power off a machine on shutdown ? I have apm in the kernel and it probes as apm v 1.2 but when the shutdown -p now command is run, the power is not turned off and I have to hold down the power button for 4 seconds to turn it off. Hows it done ? Do I have to run apmconf -e (The owner hasn't tried this yet) Yes. There is a knob in /etc/rc.conf (apm_enable) that forces this at startup. -- JMA --- José Mª Alcaide | mailto:j...@we.lc.ehu.es Universidad del País Vasco | mailto:j...@es.freebsd.org Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 --- Go ahead... make my day. - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Adding a pnp device id
Where would I look to add a pnp id number for a modem that is not being detected during the pnp device probe at boot? I have tried putting it in the pnpdata file and sio.c, (remaking reinstalling afterward), but the modem still is not detected. The modem is detected by the bios and displayed on the list after the post. I am running 4.0 current, built from last weekend (2/7/99). I have tried this on several different pc's with different motherboards with the same results. Thank you, Jerry Bell To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: umount -f
On Thu, Feb 11, 1999 at 08:24:52AM -0500, Mikhail Teterin m...@kot.ne.mediaone.net wrote: =Do you have hard mount or soft mount? I have seen such behavior =for hard mounts. Soft. But it should not matter, should it? I don't know, I'm not a expert to say for sure. Only know that about two months ago I tried to soft mount some exports from our Solaris 2.5.1 box and after that I was able to forcibly umount them. That's all I can say, I haven't used any NFS mounts since. -- Vallo Kallaste va...@matti.ee To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr
As I writed some time before, I always get the wrong results if I generate the termcap.db in an NFSv3 mounted directory. It doesn't matter which machine is the NFS server (tried Solaris 7 and the NFS client machine itself). The generated file has *always* the wrong size (always the same: 1077760 Bytes, instead of 1245184 Bytes, which it should have). With NFSv2 the output is OK. 1077760 seems to be correct. The different sizes are caused by the db library believing that statbuf.st_blksize actually gives the optimal blocksize for I/O. For nfsv3, st_blksize is 512, and this gives a smaller database, but for nfsv2 st_blksize seems to be determined by the server. I get the following results after hacking the db library to use a fixed blocksize: blocksize 8192: ufs db file size = nfs db file size = 1245184, and files same blocksize 512: ufs db file size = nfs db file size = 1077760, but files differ The differences seem to be mostly for randomly sized bunches of \0's appearing at different places in the files. cap_mkdb is incredibly slow (140 seconds on a P5/133 for an nfs output file). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Heads up! /etc/rc.conf.site is dead.
-Original Message- From: Sheldon Hearn [mailto:a...@iafrica.com] Sent: 11 February 1999 13:24 To: p...@originative.co.uk Cc: br...@awfulhak.org; tr49...@rcc.on.ca; curr...@freebsd.org Subject: Re: Heads up! /etc/rc.conf.site is dead. Hi Paul, Just a few criticisms of your comments... On Thu, 11 Feb 1999 11:56:31 GMT, p...@originative.co.uk wrote: Adding new knobs will be a doddle, the default file gets a new knob, with it's default setting and it'll just work. It won't be a doddle if, as you suggested, the defaults directory is system immutable. For exactly this reason, that suggestion wasn't a good one. I hope you agree. I don't see why. The only thing that should update the defaults directory is a system installation or 'make install'. Neither of which will be hampered in any way by the files or directory being immutable. We install new kernels without any problems. They're going into /usr/share/examples/ppp soon. [...] Besides, with all this activity, it'd be nice to get out of /etc altogether :-) Have another think about it. /etc/defaults does have its merits but it isn't going to work well unless everyone buys into it. /etc/defaults is for default knobs that are turned on by default and may be overridden. Examples are knobs that are not turned on by default. Can you see why the ppp examples are not a candidate for buy in? I don't really agree, defaults is not for knobs that are turned on by default, for a start that assumes binary state which isn't the case. /etc/defaults will have the defaults for *all* knobs. That would include options that are disabled by default. Specifically with regard to ppp, having it work the same way would require changing ppp configuration code to parse a local file for overrides but there's no reason why all configuration couldn't adopt the same general principle of operation i.e. a defaults file that sets all configuration knobs into a default state and then a local override file for local changes. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
PAM and SQL?
Hello, I've been trying to find a way to get the system to authenticate using an SQL database. My first idea was to modify NIS to use an SQL serfer for authentication, but then it was brought to my attention that this had already been talked about using PAM. Does anyone know if PAM provides full authentication services? E.g. will programs like radiusd still function w/o modification? Do you guys think that PAM would be a good starting point? :) I'd love to hear new ideas on this. Thanks! Gus Bourg To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Crippleware (was Re: adding DHCP client to src/contrib/)
Bruce Evans wrote: Where did the -C option for install(1) come from? bde pick up on somethings I did a long time ago. Uh, no, wrong. (Speaking as the creator of `install -C'.) In defense of Steven, he was the 'original' author of -C, whether or not you used his code or not. He pushed for this long before it was part of FreeBSD. AFAIR, I used Garrett's version of -C long before Steve pushed for something quite different (-z). If you check the cvs log files, it appears Bruce in fact used Garrett's work. If you search the hackers mailing list with install(1) AND kargl. You'll find a large number of emails about new features to install circa Oct 95. I added several options, I called the now used -C option -t. My method was inferior to Garrett's method. The participants in the emails exchanged in 95 were Bruce, Rod, Julian, Terry, Nate, Poul, and myself. Note: my mailing list search is not comprehensive , so Garrett may have participated. In the end, it doesn't matter who did what. I've two valuable lessons this weekend: (1) continue my anonymous hacking, and (2) never question the intentions of a committer particularly on a mailing list. -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ifq_maxlen on lo0
My boot messages recently have included a warning about the lo0 interface not setting the ifq_maxlen. I'm not particularly knowledgeable about the network code, so forgive me if I stumble a bit, but I'd like to get rid of the warning. I know that the lo0 interface isn't expected to get backed up, since the users are in the same machine, so setting the ifq_maxlen isn't of earthshaking importance, but is there a reason for not setting this anyhow (I think in if_loop.c)? It's either set it, or disable the warning, and I'm not in favor, usually, of disabling warnings. If this is the right way to go, I'll look more into making the change ... is it correct? +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr
On a related note, I've been unable to reproduce the `hanging' in 3.0-CURRENT (without Matt's patch)... -- Niels. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Jon Hamilton hamil...@pobox.com writes: But then you're right back where you started. Since rc.conf isn't supposed to be touched by the install/upgrade tools, it'll get out of date (and will become a hinderance rather than a help) as default settings change, and as settings are added/deleted. Can we make something which compares /etc/rc.conf and /etc/default/rc.conf and emits warnings if a variable is set in /etc/rc.conf which isn't in /etc/default/rc.conf? I realize that this is not as simple as extracting all variable names from both files, sorting them, and running diff. There are a few variable names which are variable, for instance the network interface settings. kai `a FreeBSD newbie but hopefully not stupid' -- I like _b_o_t_h kinds of music. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Crippleware (was Re: adding DHCP client to src/contrib/)
On Thu, 11 Feb 1999 09:46:06 PST, Steve Kargl wrote: (2) never question the intentions of a committer particularly on a mailing list. Hi Steve, I think it's healthy to question the intentions of commiters. However, I think it's important to clearly state your concerns. If you object, list your objections. Also, when your views come under criticism, try to see the point of view from which the criticism comes _before_ you start defending your views. I know from my own experience that I'm often so involved in trying to restate more clearly what I originally said that I miss valid criticisms. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Adding a pnp device id
Where would I look to add a pnp id number for a modem that is not being detected during the pnp device probe at boot? I have tried putting it in the pnpdata file and sio.c, (remaking reinstalling afterward), but the modem still is not detected. The modem is detected by the bios and displayed on the list after the post. I am running 4.0 current, built from last weekend (2/7/99). I have tried this on several different pc's with different motherboards with the same results. It needs to be in sio.c at the moment, but being a modem it should have one of the compatibility fallback IDs as well. You may need to explicitly enable it if your BIOS is not set for non PNP OS. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr
As I writed some time before, I always get the wrong results if I generate the termcap.db in an NFSv3 mounted directory. It doesn't matter which machine is the NFS server (tried Solaris 7 and the NFS client machine itself). The generated file has *always* the wrong size (always the same: 1077760 Bytes, instead of 1245184 Bytes, which it should have). With NFSv2 the output is OK. 1077760 seems to be correct. The different sizes are caused by the db library believing that statbuf.st_blksize actually gives the optimal blocksize for I/O. For nfsv3, st_blksize is 512, and this gives a smaller database, but for nfsv2 st_blksize seems to be determined by the server. I get the following results after hacking the db library to use a fixed blocksize: blocksize 8192: ufs db file size = nfs db file size = 1245184, and files same blocksize 512: ufs db file size = nfs db file size = 1077760, but files differ The differences seem to be mostly for randomly sized bunches of \0's appearing at different places in the files. cap_mkdb is incredibly slow (140 seconds on a P5/133 for an nfs output file). Ahh, this sounds reasonable. I should have noticed earlier by myself. On my home machine I recently installed another 1GB (actually 997MB) drive. In order to be able to make a release on this disk I created the filesystem with a 4096/512 block size. This saves approx. 50MB for the whole installation. With this block size, my termcap.db is only 765952 Bytes in size. It is interesting that a 4k block size generates a much smaller file than a block size of 512 Bytes... Does this have something to do that 4k is also the page size? NFSv3 doesn't seem to have a st_blksize field. Thus it is set to 512. For v2 it should be the same as for the corresponding local filesystem on the other end. The difference in the \0 Bytes is related by reading the source file: cap_mkdb uses the stdio functions to read in the source file. This again uses fstat() to obtain the optimal block size. Now more comfortable with NFSv3, I will give it another try. I hope my release builds will speed up a little. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
libc.so in bad format?
Hi
I am running current from 8 february but cvsup from 10 february and make
all install produced something weird to /usr/lib. The cc compiler doesn't
work any more. make in /usr/src gives:
cc -O -pipe -elf -Wall -Wno-unused -c
/usr/src/lib/csu/i386-elf/crt1.c -o crt1.o
crt1.o: File truncated
{standard input}: Assembler messages:
{standard input}:71: FATAL: Can't write crt1.o: File truncated
*** Error code 1
Have I right that libc.so.3 and friends and relatives are not correct? Do
can anybody loan that library in binary format? Or the libraries are
somewhere in ftp sites. Some URL:-s?
Ants Aader
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
They're going into /usr/share/examples/ppp soon. [...] Besides, with all this activity, it'd be nice to get out of /etc altogether :-) Have another think about it. /etc/defaults does have its merits but it isn't going to work well unless everyone buys into it. /etc/defaults is for default knobs that are turned on by default and may be overridden. Examples are knobs that are not turned on by default. Can you see why the ppp examples are not a candidate for buy in? I don't really agree, defaults is not for knobs that are turned on by default, for a start that assumes binary state which isn't the case. /etc/defaults will have the defaults for *all* knobs. That would include options that are disabled by default. Specifically with regard to ppp, having it work the same way would require changing ppp configuration code to parse a local file for overrides but there's no reason why all configuration couldn't adopt the same general principle of operation i.e. a defaults file that sets all configuration knobs into a default state and then a local override file for local changes. I see no problem with the `default' section in ppp.conf. It allows the specification of defaults that can be overridden by individual profiles. ppp.*.sample are samples. They are purely there to give people a feel for what their configuration files might look like and to show them how to achieve things that require quite a few commands - such as playing server, doing multilink etc. Paul. Besides, IMHO, /etc/defaults will either be abused by system administrators or will be a poor-mans copy of src/etc. I can't see the problems going away by using something like this. -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PAM and SQL?
In article pine.bsf.4.05.9902110935550.39062-100...@speed.freei.net, Gus R Bourg g...@speed.freei.net wrote: Hello, I've been trying to find a way to get the system to authenticate using an SQL database. My first idea was to modify NIS to use an SQL serfer for authentication, but then it was brought to my attention that this had already been talked about using PAM. Does anyone know if PAM provides full authentication services? E.g. will programs like radiusd still function w/o modification? Do you guys think that PAM would be a good starting point? :) I'd love to hear new ideas on this. Yes, PAM should be a good solution for this. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
rc.local not executed because of bug in rc
First, sorry for the cross-posting, but this problem affects both the -STABLE and -CURRENT branches. The rc.local script is called from rc as $conf_dir/rc.local. However, the new rc.conf does not set the conf_dir variable anymore, therefore rc.local is not executed. -- JMA --- José Mª Alcaide | mailto:j...@we.lc.ehu.es Universidad del País Vasco | mailto:j...@es.freebsd.org Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 --- Go ahead... make my day. - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: rc.local not executed because of bug in rc
: :First, sorry for the cross-posting, but this problem affects :both the -STABLE and -CURRENT branches. : :The rc.local script is called from rc as $conf_dir/rc.local. :However, the new rc.conf does not set the conf_dir variable :anymore, therefore rc.local is not executed. : :-- JMA -current's /usr/src/etc/rc no longer use $conf_dir. It looks like -stable's does, though... I've fixed it. I don't understand how it got there, I only comitted the $conf_dir stuff to -current! -Matt Matthew Dillon dil...@backplane.com :--- :José Mª Alcaide | mailto:j...@we.lc.ehu.es :Universidad del País Vasco | mailto:j...@es.freebsd.org :Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose :Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 :48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 :--- : Go ahead... make my day. - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On 11 Feb 1999 kai.grossjoh...@cs.uni-dortmund.de wrote: Jon Hamilton hamil...@pobox.com writes: But then you're right back where you started. Since rc.conf isn't supposed to be touched by the install/upgrade tools, it'll get out of date (and will become a hinderance rather than a help) as default settings change, and as settings are added/deleted. Can we make something which compares /etc/rc.conf and /etc/default/rc.conf and emits warnings if a variable is set in /etc/rc.conf which isn't in /etc/default/rc.conf? I realize that this is not as simple as extracting all variable names from both files, sorting them, and running diff. There are a few variable names which are variable, for instance the network interface settings. Actually, it's almost that easy. It may require a few hints at the beginning of the file, but I could make a shell script (not using sed/awk/whatnot) to do this if anyone would want it. kai `a FreeBSD newbie but hopefully not stupid' -- I like _b_o_t_h kinds of music. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Support for Japanese locale in FreeBSD 3.0
Hi, I'm trying to find the source file for the Japanese LC_COLLATE in FreeBSD3.0. I notice the LC_COLLATE for Japanese is just a symlink to the ISO Latin LC_COLLATE in FreeBSD3.0. If Japanese collation is not supported in 3.0, I would like to get the source file for Japanese LC_CTYPE and a copy of the LC_COLLATE for en_US as template, so I can create my own verison for Japanese LC_COLLATE. Thanks Nelson __ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Crippleware (was Re: adding DHCP client to src/contrib/)
On Thu, Feb 11, 1999 at 09:46:06AM -0800, Steve Kargl wrote: (2) never question the intentions of a committer particularly on a mailing list. Do NOT follow this rule. We should all be questioned. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 3c905B stops responding during ifconfig alias
Of all the gin joints in all the towns in all the world, tc...@staff.circle.net had to walk into mine and say: [...] During an ifconfig xl0 alias, the xl0 interface drops packets. It does NOT generate errors (netstat -in). In fact, on several occasions I've seen it go completely unresponsive (not responding to arp requests) until kicked back to life by outbound packets. [...] My apologies for not replying to you on this sooner; it took me a while to locate a machine with which I could do some testing (all the 3c905B hardware I have is in the form of embedded chipsets in Dell desktop machines, and they've been moving around on me a lot). This does NOT happen on the: xl0: 3Com 3c905 Fast Etherlink XL 10/100BaseTX rev 0x00 int a irq 10 on I think I found the problem. Currently, xl_stop() and xl_init() both issue RX and TX resets. Seems logical doesn't it? I mean, the purpose of xl_init() is to put the NIC into a known good state, and the purpose of xl_stop() is to slap it in the face and make it shut up ASAP. The difference between the 3c905 and the 3c905B (well, the important difference in this case) is that the 3c905B's chipset has a built-in PHY, while the 3c905 requires an external one (3Com uses a DP83840A for the 3c905 boards, judging by the one sample 3c905 card I have). Apparently, issuing the RX and TX reset commands on the 3c905B causes it to also reset the PHY, which causes the PHY to restart its autonegotiation session with its link partner. It takes a few seconds for the autoneg session to finish, and during this time the 3c905B stops receiving packets. This doesn't happen on the 3c905 because issuing the RX and TX reset commands does not have any affect on the external PHY: the only way to reset the PHY is by writing to the PHY's basic mode control register via the MII management interface. I'm including a patch which should fix this problem. It just disables the code that does the reset in both xl_stop() and xl_init(). Please try this and let me know if it helps. To apply the patch, do the following: - Make sure you have the kernel source code installed under /usr/src. - Save this message to a file, i.e. /tmp/xl.patch - Become root. - Run the following commands: # cd /sys/pci # patch /tmp/xl.patch - Compile a new kernel and boot it. This patch was generated using a version of if_xl.c from FreeBSD-current, but it should work on any version of the driver with only a couple of mild warnings. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = Mulder, toads just fell from the sky! I guess their parachutes didn't open. = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Heads up! /etc/rc.conf.site is dead.
-Original Message- From: Brian Somers [mailto:br...@awfulhak.org] Sent: 11 February 1999 20:56 To: p...@originative.co.uk Cc: a...@iafrica.com; br...@awfulhak.org; tr49...@rcc.on.ca; curr...@freebsd.org Subject: Re: Heads up! /etc/rc.conf.site is dead. I see no problem with the `default' section in ppp.conf. It allows the specification of defaults that can be overridden by individual profiles. ppp.*.sample are samples. They are purely there to give people a feel for what their configuration files might look like and to show them how to achieve things that require quite a few commands - such as playing server, doing multilink etc. Paul. Besides, IMHO, /etc/defaults will either be abused by system administrators or will be a poor-mans copy of src/etc. I can't see the problems going away by using something like this. I agree with the risk of /etc/defaults being abused, that's why I think the files should be immutable so that it's *VERY* clear to admins that they should not be touching those files. If they work their way around warning signs that huge then they really are on their own. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: 3c905B stops responding during ifconfig alias
Bill,
Your patch worked perfectly. THANK YOU!
By the way, I'd be happy to fedex a 3c905B to
you for your use in testing these sorts of things
if that would be helpful. We have a fairly large
commitment to this card now (40+) and I'd do this
happily to facilitate continuing performance
enhancements or other improvements to it.
Sincerely,
-Troy Cobb
Circle Net, Inc.
http://www.circle.net
-Original Message-
From: wp...@ctr.columbia.edu [mailto:wp...@ctr.columbia.edu]
My apologies for not replying to you on this sooner; it
took me a while
to locate a machine with which I could do some testing (all
the 3c905B
hardware I have is in the form of embedded chipsets in Dell desktop
machines, and they've been moving around on me a lot).
This does NOT happen on the:
xl0: 3Com 3c905 Fast Etherlink XL 10/100BaseTX rev 0x00
int a irq 10 on
I think I found the problem. Currently, xl_stop() and xl_init() both
issue RX and TX resets. Seems logical doesn't it? I mean,
the purpose
of xl_init() is to put the NIC into a known good state, and
the purpose
of xl_stop() is to slap it in the face and make it shut up ASAP. The
difference between the 3c905 and the 3c905B (well, the important
difference in this case) is that the 3c905B's chipset has a
built-in PHY,
while the 3c905 requires an external one (3Com uses a
DP83840A for the
3c905 boards, judging by the one sample 3c905 card I have).
Apparently,
issuing the RX and TX reset commands on the 3c905B causes it to also
reset the PHY, which causes the PHY to restart its
autonegotiation session
with its link partner. It takes a few seconds for the
autoneg session to
finish, and during this time the 3c905B stops receiving packets.
This doesn't happen on the 3c905 because issuing the RX and TX reset
commands does not have any affect on the external PHY: the only way
to reset the PHY is by writing to the PHY's basic mode
control register
via the MII management interface.
I'm including a patch which should fix this problem. It
just disables
the code that does the reset in both xl_stop() and xl_init(). Please
try this and let me know if it helps.
To apply the patch, do the following:
- Make sure you have the kernel source code installed under
/usr/src.
- Save this message to a file, i.e. /tmp/xl.patch
- Become root.
- Run the following commands:
# cd /sys/pci
# patch /tmp/xl.patch
- Compile a new kernel and boot it.
This patch was generated using a version of if_xl.c from
FreeBSD-current,
but it should work on any version of the driver with only a
couple of
mild warnings.
-Bill
--
=
-Bill Paul(212) 854-6020 | System Manager,
Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for
Telecommunications Research
Home: wp...@skynet.ctr.columbia.edu | Columbia University,
New York City
=
Mulder, toads just fell from the sky! I guess their
parachutes didn't open.
=
*** ../CVSWORK/sys_pci/if_xl.c Mon Feb 1 16:25:52 1999
--- if_xl.c Thu Feb 11 18:34:39 1999
***
*** 2363,2373
--- 2363,2375
for (i = 0; i 3; i++)
CSR_WRITE_2(sc, XL_W2_STATION_MASK_LO + (i * 2), 0);
+ #ifdef notdef
/* Reset TX and RX. */
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_RESET);
xl_wait(sc);
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET);
xl_wait(sc);
+ #endif
/* Init circular RX list. */
if (xl_list_rx_init(sc) == ENOBUFS) {
***
*** 2715,2724
--- 2717,2728
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_DISABLE);
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_COAX_STOP);
DELAY(800);
+ #ifdef notdef
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_RESET);
xl_wait(sc);
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET);
xl_wait(sc);
+ #endif
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_INTR_ACK|XL_STAT_INTLATCH);
/* Stop the stats updater. */
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: libc.so in bad format?
In article pine.bsf.4.05.9902112230340.23835-100...@bsd.kbfi.ee,
Ants Aader aa...@bsd.kbfi.ee wrote:
Hi
I am running current from 8 february but cvsup from 10 february and make
all install produced something weird to /usr/lib. The cc compiler doesn't
work any more. make in /usr/src gives:
cc -O -pipe -elf -Wall -Wno-unused -c
/usr/src/lib/csu/i386-elf/crt1.c -o crt1.o
crt1.o: File truncated
{standard input}: Assembler messages:
{standard input}:71: FATAL: Can't write crt1.o: File truncated
It looks like maybe your filesystem is full. Make some space and
try again.
John
--
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
Nobody ever went broke underestimating the taste of the American public.
-- H. L. Mencken
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
