Re: CA's TLS Certificate Bundle in base = BAD

[Gordon Tetlow]

On Dec 3, 2022, at 5:26 PM, grarpamp  wrote:
> 
> Again, FreeBSD should not be including the bundle in base, if users
> choose to, they can get it from ports or packages or wherever else.
> Including such bundles exposes users worldwide to massive risks.
> You need to do more gpg attestation, pubkey pinning [1], tofu, and
> cert management starting from empty file... and quit trusting bundles of
> hundreds of random CA's, all of which are entities who have zero duty
> or care to the user, and often exist/corrupt/break to present evil [2] ...
> 
> [1]
> https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
> https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
> 
> FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option,
> thus they're incapable of securely fetching packages, iso's, etc from
> servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys
> for users to get, verify, and pin out of band. Even pubkeys were swapped out
> on FreeBSD servers without announcing for users if any exploit or loss 
> occurred
> there or for some other reason. That's all bad news :( But can be fixed :)

Key pinning is a bad idea that 100% will cause outages.

As a thought experiment, let's suppose I (as the Security Officer) use the 
system you propose and require users to pin specific keys on our publicly 
available servers. Now let's further suppose that the project is compromised 
such that we believe those certificates might be in the hands of the attacker, 
but we aren't sure. I'm now stuck between a rock and hard place. Should I 
rotate the pinned certificate? In your proposed system, rotating that pinned 
certificate will cause massive downstream failures for all users. Since we 
aren't sure, maybe I'll leave the existing certificate in place, because I 
don't want to cause those outages since I'm not sure it's a problem.

In the publicly trusted CA system, I can easily rotate the certificate even if 
I don't believe it was compromised. It incentivizes better behavior. Also, 
please don't lecture me on the problems with the publicly trusted CA system: 
I'm very familiar with them. That said, it's the system we have and I have no 
interest in trying to tilt at that particular windmill.

In any event, nothing is preventing you from doing this on your own as the 
system ships with the tools to do so. Recognize the project has a need for 
cryptographic agility and ability to change certificates whenever we need to. 
Running our own root CA infrastructure necessary to provide a similar level of 
assurance to a professionally run CA is non-trivial and I don't believe we as a 
project are in a position (or interested) in taking on such a burden.

Gordon

iwm not in GENERIC kernel

[Gordon Tetlow]

I have an Intel NUC that uses an Intel 8260 wireless driver. This works
flawlessly if I load the module if_iwm via the loader or the rc.conf
kld_list directive.

Do we know if the iwm driver not being in GENERIC is an oversight or on
purpose? I couldn't find anything in the list history.

Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Removal of catman from base

[Gordon Tetlow]

On Tue, Sep 12, 2017 at 06:50:22PM +, Poul-Henning Kamp wrote:
> 
> In message <20170912184200.gd99...@gmail.com>, Gordon Tetlow writes:
> 
> >With modern hardware, it doesn't seem to be necessary to have pre-formatted
> >man pages as rendering them is short enough to not be noticeable.
> 
> That was actually not why catman was brought into the world:  ATT/USL
> thought text-processing was The Goods so they unbundled it base SVR
> and invented catman to make up for the missing nroff.

Okay, that seems reasonable. I don't think it changes the desire to
remove it (unless I'm missing something).

Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Removal of catman from base

[Gordon Tetlow]

On Tue, Sep 12, 2017 at 11:42:00AM -0700, Gordon Tetlow wrote:
> All,
> 
> I wanted to announce my intention to remove the catman utility.
> 
> For those that are unaware, this utility (disabled by default) is
> generally run out of a periodic job and causes the system to cache
> pre-formatted man pages into the /usr/share/man/cat* directories. With
> modern hardware, it doesn't seem to be necessary to have pre-formatted
> man pages as rendering them is short enough to not be noticeable.
> 
> Please note, this will not disable the ability to render cat pages or in
> any other way use existing cat pages, it just removes the utility that
> builds the cat pages. As such, any ports that install cat pages will
> continue to work.

I forgot to mention this has a review out:
https://reviews.freebsd.org/D12317

Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Removal of catman from base

[Gordon Tetlow]

All,

I wanted to announce my intention to remove the catman utility.

For those that are unaware, this utility (disabled by default) is
generally run out of a periodic job and causes the system to cache
pre-formatted man pages into the /usr/share/man/cat* directories. With
modern hardware, it doesn't seem to be necessary to have pre-formatted
man pages as rendering them is short enough to not be noticeable.

Please note, this will not disable the ability to render cat pages or in
any other way use existing cat pages, it just removes the utility that
builds the cat pages. As such, any ports that install cat pages will
continue to work.

Best,
Gordon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: man(1) no longer understands manpages like .so man3/printf.3

[Gordon Tetlow]

On Fri, Nov 5, 2010 at 8:57 AM, Anonymous  wrote:
> A few examples from ports tree
>
>  devel/automake111: automake-1.11(1)
>  devel/gettext: dcgettext(3), dcngettext(3), dgettext(3), dngettext(3)
>  devel/nasm: rdf2com(1), rdf2ihx(1), rdf2ith(1), rdf2srec(1)
>  textproc/gnugrep: egrep(1), fgrep(1)
>  www/neon29: ne_get_{request,session}_flag(3), ne_set_connect_timeout(3)
>  x11/libX11: BlackPixel(3), XArc(3), etc
>  x11/libXext: XShmAttach(3), XmbufDisplayBuffers(3), etc
>  [+ more x11 libs]

Thanks for the report. I'll look into adding the feature.

Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Rollout plan for new version of man/manpath/whatis/apropos

[Gordon Tetlow]

I'm to the point where I'm ready to the commit the code, but I wanted
to layout a plan for the conversion and ask for input to make sure I
didn't miss anything.

1. Commit the code located at
http://people.freebsd.org/~gordon/man.shar into src/usr.bin/man
(pending mentor review).
2. Unhook src/gnu/usr.bin/man from the build.
3. Unhook src/etc/manpath.config from the build (in src/etc/Makefile).
4. Add entry to src/ObsoleteFiles.inc to remove etc/manpath.config.
5. Hook src/usr.bin/man to the build.
6. Alter src/etc/mtree/BSD.local.mtree to include an entry for
LOCALBASE/etc/man.d
7. Add entry into src/UPDATING about the change over deprecating
/etc/manpath.config
8. Bump __FreeBSD_version in src/sys/sys/param.h
9. Document version bump in doc/en_US.ISO8859-1/books/porters-handbook/book.sgml
10. Contact following ports owners to use new include system rather
than manipulating /etc/manpath.config directly:
  japanese/man
  lang/perl5.8
  lang/perl5.10
  lang/perl5.12
11. Contact following ports owners to use new include system rather
than displaying a message in pkg-message:
  graphics/tcm
  lang/erlang
  lang/metaocaml
12. Contact following ports owners to change their scripts as needed
to accommodate the fact there isn't a manpath.config anymore:
  ports-mgmt/tinderbox
  x11/xorg-libraries

I think that's everything. Am I missing anything?

Thanks,
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DHCP server in base

[Gordon Tetlow]

On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER
wrote:

> Perl is a great example, I don't really understand why it's in the
> base, then the port need to rewrite the links into the base hierarchy
> and I think this is bad.


Perl is not in the base system anymore. It's in the ports system.

Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Thu, Sep 9, 2010 at 7:41 PM, Alexander Best  wrote:

> > Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages
> > would be appreciated. I'm new to manpage authoring and could use a
> review.
>
> you forgot the AUTHORS section in all of the man pages. ;) it's always nice
> to
> see who wrote the code by reading the man pages and not having to look at
> the
> source itself imho.
>

It felt weird to promote myself like that. I might add it. There is
certainly precedent for either way.

Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Thu, Sep 9, 2010 at 12:48 PM, Anonymous  wrote:

> The order is still bogus compared to gnu man. If I don't like our
> ancient GNU tools and altered PATH in order to prefer ones from ports
> then I certainly don't want to view old manpages, too. The base manpath
> should be appended *after* any PATH substitutions.
>
>  $ man -aw gperf # man.sh
>  /usr/share/man/en.UTF-8/man1/gperf.1.gz
>  /usr/share/man/man1/gperf.1.gz
>  LOCALBASE/man/man1/gperf.1.gz
>
>  $ man -aw gperf # gnu man
>  LOCALBASE/man/man1/gperf.1.gz
>  /usr/share/man/en.UTF-8/man1/gperf.1.gz
>
>  > $ echo $PATH
>  >
> LOCALBASE/libexec/ccache:HOME/.bin:LOCALBASE/sbin:LOCALBASE/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:HOME/blah/bin
>

Fixed this up to no longer add an unconditional system search path. While
I'm not planning on supporting MANPATH_MAP, I have added special casing for
/bin and /usr/bin as encountered in PATH.


> And it doesn't show anything when there are no arguments, not even
> returning with exit code > 0.
>
>  $ man # man.sh
>
>  $ man # gnu man
>  What manual page do you want?
>  zsh: exit 1 man
>

Added.

Updated drop location at:
http://people.freebsd.org/~gordon/man.shar

Thanks for the feedback,
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Thu, Sep 9, 2010 at 8:17 PM, Anonymous  wrote:

