Re: Heads up! /etc/rc.conf.site is dead.

[michael schuster]

> 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

[D. Rock]

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..

[Chris Csanady]

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" '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]

[krzysiek]

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/)

[Bruce Evans]

>> > 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

[Bruce Evans]

>> > 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.

[paul]

> -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

[Vallo Kallaste]

On Wed, Feb 10, 1999 at 01:54:53PM -0500, Mikhail Teterin 
 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)

[Eivind Eklund]

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

[Mikhail Teterin]

Vallo Kallaste once stated:

=On Wed, Feb 10, 1999 at 01:54:53PM -0500, Mikhail Teterin 
 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.

[Sheldon Hearn]

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?)

[Kris Kennaway]

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 ?

[Matthew Thyer]

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?)

[Andre Albsmeier]

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.

[Jose M. Alcaide]

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 "sysconfig"s 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 ?

[Jose M. Alcaide]

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

[Jerry Bell]

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

[Vallo Kallaste]

On Thu, Feb 11, 1999 at 08:24:52AM -0500, Mikhail Teterin 
 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

[Bruce Evans]

>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.

[paul]

> -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?

[Gus R Bourg]

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/)

[Steve Kargl]

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

[Chuck Robey]

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

[N]

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.

[Kai . Grossjohann]

Jon Hamilton  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/)

[Sheldon Hearn]

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

[Mike Smith]

> 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

[D. Rock]

> >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?

[Ants Aader]

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.

[Brian Somers]

> > > > 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   
  
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?

[John Polstra]

In article ,
Gus R Bourg   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

[Jose M. Alcaide]

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

[Matthew Dillon]

:
: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 


:---
: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.

[Brian Feldman]

On 11 Feb 1999 kai.grossjoh...@cs.uni-dortmund.de wrote:

> Jon Hamilton  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

[Nelson Ng]

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/)

[Eivind Eklund]

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

[Bill Paul]

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.

[paul]

> -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

[tcobb]

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?

[John Polstra]

In article ,
Ants Aader   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