Re: CA's TLS Certificate Bundle in base = BAD
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
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
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
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
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
On Fri, Nov 5, 2010 at 8:57 AM, Anonymous swel...@gmail.com 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
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
On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER demelier.da...@gmail.comwrote: 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
On Thu, Sep 9, 2010 at 8:17 PM, Anonymous swel...@gmail.com wrote: Gordon Tetlow gor...@tetlows.org 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
On Thu, Sep 9, 2010 at 12:48 PM, Anonymous swel...@gmail.com 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
On Thu, Sep 9, 2010 at 7:41 PM, Alexander Best arun...@freebsd.org 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
On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow gor...@tetlows.org 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.shhttp://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 whatever will generally give me the debug information I need). I have a new set for testing: http://people.freebsd.org/~gordon/man.sharhttp://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
On Wed, Aug 18, 2010 at 5:01 PM, Anonymous swel...@gmail.com wrote: Gordon Tetlow gor...@tetlows.org 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
On Wed, Aug 18, 2010 at 11:52 PM, Gordon Tetlow gor...@freebsd.org wrote: On Wed, Aug 18, 2010 at 5:01 PM, Anonymous swel...@gmail.com wrote: Gordon Tetlow gor...@tetlows.org 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
CFR: Replace man/manpath/whatis/apropos with a shell script
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.shhttp://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 whatever 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: CFR: Replace man/manpath/whatis/apropos with a shell script
On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow gor...@tetlows.org 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.shhttp://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 whatever 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/lang.enc /usr/share/man/ ... /usr/local/man//lang.enc /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/lang.enc, 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
Re: newsyslog patch implementing file includes
On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda ad...@lissyara.su wrote: It's need feature. I test patch - it work for me (CURRENT, amd64) Can I use some as: include /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
Re: newsyslog patch implementing file includes
On Thu, Apr 22, 2010 at 6:26 AM, John Baldwin j...@freebsd.org 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
newsyslog patch implementing file includes
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.diffhttp://people.freebsd.org/%7Egordon/patches/newsyslog.diff Format for the include line in /etc/newsyslog.conf is: include /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 include tag to specify include files. Globbing is supported in include 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
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.diffhttp://people.freebsd.org/%7Egordon/patches/newsyslog.diff Format for the include line in /etc/newsyslog.conf is: include /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 include tag to specify include files. Globbing is supported in include 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
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
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
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
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
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
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
On Tue, Sep 16, 2003 at 06:11:01PM +0200, Harti Brandt wrote: On Tue, 16 Sep 2003, Richard Nyberg wrote: RNAt Thu, 11 Sep 2003 14:44:55 +0200 (CEST), RNHarti 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 RNMe too :( RNTo get installworld back on track I used cp under linux emulation to RNcopy ld-elf.so.1. Then I also had to run ldconfig -m /lib. After that RNmake 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
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...
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?
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
Re: /lib symlinks problem?
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
LOR vm_object.c:434 vm_kern.c:329
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?
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
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
HEADS UP: dynamic root support now in the tree
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
Re: HEADS UP: dynamic root support now in the tree
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
Re: HEADS UP: dynamic root support now in the tree
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
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: [current tinderbox] failure on alpha/alpha
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
LOR in sound subsystem
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
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
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
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. sigh)
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: Buildworld fails in 5.1
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: Overdone rescue cleaning as part of buildworld?
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: Overdone rescue cleaning as part of buildworld?
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?
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?
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
##
# Programs from stock /usr/bin
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../usr.bin
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../gnu/usr.bin
+CRUNCH_SRCDIRS+=usr.bin
+CRUNCH_SRCDIRS+=gnu/usr.bin
-CRUNCH_PROGS+=wall
+CRUNCH_PROGS_usr.bin+=wall
-CRUNCH_PROGS+=gzip
+CRUNCH_PROGS_gnu/usr.bin+=gzip
CRUNCH_ALIAS_gzip=gunzip
Re: Overdone rescue cleaning as part of buildworld?
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: [-CURRENT tinderbox] failure on i386/i386
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: [-CURRENT tinderbox] failure on i386/pc98
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: rescue/ broke cross compiles
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: rescue/ broke cross compiles
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
LOR in kern_thread.c
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: geom_vol_ffs problems
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
Re: SMBFS automounting broken?
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: LOR on libthr exit (iirc)
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
core dump with libthr
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: core dump with libthr
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=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! 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
Yet another libthr crash
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
LOR in PCM (big suprise there)
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)
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
Re: LOR in PCM
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
Re: libthr and 1:1 threading.
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: named chroot rcNG devfs
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: gbde
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: HEADS UP: VFS changes breaks GPT
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: HEADS UP: VFS changes breaks GPT
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: RC NG, ntp and routed
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
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: RC NG, ntp and routed
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
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: RCng Awkwardness
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
Re: RCng Awkwardness
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
Changes to Kerberos daemon startup
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
tar problems with --fast-read
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
HEADS UP: rcNG is now the default
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
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
Re: HEADS UP: rcNG is now the default
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
Re: HEADS UP: rcNG is now the default
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: bug in awk implementation?
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
bug in awk implementation?
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
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
Re: HEADS UP: rc.d is in the tree
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
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
HEADS UP: rc.d is in the tree
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 some others that I'm forgetting 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
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
Crash when attaching usb ethernet
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 usb_event_thread,
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: Crash when attaching usb ethernet
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
Re: UMA lock order reversal
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: sh dies w/ sig 12
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
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
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?
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
Netiquette (Was: Re: FreeBSD's aggressive keyboard probe/attach)
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?
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 needs to be moved into the base distribution. I give perl as a prime example of one time that this actually happened, despite the arguments for or against perl, it *IS* a standard tool, and it *IS* expected to be available. And for 99.999% of the users, they could care less if it's in /usr/local or in / And for things that are not in the base system, they belong in /usr/local. That's
Re: bash in /usr/local/bin?
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 sarcasm /sarcasm 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
ahc fails to attach in -current (was: snapshot installation woes)
On Sat, 4 Aug 2001, Gordon Tetlow wrote: Sure enough, that fixed the kernel panic, but here's the next odd piece, my hard drive wasn't showing up! I have a rather standard Adaptec AHA-2940 dmesg reports that ahc0 is there. The lines from the dmesg are (hand typed): ahc0: Adaptec 2940 Ultra SCSI adapter port 0x5000-0x50ff mem 0x5000-0x5fff irq 15 at device 15.0 on pci0 device_probe_and_attach: ahc0 attach returned 12 errno.h says ENOMEM is 12, so it seems that something in the ahc driver is unable to allocate memory. Dunno where or why, but something is fouling it up. By contrast 4.3-RELEASE doesn't have any issues (I'll try a recent snapshot if that would help). Sorry I can't help out any more, but the debugging tools in the installation disks seem to lacking (understandably). Okay, I tried with a 4.4-PRERELEASE bootdisk that was available on current.jp.freebsd.org and dmesg came up with the following: ahc0: Adaptec 2940 Ultra SCSI adapter port 0x5000-0x50ff mem 0x5000-0x5fff irq 15 at device 15.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs Since -stable and -current are using the exact same driver, there is something more subtle (and sinister?) going on that I can't figure out. At this point, I'm throwing my hands up in the air unless someone can give me a better idea as to what the possible problem could be. I'd really like to try -current on this box as it's a dual proc PPro 200. Thanks, -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: snapshot installation woes
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
Re: ntpd 4.1
On Fri, 3 Aug 2001, Sheldon Hearn wrote: On Fri, 03 Aug 2001 10:18:49 +0200, Sheldon Hearn wrote: So let me guess. Not only does Mills think that the web is the only sensible distribution medium for documentation, he also thinks that English is the only sensible language for it? Ha, you think that's bad. Mills doesn't want to be bothered to change his ways to use any sort of revision control. That's how set in his ways he is. Almost as bad as Linus. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