> Gordon Tetlow  writes:
>
> > 2. Imports configuration from /usr/local/etc/man.d/*.conf and
> /etc/man.conf
> > (purposefully changed the manpath.config file since it is a different
> > syntax).
>
> Hmm, and if LOCALBASE != /usr/local? hier(7) does not specify /usr/local
> as the only place installed packages may reside in, only default one.
>

That variable is not easily found in shell. I'm open to suggestions on how
to figure it out. I suppose I could try something like make -V LOCALBASE
since it would be in /etc/make.conf if it is set. Another alternative would
be to parse the PATH and look for ../etc/man.d for each path component. That
would be even more generic (and allow for the user to customize it
potentially).

Thoughts?
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow  wrote:

> All,
>
> I sat down and rewrote the man tools from a relatively old codebase to a
> single shell script. My original motivation was to allow multiple
> configuration files so port installations did not have to mess with
> /etc/manpath.config (like perl for example) when needing to manipulate the
> manpath. After looking at the existing code, I figured I could rewrite it as
> a shell script relatively easily.
>
> Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
> /usr/bin/whatis)
> http://people.freebsd.org/~gordon/man.sh<http://people.freebsd.org/%7Egordon/man.sh>
>
> Features of the new code:
>
> 1. BSD licensed (old code is GPL).
> 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
> (purposefully changed the manpath.config file since it is a different
> syntax).
> 3. Allows ports to override the toolset used to display the manpage based
> on language. This was done to try to merge the functionality of the
> japanese/man port into the base system as much as possible.
>
> I've tried to make this mirror the functionality, directory search order,
> and arguments as the current base implementation.
>
> This brings me to my next point. I need some testers willing to try this
> out. It would be particularly great if I could get some foreign language
> testers with localized manpage installations. If something doesn't work the
> way you expect, please contact me and I can help debug it (using man -ddd
>  will generally give me the debug information I need).
>

I have a new set for testing:
http://people.freebsd.org/~gordon/man.shar<http://people.freebsd.org/%7Egordon/man.shar>

This is going to be my final set before I commit it into the tree, barring
any showstoppers. Now includes manpage documentation for the various parts
of the new utilities. To install:
# sh man.shar
# make
# make -DBINDIR=/usr/bin install

Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages
would be appreciated. I'm new to manpage authoring and could use a review.

Please let me know if you have any questions.

Thanks,
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Wed, Aug 18, 2010 at 11:52 PM, Gordon Tetlow  wrote:

> On Wed, Aug 18, 2010 at 5:01 PM, Anonymous  wrote:
>
>> Gordon Tetlow  writes:
>>
>> It doesn't search in bin/../man nor in bin/.man. For example,
>> my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/manpath.config
>> is default one and contains /usr/local/man which does not exist here.
>>
>
> Guess I missed that pretty badly in my port. I'll go back and retool the
> logic for this but that'll take a bit of time.
>

Added. Latest version at http://people.freebsd.org/~gordon/man.sh

It's a slightly different heuristic than the existing man implementation
since I don't support the notion of MANPATH_MAP. Here's the order:

Default manpaths (/usr/share/man:/usr/share/openssl/man:/usr/local/man)
Parse $PATH (path/man:path/MAN:(if ending in /bin)path/../man)
Parse config files

Thanks!
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Wed, Aug 18, 2010 at 5:01 PM, Anonymous  wrote:

> Gordon Tetlow  writes:
>
> It doesn't search in bin/../man nor in bin/.man. For example,
> my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/manpath.config
> is default one and contains /usr/local/man which does not exist here.
>

Guess I missed that pretty badly in my port. I'll go back and retool the
logic for this but that'll take a bit of time.

I guess there is one more bug.
>
>  $ MANPATH=$HOME/.bin/man man mplayer
>  zcat: HOME/.bin/man/man1/mplayer.1: not in gzip format
>  $ MANPATH=$HOME/.bin/man man -ddd mplayer
>  -- Using architecture: amd64:amd64
>  -- Using pager: less
>  -- Using manual sections: 1:1aout:8:2:3:n:4:5:6:7:9:l
>  -- Using locale paths: en_US.UTF-8:en.UTF-8:.
>  -- Searching for mplayer
>  -- Searching section 1
>  --   Searching directory HOME/.bin/man/man1
>  -- Found manpage HOME/.bin/man/man1/mplayer.1
>  -- Skipping catpage: not found or old
>  -- Command: /usr/bin/zcat HOME/.bin/man/man1/mplayer.1 | /usr/bin/tbl
> | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | less
>

Fixed. Switched to using zcat -f  which works on both compressed and
uncompressed files. (Yay for being lazy!)

Thanks for the report!
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow  wrote:

> All,
>
> I sat down and rewrote the man tools from a relatively old codebase to a
> single shell script. My original motivation was to allow multiple
> configuration files so port installations did not have to mess with
> /etc/manpath.config (like perl for example) when needing to manipulate the
> manpath. After looking at the existing code, I figured I could rewrite it as
> a shell script relatively easily.
>
> Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
> /usr/bin/whatis)
> http://people.freebsd.org/~gordon/man.sh<http://people.freebsd.org/%7Egordon/man.sh>
>
> Features of the new code:
>
> 1. BSD licensed (old code is GPL).
> 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
> (purposefully changed the manpath.config file since it is a different
> syntax).
> 3. Allows ports to override the toolset used to display the manpage based
> on language. This was done to try to merge the functionality of the
> japanese/man port into the base system as much as possible.
>
> I've tried to make this mirror the functionality, directory search order,
> and arguments as the current base implementation.
>
> This brings me to my next point. I need some testers willing to try this
> out. It would be particularly great if I could get some foreign language
> testers with localized manpage installations. If something doesn't work the
> way you expect, please contact me and I can help debug it (using man -ddd
>  will generally give me the debug information I need).
>
> Thanks,
> Gordon
>

I did some additional testing with the japanese/man-doc port and found the
following was necessary:

1. Install my script as /usr/bin/man
2. Install japanese/man-doc
3. Create a /usr/local/etc/man.d/ja-man-doc.conf with the following
contents:

EQN_JA /usr/local/bin/geqn
COL_JA /bin/cat
NROFF_JA /usr/local/bin/groff -S -Wall -mtty-char -man -Tnippon
-dlang=ja_JP.eucJP
PIC_JA /usr/local/bin/gpic
TBL_JA /usr/local/bin/gtbl
TROFF_JA /usr/local/bin/groff -man -dlang=ja_JP.eucJP
MANLOCALE ja_JP.eucJP

4. Create a symlink from /usr/share/man/ja.eucJP -> /usr/local/man/ja
5. Set LC_CTYPE=ja_JP.eucJP
6. man ls

When all is said and done, 3 should be handled by the man-doc port while 4
is a problem.

The current base system man uses the following search order for localized
manpages (which I have emulated):

Look in
/usr/share/man/.
/usr/share/man/
...
/usr/local/man/.
/usr/local/man/
...

Without step 4 from above, if you were to attempt to get a localized manpage
for ls(1) that resides in /usr/local/man/., you would never see
it because the english language manpage in /usr/share/man would be found
first. The japanese man port gets around this by installing their own man
implementation (jman) forcing /usr/local/man/ja before /usr/share/man in
the search order. I'm interested in feedback about whether the search order
should change or if I should leave it as is.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

All,

I sat down and rewrote the man tools from a relatively old codebase to a
single shell script. My original motivation was to allow multiple
configuration files so port installations did not have to mess with
/etc/manpath.config (like perl for example) when needing to manipulate the
manpath. After looking at the existing code, I figured I could rewrite it as
a shell script relatively easily.

Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
/usr/bin/whatis)
http://people.freebsd.org/~gordon/man.sh

Features of the new code:

1. BSD licensed (old code is GPL).
2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
(purposefully changed the manpath.config file since it is a different
syntax).
3. Allows ports to override the toolset used to display the manpage based on
language. This was done to try to merge the functionality of the
japanese/man port into the base system as much as possible.

I've tried to make this mirror the functionality, directory search order,
and arguments as the current base implementation.

This brings me to my next point. I need some testers willing to try this
out. It would be particularly great if I could get some foreign language
testers with localized manpage installations. If something doesn't work the
way you expect, please contact me and I can help debug it (using man -ddd
 will generally give me the debug information I need).

Thanks,
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: newsyslog patch implementing file includes

[Gordon Tetlow]

On Thu, Apr 22, 2010 at 6:26 AM, John Baldwin  wrote:

> This is a great feature!  One suggestion, I think this text in the new
> manpage
> isn't quite right:
>
>  Name of the system log file to be archived, the literal string "default",
>  or "include".
>
> I think it's ambiguous about "include" also being a literal string.  Two
> possible suggestions:
>
>  Name of the system log file to be archived, or one of the literal strings
>  "default" or "include".
>
>  Name of the system log file to be archived, the literal string "default",
>  or the literal string "include".
>

I took your first suggestion and updated the patch.

Thanks,
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: newsyslog patch implementing file includes

[Gordon Tetlow]

On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda  wrote:

> It's need feature. I test patch - it work for me (CURRENT, amd64)
> Can I use some as:
>  /path/to/dir/*.conf
> ?
> and can I create recursive include?
>

Yes, wildcards and recursive includes are supported.

Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

newsyslog patch implementing file includes

[Gordon Tetlow]

I wanted the ability for a port to have a rotating log policy so I wrote a
patch for newsyslog to implement includes of other newsyslog.conf style
files.

Please find the patch at:
http://people.freebsd.org/~gordon/patches/newsyslog.diff

Format for the include line in /etc/newsyslog.conf is:
 /etc/defaults/newsyslog.conf

Here's a quick overview of the changes:
Convert the conf_entry struct from using a home rolled linked list to the
queue(3) macros.
Add a STAILQ to process include files.
Add support for  tag to specify include files.
Globbing is supported in  statements.
Properly detect circular include loop dependencies.

Please take a look and send me any comments you might have.

Thanks,
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

newsyslog patch implementing file includes

[Gordon Tetlow]

I wanted the ability for a port to have a rotating log policy so I wrote a
patch for newsyslog to implement includes of other newsyslog.conf style
files.

Please find the patch at:
http://people.freebsd.org/~gordon/patches/newsyslog.diff

Format for the include line in /etc/newsyslog.conf is:
 /etc/defaults/newsyslog.conf

Here's a quick overview of the changes:
Convert the conf_entry struct from using a home rolled linked list to the
queue(3) macros.
Add a STAILQ to process include files.
Add support for  tag to specify include files.
Globbing is supported in  statements.
Properly detect circular include loop dependencies.

Please take a look and send me any comments you might have.

Thanks,
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lock order reversal

[Gordon Tetlow]

On Tue, Nov 25, 2003 at 07:05:36PM -0600, John wrote:
> i was just looking through my daily reports from my new 5.2 beta box and 
> found this in dmesg.
> lock order reversal
>  1st 0xc08f7ce0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201
>  2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210

Here is the stack trace for the first one:

lock order reversal
 1st 0xc098e840 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201
 2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210
Stack backtrace:
backtrace(c089c5dc,c1031100,c08afe80,c08afe80,c08afef6) at backtrace+0x17
witness_lock(c1031100,8,c08afef6,8a2,c10310a0) at witness_lock+0x672
_mtx_lock_flags(c1031100,0,c08afef6,8a2,c55ae000) at _mtx_lock_flags+0xba
_vm_map_lock(c10310a0,c08afef6,8a2,c5394bd0,0) at _vm_map_lock+0x36
vm_map_remove(c10310a0,c55ae000,c55af000,d77e5bf8,c07eacab) at vm_map_remove+0x30
kmem_free(c10310a0,c55ae000,1000,d77e5c28,c07ea6bf) at kmem_free+0x32
page_free(c55ae000,1000,2,0,c55ae000) at page_free+0x3b
zone_drain(c101e000,0,c08b16a1,4b1,0) at zone_drain+0x2cf
zone_foreach(c07ea3f0,d77e5cf0,c07e7b98,c08b154f,0) at zone_foreach+0x45
uma_reclaim(c08b154f,0,c08b14bc,29e,c095bf80) at uma_reclaim+0x17
vm_pageout_scan(0,0,c08b14bc,5a9,1f4) at vm_pageout_scan+0x148
vm_pageout(0,d77e5d48,c0896d18,311,0) at vm_pageout+0x31b
fork_exit(c07e8990,0,d77e5d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd77e5d7c, ebp = 0 ---


pgp0.pgp
Description: PGP signature

Re: 40% slowdown with dynamic /bin/sh

[Gordon Tetlow]

On Mon, Nov 24, 2003 at 08:55:31PM -0500, Andrew Gallatin wrote:
> 
> Daniel O'Connor writes:
> 
>  > Why didn't you pipe up when this was discussed _long_ ago?
> 
> In the orginal thread, there was an agreement that the performance
> would be measured BEFORE the default was changed, and the default
> would only be changed if there was no measurable performance impact.
> I believe sam@ asked for this.  As far as I know, performance
> measurments were never done.  Instead, the switch was thrown just
> before the code freeze.

That's not true. I was asked to present numbers so we could make a
determination as to what the impact was. It was never said that it
would only be the default iff there was no performance impact.

FWIW, I did find that the boot process took a performance hit, I
also found that the average worldstone did not increase appreciably
(ie, less than 1%). I took these numbers to re@ when I was asked to
flip the dynamic switch and the feeling was that the overhead was
worth the tradeoff for functionality.

Finally, I must ask if anyone has evidence that this has slowed down
anything other than microbenchmarks? My point of view was it did
slow down the boot, but so did rcNG and no one seemed to mind about
that. Also, you don't write time-sensitive applications in shell
so the dynamic link overhead is not noticed there. People asked me
about the affect on periodic. My response is why do you care if your
periodic took 1 extra second to run (on the outside) due to dynamic
linking overhead. It's just crazy.

In summary, I have yet to see a compelling arguement to consider
backing out the dynamic linking changes I've put in. I've read all of
the messages in all of the 3+ huge threads and I'm still as resolved
today as I was when I made the commit. Frankly, I'm surprised people
didn't yell at me when I massively restructured the tree to put
libraries in /lib. Turning on dynamic linking was the most minor part
from the architectural point of view but is getting the most vitriol.
How typical.

-gordon


pgp0.pgp
Description: PGP signature

Re: Unfortunate dynamic linking for everything

[Gordon Tetlow]

On Tue, Nov 18, 2003 at 08:03:23PM -0500, [EMAIL PROTECTED] wrote:
> 
> However, PAM and NSS 'tricks' really seem to be exactly that,
> and certainly worthy of special builds.  However, that isn't
> necessary, yet still not building everything with a shared
> libc.

Things like nss_ldap (which is used *heavily* at my place of employment)
are some reasons that FreeBSD doesn't make it into more places. It was
the reason why FreeBSD isn't being used here. Calling them 'tricks'
(and succumbing to the name calling you wanted to avoid) doesn't change
the fact that every major contender (IRIX, Solaris, Linux to name a few)
all support this feature set.

-gordon


pgp0.pgp
Description: PGP signature

HEADS UP: /bin and /sbin are now dynamically linked

[Gordon Tetlow]

I just committed a patch to change /bin and /sbin from statically to
dynamically linked. If you don't like the idea of using a dynamically
linked /bin and /sbin, now is the time to define NO_DYNAMICROOT in your
make.conf.

The reasons for doing so have been hashed over lots of times. But the
short of it:

1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB static.
   Dynamically linked, they are only 4 MB.
2) Proper support for NSS. This will finally allow you to use NSS modules
   and get things like usernames in ls -l working for modules that are
   dynamically loaded.

-gordon


pgp0.pgp
Description: PGP signature

Re: Bluetooth patch

[Gordon Tetlow]

On Mon, Sep 29, 2003 at 10:51:56PM +0200, John Hay wrote:
> > 
> > i see, is that a problem? i can clean up the patch and remove these entries.
> > (frankly i thought CVS should take care of it).
> 
> I don't think it will break cvs, it might just cause some extra bloat.
> Maybe just get rid of those parts of the patch where the only change
> to the file is the $FreeBSD$ line?

We have CVS magic that unexpands the $FreeBSD$ on it's way back into the
repo. It might complain that it is invalid, but it shouldn't cause any
repo bloat.


pgp0.pgp
Description: PGP signature

if_em and ibm thinkpad T40

[Gordon Tetlow]

I have an IBM T40 that has an onboard Intel GigE card. When the em
driver tries to probe it, I get "The EEPROM Checksum Is Not Valid".
Adding a printf, I discover the checksum is 0x08b8 (not the 0xBABA
that is documented in the headers). Anyone else seen any problems
with this? I'd really rather not have to drag around a USB ethernet
device.

-gordon


pgp0.pgp
Description: PGP signature

Re: upgrade from static to dynamic root

[Gordon Tetlow]

On Tue, Sep 16, 2003 at 06:11:01PM +0200, Harti Brandt wrote:
> On Tue, 16 Sep 2003, Richard Nyberg wrote:
> 
> RN>At Thu, 11 Sep 2003 14:44:55 +0200 (CEST),
> RN>Harti Brandt wrote:
> RN>> Hi,
> RN>>
> RN>> I just tried to upgrade one of my systems from a static root from july to
> RN>> an actual dynamic root. The installworld went fine 'til the place where
> RN>> /bin/test is installed. At that point the installation stopped with "ELF
> RN>> interpreter /libexec/ld-elf.so.1 not found". And really /libexec is not
> RN>> populated yet.
> RN>
> RN>Me too :(
> RN>To get installworld back on track I used cp under linux emulation to
> RN>copy ld-elf.so.1. Then I also had to run ldconfig -m /lib. After that
> RN>make installworld completed successfully.
> 
> Or you could cd into /usr/obj/usr/src/rescue/rescue and do ./rescue cp ...
> (as long as you have a working shell)

Which of course exists in /rescue too.

-gordon


pgp0.pgp
Description: PGP signature

Re: upgrade from static to dynamic root

[Gordon Tetlow]

On Thu, Sep 11, 2003 at 02:44:55PM +0200, Harti Brandt wrote:
> 
> Hi,
> 
> I just tried to upgrade one of my systems from a static root from july to
> an actual dynamic root. The installworld went fine 'til the place where
> /bin/test is installed. At that point the installation stopped with "ELF
> interpreter /libexec/ld-elf.so.1 not found". And really /libexec is not
> populated yet. May it be, that the makefile uses one of the newly
> installed tools during install? For example 'ln' to make the link test ->
> [?
> 
> Also, wouldn't it be helpful to populate /rescue before /bin? Just in
> the case something goes wrong between installing been and rescue for the
> first time?

A dynamic root is still a little bit of a no seatbelt kind of activity.
We should probably bring back the ${OBJDIR}/bin/sh test and if we fail,
install /libexec/ld-elf.so.1 then reattempt the ${OBJDIR}/bin/sh test
and continue on with life.

-gordon


pgp0.pgp
Description: PGP signature

Re: Question related to FreeBSD Serial Console...

[Gordon Tetlow]

On Tue, Sep 02, 2003 at 12:18:51PM +0100, [EMAIL PROTECTED] wrote:
> Hiya
> 
> 
> > Unfortunately, many motherboards (BIOSs?) won't initialise a PS/2 keyboard
> > interface unless a keyboard is connected at boot time, so if you plug in a
> > keyboard subsequently it won't work. Nothing the OS can do in this case (I
> > believe), and yes it's a PITA.
> 
> Keyboard and mouse manufacturers usually give dire warnings about plugging
> in PS/2 devices when the machine is powered up, maybe that's the reason
> why.

I've personally killed about 5 keyboards this way. I don't recommend hot
plugging PS/2 keyboards.

-gordon


pgp0.pgp
Description: PGP signature

Re: /lib symlinks problem?

[Gordon Tetlow]

On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
> On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
> > > > I might be missing an obvious, but I just don't see a reason
> > > > why we should use relative linking here: we should just link
> > > > to where we really install.  With the attached patch, I get:
> ...
> > +.if ${LIBDIR} != ${SHLIBDIR}
> > +   ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
> 
> Why are we making *any* symlinks here??

It was before we corrected ld(1) to look in /lib. I'm happy with
removing them now that it has been corrected.

-gordon


pgp0.pgp
Description: PGP signature

Re: /lib symlinks problem?

[Gordon Tetlow]

On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
> 
> Now it looks like this:
> 
> install -C -o root -g wheel -m 444   libalias.a /foo/usr/lib
> install -s -o root -g wheel -m 444 libalias.so.4 /foo/lib
> ln -fs libalias.so.4 /foo/lib/libalias.so
> ln -fs /lib/libalias.so.4  /foo/usr/lib/libalias.so
> 
> This is also consistent with how we handle SYMLINKS:
> 
> # make -f bsd.prog.mk BINDIR=/bin SYMLINKS='${BINDIR}/file1 ${BINDIR}/file2' install 
> DESTDIR=/foo
> /foo/bin/file2 -> /bin/file1
> # ls -l /foo/bin
> total 0
> lrwxr-xr-x  1 root  wheel  10 Aug 31 17:44 file2 -> /bin/file1

This *really* breaks the build-tools part, which is why I made it
a relative symlink in the first place.

-gordon


pgp0.pgp
Description: PGP signature

LOR vm_object.c:434 vm_kern.c:329

[Gordon Tetlow]

I got this LOR when I started X.

Kernel rev:
FreeBSD roark.gnf.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Aug 21 09:39:38 PDT 2003 
[EMAIL PROTECTED]:/local/usr.obj/local/usr.src/sys/ROARK  i386

lock order reversal
 1st 0xc6856de0 vm object (vm object) @ /local/usr.src/sys/vm/vm_object.c:434
 2nd 0xc082f110 system map (system map) @ /local/usr.src/sys/vm/vm_kern.c:329
Stack backtrace:
backtrace(c033da41,c082f110,c034916c,c034916c,c0349001) at backtrace+0x17
witness_lock(c082f110,8,c0349001,149,c082f0b0) at witness_lock+0x671
_mtx_lock_flags(c082f110,0,c0349001,149,101) at _mtx_lock_flags+0xb2
_vm_map_lock(c082f0b0,c0349001,149,c0397d08,c0397d30) at _vm_map_lock+0x36
kmem_malloc(c082f0b0,1000,101,e7866b18,c02c59e0) at kmem_malloc+0x3a
page_alloc(c083a200,1000,e7866b0b,101,0) at page_alloc+0x27
slab_zalloc(c083a200,101,c083a214,8,c034a980) at slab_zalloc+0xc0
uma_zone_slab(c083a200,101,c034a980,695,0) at uma_zone_slab+0xd4
uma_zalloc_internal(c083a200,0,101,719,0) at uma_zalloc_internal+0x4f
uma_zfree_arg(c083a800,c686e000,0,e7866bc4,c02add19) at uma_zfree_arg+0x2a0
dev_pager_putfake(c686e000,0,c03486e4,bd,c6856de0) at dev_pager_putfake+0x34
dev_pager_dealloc(c6856de0,1,c034a909,104,0) at dev_pager_dealloc+0xb9
vm_pager_deallocate(c6856de0,0,c0349abb,261,1b2) at vm_pager_deallocate+0x3d
vm_object_terminate(c6856de0,0,c0349abb,1b2,c680d078) at vm_object_terminate+0x1e3
vm_object_deallocate(c6856de0,c67dad98,c6856de0,c67dad98,e7866ca0) at 
vm_object_deallocate+0x359
vm_map_entry_delete(c6490c00,c67dad98,c03491e2,8a4,c01cd655) at 
vm_map_entry_delete+0x3b
vm_map_delete(c6490c00,282e5000,282e6000,1000,282e5000) at vm_map_delete+0x3c0
vm_map_remove(c6490c00,282e5000,282e6000,0,c67d69e0) at vm_map_remove+0x55
munmap(c648b5f0,e7866d14,c034edf9,3eb,2) at munmap+0x9e
syscall(2f,2f,2f,f8000,1000) at syscall+0x253
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (73), eip = 0x28256c2f, esp = 0xbfbff99c, ebp = 0xbfbff9c8 ---


pgp0.pgp
Description: PGP signature

Re: status of nsswitch.conf in current?

[Gordon Tetlow]

On Fri, Aug 22, 2003 at 11:15:01AM -0700, Tim Kientzle wrote:
> Ruslan Ermilov wrote:
> >On Fri, Aug 22, 2003 at 10:40:32AM -0400, Richard Coleman wrote:
> >
> >>I saw that.  I guess my question is whether a default nsswitch.conf file 
> >>will be checked into /etc and /usr/share/examples/etc, or whether it 
> >>will be left empty?  I would expect that if this capability was working, 
> >>that a default nsswitch.conf would be checked into /etc.
> >>
> >
> >Adding /etc/nsswitch.conf with the default settings would just slow the
> >things down.  For the same reason, we don't provide /etc/resolv.conf by
> >default.  Adding src/share/examples/etc/nsswitch.conf and installing it
> >in /usr/share/examples/etc/ is a good idea.
> 
> On the other hand, having
> 
> /etc/nsswitch.conf.example
> 
> would
>   a) Advertise the existence of nsswitch capabilities in
>  an obvious place where people new to FreeBSD would
>  see it.
>   b) Document the defaults.
>   c) Not slow anything down.
>   d) Serve as an example and template for people just
>  getting started..
e) clutter /etc with a file that serves no purpose other than
   illustration.

It should either go in as /etc/nsswitch.conf or into
/usr/share/examples/etc.

-gordon


pgp0.pgp
Description: PGP signature

Re: HEADS UP: dynamic root support now in the tree

[Gordon Tetlow]

On Sun, Aug 17, 2003 at 06:48:23PM -0700, David O'Brien wrote:
> On Sun, Aug 17, 2003 at 01:54:38AM -0700, Gordon Tetlow wrote:
> > I just got through with my commit spree to enable users to build /bin
> > and /sbin dynamically linked. To do this required a fair amount of
> > tweaking and moving around libraries and such dangerous equipment as
> 
> I think this is a more correct way to change the install locations of the
> / needed libs.  Your current way makes the real location a "2nd class
> citizen" vs. /usr/lib for any needed compatibility links.
> 
> I'd like to commit this:

[snip patch changing SHLIBDIR to LIBDIR]

I think this is a bad idea because all of the .a archives will end up in
/lib. Seeing how those aren't necessary for running binaries in /bin and
/sbin, I'd rather they stay in /usr/lib (which means LIBDIR shouldn't
change if I'm reading the Makefile glue correctly).

-gordon


pgp0.pgp
Description: PGP signature

Re: [current tinderbox] failure on alpha/alpha

[Gordon Tetlow]

On Sun, Aug 17, 2003 at 12:58:12PM -0400, Tinderbox wrote:
> >>> stage 4: building everything..
> [...]
> cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee 
> -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure/libexec/sftp-server/../../../crypto/openssh
>  -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/bin/ld:
>  warning: libz.so.2, needed by 
> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so,
>  not found (try using -rpath or -rpath-link)

I have a patch to fix this that I'm currently waiting on DES to approve.

-gordon


pgp0.pgp
Description: PGP signature

Re: HEADS UP: dynamic root support now in the tree

[Gordon Tetlow]

On Sun, Aug 17, 2003 at 01:54:38AM -0700, Gordon Tetlow wrote:
> I just got through with my commit spree to enable users to build /bin
> and /sbin dynamically linked. To do this required a fair amount of
> tweaking and moving around libraries and such dangerous equipment as
> rtld-elf. If you have any systems that you are dearly in love with,
> now is not the time to cvsup. Please wait until any potential issues
> are shaken out of the tree. I've done as much testing as I can, but
> as experience has shown me, there are likely to be issues.

Just to clear everything up. A dynamically-linked /sbin and /bin is
still not the default. In order to build a dynamically-linked /sbin
and /bin requires you to define WITH_DYNAMICROOT. Sorry for the
confusion.

-gordon


pgp0.pgp
Description: PGP signature

Re: HEADS UP: dynamic root support now in the tree

[Gordon Tetlow]

On Sun, Aug 17, 2003 at 11:51:36AM -0700, Gordon Tetlow wrote:
> On Sun, Aug 17, 2003 at 08:47:42PM +0900, Shin-ichi Yoshimoto wrote:
> > make installworld broken.
> > 
> > ==>libexex/rtld-elf
> > [snip]
> > ln: /usr/libexec/ld-elf.so.1: Operation not permitted
> > *** Error code 1
> > 
> > any idea ?
> 
> Thanks for reporting this. I've fixed it in rev 1.22 of
> src/libexec/rtld-elf/Makefile.

Silly me forgot to honor DESTDIR. rev 1.23 is much better =)

-gordon


pgp0.pgp
Description: PGP signature

Re: HEADS UP: dynamic root support now in the tree

[Gordon Tetlow]

On Sun, Aug 17, 2003 at 08:47:42PM +0900, Shin-ichi Yoshimoto wrote:
> make installworld broken.
> 
> ==>libexex/rtld-elf
> [snip]
> ln: /usr/libexec/ld-elf.so.1: Operation not permitted
> *** Error code 1
> 
> any idea ?

Thanks for reporting this. I've fixed it in rev 1.22 of
src/libexec/rtld-elf/Makefile.

-gordon


pgp0.pgp
Description: PGP signature

HEADS UP: dynamic root support now in the tree

[Gordon Tetlow]

I just got through with my commit spree to enable users to build /bin
and /sbin dynamically linked. To do this required a fair amount of
tweaking and moving around libraries and such dangerous equipment as
rtld-elf. If you have any systems that you are dearly in love with,
now is not the time to cvsup. Please wait until any potential issues
are shaken out of the tree. I've done as much testing as I can, but
as experience has shown me, there are likely to be issues.

IA64 users (both of you), do not attempt to build the world using
WITH_DYNAMICROOT! This is guaranteed to fail! I'm currently working
on getting ahold of a toolchain expert to work out the one outstanding
issue with this platform.

Thank you for being patient and please follow up with me if there are
*any* issues. There is a huge potential for foot-shooting here that I
hope to have mitigated but it is possible that I might have missed
something.

Now that all the grim stuff is out of the way, a couple of nice
benefits to building your world WITH_DYNAMICROOT:

1) Space savings. A statically linked /bin and /sbin is 32 MB on
   i386. A dynamically linked /bin and /sbin is only 12 MB (including
   /lib, /libexec, and /rescue)

2) NSS support. You are now able to use a dynamically loaded nss
   module for passwd and group maps and have things like ls(1) and
   tcsh(1) grok uids and gids coming from those sources.

-gordon


pgp0.pgp
Description: PGP signature

LOR in sound subsystem

[Gordon Tetlow]

From yesterday's build, 2 different LORs:

acquiring duplicate lock of same type: "pcm channel"
 1st pcm0:record:0 @ /local/usr.src/sys/dev/sound/pcm/sound.c:191
 2nd pcm0:play:0 @ /local/usr.src/sys/dev/sound/pcm/sound.c:191
Stack backtrace:
backtrace(c052152d,c620a054,c0716750,bf,246) at backtrace+0x17
witness_lock(c621fb00,8,c0716750,bf,c620a000) at witness_lock+0x671
_mtx_lock_flags(c621fb00,0,c0716750,bf,3) at _mtx_lock_flags+0xb2
pcm_chnalloc(c6211000,1,1c8e,,8) at pcm_chnalloc+0x49
dsp_open(c05de290,7,2000,c6912000,c69cab80) at dsp_open+0x14f
spec_open(e6f4ba5c,e6f4bb18,c03827e8,e6f4ba5c,c05e52a0) at spec_open+0x28b
spec_vnoperate(e6f4ba5c,c05e52a0,c05e6010,180,c6912000) at spec_vnoperate+0x18
vn_open_cred(e6f4bbc4,e6f4bcc4,0,c69cab80,6) at vn_open_cred+0x528
vn_open(e6f4bbc4,e6f4bcc4,0,6,c0573924) at vn_open+0x30
kern_open(c6912000,c649bc00,1,7,0) at kern_open+0x13a
linux_open(c6912000,e6f4bd14,c053a57e,3ee,3) at linux_open+0x11e
syscall(2f,2f,2f,0,bfbff290) at syscall+0x253
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (5), eip = 0x283716b4, esp = 0xbfbff258, ebp = 0xbfbff2b8 ---

lock order reversal
 1st 0xc621fec0 pcm0 (sound softc) @ /local/usr.src/sys/dev/sound/pci/cmi.c:520
 2nd 0xc621fb00 pcm0:play:0 (pcm channel) @ /local/usr.src/sys/dev/sound/pcm/cha
nnel.c:440
Stack backtrace:
backtrace(c05215e4,c621fb00,c620a054,c07161f3,c0716271) at backtrace+0x17
witness_lock(c621fb00,8,c0716271,1b8,c620a000) at witness_lock+0x671
_mtx_lock_flags(c621fb00,0,c0716271,1b8,80c1) at _mtx_lock_flags+0xb2
chn_intr(c620a000,c,1,208,c621fdc0) at chn_intr+0x2f
cmi_intr(c620a400,0,c051c223,215,c61cb3c8) at cmi_intr+0xa0
ithread_loop(c61cfd80,df0ebd48,c051c07d,30e,c61cfd80) at ithread_loop+0x164
fork_exit(c030d9a0,c61cfd80,df0ebd48) at fork_exit+0xc0
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xdf0ebd7c, ebp = 0 ---

FWIW, I'm using cmi (obviously) and I have the following in my
/etc/sysctl.conf:

hw.snd.pcm0.vchans=4
hw.snd.maxautovchans=4

Hope it helps.

-gordon


pgp0.pgp
Description: PGP signature

Re: Buildworld /rescue failures in 5.1

[Gordon Tetlow]

On Wed, Jul 23, 2003 at 10:13:20PM -0400, Garance A Drosihn wrote:
> At 8:14 PM -0400 7/23/03, Garance A Drosihn wrote:
> >
> >So indeed, that 'make depend' had not finished before
> >the 'make' for the object had started.
> 
> I was going to do some debugging of what 'make' is doing, but
> it looks like crunchgen gets confused if make has any kind of
> debugging flags turned on.  However, I have to get back to my
> real-job work before my manager clobbers me, so this is
> probably as far as I'm going to take this for now.

I just committed 1.14 of src/rescue/rescue/Makefile that should
fix the -j build with rescue. Please let me know if it doesn't
work. Otherwise, I'm heading to bed. Night.

-gordon


pgp0.pgp
Description: PGP signature

Re: Buildworld /rescue failures in 5.1

[Gordon Tetlow]

On Wed, Jul 23, 2003 at 07:41:18PM -0400, Garance A Drosihn wrote:
> 
> So it is easy to image that this .depend file is crucial to
> successfully making addext.o.
> 
> The .depend file is apparently created by
> /usr/obj/usr/src/rescue/rescue/rescue.mk
> 
> and that in turn says it is generated from rescue.conf
> by crunchgen 0.2.  The rescue.mk file includes the rule:
> 
> tar_make:
> (cd $(tar_SRCDIR) && \
> $(MAKE) $(BUILDOPTS) $(tar_OPTS) depend &&\
> $(MAKE) $(BUILDOPTS) $(tar_OPTS) $(tar_OBJS))
> 
> and my guess is that construct is not '-j' safe.
> 
> I have no idea how to fix that, or even if I'm on the right
> track, but perhaps the above will be useful to someone who
> understands parallel makes more than I do...

I don't see how this construct cannot be parallel make safe.
The && requires that the third line check the result of the
second before continuing. It doesn't make sense.

-gordon


pgp0.pgp
Description: PGP signature

Re: Buildworld fails in 5.1

[Gordon Tetlow]

On Mon, Jul 21, 2003 at 09:36:37AM -0700, Tim Kientzle wrote:
> Gordon Tetlow wrote:
> >It seems that the $(OUTPUTS) target (which has 3 components) causes
> >this particular error.
> >
> >+.ORDER: $(OUTPUTS)
> > $(OUTPUTS): $(CONF)
> >MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) 
> >\
> >$(CONF)
> 
> Hmmm...  Is that what .ORDER is for?  To work around a
> parallel make that gratuitously rebuilds things?

Right it serializes build dependencies. The problem with crunchgen is
that a single command makes all of the OUTPUTS, so normally make will
spawn off the same command 3 times in parallel (which seems to cause
problems). To get around it, make it so you each of the OUTPUTS is
built in order and what occurs is a single crunchgen invocation that
the sees that the other OUTPUT targets are up-to-date and then
contintues along.

> >After doing that, I run into a problem with clparse.o from the dhclient
> >build. I think I might have a solution for that, but I'm too tired
> >right now to think straight. I'll look at it tomorrow.
> 
> 
> A-ha!  I've known that dhclient was a problem, but the
> above gives me an idea.  I wonder if the following helps?

I'll give it a whirl.

-gordon


pgp0.pgp
Description: PGP signature

Re: Buildworld fails in 5.1

[Gordon Tetlow]

On Fri, Jul 18, 2003 at 11:39:53AM -0700, Tim Kientzle wrote:
> 
> I wrote the /rescue stuff and a lot of people have
> reported that it breaks parallel builds, but I haven't yet
> come up with anything.  (In part, because I haven't yet
> managed to reproduce it. )
> 
> A couple of things look odd about this:
> 
> 1) You should not be building 'rescue.mk' twice.
>That could be the problem right there, if the rescue.mk
>makefile is getting rebuilt (overwritten) while another
>build thread is using it.  The dependencies in
>rescue/rescue/Makefile look right to me, but I
>could be missing something.

It seems that the $(OUTPUTS) target (which has 3 components) causes
this particular error. It can be easily avoided with the following
patch (against an older version of src/rescue/rescue/Makefile,
should be fine):

(Whitespace is probably messed up)
 //depot/user/gordon/dynamic/src/rescue/rescue/Makefile#7 - /home/gtetlow/p4
/dynamic/src/rescue/rescue/Makefile 
@@ -244,6 +244,7 @@
 .endfor


+.ORDER: $(OUTPUTS)
 $(OUTPUTS): $(CONF)
MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) \
$(CONF)


After doing that, I run into a problem with clparse.o from the dhclient
build. I think I might have a solution for that, but I'm too tired
right now to think straight. I'll look at it tomorrow.

-gordon


pgp0.pgp
Description: PGP signature

Re: Overdone rescue cleaning as part of buildworld?

[Gordon Tetlow]

On Mon, Jul 14, 2003 at 03:48:33PM -0700, Tim Kientzle wrote:
> Gordon Tetlow wrote:
> >Attached is the patch. It basically makes CRUNCH_PROGS into a per
> >directory item and then only does a make obj on the per program
> >directory.
> 
> Hmmm  I do have a philosophical quibble with your
> approach:  My original intent for this Makefile was
> that the top part was rescue-specific and the bottom
> part would be sufficiently generic to be used in other
> crunchgen-based projects.
> 
> Your patches embed a certain amount of /rescue-specific knowledge
> into the generic portion of the Makefile. For example,
> >+cd $(.CURDIR)/../../${D}/${P} 
> makes a prett strong assumption about the relative
> locations of the crunchgen-using source directory
> and its components.

That could probably be solved with a bit of make-foo. I'll see if I
can work that up. But I don't think it's going to be a huge priority.

-gordon


pgp0.pgp
Description: PGP signature

Re: Overdone rescue cleaning as part of buildworld?

[Gordon Tetlow]

On Mon, Jul 14, 2003 at 03:15:01PM -0700, Tim Kientzle wrote:
> Gordon Tetlow wrote:
> >On Mon, Jul 14, 2003 at 12:44:05PM -0700, Tim Kientzle wrote:
> >>Gordon Tetlow wrote:
> >>>>On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote:
> >>>>>It appears /rescue is cleaning for way too much as part of buildworld.
> >>>>>For instance, groff is NOT part of /rescue (or we have other things to
> >>>>>discuss. :)  This adds a bit of time to buildworld, can it be removed?
> >>>>
> >>Yeah, I took a few shortcuts; /rescue does build far more in
> >>OBJDIR than it needs to, and similarly cleans much more than it needs
> >>to.  (Those extra dirs are never populated, but building and cleaning
> >>them does still take time.)  I believe the attached patch addresses
> >>this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to
> >>just the directories actually needed.
> >
> >This solution is kinda hackish, I have a more generic solution that makes
> >it easier to add programs without having to specifically add
> >CRUNCH_SRCDIR_foo to every program outside of src/bin and src/sbin. I'm
> >hoping to iron out the wrinkles today and post the patches. Other than
> >that the patch is pretty much complete.
> 
> Great!  Looking forward to it.

Attached is the patch. It basically makes CRUNCH_PROGS into a per
directory item and then only does a make obj on the per program
directory. I've incorporated the CRUNCH_SRCDIR_foo stuff you had
although I had come up with a similar solution.

It's lightly tested, some more eyes looking at it would be useful.
I'm currently running it through a buildworld.

-gordon
--- //depot/vendor/freebsd/src/rescue/rescue/Makefile   2003/07/11 10:38:05
+++ //depot/user/gordon/dynamic/src/rescue/rescue/Makefile  2003/07/14 13:04:49
@@ -1,4 +1,4 @@
-#$FreeBSD: src/rescue/rescue/Makefile,v 1.6 2003/07/11 16:57:43 gordon Exp $
+#$FreeBSD: src/rescue/rescue/Makefile,v 1.5 2003/06/30 21:13:56 gordon Exp $
 #  @(#)Makefile8.1 (Berkeley) 6/2/93
 
 PROG=  rescue
@@ -66,9 +66,9 @@
 # WARNING: Changing this list may require adjusting
 # /usr/include/paths.h as well!  You were warned!
 #
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin $(.CURDIR)/../../usr.bin
-CRUNCH_PROGS=cat chflags chio chmod cp date dd df domainname echo ed   \
-expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd  \
+CRUNCH_SRCDIRS+=bin
+CRUNCH_PROGS_bin=cat chflags chio chmod cp date dd df domainname echo  \
+ed expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd   \
 realpath rm rmdir setfacl sh sleep stty sync test
 CRUNCH_LIBS+=-lcrypt -lcrypto -ledit -lkvm -ll -lm -ltermcap -lutil
 
@@ -82,18 +82,18 @@
 CRUNCH_ALIAS_ed= red
 
 .if !defined(NO_RCMNDS)
-CRUNCH_PROGS+= rcp
+CRUNCH_PROGS_bin+= rcp
 .endif
 
 .if !defined(NO_TCSH)
-CRUNCH_PROGS+= csh
+CRUNCH_PROGS_bin+= csh
 CRUNCH_ALIAS_csh= -csh tcsh -tcsh
 CRUNCH_SUPPRESS_LINK_-csh=1
 CRUNCH_SUPPRESS_LINK_-tcsh=1
 .endif
 
 #Is rmail of any use at all here?  I think not.
-#CRUNCH_PROGS+= rmail  
+#CRUNCH_PROGS_bin+= rmail  
 
 ###
 # Programs from standard /sbin
@@ -104,8 +104,8 @@
 # Note that mdmfs and shutdown have their own private 'pathnames.h'
 # headers in addition to the standard 'paths.h' header.
 #
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../sbin
-CRUNCH_PROGS+=atm adjkerntz atacontrol badsect bsdlabel camcontrol \
+CRUNCH_SRCDIRS+=sbin
+CRUNCH_PROGS_sbin=atm adjkerntz atacontrol badsect bsdlabel camcontrol \
ccdconfig clri comcontrol conscontrol devfs dmesg dump  \
dumpfs dumpon fore_dnld fsck fsck_ffs fsck_msdosfs fsdb \
fsirand gbde growfs ifconfig ilmid init ip6fw ipf ipfs ipfstat  \
@@ -124,7 +124,7 @@
-lgeom -lmd -lreadline -lsbuf -lufs -lz 
 
 .if ${MACHINE_ARCH} == "i386"
-CRUNCH_PROGS+= cxconfig fdisk
+CRUNCH_PROGS_sbin+= cxconfig fdisk
 CRUNCH_ALIAS_bsdlabel= disklabel
 #CRUNCH_PROGS+= mount_nwfs mount_smbfs
 #CRUNCH_LIBS+= -lncp -lsmb
@@ -135,11 +135,11 @@
 .endif
 
 .if ${MACHINE_ARCH} == "ia64"
-CRUNCH_PROGS+= mca gpt fdisk
+CRUNCH_PROGS_sbin+= mca gpt fdisk
 .endif
 
 .if ${MACHINE_ARCH} == "sparc64"
-CRUNCH_PROGS+= sunlabel
+CRUNCH_PROGS_sbin+= sunlabel
 .endif
 
 .if ${MACHINE_ARCH} == "alpha"
@@ -147,7 +147,7 @@
 .endif
 
 .if ${MACHINE_ARCH} == "amd64"
-CRUNCH_PROGS+= fdisk
+CRUNCH_PROGS_sbin+= fdisk
 CRUNCH_ALIAS_bsdlabel= disklabel
 .endif
 
@@ -162,26 +162,26 @@
 CRUNCH_ALIAS_mount_std= mount_devfs mount_fdescfs mount_linprocfs mount_procfs
 
 # dhclient has historically been troublesome...
-CRUNCH_PROGS+=dhclient
+CRUNCH_PROGS_sbin+=dhclient
 CRUNCH_BUILDOPTS_dhclient=-DRELEASE_CRUNCH -Dlint
 
 ##

Re: Overdone rescue cleaning as part of buildworld?

[Gordon Tetlow]

On Mon, Jul 14, 2003 at 12:44:05PM -0700, Tim Kientzle wrote:
> Gordon Tetlow wrote:
> >On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote:
> >>On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote:
> >>>It appears /rescue is cleaning for way too much as part of buildworld.
> >>>For instance, groff is NOT part of /rescue (or we have other things to
> >>>discuss. :)  This adds a bit of time to buildworld, can it be removed?
> 
> Yeah, I took a few shortcuts; /rescue does build far more in
> OBJDIR than it needs to, and similarly cleans much more than it needs
> to.  (Those extra dirs are never populated, but building and cleaning
> them does still take time.)  I believe the attached patch addresses
> this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to
> just the directories actually needed.

This solution is kinda hackish, I have a more generic solution that makes
it easier to add programs without having to specifically add
CRUNCH_SRCDIR_foo to every program outside of src/bin and src/sbin. I'm
hoping to iron out the wrinkles today and post the patches. Other than
that the patch is pretty much complete.

-gordon


pgp0.pgp
Description: PGP signature

Re: Overdone rescue cleaning as part of buildworld?

[Gordon Tetlow]

On Mon, Jul 14, 2003 at 01:53:29PM -0400, Garance A Drosihn wrote:
> At 9:09 AM -0700 7/14/03, Gordon Tetlow wrote:
> >On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote:
> > > Gordon, 'make world' times have climbed up to over 1 hour
> > > on a machine that used to do it in 25 minutes.  Can you
> > > please commit to understanding how /resuce is build and
> >optimizing it before 5.2-RELEASE.
> >
> >I've already started this process and I have some work ...
> 
> Btw, when I was doing a buildworld this weekend, I noticed
> the following error in the section that builds /rescue.  Has
> anyone else noticed this?  It may be easy to miss, because
> 'make buildworld' does not abort at the error.  The following
> is some information I sent to Tim Kientzle <[EMAIL PROTECTED]>
> early this morning, but I thought I'd send it to the list just
> to see if anyone else has seen this problem.  Perhaps it is
> due to something at my end of things.
> 
> For me, 'make buildworld' goes through:
>===> rescue/rescue/dhcpctl
>===> rescue/rescue/client
>===> rescue/rescue/omshell
> 
> successfully, and then while building:
>   ===> rescue/rescue/common
> 
> Here is the last few lines I get:
> 
> cc -O -pipe -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H 
> -DPREFIX=\"/usr\" 
> -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools 
> -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools 
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc 
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config 
> -DHAVE_CONFIG_H -DTARGET_NAME=\"i386-undermydesk-freebsd\" -DIN_GCC 
> -c /usr/src/contrib/gcc/make-temp-file.c
> make: don't know how to make 
> /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. 
> Stop
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 
> Now, after those Error's, make seems to go merrily along, and
> makes bunch of other stuff.  It looks like it even gets to the
> end of the buildworld OK. However the way I do buildworld's
> notices those '*** Error' lines, and it starts waving flags at
> me.  I am generally reluctant to ignore those flags...
> 
> I did a bunch of cvsup's and cross-checks to make sure I had
> the correct up-to-the-minute sources.  I had also removed
> all of /usr/obj/usr/src in case I had old cruft there (well,
> actually I did that just because of the new gcc import...).
> I rebuilt with -DNORESCUE and the buildworld finished OK.
> 
> I am building with -j5 on a dual-processor Athlon system, if
> that is significant.  I am not doing any cross-build.

I've heard some reports of this specifically with -j flag. I'll
see if I can look at it once I finish depessimizing the build.

-gordon


pgp0.pgp
Description: PGP signature

Re: Overdone rescue cleaning as part of buildworld?

[Gordon Tetlow]

On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote:
> On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote:
> > It appears /rescue is cleaning for way too much as part of buildworld.
> > For instance, groff is NOT part of /rescue (or we have other things to
> > discuss. :)  This adds a bit of time to buildworld, can it be removed?
> 
> Gordon, 'make world' times have climbed up to over 1 hour on a machine
> that used to do it in 25 minutes.  Can you please commit to understanding
> how /resuce is build and optimizing it before 5.2-RELEASE.

I've already started this process and I have some work in a local tree
to depessimize the build dramatically. Thank you for the reminder. Would
you be interested in taking a look at the patches?

-gordon


pgp0.pgp
Description: PGP signature

Re: [-CURRENT tinderbox] failure on i386/i386

[Gordon Tetlow]

On Wed, Jul 02, 2003 at 05:48:47PM +, Tinderbox wrote:
> TB --- 2003-07-02 17:10:04 - starting CURRENT tinderbox run for i386/i386
> TB --- 2003-07-02 17:10:04 - checking out the source tree
> TB --- cd /home/des/tinderbox/CURRENT/i386/i386
> TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
> TB --- 2003-07-02 17:12:14 - building world
> TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
> TB --- /usr/bin/make -B buildworld
> >>> Rebuilding the temporary build tree
> >>> stage 1: legacy release compatibility shims
> >>> stage 1: bootstrap tools
> >>> stage 2: cleaning up the object tree
> >>> stage 2: rebuilding the object tree
> >>> stage 2: build tools
> >>> stage 3: cross tools
> >>> stage 4: populating 
> >>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include
> >>> stage 4: building libraries
> >>> stage 4: make dependencies
> [...]
> mkdep -f .depend -a-DINET6 -DIPSEC  
> /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/mld6query/mld6.c
> echo mld6query: 
> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libc.a
>   >> .depend
> ===> usr.sbin/mlxcontrol
> rm -f .depend
> mkdep -f .depend -a
> -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/mlxcontrol/../../sys  
> /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/mlxcontrol/command.c 
> /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/mlxcontrol/config.c 
> /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/mlxcontrol/interface.c 
> /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/mlxcontrol/util.c
> echo mlxcontrol: 
> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libc.a
>   >> .depend
> ===> usr.sbin/mount_portalfs
> make: don't know how to make getmntopts.c. Stop
> *** Error code 2

I don't know how I do it, there was a 21 minute window before
this problem was solved. I guess I just have bad luck.

-gordon


pgp0.pgp
Description: PGP signature

Re: rescue/ broke cross compiles

[Gordon Tetlow]

On Mon, Jun 30, 2003 at 03:52:06PM -0700, Marcel Moolenaar wrote:
> 
> Since you create a seperate object tree for rescue, you need to
> go through the same phases as a world does. That way tools (like
> build-tools) will be compiled against the right headers and linked
> against the right libraries (in both cases those of the machine
> on which the tool runs).
> 
> Unfortunately, it's not that simple. There's a deliberate phase
> ordering that makes sure that we don't pick up cross-tools before
> we're ready for them. Since rescue is built *after* the cross-
> tools are installed, you'll have a hard time resolving the phase
> ordering problem.
> 
> That's why ru@ suggested to add a build-tools target. That way you
> populate the seperate tree in sync with the phases of a world,
> thereby avoiding the phase ordering problem.

Is there a way to leverage the existing build-tools so we don't have
to do extra compiling that isn't necessary?

-gordon


pgp0.pgp
Description: PGP signature

Re: rescue/ broke cross compiles

[Gordon Tetlow]

On Tue, Jul 01, 2003 at 01:23:53AM +0300, Ruslan Ermilov wrote:
> Hi there!
> 
> As seen by the latest series of tinderbox failures,
> the rescue/ stuff breaks cross compiles.  The problem
> is that some bits like bin/sh have the so-called
> "build tools".  These are small utilities not normally
> visible in the world except during the build stage.
> As such, "make buildworld" builds them in the native
> host's environment (using the host compiler, headers,
> libraries, and binutils).  The /rescue should have
> such a target too (build-tools), that would in effect
> call the build-tools targets in all makefiles that
> have it, e.g. bin/sh/Makefile.

I'm the first to admit my Make-foo is lacking. I'm not sure
I understand why /rescue needs build-tools bits. Can you help
enlighten me?

-gordon


pgp0.pgp
Description: PGP signature

Re: [-CURRENT tinderbox] failure on i386/pc98

[Gordon Tetlow]

On Sun, Jun 29, 2003 at 08:13:15PM +, Tinderbox wrote:
>
> mkdep -f .depend -a  
> /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/mdmfs/mdmfs.c
> /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/mdmfs/mdmfs.c:53:23: 
> pathnames.h: No such file or directory
> mkdep: compile failed
> *** Error code 1

This was fixed in 1.15 of mdmfs.c

-gordon


pgp0.pgp
Description: PGP signature

Re: SMBFS automounting broken?

[Gordon Tetlow]

On Wed, Jun 04, 2003 at 06:57:09PM -0400, The Anarcat wrote:
> Hi!
> 
> Recently, I noticed that my samba shares were not automounted on
> boot.
> 
> What I understand of it is that netfs_types is defined in
> rc.d/mountcritlocal, but not in rc.d/mountcritremote, which makes the
> code:

You are a little late. I committed a solution to this problem on
the 1st. I asked re@ for permission to MFC but that request was
denied (understandably from my point of view).

-gordon


pgp0.pgp
Description: PGP signature

Re: geom_vol_ffs problems

[Gordon Tetlow]

On Fri, Jun 06, 2003 at 07:38:36PM +0200, Per Kristian Hove wrote:
> I've nailed it down to this: geom_vol_ffs assumes that a file system
> is able to fill the partition completely. That's not a valid
> assumption, since the file system size is a multiple of the file
> system block size (in my case 16k bytes = 32 blocks), and the
> partition size is/should be a multiple of the sectors/cylinder count
> (in my case 1008).

Thanks for doing this analysis. I've run into the same thing here at
work but I just haven't had any time to debug it. I'll see if I can
work something up that'll address this problem.

-gordon


pgp0.pgp
Description: PGP signature

LOR in kern_thread.c

[Gordon Tetlow]

I was playing with libkse and got the follow LOR:

lock order reversal
 1st 0xc6ce0aa8 sigacts (sigacts) @ /local/usr.src/sys/kern/subr_trap.c:248
 2nd 0xc6cbc250 process lock (process lock) @ /local/usr.src/sys/kern/kern_threa
d.c:1439
Stack backtrace:
backtrace(c04fd0b6,c6cbc250,c04f9a3a,c04f9a3a,c04fae7a) at backtrace+0x17
witness_lock(c6cbc250,8,c04fae7a,59f,c6bb8130) at witness_lock+0x692
_mtx_lock_flags(c6cbc250,0,c04fae7a,59f,c6cbc1e4,2,0,0,0) at _mtx_lock_flags+0xb
2
thread_signal_add(c6bb8130,2,c04fa4c7,85e,280a1e20) at thread_signal_add+0xe1
postsig(2,0,c04fcb3a,f8,20800) at postsig+0x34f
ast(e98d9d48) at ast+0x41d
doreti_ast() at doreti_ast+0x17

-gordon


pgp0.pgp
Description: PGP signature

Re: LOR on libthr exit (iirc)

[Gordon Tetlow]

On Fri, Apr 04, 2003 at 04:31:00PM -0600, Dan Nelson wrote:
> In the last episode (Apr 02), Jeff Roberson said:
> > On Wed, 2 Apr 2003, Gordon Tetlow wrote:
> > 
> > > I think it was a libthr linked app after I killed it:
> > 
> > Yeah, this is a problem with the thread single exit and suspend code. 
> > I haven't fixed it yet.  Thanks for the report.
> 
> I get the same LOR message on my machine, but it is always immediately
> followed by a panic.  libthr also seems to only work with WITNESS. 
> Without it the machine locks up hard (serial debugger doesn't even
> respond) when you start any libthr-linked app.

Well, I'm running the SMP config which does have WITNESS in it.

-gordon


pgp0.pgp
Description: PGP signature

Yet another libthr crash

[Gordon Tetlow]

I'm just hitting all the fun bugs today.

No core dump from this one. Privoxy seems to be a good app to test
multiple io threads and is simple enough to be debug.

Here's what I got this time:

$ /usr/local/sbin/privoxy --no-daemon /usr/local/etc/privoxy/config
Apr 03 15:50:49 Privoxy(134709248) Info: loading configuration file 
'/usr/local/etc/privoxy/config':
...
Apr 03 15:51:09 Privoxy(134922240) Request: www.dilbert.com/images/ff_dot.gif
Apr 03 15:51:09 Privoxy(134922240) Error: could not resolve hostname www.dilbert.com
Apr 03 15:51:09 Privoxy(134925312) Request: 
www.dilbert.com/comics/dilbert/images/dilbertawards_250x50.gif
Apr 03 15:51:09 Privoxy(134992896) Request: 
www.dilbert.com/comics/dilbert/images/current_features_bullet.gif
gif
Apr 03 15:51:09 Privoxy(134992896) Request: 
www.dilbert.com/comics/dilbert/images/current_features_bullApr 03 15:51:09 
Privoxy(134929408) Request: 
www.dilbert.com/comics/dilbert/images/current_features_border_righFatal error 'Illegal 
call from signal handler' at line 1542 in file 
/local/usr.src/lib/libthr/thread/thr_mutex.c (errno = 2)
$

Kind of odd how the requests are interleaved. And then it seems to have
died somewhere in thr_mutex.c::mutex_queue_enq().

-gordon


pgp0.pgp
Description: PGP signature

Re: core dump with libthr

[Gordon Tetlow]

I forgot to mention, this is on a dual Athlon MP 1900+. Here's the
appropriate part of the dmesg:

CPU: AMD Athlon(TM) MP 1900+ (1600.07-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x662  Stepping = 2
  
Features=0x383fbff
  AMD Features=0xc048
real memory  = 1073659904 (1023 MB)
avail memory = 1035481088 (987 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00040010, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040010, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0

-gordon


pgp0.pgp
Description: PGP signature

core dump with libthr

[Gordon Tetlow]

I got a userland core dump while using privoxy linked against libthr.
I don't know if this is libthr specific, but I thought I would report
it anyway. This might also explain why kde apps always crash on exit
(possibly, not really sure).

-gordon

GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
(no debugging symbols found)...
Core was generated by `privoxy'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libthr.so.1...done.
Loaded symbols for /usr/lib/libthr.so.1
Reading symbols from /usr/lib/libc.so.5...done.
Loaded symbols for /usr/lib/libc.so.5
Reading symbols from /usr/libexec/ld-elf.so.1...done.
Loaded symbols for /usr/libexec/ld-elf.so.1
#0  0x28156824 in flockfile () from /usr/lib/libc.so.5
(gdb) bt
#0  0x28156824 in flockfile () from /usr/lib/libc.so.5
#1  0x2813c33a in fgets () from /usr/lib/libc.so.5
#2  0x28136b60 in gethostent () from /usr/lib/libc.so.5
#3  0x28136d87 in _ht_gethostbyname () from /usr/lib/libc.so.5
#4  0x28136663 in nsdispatch () from /usr/lib/libc.so.5
#5  0x28135eac in gethostbyname2 () from /usr/lib/libc.so.5
#6  0x28135e35 in gethostbyname () from /usr/lib/libc.so.5
#7  0x0805a923 in getsockname ()
#8  0x0805a3f6 in getsockname ()
#9  0x0805a090 in getsockname ()
#10 0x0805b0f7 in getsockname ()
#11 0x0805bd14 in getsockname ()
#12 0x2809c0f1 in _thread_start (thread=0x809df40)
at /local/usr.src/lib/libthr/thread/thr_create.c:216
#13 0x28140f33 in _ctx_start () from /usr/lib/libc.so.5
(gdb) frame 12
#12 0x2809c0f1 in _thread_start (thread=0x809df40)
at /local/usr.src/lib/libthr/thread/thr_create.c:216
216 pthread_exit(thread->start_routine(thread->arg));
(gdb) list
211 _thread_start(pthread_t thread)
212 {
213 thread->arch_id = _set_curthread(thread);
214 
215 /* Run the current thread's start routine with argument: */
216 pthread_exit(thread->start_routine(thread->arg));
217 
218 /* This point should never be reached. */
219 PANIC("Thread has resumed after exit");
220 }


pgp0.pgp
Description: PGP signature

Re: libthr and 1:1 threading.

[Gordon Tetlow]

On Wed, Apr 02, 2003 at 06:37:21PM -0500, Daniel Eischen wrote:
> On Wed, 2 Apr 2003, Peter Wemm wrote:
> 
> > Terry Lambert wrote:
> > 
> > > KSE mailing list, starting Monday or so:
> > > ] We still haven't heard from jeff with regard to the process
> > > ] signal mask removal.
> > 
> > We can add new mailing lists really easily now - it takes about 20-30 seconds.
> > Would it be worth adding a freebsd-threads and/or freebsd-kse type list
> > where it is a bit higher profile?
> 
> That's up to the folks here (on the KSE list) I guess.
> Is it possible to make it non-public?  The nice thing
> about the current kse list is it's relatively low
> volume and lack of spam.

That kind of flies in the face of the way we do things. I would imagine
if nothing else, being able to read the archives would be a good thing.

-gordon


pgp0.pgp
Description: PGP signature

Re: LOR in PCM

[Gordon Tetlow]

I just wanted to apologize for my poor taste in the subject. It
wasn't really called for.

-gordon

On Wed, Apr 02, 2003 at 01:46:28PM -0800, Gordon Tetlow wrote:
> Just thought I would report it:
> 
> lock order reversal
>  1st 0xc61f5940 pcm0 (sound softc) @ /local/usr.src/sys/dev/sound/pci/cmi.c:520
>  2nd 0xc6209e80 pcm0:play:0 (pcm channel) @ 
> /local/usr.src/sys/dev/sound/pcm/channel.c:440
> Stack backtrace:
> backtrace(c04e759f,c6209e80,c61a9b54,c06a2127,c06a21a5) at backtrace+0x17
> witness_lock(c6209e80,8,c06a21a5,1b8,c61a9b00) at witness_lock+0x692
> _mtx_lock_flags(c6209e80,0,c06a21a5,1b8,80c1) at _mtx_lock_flags+0xb2
> chn_intr(c61a9b00,c,1,208,c61f5a40) at chn_intr+0x2f
> cmi_intr(c61a9c00,0,c04e258e,217,c61a43c0) at cmi_intr+0xa6
> ithread_loop(c61fa980,df0f0d48,c04e23fe,314,c21c9390) at ithread_loop+0x16c
> fork_exit(c02e7dd0,c61fa980,df0f0d48) at fork_exit+0xc4
> fork_trampoline() at fork_trampoline+0x1a
> --- trap 0x1, eip = 0, esp = 0xdf0f0d7c, ebp = 0 ---
> 
> -gordon




pgp0.pgp
Description: PGP signature

LOR on libthr exit (iirc)

[Gordon Tetlow]

I think it was a libthr linked app after I killed it:

lock order reversal
 1st 0xc679d248 process lock (process lock) @ /local/usr.src/sys/kern/kern_exit.
c:134
 2nd 0xc05394a0 Giant (Giant) @ /local/usr.src/sys/kern/kern_exit.c:142
Stack backtrace:
backtrace(c04e759f,c05394a0,c04e3f7f,c04e3f7f,c04e2359) at backtrace+0x17
witness_lock(c05394a0,8,c04e2359,8e,0) at witness_lock+0x692
_mtx_lock_flags(c05394a0,0,c04e2359,8e,c6d9deac) at _mtx_lock_flags+0xb2
exit1(c6d9de40,f00,c04e2359,63,e9971d40) at exit1+0x174
sys_exit(c6d9de40,e9971d14,c04ff422,404,1) at sys_exit+0x41
syscall(2f,2f,2f,0,) at syscall+0x24e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (1), eip = 0x280ef90f, esp = 0xbf91071c, ebp = 0xbf910738 ---

-gordon


pgp0.pgp
Description: PGP signature

LOR in PCM (big suprise there)

[Gordon Tetlow]

Just thought I would report it:

lock order reversal
 1st 0xc61f5940 pcm0 (sound softc) @ /local/usr.src/sys/dev/sound/pci/cmi.c:520
 2nd 0xc6209e80 pcm0:play:0 (pcm channel) @ 
/local/usr.src/sys/dev/sound/pcm/channel.c:440
Stack backtrace:
backtrace(c04e759f,c6209e80,c61a9b54,c06a2127,c06a21a5) at backtrace+0x17
witness_lock(c6209e80,8,c06a21a5,1b8,c61a9b00) at witness_lock+0x692
_mtx_lock_flags(c6209e80,0,c06a21a5,1b8,80c1) at _mtx_lock_flags+0xb2
chn_intr(c61a9b00,c,1,208,c61f5a40) at chn_intr+0x2f
cmi_intr(c61a9c00,0,c04e258e,217,c61a43c0) at cmi_intr+0xa6
ithread_loop(c61fa980,df0f0d48,c04e23fe,314,c21c9390) at ithread_loop+0x16c
fork_exit(c02e7dd0,c61fa980,df0f0d48) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xdf0f0d7c, ebp = 0 ---

-gordon


pgp0.pgp
Description: PGP signature

Re: gbde

[Gordon Tetlow]

On Tue, Feb 11, 2003 at 08:15:56PM -0700, [EMAIL PROTECTED] wrote:
> I keep ketting errors when trying to make my root filesystem encrypted: 

I hope you have /boot on a different unencrypted filesystem.

-gordon



msg52350/pgp0.pgp
Description: PGP signature

Re: named & chroot & rcNG & devfs

[Gordon Tetlow]

On Tue, Feb 11, 2003 at 06:59:31PM +0100, Alexander Leidinger wrote:
> Hi,
> 
> /etc/rc.d/named copies /dev with pax to the named chroot directory. This
> is obviously wrong with devfs, isn't it?

You should read the script a little closer. That code path is only taken
on NetBSD.

-gordon



msg52349/pgp0.pgp
Description: PGP signature

Re: HEADS UP: VFS changes breaks GPT

[Gordon Tetlow]

On Thu, Jan 09, 2003 at 04:51:36PM -0800, Marcel Moolenaar wrote:
> 
> Nah... :-)
> 
> Jake has a good point and I've got a dotless i, so what about
> the following patch to dot the, well, i:
> 
> [snip patch]
> 
> Note that the padding is not specific to non-i386. The reason or
> cause of the padding is specific to non-i386, because it's due to
> the alignment requirements of fs_swuid. A nit, but will probably
> avoid some confusion..

Please go ahead and commit it. It looks quite reasonable, but I'm the
last person that should be approving such a commit =)

-gordon



msg49915/pgp0.pgp
Description: PGP signature

Re: HEADS UP: VFS changes breaks GPT

[Gordon Tetlow]

On Thu, Jan 09, 2003 at 01:12:30AM -0800, Marcel Moolenaar wrote:
> Gang,
> 
> GPT based systems are unable to mount the root file system. I
> haven't had the time to dig into this, but we must be making
> assumptions we previously didn't make. In any case ia64 is
> hosed. More to come...

I'll own up to this one. I forgot about alignment issues on non-i386
platforms when I committed rev 1.36 of src/sys/ufs/ffs/fs.h. I've
committed the fix that marcel has provided. If there are anymore
troubles, please don't hesitate in reverting to rev 1.35.

-gordon



msg49905/pgp0.pgp
Description: PGP signature

Re: RC NG, ntp and routed

[Gordon Tetlow]

On Wed, Dec 11, 2002 at 12:46:03AM -0800, Mike Makonnen wrote:
> You misunderstood. I meant let's move the routing daemons from /usr/sbin to /sbin.
> I think if we have routed there we might as well have the others there. Actually we
> only need to move route6d to /sbin. I can't think of a reason you would need
> multicast routing before the whole system was up. I think we can live with and
> additional 42k on /.

Lest we forget, / is statically linked. that 42k binary turns into a 450k
binary in /sbin.

-gordon



msg48529/pgp0.pgp
Description: PGP signature

Re: RC NG, ntp and routed

[Gordon Tetlow]

On Tue, Dec 10, 2002 at 09:47:54PM -0800, Mike Makonnen wrote:
> On Tue, Dec 10, 2002 at 04:23:18PM -0800, Gordon Tetlow wrote:
> > 
> > Ideally, ntpd should require NETWORKING and that should solve all problems.
> > The real problem is that routed is included with DAEMON, not NETWORKING. I
> > think that's the real problem and judging that routed is in /sbin, we could
> > probably move it there without a problem.
> 
> That sounds like a good idea. According to current NETWORKING requirements it
> just means the network interfaces are brought up, but routing seems to be a
> reasonable requirement as well. I can't think of a good reason why it would
> not be a good idea. Maybe we could move the other routing daemons
> there as well (from /usr/sbin)? 

Well, there in lies the chicken and the egg problem (and why I've been
cursing rcng recently). /usr is mounted after networking so all the things
that implictly require /usr must be run after networking is setup (but what
about things like route6d that is in /usr/sbin?)

IMO rc.d should have the following major catagories:

DISKS
FILESYSTEMS
NETWORKING
DAEMON
LOGIN

DISKS would be things that are needed to get the disks in order to start
getting filesystems mounted (vinum, ccd, raidframe and friends). It may
be a superflous step.
FILESYSTEMS and NETWORKING are a problem because they kind of intertwine.
It's not a clear cut case of mount all the filesystems then start the
networking interfaces. In reality, FILESYSTEMS and NETWORKING are very
much muddled (and cause me no end of grief as a result).
DAEMON is for things like ssh and the like that need to run (thinking
about nfsd, sshd, and just about any *d)
LOGIN is just that. Things that are started at the end of system
initialization.

NETWORKING, DAEMON, and LOGIN exist in the NetBSD framework. NetBSD also
describes a SERVERS catagory that I don't really understand the need for.

I'd like to think about really sitting down and overhauling the rc.d
system after 5.0 is branched. I think that it's reasonable to say we
should not try to be compatible with NetBSD except for keeping a common
rc.subr and major initialization catagories (basically anything that is
in all caps). Does anyone have a problem with dyking out the NetBSD
specific portions after 5.0?

-gordon

-gordon



msg48505/pgp0.pgp
Description: PGP signature

Re: RC NG, ntp and routed

[Gordon Tetlow]

On Tue, Dec 10, 2002 at 02:50:14PM -0800, Mike Makonnen wrote:
> On Tue, Dec 10, 2002 at 03:01:24PM -0200, Daniel C. Sobral wrote:
> > On another note, I thought the patch a bit excessive. Here, I just added 
> > BEFORE: ntpd to routed. OTOH, it seems that patch did a bit more.
> 
> It's not excessive. It's the correct solution. 
> Your solution solves your specific problem but it's
> not the right way to go about solving the problem. It's kind of hard to
> explain, you have to work with it for a while to get the hang of it. For
> some things it might be easier _and_ right to say this must come before
> that. In this case; however,  ntpd requires that routing be available as a 
> prerequisite, but there's no real relationship that exists between
> the two that necessitates routed having to know about ntpd. If we were
> to follow your example to its logical conclusion the BEFORE line for
> the routing daemons would have to include _every_ daemon that requires
> network availability. I think in this case it would be more correct to
> have the network daemons REQUIRE the routing daemons. Does that make
> sense?

Ideally, ntpd should require NETWORKING and that should solve all problems.
The real problem is that routed is included with DAEMON, not NETWORKING. I
think that's the real problem and judging that routed is in /sbin, we could
probably move it there without a problem.

-gordon



msg48493/pgp0.pgp
Description: PGP signature

Re: RC NG, ntp and routed

[Gordon Tetlow]

On Mon, Dec 09, 2002 at 06:43:50PM -0800, Mike Makonnen wrote:
> 
> The following patch should solve your problem. However,
> it's only a partial solution. It fixes the case for ntpd
> and ntpdate but not for other network daemons like rpcbind, which still get
> started _before_ the routing daemons. I haven't included patches for
> those because sorting out the dependencies is going to be a bit more
> involved. I'll have it done when I get a chance later this week.
> (A consequence of this is going to be that we will be moving *away* from
>  NetBSD in the dependency ordering, but we can sort that out with them later).

I think keeping our boot scripts the same is kind of a pipe dream. I think
we should keep our rc.subr the same, but for individual scripts, I think we
should just go our own way.

-gordon



msg48461/pgp0.pgp
Description: PGP signature

Re: RCng Awkwardness

[Gordon Tetlow]

On Wed, Oct 30, 2002 at 02:23:48PM -0800, Tim Kientzle wrote:
> Gordon Tetlow wrote:
> 
> >On Wed, Oct 30, 2002 at 11:50:45AM -0800, Tim Kientzle wrote:
> >
> >>I find the standard arguments used by RCng quite
> >>awkward.  In particular, ... "/etc/rc.d/nfsd stop" does
> >>not actually stop the nfsd process. ...
> >
> >... I've found this behavior to be quite annoying. I'll
> >see if I can put something together. If you want to help me out and
> >put together the patches, I'd be more than happy to commit them.
> 
> 
> I have something partly sketched out, but
> it still needs some work.  I can
> send you something in the next
> couple of days to look at.
> 
> I see two awkward issues:
> 
> * Is it necessary to distinguish 'stop'
>   (unconditional stop) from 'shutdown'
>   (stop only if enabled)??
> 
>   Seems that at system shutdown you want
>   everything to be taken down, regardless
>   of whether it was brought up at boot
>   or brought up manually post-boot.
>   The unconditional 'stop' seems to be
>   all that's needed.

I agree, but can you make it use shutdown and just alias it to stop?
This will be just in case we see a new need for a special shutdown case.

> * Local rc scripts (in /usr/local/etc/rc.d)
>   will still get run with a 'start'
>   argument, while system scripts in
>   /etc/rc.d will get a 'boot' argument.
>   That's a bit awkward, but still
>   reasonably consistent:  'start'
>   is still an unconditional operation.

That's fine. No big deal there.

-gordon



msg45718/pgp0.pgp
Description: PGP signature

Re: RCng Awkwardness

[Gordon Tetlow]

On Wed, Oct 30, 2002 at 11:50:45AM -0800, Tim Kientzle wrote:
> I find the standard arguments used by RCng quite
> awkward.  In particular, especially for people who
> have worked with SysV-style init scripts, it's
> rather surprising that "/etc/rc.d/nfsd stop" does
> not actually stop the nfsd process.  Likewise, 'start'
> doesn't actually start the specified system.

As one of the people that supposedly worked on this. I'm heartily in
favor of this. I've found this behavior to be quite annoying. I'll
see if I can put something together. If you want to help me out and
put together the patches, I'd be more than happy to commit them.

-gordon



msg45677/pgp0.pgp
Description: PGP signature

tar problems with --fast-read

[Gordon Tetlow]

I was trying out the fast-read feature of tar and got the following:

gtetlow@roark:~$ touch testa testb
gtetlow@roark:~$ tar cf test.tar testa testb 
gtetlow@roark:~$ tar tf test.tar --fast-read testa
testa
Terminated
gtetlow@roark:~$ 

Further investigtion shows that there is a SIGPIPE being delivered.
Any ideas?

-gordon



msg44298/pgp0.pgp
Description: PGP signature

Changes to Kerberos daemon startup

[Gordon Tetlow]

I have a patch at http://people.freebsd.org/~gordon/patches/kerberos.diff
that changes the variables used for kerberos startup. I haven't had a
chance to test these changes just yet, but I'd like peoples opinion on
them. There will be a corresponding change in rc.d scripts that I have to
make yet.

-gordon



msg44295/pgp0.pgp
Description: PGP signature

Re: HEADS UP: rcNG is now the default

[Gordon Tetlow]

On Mon, Sep 02, 2002 at 10:30:19PM -0700, Gregory Neil Shapiro wrote:
> gordont> There is one outstanding issue with the sendmail script that I'm working on
> gordont> a solution for. In the general case it should work fine. If you set
> gordont> sendmail_enable="NONE" it will echo a benign warning about it being set
> gordont> improperly.
> 
> I've been discussing the issue with Mike Makonnen and we are going to use
> his idea of deprecating the use of NONE (with a warning) for -CURRENT and
> leaving it available in -STABLE.  At some point, "NONE" support will go
> away in 5.X.

I committed a script that pretty much works as the current sendmail support
does. I should have run it by you before, but I was in a hurry to get to a
barbecue and trying to keep the tree from breaking too badly. Please feel
free to rip apart my commit and make it closer to your satisfaction.

-gordon



msg42526/pgp0.pgp
Description: PGP signature

Re: HEADS UP: rcNG is now the default

[Gordon Tetlow]

On Mon, Sep 02, 2002 at 09:33:35AM -0700, Gordon Tetlow wrote:
> I'm going to toggle the switch to activate rcNG as the default boot scripts.
> If you experience any problems, put rc_ng="NO" in your /etc/rc.conf and
> please report any problems.

There is one outstanding issue with the sendmail script that I'm working on
a solution for. In the general case it should work fine. If you set
sendmail_enable="NONE" it will echo a benign warning about it being set
improperly.

-gordon



msg42465/pgp0.pgp
Description: PGP signature

HEADS UP: rcNG is now the default

[Gordon Tetlow]

I'm going to toggle the switch to activate rcNG as the default boot scripts.
If you experience any problems, put rc_ng="NO" in your /etc/rc.conf and
please report any problems.

-gordon



msg42462/pgp0.pgp
Description: PGP signature

Re: aout support broken in gcc3

[Gordon Tetlow]

On Mon, Sep 02, 2002 at 11:34:48AM -0400, Alexander Kabaev wrote:
> On Tue, 3 Sep 2002 01:09:11 +1000 (EST)
> Bruce Evans <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Except I just used it to compile biosboot :-).  (I had more problems
> > with ufs2 changes than with the compiler.)
> > 
> > Actually, I agree.  Not having a clean break in FreeBSD-3 was very
> > expensive. Support for running aout binaries and compatibility cruft
> > to support old binaries should have been dropped too.
> 
> Do we have an agreement here? A.OUT support is to be dropped with the
> next gcc upgrade, when/if it will happen?

I think it should be turned off now. That will help shake out any issues
and people complaining that it is gone. The sooner the better.

-gordon



msg42464/pgp0.pgp
Description: PGP signature

odd nfs message

[Gordon Tetlow]

When I try to serve my cdrom out to Solaris clients, I get the following 
message in my syslog:

Jul 30 13:27:15 roark kernel: RRIP without PX field?
Jul 30 13:27:15 roark last message repeated 7 times

When the clients try to mount my cdrom drive, they see the top directory
structure just fine, but all the files are 0 bytes (not the case for
sure):

-r-xr-xr-x   1 root root   0 Dec 31  1969 ClusterManager*
-r-xr-xr-x   1 root root   0 Dec 31  1969 VRTScscm*
-r-xr-xr-x   1 root root   0 Dec 31  1969 VRTSgab*
-r-xr-xr-x   1 root root   0 Dec 31  1969 VRTSllt*
-r-xr-xr-x   1 root root   0 Dec 31  1969 VRTSperl*
-r-xr-xr-x   1 root root   0 Dec 31  1969 VRTSvcs*
-r-xr-xr-x   1 root root   0 Dec 31  1969 VRTSvcsdc*
-r-xr-xr-x   1 root root   0 Dec 31  1969 VRTSvcsw*
-r-xr-xr-x   1 root root   0 Dec 31  1969 VRTSweb*
-r-xr-xr-x   1 root root   0 Dec 31  1969 copyright*
-r-xr-xr-x   1 root root   0 Dec 31  1969 installvcs*
-r-xr-xr-x   1 root root   0 Dec 31  1969 installvcsscripts*
-r-xr-xr-x   1 root root   0 Dec 31  1969 licensevcs*
-r-xr-xr-x   1 root root   0 Dec 31  1969 qstovcs*
-r-xr-xr-x   1 root root   0 Dec 31  1969 support*
-r-xr-xr-x   1 root root   0 Dec 31  1969 uninstallvcs*
-r-xr-xr-x   1 root root   0 Dec 31  1969 upgradecfg.pl*
-r-xr-xr-x   1 root root   0 Dec 31  1969 vcssol_ig.pdf*
-r-xr-xr-x   1 root root 609767424 Dec 31  1969 vcssol_notes.pdf*

Kinda strange I thought. Still needing to get this done and too lazy to 
walk downstairs to put the cluster cd in the sun box, I remounted the nfs 
share using nfs version 2 and things seem to work fine:

drwxrwxr-x   4 root root2048 Aug  8  2001 ClusterManager/
drwxrwxr-x   4 root root2048 Aug  8  2001 VRTScscm/
drwxrwxr-x   4 root root2048 Aug  8  2001 VRTSgab/
drwxrwxr-x   4 root root2048 Aug  8  2001 VRTSllt/
drwxrwxr-x   8 root root2048 Aug  8  2001 VRTSperl/
drwxrwxr-x   4 root root2048 Aug  8  2001 VRTSvcs/
drwxrwxr-x   4 root root2048 Aug  9  2001 VRTSvcsdc/
drwxrwxr-x   4 root root2048 Aug  8  2001 VRTSvcsw/
drwxrwxr-x   5 root root2048 Aug  8  2001 VRTSweb/
-rw-r--r--   1 root root 162 Aug 10  2001 copyright
-rwxr-xr-x   1 root root   44677 Aug  8  2001 installvcs*
drwxrwxr-x   5 root root2048 Aug  8  2001 installvcsscripts/
-rwxr-xr-x   1 root root8417 Aug  8  2001 licensevcs*
-rwxr-xr-x   1 root root   14575 Aug  8  2001 qstovcs*
drwxrwxr-x   3 root root2048 Aug  9  2001 support/
-rwxr-xr-x   1 root root   17803 Aug  8  2001 uninstallvcs*
-rwxr-xr-x   1 root root5005 Aug  8  2001 upgradecfg.pl*
-rwxr-xr-x   1 root root  504395 Aug  9  2001 vcssol_ig.pdf*
-rwxr-xr-x   1 root root   85149 Aug  9  2001 vcssol_notes.pdf*

I'm using a month old kernel/world setup mostly because I'm too lazy to 
upgrade. =)

Any thoughts/suggestions?

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: bug in awk implementation?

[Gordon Tetlow]

On Tue, 16 Jul 2002, Crist J. Clark wrote:

> And since it is clearly documented, awk(1) says,
> 
>Records
>Normally,  records  are  separated  by newline characters.
>You can control how records  are  separated  by  assigning
>values  to  the built-in variable RS.  If RS is any single
>character, that character separates  records.   Otherwise,
>RS  is  a  regular  expression.   Text  in  the input that
>matches this regular expression will separate the  record.
>However,  in  compatibility mode, only the first character
>of its string value is used for separating records.  If RS
>is  set  to the null string, then records are separated by
>blank lines.  When RS is set to the null string, the  new-
>line  character always acts as a field separator, in addi-
>tion to whatever value FS may have.
> 
> It is not a bug.

No, you are quoting from the gawk(1) man page. The awk(1) man page makes 
no such statement.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: bug in awk implementation?

[Gordon Tetlow]

On Mon, 15 Jul 2002, Robert Drehmel wrote:

> > So, this seems to be a bug in the one-true-awk implementation. Any ideas 
> > on how to fix this?
> 
> To me, this seems like a bug in 'gawk'.  The AWK language uses
> only the first character in RS as the record separator, to my
> knowledge.

Ah, okay, there is a distinct lack of documentation to that fact. I have 
figured out that I can just set RS="" and that does the same thing. I 
suppose it would be helpful to have an awk book around. =)

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

bug in awk implementation?

[Gordon Tetlow]

I was parsing ldif format with awk (formerly gawk) and found a buglet in 
awk with the following script:

BEGIN {
RS="\n\n";
FS="(: |\n)";
}

{ print $2; }

Fed the following output:

dn: Some Such DN
gidNumber: 1000
uidNumber: 1080

dn: Some Other DN
gidNumber: 1000
uidNumber: 1405

This is what I get:

one-true-awk:

Some Such DN
1000
1080

Some Other DN
1000
1405

gawk:

Some Such DN
Some Other DN


So, this seems to be a bug in the one-true-awk implementation. Any ideas 
on how to fix this?

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: rc.d is in the tree

[Gordon Tetlow]

On Fri, 14 Jun 2002, Terry Lambert wrote:

> Mike Makonnen wrote:
> > Danny Braniss <[EMAIL PROTECTED]> wrote:
> > > in amd,
> > >   # REQUIRE: rpcbind mountall ypbind nfsclient
> > >   **
> > > since i don't use yp, how can i override this?
> > >
> > > or in other words, can REQUIRE be configurable too?
> > 
> > The REQUIRE line doesn't mean it will be started. It just means that
> > ypbind comes before amd in the boot process.
> 
> Ick.
> 
> What should be used instead of REQUIRE to mean that it will be
> started?
> 
> I.e. if "REQUIRE" describes soft dependency ordering, what
> describes hard dependency ordering?

I don't like this design decision either. I have a couple of ideas on how
to get rid of rcorder completely and bring the dependency checking into
the script itself (complete with the notion of hard and soft
dependencies).

I was thinking of coming up with a way to make dynamic dependency 
registration and coming up with a reverse and forward dependency tree so 
if you stop nfsd, it would make a call to mountd to see if there was 
anything still using nfsd. If there weren't any more dependencies, it 
would then stop mountd (that could be a bit risky though, depending on the 
completeness of the dependency tree).

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: rc.d is in the tree

[Gordon Tetlow]

On Sat, 15 Jun 2002, Greg 'groggy' Lehey wrote:

> Hmm, appears to be Luke Mewburn's NetBSD stuff, which I know.
> Shouldn't there be an "Obtained From: NetBSD" in the commit messages?

Heh, sorry about that. I thought taking if off the NETBSD vendor branch 
was enough of a hint. It appears that I should have been much more 
specific with my commit message. My apologies on that.

> Are you (or is anybody) doing something about keeping as close as
> possible to being in sync with NetBSD?

If I am correct (Mike will correct me if I'm wrong), we are caught up with 
NetBSD with this commit.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HEADS UP: rc.d is in the tree

[Gordon Tetlow]

On Fri, 14 Jun 2002, Danny Braniss wrote:

> in amd, 
>   # REQUIRE: rpcbind mountall ypbind nfsclient
>   **
> since i don't use yp, how can i override this?
> 
> or in other words, can REQUIRE be configurable too?

This isn't a hard requirement for starting, but instead a hint for 
ordering the startup of the system.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

HEADS UP: rc.d is in the tree

[Gordon Tetlow]

I've imported the excellent work by Mike Makonnen into the tree. Please 
note that it should be fully functional but there are some parts that need 
some looking at:

atm
ipfilter


Hopefully Mike will chime in with some others.

Please try out the functionality by putting rc_ng="YES" into your rc.conf 
and post any problems you might have.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Fix order of directories in rc.shutdown

[Gordon Tetlow]

The enclosed patch fixes the order of script execution so the directory 
order is also reversed. The current behavior is to have directories 
traversed in the same order as at startup, but have the scripts in the 
directories reversed. I just changed it so it builds the script list 
forward (like for startup), but then reverses the entire list before 
execution.

-gordon


--- /etc/rc.shutdownThu Apr 11 14:39:20 2002
+++ rc.shutdown Fri May 10 14:25:35 2002
@@ -52,6 +52,18 @@
. /etc/rc.conf
 fi
 
+# reverse_list list
+#  print the list in reverse order
+#
+reverse_list()
+{
+   _revlist=
+   for _revfile in $*; do
+   _revlist="$_revfile${script_name_sep}$_revlist"
+   done
+   echo $_revlist
+}
+
 # Write some entropy so the rebooting /dev/random can reseed
 #
 case ${entropy_file} in
@@ -109,13 +121,13 @@
for dir in ${local_startup}; do
if [ -d "${dir}" ]; then
for script in ${dir}/*.sh; do
-   slist="${script}${script_name_sep}${slist}"
+   slist="${slist}${script_name_sep}${script}"
done
fi
done
script_save_sep="$IFS"
IFS="${script_name_sep}"
-   for script in ${slist}; do
+   for script in `reverse_list ${slist}`; do
if [ -x "${script}" ]; then
(set -T
trap 'exit 1' 2

Re: UMA lock order reversal

[Gordon Tetlow]

On Sun, 5 May 2002, Doug Barton wrote:

> With yesterday's -current:
> 
> lock order reversal
>  1st 0xcc5987a4 DIRHASH (UMA zone) @
> /usr/Local/src-current/sys/vm/uma_core.c:297
>  2nd 0xc76c2224 PCPU 256 (UMA cpu) @
> /usr/Local/src-current/sys/vm/uma_core.c:1630
> 
> FYI.

Here's another from yesterday's current. I get this when running savecore:

lock order reversal
 1st 0xcc614524 PIPE (UMA zone) @ /usr/src/sys/vm/uma_core.c:530
 2nd 0xc082a9a4 PCPU PV ENTRY (UMA cpu) @ /usr/src/sys/vm/uma_core.c:1630

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Crash when attaching usb ethernet

[Gordon Tetlow]

On Sun, 5 May 2002, Gordon Tetlow wrote:

> I've got a Seimens SpeedStream USB -> Ethernet adapter that when I plug 
> into my laptop (built -CURRENT yesterday), it always crashes. Here's the 
> info:

snip...

Of course, after a quick search, I find the thread that Joe has about the 
usb subsystem. Well, I hope that I can help in anyway possible.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Crash when attaching usb ethernet

[Gordon Tetlow]

I've got a Seimens SpeedStream USB -> Ethernet adapter that when I plug 
into my laptop (built -CURRENT yesterday), it always crashes. Here's the 
info:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xdeadc0e2
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01f93e9
stack pointer   = 0x10:0xcdd9f3f8
frame pointer   = 0x10:0xcdd9f810
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 23 (usb0)

... snip ...

#11 0xc01f93e9 in aue_attach (self=0xce96a100)
at /usr/src/sys/dev/usb/if_aue.c:682
#12 0xc025a33e in device_probe_and_attach (dev=0xce96a100) at device_if.h:40
#13 0xc020d806 in usbd_probe_and_attach (parent=0xcdd64d80, dev=0xce884c00,
port=1, addr=2) at /usr/src/sys/dev/usb/usb_subr.c:883
#14 0xc020dbf3 in usbd_new_device (parent=0xcdd64d80, bus=0xcdd34000, depth=1,
speed=2, port=1, up=0xcdd64d30) at /usr/src/sys/dev/usb/usb_subr.c:1094
#15 0xc02057a9 in uhub_explore (dev=0xcdd64e80)
at /usr/src/sys/dev/usb/uhub.c:474
#16 0xc020c29d in usb_discover (v=0xcdd62560) at /usr/src/sys/dev/usb/usb.c:716
#17 0xc020bda2 in usb_event_thread (arg=0xcdd62560)
at /usr/src/sys/dev/usb/usb.c:403
#18 0xc023ef36 in fork_exit (callout=0xc020bd58 ,
arg=0xcdd62560, frame=0xcdd9fd48) at /usr/src/sys/kern/kern_fork.c:829
(kgdb) select-frame 11
(kgdb) print *sc->aue_iface
$1 = {device = 0xdeadc0de, idesc = 0xdeadc0de, index = -559038242,
  altindex = -559038242, endpoints = 0xdeadc0de, priv = 0xdeadc0de, pipes = {
lh_first = 0xdeadc0de}}
(kgdb) select-frame 13
(kgdb) print dev->ifaces[0]
$2 = {device = 0xce884c00, idesc = 0xce87fc49, index = 0, altindex = 0,
  endpoints = 0xcdd636c0, priv = 0x0, pipes = {lh_first = 0x0}}
(kgdb) print *uaa->iface
$3 = {device = 0xdeadc0de, idesc = 0xdeadc0de, index = -559038242,
  altindex = -559038242, endpoints = 0xdeadc0de, priv = 0xdeadc0de, pipes = {
lh_first = 0xdeadc0de}}

>From a cursory look at the code, in frame 13, uaa->iface should be equal
to dev->ifaces[0] but in fact they aren't. I'm wondering if this might
have something to do with the fact that uaa is static. I might be barking
up the wrong tree, I'm not an expert with this. I'll keep the crashdump
for a while if anyone has any more questions.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sh dies w/ sig 12

[Gordon Tetlow]

On Thu, 11 Apr 2002, Jean-Marc Zucconi wrote:

> > Seth Hettich writes:
> 
>  > Trying to update to -current, in SU mode, doing the make installworld:
>  > [ ! -e /usr/bin/passwd ] || echo foo
> 
>  > will make sh die
> 
>  > This is even with the "new" sh from my buildworld (I am running the new
>  > kernel).
> 
>  > Ideas?
> 
> I think this was discussed in -current some time ago. Compile a
> -current kernel and reboot. Then redo the make installworld. 

Or as an alternative, read /usr/UPDATING like you should have and it would 
tell you how to make the leap from -STABLE to -CURRENT

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: NetBSD-style rc.d Project

[Gordon Tetlow]

On Wed, 27 Feb 2002, Kevin Way wrote:

> * Sheldon Hearn <[EMAIL PROTECTED]> [27-02-02 03:58]:
> > > At this point, I'm very willing to help anybody who is doing the
> > > main development, with either coding or testing, but I have no
> > > interest being a lead developer on the project.
> > 
> > Have you been in contact with Gordon Tetlow to see how he's faring?
> 
> No, I haven't heard from Gordon since October, or so.  Last I heard, he
> was taking a different approach than me, converting the FreeBSD scripts
> to the NetBSD format, so there was very little overlap between our
> efforts, despite similar progress and goals.  I don't know if he
> quietly finished his efforts, without a press release or if they became
> shelfware.

The latter, work became terribly hectic. And after a fair amount of
discussion on -arch and that irc channel, people seemed to believe that we
should keep as close to NetBSD's scripts as we could to keep the diffs
down between them. From that, maybe we should start with Kevin's base and
work from there. I'd be more than happy to contribute what little I've 
done (I got it booting up to network initialization).

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Gordon Tetlow]

If this isn't a troll, I don't know what is

On Mon, 10 Dec 2001, Jackie 'business-first' Cook wrote:

> There are days when people get tired with the lagacy code in the
> system - when things of the past just have to go. Recently I got sick
> and tired with one of those things. The command is, as you could have
> guessed from the subject, xags(1) aka /usr/bin/xargs. It is buggy and
> cluttered piece of code. Faulty and hard to use command. It's
> idiosyncratic syntax makes people dizzy everytime they use/or just try
> to use it.

Well, in that case, find(1) needs to be pitched as well for it's 
"idiosyncratic syntax" as well. Besides xargs is part of the POSIX 1003.2 
Standard. Since we are trying to be POSIX compliant, xargs should stay. If 
you think the code is ugly, please feel free to fix it. Patches are most 
welcome.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: bash in /usr/local/bin?

[Gordon Tetlow]

On Sun, 12 Aug 2001, Steve Kargl wrote:

> On Sun, Aug 12, 2001 at 04:54:08PM -0700, Gordon Tetlow wrote:
> > > FreeBSD is getting military contracts now.  We need to think ahead to
> > > the needs of a whole new class of admin and user, and they are in
> > > highly restrictive environments that preclude `mv /usr/local/bin/*sh
> > > /bin`.
> >
> > And those people that are working there are probably programming in COBOL
> > and Fortran.
> >
>
> Sigh.  A stupid language war troll.  You haven't looked at
> the Fortran language since 1977 have you?

I forgot to add   around that. Actually, ADA would
probably be more correct. I was born in 1978 btw.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: bash in /usr/local/bin?

[Gordon Tetlow]

Not to be a pain, but can you wrap lines at a more standard 74 columns as
opposed to whatever you are currently wrapping them at? Thanks.

On Sun, 12 Aug 2001, Jim Bryant wrote:

> Gordon Tetlow wrote:
>
> > As a preface to this whole thing, I find it higly amusing that you are
> > sending this mail from a Linux box. Of course, for that matter, so am I.
> > (I'm planning on changing that soon.)
>
>
> Excuse me?
>
> FreeBSD wahoo.kc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Fri Aug 10 16:51:25 CDT 
>2001
> [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WAHOO  i386
>
> When Netscape comes out with support for FreeBSD again, I'll run
> native, until then, I, like everyone else using freebsd am stuck using
> netscape in the COMPATLINUX construct.
>
> Please don't make assumptions about an operating environment without
> understanding the problems of living within that environment.

Ah, my apologies. It's much less amusing now.

> Also, dinosaurs or not, DOD is now an INVESTOR in the FreeBSD system.
> Name any other group besides maybe BSDI that has provided $1.4 million
> [USD] to the project.

Okay, I don't recall the FreeBSD Foundation getting $1.4 mil. I know that
the DOD is sponsoring some TrustedBSD stuff, but where exactly is the
money going?

> We should look towards making FreeBSD the open-source OS of choice in
> the DOD environment, in which Linux has already made major inroads
> where FreeBSD isn't even allowed to tread yet.
>
> Actually, it is up to us to resolve this.  I don't think you
> understand how DOD operates.  The vendor makes the changes, not DOD.
> Not the admin.

Again, I don't see why we should cater to one specific group of people and
let them dictate the direction of the project.

> Another priority item should be making sure we are compatible with
> such things as the latest versions of Oracle, etc...  This is an area
> in which we can compete head-to-head with the high-dollar stuff.

Well, considering that Oracle doesn't publish *anything* for FreeBSD, I
doubt there is anything we can do about it. Veritas NetBackup has a
FreeBSD client (no server). IBM DB2 has no FreeBSD support. Heck, as you
point out Netscape doesn't even make FreeBSD binaries. And you know what?
There's squat that the project can do about it. We can't make companies
support FreeBSD if they don't want to spend the resources for it.

> Also, I havn't worked for DOD in a long time, but I have done recent
> contracts with them, and understand firsthand the BS involved in
> having to do without tools all unix people, including myself, consider
> standard, that are not allowed because it's not part of the base
> install.
>
> Moving the non-GPL shells to /bin is a trivial request that can solve
> problems that you obviously don't understand.

Um, bash is GPL. The reason for not putting it in the base system is due
to licensing restrictions. We try to use as few GPL'd pieces as possible.
After seeing that grep is a GNU tool, I'm almost tempted to try writing a
BSD-style grep for the fun/exercise of it.

> DOD will is a vast new market for FreeBSD, and if we don't think ahead
> now and consider what will make admins recommend FreeBSD over Linux,
> Solaris, or HP-UX, then we'll never reach the kind of market
> penetration that Linux, Solaris, and HP-UX have in the DOD market.
> Key to this is an admin-friendly environment designed to get around
> the pre-cambrian attitudes that prevent DOD admins from using standard
> tools just because it's in the wrong place on the disk array or
> because it's considered a third-party option, or even worse: freeware
> [h!  step away from the keyboard, son.  you going to prison,
> boy!].

Read my lips (er text, whatever). Bash and other shells are not going to
make it into the base FreeBSD OS. The increasing code base does worry me
though. I'm not a big fan of adding more and more functionality to the
"base." I like the very functional, very useful codebase that we currently
have. You can do alot more with a base FreeBSD installation than you can
with a base Solaris installation (like compile things).

> I'm more for an evolutionary unix where the idea of what's standard
> changes to reflect the needs of it's admins and users in diverse
> environments.

Then feel free to take FreeBSD, tweak it and publish it as DODBSD. By
all means, the license lets you do it.

> I may not be one of the big movers, but I think this is why I do what
> I can to help out with -CURRENT, to move forwards meeting the needs,
> instead of going nowhere due to outdated beliefs "oh, but that belongs
> in /usr/local/bin".  If something after years of use becomes a
> standard tool, it

Netiquette (Was: Re: FreeBSD's aggressive keyboard probe/attach)

[Gordon Tetlow]

On Sun, 12 Aug 2001, Warner Losh wrote:

> A word about tone.  If you were to get as in my face about, say,
> pccard, as you about the psm driver, I'd certainly be ill inclined to
> provide you with what you want.
>
> Good Tone:
>   Say Warner, why do you bother turning off the power after
>   you suspend a socket.  Shouldn't the power routines take care
>   of that?  Is there something subtle that's going on?  Maybe a
>   comment is in order?
>
> Bad Tone:
>   Please explain the pros and cons for turning the power off
>   after suspending a socket.  I really want to know.  Why did
>   they do this?  Didn't the coder trust the power routines?  The
>   least he could have done was include a comment.  Was there
>   some long discussion that I missed?
>
> See the difference?  The first tone is friendly, suggesting that
> something in the code might be unclear.  The second seems to imply
> that I'm a moron for not documenting every trivial solution with a 20
> page thesis on why it is good or bad to do.

This is such a great example of how tone can come across poorly in a text
medium. I doubt (hope) that Joe didn't mean to come across as that. But
tone in email is so often inferred based on the readers own moods, that
phrasing email becomes much more important so as to not give the reader
the wrong impression.

This should be required reading for anyone considering posting to a
FreeBSD mailing list.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: bash in /usr/local/bin?

[Gordon Tetlow]

As a preface to this whole thing, I find it higly amusing that you are
sending this mail from a Linux box. Of course, for that matter, so am I.
(I'm planning on changing that soon.)

On Sun, 12 Aug 2001, Jim Bryant wrote:

> I said I'd drop it, but apparently there are people that don't
> understand the dinosaur mentality of certain organizations such as
> DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC.
>
> If it's not in the base setup, on a production box, you can't use it.
> Everything must be kept in it's ORIGINAL install location, otherwise
> you MUST justify it and ask DISA/DECC for a waiver, which in itself,
> is a pain in the ass, and in many cases, not likely to happen due to
> dinosaur mentality.

You said it yourself. They are a dinosaur. Why should be drag ourselves
back to the paleolithic and cater to a very specific problem in our base
tree? bash is a nice shell. I use it as my normal shell, but when I drop
to single user mode, I *always* end up using /bin/sh. I'm not a fan of csh
(tcsh isn't bad though) and I only write shell scripts in /bin/sh.
Besides, how often do you need to drop to single user mode and *really*
need bash?

> I now refer you to the recent news concerning the TrustedBSD project.
>
> FreeBSD is getting military contracts now.  We need to think ahead to
> the needs of a whole new class of admin and user, and they are in
> highly restrictive environments that preclude `mv /usr/local/bin/*sh
> /bin`.

And those people that are working there are probably programming in COBOL
and Fortran.

> I'm sure there are equally restrictive environments for computers and
> operating systems in *EVERY* country, but I speak from my personal
> experience with the dinosaurs at DOD.  At DOD, *EVERY* copy of FreeBSD
> will be subject to what I am saying.  In the Sun environment in which
> I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have
> been able to use it.  That's how backwards they are.
>
> In answer to your statement, some admins can be fired, even arrested
> and brought up on charges for doing what you suggest.  I'm certain
> that this happens in countries other than America as well.

Again, this is a problem for you and the DOD to sort out. It should be of
no concern to the project.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: snapshot installation woes

[Gordon Tetlow]

On Sat, 4 Aug 2001, John Baldwin wrote:

> On 04-Aug-01 Gordon Tetlow wrote:
> > I decided I was going to brave 5.0-CURRENT and give the snapshots
> > available on current.jp.freebsd.org a try. I found a couple issues with
> > installation disks (FWIW, I tried it on the lastest snapshot avail on
> > current.freebsd.org. I got the same results).
> >
> > Anyway, I go through the standard kern/mfsroot floppy deal and when it
> > boots the kernel, everything seems to be going fine until I get the
> > following kernel panic:
> >
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address = 0xffab
>
> That's a NULL pointer deref.
>
> > fault code= supervisor write, page not present
> > instruction pointer   = 0x8:0xc0a75ac0
>
> Hmmm...  Can you look in the bin dist for the kernel.debug and do a
> 'gdb -k' on it to look up this address to see what line it is dying on?
>
> No idea on the ahc0 error. :(

A little more information, if I disable the on-board audio (pnpscan shows
it to be CSCe835 IBM Audio Feature) the kernel panic goes away. I'm still
working on getting the line it's dying on.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message