Re: dangling symlinks in openzfs import
On Tue, Mar 21, 2023 at 11:39:11PM +0100, Yuri wrote: > These have been in there for quite some time now, and every time I > try to grep something I see this (I know about -s option, but it's > there in opengrok and other tools output as well): > grep: sys/contrib/openzfs/contrib/debian/openzfs-zfsutils.zfs-load-key.init: > No such file or directory Yes! Please someone delete them, or tell me the vendor workflow approved way of doing the task myself. I'd have fixed them myself if we were still using Subversion, but I don't know the correct way to handle them in the vendor branching within Git. -- -- David(obr...@freebsd.org)
Re: r255449: kernel compilation fails due to : cc: error: no input files
On Tue, Sep 10, 2013 at 08:14:30PM +0200, O. Hartmann wrote: On Tue, 10 Sep 2013 09:24:45 -0700 John-Mark Gurney j...@funkthat.com wrote: But, can you tell use how you built your kernel and on what system? COMPILER_TYPE should always be defined... Are you trying to build a HEAD kernel on 9stable w/o using buildkernel or something strange like that? With r255453 everything works as expected again. Thank you very much. It would still be helpful to know how you were building your kernel. If you were trying to build it on non-CURRENT, maybe we should add a check to ensure that COMPILER_TYPE is defined and if not warn folks their environment is not-supported. -- -- David (obr...@freebsd.org) ___ 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: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On Fri, Sep 06, 2013 at 09:19:32PM +0100, David Chisnall wrote: As of r255321, we are no longer building gcc or libstdc++ as part of the default install on platforms where clang is cc. I guess I missed where this was discussed. I don't feel we should not ship 10.0 without /usr/bin/g[c+][c+]. It is still very useful for folks to test changes in order to help ensure one doesn't break the build on platforms still using GCC. In the past, we've deprecated for a full release and then remove on the next. This is pretty late in the 10.0 game (now in code freeze) to be making such impactful changes. We have no idea how many 3rd party Makefiles (or other build systems) specify gcc explicitly. 2) Put WITH_GCC=yes and WITH_GNUCXX=yes in your src.conf when you build world. GCC will stay in the base system tree for at least the lifetime of the 10.x release, and possibly longer if it is still being actively used. It will remain used by tinderboxes and make universe for some architectures, so if you commit code without testing with gcc people will know very soon... Requiring folks to keep remembering to add this knob to any new installation will make it harder for developers to test... Compare to the buildworld time impact of Clang, the GCC build is nothing, so why not just have a WITHOUT_GCC knob for those that want nothing more to do with GCC? -- -- David (obr...@freebsd.org) ___ 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: GCC withdraw
On Thu, Aug 29, 2013 at 06:02:06PM +0100, David Chisnall wrote: rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). And committers need to learn that Devsummit discussions (and optional wiki's) are just like IRC ones -- we're all not there. But we're on the mailing lists. That's how we communicate far-and-wide. John and others bring up really good points. Until GCC is no longer used to build FreeBSD on any platform it should remain in all platforms. If part of your reasoning is to free up gcc and g++ commands for ports -- fine, but change the names /usr/bin/gcc and /usr/bin/g++ on all platforms for something else. /usr/bin/fbsd-gcc /usr/bin/fbsd-g++ or what not. -- -- David (obr...@freebsd.org) ___ 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
Unexpected behavior change [FreeBSD]make - bmake
For some reason bmake is now using share/mk/ from within a source tree instead of the installation in /usr/share/mk/: /w/10/usr.bin/xinstall$ bmake bmake: /b/deo/10/share/mk/bsd.own.mk line 444: MK_BMAKE can't be set by a user. I believe this is against POLA as there is no guarantee that a share/mk/ within the source tree is parseable by the invoked /usr/bin/bmake. It is /usr/share/mk/ that is guaranteed to be consistent with /usr/bin/make. I see this as synonymous with using headers from lib/libc/ within the source tree vs. /usr/include (which match the /lib/libc.so) when building in this same way. I think we can all agree that is wrong (the headers that match the libc that is being linked against needs to be used). Can we go back to the pre-16-May-2013 behavior? -- -- David (obr...@freebsd.org) ___ 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: [RFC/RFT] calloutng
On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote: On 15.12.2012 23:03, Alexander Motin wrote: Sorry, it's my fault. I've tried to save some time on patch generation and forgot about that change in lib/. We haven't touched user-level in our work except that file. Here is patch with that chunk added: http://people.freebsd.org/~mav/calloutng_12_15_1.patch And one more part I've missed is manual pages update, that probably needs more improvements: http://people.freebsd.org/~mav/calloutng_12_15.man.patch Perhaps use the SCM at what its good at? Sync your branch with HEAD and then do an 'svn diff ^/head' and your branch. -- -- David (obr...@freebsd.org) ___ 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: Traditional cpp (was: /usr/bin/calendar broken on current)
On Sat, Nov 10, 2012 at 05:46:21PM +1100, Greg 'groggy' Lehey wrote: On Friday, 9 November 2012 at 13:52:24 +0100, Dimitry Andric wrote: Looks like yet another cpp -traditional abuse. Use or abuse? In any case, it's not the only one. In the Good Old Days people did things like that. So, it seems, does imake, and I'm sure others will come out of the woodwork. ... Clang will most likely never support traditional preprocessing. ... What we really need is a traditional cpp. That's not difficult: there's one in 4.3BSD (all 32 kB of source). OpenBSD also had one, though it's gone now, so presumably that one has a clean license. Both appear to be from pcc. Should we import it into the tree as, say, tradcpp? There is also a public domain one in the X11R5 sources. And the well writen http://mcpp.sourceforge.net/ (BSD-style-licensed), with a test suite, etc.. See 'lmcpp-summary-272.pdf' there. -- -- David (obr...@freebsd.org) ___ 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: RFC: removal of share/doc/{papers,psd,smm,usd} in 2 months
On Fri, Oct 19, 2012 at 04:36:18PM +0200, Ulrich Sprlein wrote: those roff sources have been very naughty and will be removed from the tree by the end of the year. ... Should people feel strongly about them, we might be able to move them over to the doc repository. This does not seem a RFC -- this sounds more like you or a cabal already made the decision. -- -- David (obr...@freebsd.org) ___ 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: RFC: removal of share/doc/{papers,psd,smm,usd} in 2 months
On Mon, Oct 22, 2012 at 02:53:11PM +0200, C. P. Ghost wrote: How about converting them to SGML and integrating them into the Handbook (with the caveat that they are outdated, but retained for archival purposes)? I find the Handbook to not look very well due to its SGML nature and one page per chapter layout. The roff generated docs are nice proper papers. Not to mention, they can be read without a network connection or GUI application. (sure there's lynx, but its formatting of the Handbook is even worse than a GUI browser) -- -- David (obr...@freebsd.org) ___ 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: SVN2CVS exporter down
On Sun, Jul 01, 2012 at 11:14:45AM +0100, Simon L. B. Nielsen wrote: On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote: Just FYI, the svn2cvs exporter is currently down due to http://svn.freebsd.org/changeset/base/237860 . I'll fix it as soon as I get back from lunch, so should be back in a few hours. Fixed. Please try not to replace files or even worse directories. Thanks. Simon, Are you saying we are now restricted in the svn operations we can perform due to the lack of the svn2cvs exporter to consume them? If so, this doesn't seem desirable... we moved to Subversion to obtain such operations as file and directory moves. I suspect such operations will only happen with increased frequency after the Ports Collection moves to Subversion. -- -- David (obr...@freebsd.org) ___ 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: SVN2CVS exporter down
On Mon, Jul 02, 2012 at 10:55:57PM +0100, Simon L. B. Nielsen wrote: Tested patches are accepted (http://svnweb.freebsd.org/base/svnadmin/tools/export.py), or even better - work on killing off CVS sooner rather than later. I like the latter. :-) As we discussed at BSDcan -- I don't use CVS at all for src or docs. I use a svnsync'ed mirror at home and $WORK. :-) It works great. -- -- David (obr...@freebsd.org) ___ 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: [RFC] Un-staticise the toolchain
On Sat, Apr 28, 2012 at 11:03:17AM +0100, Bob Bishop wrote: Yes. You to have a statically linked /rescue/sh on board, so what's the point of /bin/sh being dynamic? While you and I agree on this, the primary reason we went with a dynamically linked root was for PAM and NSS support -- which are dlopen'ed. And thus requires using a shared libc. -- -- David (obr...@freebsd.org) ___ 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: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On Tue, Apr 24, 2012 at 09:34:58PM +0300, Vladimir Sharun wrote: === usr.bin/file (all) ... file.o: In function `main': /usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x717): undefined reference to `magic_getpath' /usr/src/usr.bin/file/../../contrib/file/file.c:(.text+0x7df): undefined reference to `magic_list' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [file] Error code 1 How are you building this? Did libmagic get [re]built first? r234657 $ svn info -r234657 svn info -r234657 svn://svn.freebsd.org/base/head Last Changed Date: 2012-04-24 10:51:36 -0700 (Tue, 24 Apr 2012) I do not believe that a 10-CURRENT system from 2012-04-24 has trouble building the new file(1). The issue that started this thread is due to a commit from 2009-02-27 -- which pre-dates 10-CURRENT. -- -- David (obr...@freebsd.org) ___ 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: [workaroud/fix for] buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On Fri, Apr 27, 2012 at 02:05:37PM +0200, Jan Sieka wrote:
--- a/lib/libmagic/Makefile
+++ b/lib/libmagic/Makefile
@@ -10,9 +10,16 @@ DPADD= ${LIBZ}
LDADD= -lz
MAN= libmagic.3 magic.5
+HOSTOSRELDATE!= echo ${VERSION} | cut -d -f 4
$ cd lib/libmagic
$ make -V VERSION
{empty}
Where is VERSION set?
+.if ${HOSTOSRELDATE} 80
+GETLINE_C= getline.c
+.else
+GETLINE_C=
+.endif
SRCS=apprentice.c apptype.c ascmagic.c cdf.c cdf_time.c compress.c \
encoding.c fsmagic.c funcs.c \
- is_tar.c magic.c print.c readcdf.c readelf.c softmagic.c
+ is_tar.c magic.c print.c readcdf.c readelf.c softmagic.c ${GETLINE_C}
Just
.if ${HOSTOSRELDATE} 80
GETLINE_C= getline.c
.endif
is shorter.
Also r189136 (which added getline(3)) bumped __FreeBSD_version from
800066 to 800067. So your patch is broken for some systems. Getting
this right is one reason I'm loath to carry around this type of hack
in -CURRENT.
--- a/lib/libmagic/config.h
+++ b/lib/libmagic/config.h
/* Define to 1 if you have the `getline' function. */
-#define HAVE_GETLINE 1
+#if (__FreeBSD_version = 80)
Where is __FreeBSD_version getting set?
+#else
+#define HAVE_GETLINE 0
+#endif
You've basically defined HAVE_GETLINE always as 0.
--
-- David (obr...@freebsd.org)
___
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: [RFC] Un-staticise the toolchain
On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote: Apparently, current dependencies are much more spread, e.g. /bin/sh is dynamically linked [etc] That seems like a bad mistake, because it would prevent even booting single-user if rtld/libraries are broken. When one enters single user they are prompted for which shell to use. If /bin/sh is broken due to being dynamic, '/rescue/sh' will likely still work. -- -- David (obr...@freebsd.org) ___ 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: [RFC] Un-staticise the toolchain
On Thu, Apr 26, 2012 at 07:52:01AM -0400, John Baldwin wrote: You could use /rescue/sh as your single-user shell. Of course, that would perhaps let you still be able to recompile things if you had a static toolchain. :) Having the toolchain static has saved me in exactly this way. -- -- David (obr...@freebsd.org) ___ 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: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012
On Sun, Apr 22, 2012 at 09:06:18AM -0700, Garrett Cooper wrote: On 4/20/2012 5:16 AM, Jan Sieka wrote: I can't build world from recent sources (HEAD as of 2012.04.19 11:06:48 UTC) on a machine running FreeBSD 7.3. ... Ugh. The usecase (that's now broken) is that Jan from Semihalf might have been running CURRENT builds on an older (stable) build machine. Lets not guess. If you've found that any version of 10-CURRENT cannot build HEAD post r234449 please let me know. I've verified that I can build HEAD on 8.3-PRERELEASE (r231882). -- -- David (obr...@freebsd.org) ___ 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: contrib/jemalloc
On Fri, Apr 20, 2012 at 02:13:32PM -0700, Pedro Giffuni wrote: Easier said than done. Feel free to give libedit a try. That has nothing to do with our process and everything to do with us blindly hacking away pissing all over to be our own thing -- BUT still wanting to take work from the original author. I fail to see how not updating thru $FBSDrepo/vendor/NetBSD/libedit is easier than updating thru it. Either way you have to figure out what to do with our great divergance. At least when using the vendor branch you can use a good 3-way diff merge tool (e.g. svn). -- -- David (obr...@freebsd.org) ___ 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: contrib/jemalloc
On Thu, Apr 12, 2012 at 01:19:56PM -0700, Jason Evans wrote: On Apr 12, 2012, at 11:41 AM, David O'Brien wrote: On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote: I have the current version of jemalloc integrated into libc as contrib/jemalloc: http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch ... * Is it acceptable to check this in directly to trunk without using a vendor branch? For the import workflow I have planned, a vendor branch would just be extra work with no benefit that I can see. I do not think it is acceptable. Our workflow is to do vendor imports. They are invaluable in tracking down history and changes years after the fact. They are also very valuable to commercial third-parties that consume FreeBSD into their products (I speak for Juniper Networks in this). Why do you feel they are [measurably] extra work with no benefit? The workflow I'm using is documented in the patch (contrib/jemalloc/FREEBSD-upgrade). Can you tell me how to achieve a similarly streamlined import flow with a vendor branch in the mix? Hi Jason, It looks like you could run './FREEBSD-upgrade extract' from a check out of ssh://svn.freebsd.org/base/vendor/jemalloc. I'm unclear what the './FREEBSD-upgrade rediff' step is for. I'm having trouble following what then regenerate diffs to update line offsets is for. How do you handle the difference between FreeBSD having include/malloc_np.h and your GIT repo having jemalloc/include/jemalloc/jemalloc.h[.in]? Does './FREEBSD-upgrade extract' or './FREEBSD-upgrade rediff' patch 'include/malloc_np.h' and 'include/stdlib.h'? Especially with the '#define JEMALLOC_P(s) s' wrapping. Is that part of the './FREEBSD-upgrade rediff' step? Can you nudge me in the right direction to understanding this workflow? Typically the tracking of diffs between what's in your vendor GIT repo and FreeBSD comes from the FreeBSD SCM system. A combination of 'svn diff ^/vendor/jemalloc/dist ^/head/contrib/jemalloc' and 'cd contrib/jemalloc svn merge ^/vendor/jemalloc/dist'. Also, what history would a vendor branch preserve that this workflow does not? contrib/jemalloc/FREEBSD-upgrade doesn't describe the commit into FreeBSD subversion repo step, that I can see. So I am not sure what gets committed vs. what's in git://canonware.com/jemalloc.git. The only upside to vendor branch merges I can think of is that if any jemalloc sources were manually modified between imports, merging would fail rather than silently overwriting the changes. I feel that is an important check-and-balance. Not following our established procedure also means that the average developer(committer) and commercial consumer will have their expectations fails. One expects to be able to find the stock vendor sources in ssh://svn.freebsd.org/base/vendor/ and to be able to find FreeBSD local changes to the sources thru 'svn diff' against ssh://obr...@svn.freebsd.org/base. However, this presumes that changes aren't making it upstream. That is not an unreasonable presumption. Unless contrib/jemalloc/ is locked so that you are aware of every commit FreeBSD and git://canonware.com/jemalloc.git can diverge at times. -- -- David (obr...@freebsd.org) ___ 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: contrib/jemalloc
On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote: I have the current version of jemalloc integrated into libc as contrib/jemalloc: http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch Looking at the latest patch http://people.freebsd.org/~jasone/patches/jemalloc_20120405a.patch I cannot tell for sure if you did an 'svn move' of the files from lib/libc/stdlib/ to contrib/jemalloc/. It looks to me like they have not. If not, can you regen the diff after using 'svn move' so we maintain log history? * Is it acceptable to check this in directly to trunk without using a vendor branch? For the import workflow I have planned, a vendor branch would just be extra work with no benefit that I can see. I do not think it is acceptable. Our workflow is to do vendor imports. They are invaluable in tracking down history and changes years after the fact. They are also very valuable to commercial third-parties that consume FreeBSD into their products (I speak for Juniper Networks in this). Why do you feel they are [measurably] extra work with no benefit? -- -- David (obr...@freebsd.org) ___ 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: removing libreadline from base system
On Thu, Dec 01, 2011 at 08:41:12PM -0600, Brooks Davis wrote: On Thu, Dec 01, 2011 at 05:55:37PM -0800, David O'Brien wrote: On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb Max, What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. We are rapidly approaching the point where it will be practical to remove all GPL code from the base system (assuming we are willing to require external toolchains for some architectures) and a number of us are pushing to make this a reality for 10.0. Agreed and known. If the application(s) using libreadline weren't already GPL I wouldn't have spoken up. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses to libedit. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. I guess this is the real agenda? To get ports to depend on an /usr/ports' version of libreadline? If so, can it please wait 6 months until we've gotten thru the current nightmare that /usr/ports is on FreeBSD-CURRENT? Until this November that most ports would not build on -current, one still cannot 'pkg_add -r' anything, etc... Right now, I don't think we need another thing different between FreeBSD pre-10 and 10 that will be a /usr/ports headache. -- -- David (obr...@freebsd.org) ___ 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: WITHOUT_PROFILE=yes by default
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote: You still failed to name a single compelling reason to leave profiled libs even in -CURRENT. Sorry Joe, I don't think your reasoning is compelling. I'm sure you know how to stick NO_PROFILE=true in your /etc/src.conf. How far do you want to take this? By this reasoning we should set all the knobs to NO to speed up the build. I mean we're all competent code builders running FreeBSD-current and know how to enable knobs in /etc/src.conf. Is speeding up the build import important to you then the default base system being an comfortable featureful development environment? On Thu, Dec 01, 2011 at 11:23:49PM -0800, Steve Kargl wrote: On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote: On 12/01/2011 22:41, Steve Kargl wrote: Having a set of profiled libraries in-sync with the static and shared libraries allows one to run the profiler on their code when someone changes a library and that change causes a dramatic change in the performance of one's code. And as Max pointed out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. Not only do I want to use them, I do use use profiled libraries. All those changes to libm that I've submitted over the years have been run through the profile. More importantly, we are discussion freebsd-current. I would hope that the other developers profile their changes to system before committing. Exactly! We want to *encourage* the use of profiling in development. Not make it harder. With out the profiled libs being readily available, it becomes yet another step to go thru and an impediment to quick performance checking. -- -- David (obr...@freebsd.org) P.S. Max, would you please turn off HTML mail when sending to FreeBSD mailing lists? Many of us use that as an indication of SPAM on these lists. I've missed your responses to me due to that. ___ 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: removing libreadline from base system
On Fri, Dec 02, 2011 at 12:57:20PM +0700, Max Khon wrote: On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien obr...@freebsd.org wrote: If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. Then you need to define what base system is. Eh? Its the same definition has been for the past 17 years -- that which is in /usr/src. As long as there is a GPL consumer of libreadline in /usr/src, there is no benefit to kicking libreadline out of /usr/src. I understand the anti-GPL sentiment -- I've done my share over the years to help achieve a GPL-free FreeBSD. But until there is a debugger that is anywhere near as capable (and mature) as GDB, we'll have a few GPL bits in /usr/src. I see that as OK -- its is small and contained. Show me a non-GPL consumer of libreadline in /usr/src and I'll do everything I can to have it work with libedit. When I added the libreadline compatibility to libedit, I changed all the non-GPL libreadline uses I knew of to libedit. We have much more ports that depend on libintl or libglib2 than libreadline. Should we add these libs to the base system too? Please tell me what consumer of libintl or libglib2 we have in /usr/src. Also, almost all ports require gmake and autotools to be built. Should we add them to the base system too? You're now being quite ridiculous. -- -- David (obr...@freebsd.org) ___ 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: Remove debug echo
On Wed, Nov 30, 2011 at 05:59:33PM -0800, Garrett Cooper wrote: On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best arun...@freebsd.org wrote: On Wed Nov 30 11, Garrett Cooper wrote: On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best arun...@freebsd.org wrote: ? ? pmake sucks as far as diagnostic output is concerned when compared with gmake. I'd rather not have to fish through with -j1 (if I'm lucky and it's not a race) to determine what directory created the Error Code output. With the printouts discussed here, at least you have a chance at determining what the issue was. ? ? Maybe it's just me, but I like noisy builds -- otherwise the amount of time I have to spend root-causing the issue becomes expensive. [...] Otherwise diagnosing issues becomes a PITA with -j 1 (with pmake I have to start using some serious grep'ing, and if I'm lucky I can find the source of error). Well its a PITA mostly because we disabled Pmake's -j job-markers back in 1998 (r41151). If you build with 'make -v -j1' you get much more debugable output. bmake (NetBSD's make) is even nicer in this regard. I was *amazed* when I joined $WORK and a '-j16' build was debugable. -- -- David (obr...@freebsd.org) ___ 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: Remove debug echo
On Thu, Dec 01, 2011 at 10:04:08AM -0500, John Baldwin wrote: I think this is useful, perhaps send it to harti@ or jilles@ for review? I'd like to get some NetBSD bmake maintainers POV too. We should reduce the needless diversion between the two makes. -- -- David (obr...@freebsd.org) ___ 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: stupid cp(1) behaviour
On Thu, Dec 01, 2011 at 11:35:50AM -0800, Matt Mullins wrote: On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best arun...@freebsd.org wrote: implement a new -N switch or so which isn't based on a file's existance, but a file's checksum. You can always use net/rsync, which does by default compare checksums. I don't believe that is true [anymore]: $ rsync --help rsync version 3.0.9 protocol version 30 Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others. [...] -c, --checksum skip based on checksum, not mod-time size ... -I, --ignore-times don't skip files that match in size and mod-time --size-only skip files that match in size --modify-window=NUM compare mod-times with reduced accuracy -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ 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: removing libreadline from base system
On Tue, Nov 29, 2011 at 04:46:30PM +0700, Max Khon wrote: This is a separate issue that I want to handle separately. I see no value in handling it separately. I either have a libreadline on my system or I don't. Again, what problem are you trying to solve? The question is what to do with gdb friends. Link it with libedit or re-import bundled readline (that is shipped with gdb) and build/link it only to gdb. I am inclined to do the former. Consider this an explicit request to do nothing to the base libreadline. -- -- David (obr...@freebsd.org) ___ 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: WITHOUT_PROFILE=yes by default
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: I would like to disable building profiled libraries by default. Opinions? On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote: Author: fjoe Date: Tue Nov 29 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Wow, a single day of discussion in freebsd-current@ was sufficient to invert a 17 year default. I'd like to see the profile libs remain built by default in -CURRENT. If you like, add it to the list of things to disable on -STABLE creation. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ 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: removing libreadline from base system
On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: It is possible to build and link our in-tree gdb friends with libedit after r228114. The remaining question is what to do with libreadline: 1) just build link gdb with libedit OR 2) re-import libreadline from gdb sources and build INTERNALLIB version of it that is never installed and is linked only to gdb Max, What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. I am inclined to go for 1) but libedit may have (and has) incompatibilities with libreadline. I'm inclined to DO NOTHING. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ 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: Upgrade contributed gperf, m4 and flex
On Fri, Nov 25, 2011 at 08:01:37PM +0100, Baptiste Daroussin wrote: and last: upgrade flex to the latest upstream version (it will need the m4 upgrade) while here I'll move back flex to contrib/ patches can be found there: http://people.freebsd.org/~bapt/flex-update.diff Hi Baptiste, I cannot tell from this what you are really doing. It would likely be best to keep the old history, so that would involve a 'svn move usr.bin/lex contrib/flex'. Additionally if flex is now considered to be 3rd-party code (signified by living in contrib/) it should be imported we into '$REPO/base/vendor'. These actions would give a different diff than that above. Do you have a diff that shows what the real changes to FreeBSD are? I also plan to upgrade m4 syncing code from openbsd, taking code from netbsd (improve gnu m4 compatibility). http://people.freebsd.org/~bapt/update_m4_from_openbsd_and_netbsd.diff We don't seen to have '$REPO/base/vendor/OpenBSD/m4' as we likely should. How different is our usr.bin/m4 from OpenBSD's? http://people.freebsd.org/~bapt/upgrade-gperf-to-3.0.3.diff I assume an import into '$REPO/base/vendor/gperf/' will happen first? ['$REPO/base/vendor/gperf/' needs to be flattend out first] thanks, -- -- David (obr...@freebsd.org) ___ 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: cvsup broken on amd64?
On Fri, Sep 09, 2011 at 06:00:02PM +0300, Kostik Belousov wrote:
--- libs/m3core/src/thread/POSIX/ThreadPosix.m3.orig 2011-09-09
17:58:12.867431639 +0300
+++ libs/m3core/src/thread/POSIX/ThreadPosix.m3 2011-09-09
17:58:30.380428486 +0300
@@ -180,7 +180,7 @@
pausedThreads : T;
selected_interval:= UTime{0, 100 * 1000};
- defaultStackSize := 3000;
+ defaultStackSize := 1;
This might not be a large enough value (depending on the unit of measure).
I synced tzdata+tzcode at $WORK and we found the amount of stack used by
tzload() alone is now quite large -- 41k on ARM.
--
-- David (obr...@freebsd.org)
___
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: Experiences with FreeBSD 9.0-BETA2
On Mon, Sep 26, 2011 at 07:48:23PM -0400, Benjamin Kaduk wrote: My recollection is that this is because kensmith forgot to take 'makeoptions DEBUG=-g' out of GENERIC when branching stable/8, and no one noticed until a couple of releases in, at which point it seemed consistent with POLA to just keep it there. Unfortunately I am not having much luck digging through mail archives trying to confirm that. I don't remember whether the plan was to turn it off on stable/9 or not. When I split out the symbols from the kernel, the intention was to always build with -g so users would have the symbols to help debug reported problems. If one was running a stock release kernel, they are not needed as we know where to find them -- the intention was to have a kernel-symbols tarball that was an option install. I pretty strongly feel that -g should not be removed from stable/9's kernel configs. Otherwise we're more in the dark when folks report problems from tracking -STABLE. -- -- David (obr...@freebsd.org) ___ 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: Thoughts on TMPFS no longer being considered highly experimental
Hi KIB, Thanks for the list of issues you know about -- I don't believe we have PRs covering those. On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: - I believe Peter Holm has more test cases that fails with tmpfs. He would have more details. I somewhat remember some panic on execve(2) the binary located on tmpfs. I've been following the patches you've been passing to Peter Holm as part of this thread. Seems good progress has been made in fixing some of the issues. Removing the warning will not make the issues coming away. Quite true, but is there any other subsystem where we know we have bugs and have put up such a scary warning? I've never used ZFS on i386, but I understand it is trivial to panic with out-of-the-box settings. We don't print a dire warning for ZFS usage on 32-bit platforms. So I'm not sure we should keep it for TMPFS. I cannot tell from your response if you're OK or against removing the warning. [especially if your patches pass the Peter Holm test and remove some of the bugs] -- -- David (obr...@freebsd.org) ___ 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
Thoughts on TMPFS no longer being considered highly experimental
Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Index: tmpfs_vfsops.c === --- tmpfs_vfsops.c (revision 221113) +++ tmpfs_vfsops.c (working copy) @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp) return EOPNOTSUPP; } - printf(WARNING: TMPFS is considered to be a highly experimental - feature in FreeBSD.\n); - vn_lock(mp-mnt_vnodecovered, LK_SHARED | LK_RETRY); error = VOP_GETATTR(mp-mnt_vnodecovered, va, mp-mnt_cred); VOP_UNLOCK(mp-mnt_vnodecovered, 0); -- -- David (obr...@freebsd.org) ___ 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
[PANIC] ffs_alloccg: map corrupted (w/SU+J)
Feb 24 19:43:16 : FreeBSD 9.0-CURRENT #662 r218815:218845M: Tue Feb 22 00:13:31
PST 2011
Feb 24 19:43:16 : /sys/i386/compile/DRAGON i386
[..]
Mar 5 14:41:38 : start = 0, len = 1659, fs = /storage
Mar 5 14:41:38 : panic: ffs_alloccg: map corrupted
Mar 5 14:41:38 : cpuid = 0
Mar 5 14:41:38 : KDB: stack backtrace:
Mar 5 14:41:38 : db_trace_self_wrapper(c084242b,65676172,a0d,4,0,...) at
0xc04ebf46 = db_trace_self_wrapper+0x26
Mar 5 14:41:38 : kdb_backtrace(c0860edc,0,c085531a,eaf4870c,0,...) at
0xc05ff87a = kdb_backtrace+0x2a
Mar 5 14:41:38 : panic(c085531a,0,67b,c65230d4,e000c000,...) at 0xc05d1d67 =
panic+0x117
Mar 5 14:41:38 : ffs_mapsearch(4462ea0,0,8,0,0,...) at 0xc0759163 =
ffs_mapsearch+0x153
Mar 5 14:41:38 : ffs_alloccgblk(4462ea0,0,4000,5ae,0,...) at 0xc075935c =
ffs_alloccgblk+0xec
Mar 5 14:41:38 : ffs_alloccg(c99c29f8,2fa,4462ea0,0,4000,...) at 0xc0759c83 =
ffs_alloccg+0x1b3
Mar 5 14:41:38 : ffs_hashalloc(4462ea0,0,4000,4000,c0759ad0,...) at 0xc0756321
= ffs_hashalloc+0x41
Mar 5 14:41:38 : ffs_alloc(c99c29f8,100e,0,4462ea0,0,...) at 0xc075acff =
ffs_alloc+0x19f
Mar 5 14:41:38 : ffs_balloc_ufs2(ca740110,4038000,0,4000,c8bc7400,...) at
0xc075cff9 = ffs_balloc_ufs2+0x1949
Mar 5 14:41:38 : ffs_write(eaf48b90,eaf48b4c,eaf48b10,c0780ac2,ca740168,...)
at 0xc077fc66 = ffs_write+0x276
Mar 5 14:41:38 : VOP_WRITE_APV(c08bb080,eaf48b90,ca740110,264,0,...) at
0xc08036e4 = VOP_WRITE_APV+0xe4
Mar 5 14:41:38 : vn_write(c7cfcc78,eaf48c24,c8bc7400,0,cddd05c0,...) at
0xc0663ad3 = vn_write+0x1c3
Mar 5 14:41:38 : dofilewrite(eaf48c24,,,0,c7cfcc78,...) at
0xc060fe55 = dofilewrite+0x95
Mar 5 14:41:38 : kern_writev(cddd05c0,4,eaf48c24,eaf48c44,1,...) at 0xc06100e8
= kern_writev+0x58
Mar 5 14:41:38 : write(cddd05c0,eaf48cec,cddd05c0,eaf48d28,4,...) at
0xc061016f = write+0x4f
Mar 5 14:41:38 : syscallenter(cddd05c0,eaf48ce4,eaf48ce4,0,3,...) at
0xc060b363 = syscallenter+0x2c3
Mar 5 14:41:38 : syscall(eaf48d28) at 0xc07e3114 = syscall+0x34
Mar 5 14:41:38 : Xint0x80_syscall() at 0xc07cf121 = Xint0x80_syscall+0x21
Mar 5 14:41:38 : --- syscall (4, FreeBSD ELF32, write), eip = 0x2818c60b, esp
= 0xbfbfe86c, ebp = 0xbfbfe8d8 ---
Changes since my last reported SU+J panic:
1. Newer revision of ahd(4) ASIC
2. New U320 SCA enclosures (different vendor + model).
3. New motherboard
--
-- David (obr...@freebsd.org)
P.S. I am using this UFS patch:
Index: ufs/ffs/ffs_softdep.c
===
--- ufs/ffs/ffs_softdep.c (revision 218815)
+++ ufs/ffs/ffs_softdep.c (working copy)
@@ -6068,6 +6068,7 @@ indir_trunc(freework, dbn, lbn)
struct jnewblk *jnewblk;
struct freeblks *freeblks;
struct buf *bp;
+ struct bufobj *bo;
struct fs *fs;
struct worklist *wkn;
struct worklist *wk;
@@ -6106,14 +6107,13 @@ indir_trunc(freework, dbn, lbn)
* a complete copy of the indirect block in memory for our use.
* Otherwise we have to read the blocks in from the disk.
*/
-#ifdef notyet
- bp = getblk(freeblks-fb_devvp, dbn, (int)fs-fs_bsize, 0, 0,
- GB_NOCREAT);
-#else
- bp = incore(freeblks-fb_devvp-v_bufobj, dbn);
-#endif
+ bo = freeblks-fb_devvp-v_bufobj;
+check_incore:
ACQUIRE_LOCK(lk);
+ BO_LOCK(bo);
+ bp = gbincore(bo, dbn);
if (bp != NULL (wk = LIST_FIRST(bp-b_dep)) != NULL) {
+ BO_UNLOCK(bo);
if (wk-wk_type != D_INDIRDEP ||
(wk-wk_state GOINGAWAY) == 0)
panic(indir_trunc: lost indirdep %p, wk);
@@ -6126,15 +6126,34 @@ indir_trunc(freework, dbn, lbn)
ump-um_numindirdeps -= 1;
FREE_LOCK(lk);
} else {
-#ifdef notyet
- if (bp)
- brelse(bp);
-#endif
FREE_LOCK(lk);
- if (bread(freeblks-fb_devvp, dbn, (int)fs-fs_bsize,
- NOCRED, bp) != 0) {
- brelse(bp);
- return;
+ if (bp != NULL) {
+ if (BUF_LOCK(bp, LK_EXCLUSIVE | LK_NOWAIT |
+ LK_INTERLOCK, BO_MTX(bo)) != 0) {
+ pause(INDIRT, 1);
+ goto check_incore;
+ }
+ } else {
+ BO_UNLOCK(bo);
+ bp = getblk(freeblks-fb_devvp, dbn, fs-fs_bsize, 0,
+ 0, 0);
+ if (LIST_FIRST(bp-b_dep) != NULL) {
+ brelse(bp);
+ goto check_incore;
+ }
+ }
+
+ if ((bp-b_flags B_CACHE) == 0) {
+ bp-b_iocmd = BIO_READ;
+ bp-b_flags = ~B_INVAL;
+ bp-b_ioflags = ~BIO_ERROR;
+ vfs_busy_pages(bp, 0);
+
Re: [PANIC] ffs_alloccg: map corrupted
On Thu, Dec 02, 2010 at 03:31:41PM -0800, Garrett Cooper wrote: On Thu, Dec 2, 2010 at 2:43 PM, David O'Brien obr...@freebsd.org wrote: Thoughts? FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010 ? ?ro...@dragon:/sys/i386/compile/DRAGON i386 [..] start = 0, len = 3359, fs = /files panic: ffs_alloccg: map corrupted [..] ffs_balloc_ufs2(ce55e660,38000,0,4000,ce77b300,...) at 0xc0755629 = ffs_balloc_ufs2+0x1949 [..] panic: bufwrite: buffer is not busy??? UFS? UFS2? SU? SU+J? Got more details :)? UFS2, SU+J, ahd(4) HBA -- -- David (obr...@freebsd.org) ___ 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
[PANIC] after manually issuing 'ifconfig sf0'
Machine booted, without any mention of sf(4) in rc.conf or loader.conf and without sf(4) in the core kernel. This is without WITNESS or INVARIANTS. From multi-user, I issued 'ifconfig sf0' and got the below panic. These are the console messages related to this: FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010 ro...@dragon:/sys/i386/compile/DRAGON i386 [..] Thu Dec 2 09:33:50 PST 2010 sf0: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x5000-0x50ff mem 0xb040-0xb047 irq 19 at device 4.0 on pci5 miibus2: MII bus on sf0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf0: Ethernet address: 00:00:d1:ed:81:95 sf1: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x5400-0x54ff mem 0xb048-0xb04f irq 16 at device 5.0 on pci5 miibus3: MII bus on sf1 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf1: Ethernet address: 00:00:d1:ed:81:96 sf2: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x5800-0x58ff mem 0xb050-0xb057 irq 18 at device 6.0 on pci5 miibus4: MII bus on sf2 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus4 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf2: Ethernet address: 00:00:d1:ed:81:97 sf3: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x5c00-0x5cff mem 0xb058-0xb05f irq 17 at device 7.0 on pci5 miibus5: MII bus on sf3 ukphy3: Generic IEEE 802.3u media interface PHY 1 on miibus5 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf3: Ethernet address: 00:00:d1:ed:81:98 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x238 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05be315 stack pointer = 0x28:0xe7a5eab4 frame pointer = 0x28:0xe7a5eaf4 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 = 2590 (mail.local) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0839222,d31206e,2c66000a,70797420,78302065,...) at 0xc04e9ab6 = db_trace_self_wrapper+0x26 kdb_backtrace(c0857e2a,0,c0822eb2,e7a5e910,0,...) at 0xc05fa2fa = kdb_backtrace+0x2a panic(c0822eb2,c0858b68,c59aea18,1,1,...) at 0xc05cd297 = panic+0x117 trap_fatal(c596d880,0,c0858a20,36b,238,...) at 0xc07dcd65 = trap_fatal+0x325 trap_pfault(e7a5e9b8,c07fae4d,e7a5e9cc,0,c59ae870,...) at 0xc07dcf40 = trap_pfault+0x1c0 trap(e7a5ea74) at 0xc07dd5f5 = trap+0x5d5 calltrap() at 0xc07c8dfc = calltrap+0x6 --- trap 0xc, eip = 0xc05be315, esp = 0xe7a5eab4, ebp = 0xe7a5eaf4 --- _mtx_lock_sleep(c51b8be8,c59ae870,0,c08501a2,a43,...) at 0xc05be315 = _mtx_lock_sleep+0xa5 _mtx_lock_flags(c51b8be8,0,c08501a2,a43,c51b8c1c,...) at 0xc05be542 = _mtx_lock_flags+0x42 uma_zfree_arg(c51b8c08,c6555000,c6554000,0,e7a5eb80,...) at 0xc0790958 = uma_zfree_arg+0xd8 free(c6555000,c0886600,e7a5ec24,c6eb39a0,e7a5ec24,...) at 0xc05bb61e = free+0xae random_read(c5283700,e7a5ec24,0,0,0,...) at 0xc0c3535e = random_read+0x9e devfs_read_f(c6eb39a0,e7a5ec24,c5157580,0,c59ae870,...) at 0xc056bd32 = devfs_read_f+0x82 dofileread(e7a5ec24,,,0,c6eb39a0,...) at 0xc060adbe = dofileread+0x9e kern_readv(c59ae870,4,e7a5ec24,e7a5ec44,1,...) at 0xc060b148 = kern_readv+0x58 read(c59ae870,e7a5ecec,c59ae870,e7a5ed28,6,...) at 0xc060b23f = read+0x4f syscallenter(c59ae870,e7a5ece4,e7a5ece4,0,3,...) at 0xc0605d43 = syscallenter+0x2c3 syscall(e7a5ed28) at 0xc07dcf94 = syscall+0x34 Xint0x80_syscall() at 0xc07c8e91 = Xint0x80_syscall+0x21 --- syscall (3, FreeBSD ELF32, read), eip = 0x2819762b, esp = 0xbfbfdf6c, ebp = 0xbfbfe028 --- Uptime: 6m26s Physical memory: 2034 MB Dumping 111 MB: ___ 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
[PANIC] ffs_alloccg: map corrupted
Thoughts? FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010 ro...@dragon:/sys/i386/compile/DRAGON i386 [..] start = 0, len = 3359, fs = /files panic: ffs_alloccg: map corrupted cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c0839222,a0d7365,0,c08affe0,7,...) at 0xc04e9ab6 = db_trace_self_wrapper+0x26 kdb_backtrace(c0857e2a,1,c084c0c3,e99dd70c,1,...) at 0xc05fa2fa = kdb_backtrace+0x2a panic(c084c0c3,0,d1f,c6bfc8d4,e123,...) at 0xc05cd297 = panic+0x117 ffs_mapsearch(3f03fe0,0,8,0,0,...) at 0xc0751793 = ffs_mapsearch+0x153 ffs_alloccgblk(3f03fe0,0,4000,5a5,0,...) at 0xc075198c = ffs_alloccgblk+0xec ffs_alloccg(c98706cc,2be,3f03fe0,0,4000,...) at 0xc07522b3 = ffs_alloccg+0x1b3 ffs_hashalloc(3f03fe0,0,4000,4000,c0752100,...) at 0xc074ebb1 = ffs_hashalloc+0x41 ffs_alloc(c98706cc,e,0,3f03fe0,0,...) at 0xc075332f = ffs_alloc+0x19f ffs_balloc_ufs2(ce55e660,38000,0,4000,ce77b300,...) at 0xc0755629 = ffs_balloc_ufs2+0x1949 ffs_write(e99ddb90,e99ddb4c,e99ddb10,c0778dc2,ce55e6b8,...) at 0xc0777f66 = ffs_write+0x276 VOP_WRITE_APV(c08b0500,e99ddb90,ce55e660,264,0,...) at 0xc07fb574 = VOP_WRITE_APV+0xe4 vn_write(cf7a9cb0,e99ddc24,ce77b300,0,cb5a2870,...) at 0xc065ec93 = vn_write+0x1c3 dofilewrite(e99ddc24,,,0,cf7a9cb0,...) at 0xc060a9f5 = dofilewrite+0x95 kern_writev(cb5a2870,1,e99ddc24,e99ddc44,1,...) at 0xc060ac88 = kern_writev+0x58 write(cb5a2870,e99ddcec,4,c08ecbc0,b,...) at 0xc060ad0f = write+0x4f syscallenter(cb5a2870,e99ddce4,c05bde7d,c709d0d0,3110a33f,...) at 0xc0605d43 = syscallenter+0x2c3 syscall(e99ddd28) at 0xc07dcf94 = syscall+0x34 Xint0x80_syscall() at 0xc07c8e91 = Xint0x80_syscall+0x21 --- syscall (4, FreeBSD ELF32, write), eip = 0x281e260b, esp = 0xbfbfc19c, ebp = 0xbfbfc1b8 --- panic: bufwrite: buffer is not busy??? cpuid = 1 -- -- David (obr...@freebsd.org) ___ 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
[PANIC] ffs_alloccg: map corrupted (2nd file system)
FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010 ro...@dragon:/sys/i386/compile/DRAGON i386 [..] start = 0, len = 2, fs = /jazz panic: ffs_alloccg: map corrupted cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper(c0839222,0,1,4,0,...) at 0xc04e9ab6 = db_trace_self_wrapper+0x26 kdb_backtrace(c0857e2a,2,c084c0c3,ea17f70c,2,...) at 0xc05fa2fa = kdb_backtrace+0x2a panic(c084c0c3,0,2,c5d580d4,dc7d4000,...) at 0xc05cd297 = panic+0x117 ffs_mapsearch(3af3c10,0,8,0,0,...) at 0xc0751793 = ffs_mapsearch+0x153 ffs_alloccgblk(3af3c10,0,4000,5a5,0,...) at 0xc075198c = ffs_alloccgblk+0xec ffs_alloccg(c7758ae0,291,3af3c10,0,4000,...) at 0xc07522b3 = ffs_alloccg+0x1b3 ffs_hashalloc(3af3c10,0,4000,4000,c0752100,...) at 0xc074ebb1 = ffs_hashalloc+0x41 ffs_alloc(c7758ae0,380c,0,3af3c10,0,...) at 0xc075332f = ffs_alloc+0x19f ffs_balloc_ufs2(c7753110,e03,0,4000,c8ac8880,...) at 0xc0755369 = ffs_balloc_ufs2+0x1689 ffs_write(ea17fb90,ea17fb4c,ea17fb10,c0778dc2,c7753168,...) at 0xc0777f66 = ffs_write+0x276 VOP_WRITE_APV(c08b0500,ea17fb90,c7753110,264,0,...) at 0xc07fb574 = VOP_WRITE_APV+0xe4 vn_write(c6cc6888,ea17fc24,c8ac8880,0,c88c2000,...) at 0xc065ec93 = vn_write+0x1c3 dofilewrite(ea17fc24,,,0,c6cc6888,...) at 0xc060a9f5 = dofilewrite+0x95 kern_writev(c88c2000,4,ea17fc24,ea17fc44,1,...) at 0xc060ac88 = kern_writev+0x58 write(c88c2000,ea17fcec,c88c2000,ea17fd28,e8e2d15e,...) at 0xc060ad0f = write+0x4f syscallenter(c88c2000,ea17fce4,ea17fce4,0,0,...) at 0xc0605d43 = syscallenter+0x2c3 syscall(ea17fd28) at 0xc07dcf94 = syscall+0x34 Xint0x80_syscall() at 0xc07c8e91 = Xint0x80_syscall+0x21 --- syscall (4, FreeBSD ELF32, write), eip = 0x281e260b, esp = 0xbfbfb61c, ebp = 0xbfbfb638 --- panic: bufwrite: buffer is not busy??? cpuid = 2 -- -- David (obr...@freebsd.org) ___ 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
'panic: make_dev_credv: bad si_name (error=17, si_name=ttyU0)' with USB serial adapter
Thoughts? anh-thu.NUXI.org dumped core - see ./vmcore.1 Tue Nov 30 16:10:57 PST 2010 FreeBSD anh-thu.NUXI.org 9.0-CURRENT FreeBSD 9.0-CURRENT #85 r214782M: Thu Nov 4 09:13:24 PDT 2010 ro...@anh-thu.nuxi.org:/usr/src/sys/i386/compile/ANH-THU i386 panic: make_dev_credv: bad si_name (error=17, si_name=ttyU0) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd... Unread portion of the kernel message buffer: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #85 r214782M: Thu Nov 4 09:13:24 PDT 2010 ro...@anh-thu.nuxi.org:/usr/src/sys/i386/compile/ANH-THU i386 CPU: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz (1828.79-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6ec Family = 6 Model = e Stepping = 12 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xc1a9SSE3,MON,VMX,EST,TM2,xTPR,PDCM AMD Features=0x10NX TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2093707264 (1996 MB) Event timer LAPIC quality 400 ACPI APIC Table: LENOVO TP-79 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20101013/tbfadt-625) ACPI Warning: Optional field Gpe1Block has zero address or length: 0x102C/0x0 (20101013/tbfadt-655) ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: LENOVO TP-79 on motherboard CPU0: local APIC error 0x40 acpi_ec0: Embedded Controller: GPE 0x1c, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xd800-0xdfff,0xee10-0xee10 irq 16 at device 0.0 on pci1 hdac0: Intel 82801G High Definition Audio Controller mem 0xee40-0xee403fff irq 17 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 pcib2: ACPI PCI-PCI bridge irq 20 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection 7.1.7 port 0x3000-0x301f mem 0xee00-0xee01 irq 16 at device 0.0 on pci2 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1a:6b:67:33:3d pcib3: ACPI PCI-PCI bridge irq 21 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xedf0-0xedf00fff irq 17 at device 0.0 on pci3 pcib4: ACPI PCI-PCI bridge irq 22 at device 28.2 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 23 at device 28.3 on pci0 pci12: ACPI PCI bus on pcib5 uhci0: Intel 82801G (ICH7) USB controller USB-A port 0x1800-0x181f irq 16 at device 29.0 on pci0 usbus0: Intel 82801G (ICH7) USB controller USB-A on uhci0 uhci1: Intel 82801G (ICH7) USB controller USB-B port 0x1820-0x183f irq 17 at device 29.1 on pci0 usbus1: Intel 82801G (ICH7) USB controller USB-B on uhci1 uhci2: Intel 82801G (ICH7) USB controller USB-C port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2: Intel 82801G (ICH7) USB controller USB-C on uhci2 uhci3: Intel 82801G (ICH7) USB controller USB-D port 0x1860-0x187f irq 19 at device 29.3 on pci0 usbus3: Intel 82801G (ICH7) USB controller USB-D on uhci3 ehci0: Intel 82801GB/R (ICH7) USB 2.0 controller mem 0xee404000-0xee4043ff irq 19 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci21: ACPI PCI bus on pcib6 cbb0: TI1510 PCI-CardBus Bridge mem 0xe430-0xe4300fff irq 16 at device 0.0 on pci21 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb0: [FILTER] isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 atapci1: Intel ICH7M SATA150
Kernel page fault with the following non-sleepable locks held
Thoughts? Script started on Sat Nov 20 22:44:55 2010 FreeBSD 9.0-CURRENT #644 r215099M: Wed Nov 10 11:45:01 PST 2010 obr...@dragon:/usr/obj/4kib/i386/compile/DRAGON-WITNESS i386 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. [..] Starting default moused. Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex 4096 (UMA zone) r = 0 (0xc11b9c88) locked @ vm/uma_core.c:2010 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,c650c380,c650c178,4,0,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(7da,1,,c0a832fc,da8b5708,...) at 0xc061152a = kdb_backtrace+0x2a _witness_debugger(c08898ba,da8b571c,4,1,0,...) at 0xc0626256 = _witness_debugger+0x26 witness_warn(5,0,c08b2265,da8b5740,c6c95b40,...) at 0xc062776d = witness_warn+0x1fd trap(da8b57f4) at 0xc08214bd = trap+0x2ad calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc07d051e, esp = 0xda8b5834, ebp = 0xda8b5848 --- uma_dbg_alloc(c11b7300,0,c6ce9000,7da,c0877fc4,...) at 0xc07d051e = uma_dbg_alloc+0x4e uma_zalloc_arg(c11b7300,0,2,2,da8b5924,...) at 0xc07cfa4a = uma_zalloc_arg+0xea malloc(fa0,c08e1770,2,c7a1b000,da8b5924,...) at 0xc05c9fda = malloc+0x11a sc_vtb_init(da8b5924,1,50,19,0,...) at 0xc0805142 = sc_vtb_init+0x72 sc_alloc_scr_buffer(c7a1b000,1,1,c0625ffb,c689b520,...) at 0xc0568385 = sc_alloc_scr_buffer+0x65 alloc_scp(c664,c0286b0a,da8b598c,c05cd3eb,c79a0310,...) at 0xc05684b4 = alloc_scp+0x54 sctty_open(c666b200,4,c088c568,4e,c78912d8,...) at 0xc0568c3b = sctty_open+0xeb ttydev_open(c68c8700,1,2000,c6c95b40,da8b5afc,...) at 0xc0638954 = ttydev_open+0x254 devfs_open(da8b5afc,c08b7391,c650b340,c650f440,c69ba984,...) at 0xc0573342 = devfs_open+0x102 VOP_OPEN_APV(c08d7600,da8b5afc,100,da8b5a84,0,...) at 0xc083ff80 = VOP_OPEN_APV+0x100 vn_open_cred(da8b5b74,da8b5c28,d88,0,c6575e80,...) at 0xc06843c7 = vn_open_cred+0x4f7 vn_open(da8b5b74,da8b5c28,d88,c78912d8,da8b5b74,...) at 0xc068450b = vn_open+0x3b kern_openat(c6c95b40,ff9c,28405bc8,0,1,...) at 0xc0681088 = kern_openat+0x128 kern_open(c6c95b40,28405bc8,0,0,bfbfdf98,...) at 0xc06814d5 = kern_open+0x35 open(c6c95b40,da8b5cec,0,da8b5d28,7,...) at 0xc0681550 = open+0x30 syscallenter(c6c95b40,da8b5ce4,da8b5ce4,0,c087ed17,...) at 0xc061e8b3 = syscallenter+0x2c3 syscall(da8b5d28) at 0xc082112f = syscall+0x4f Xint0x80_syscall() at 0xc080b9d1 = Xint0x80_syscall+0x21 --- syscall (5, FreeBSD ELF32, open), eip = 0x281ed72b, esp = 0xbfbfdedc, ebp = 0xbfbfdf98 --- Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc51b9cd0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07d051e stack pointer = 0x28:0xda8b5834 frame pointer = 0x28:0xda8b5848 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 = 2073 (sh) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,d31206e,2c66000a,70797420,78302065,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(c08b0bbd,1,c086c89f,da8b56d0,1,...) at 0xc061152a = kdb_backtrace+0x2a panic(c086c89f,c08b226c,c6c95ce8,1,1,...) at 0xc05de537 = panic+0x117 trap_fatal(5,0,c08b2265,da8b5740,c6c95b40,...) at 0xc0820ee5 = trap_fatal+0x325 trap(da8b57f4) at 0xc08214ce = trap+0x2be calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc07d051e, esp = 0xda8b5834, ebp = 0xda8b5848 --- uma_dbg_alloc(c11b7300,0,c6ce9000,7da,c0877fc4,...) at 0xc07d051e = uma_dbg_alloc+0x4e uma_zalloc_arg(c11b7300,0,2,2,da8b5924,...) at 0xc07cfa4a = uma_zalloc_arg+0xea malloc(fa0,c08e1770,2,c7a1b000,da8b5924,...) at 0xc05c9fda = malloc+0x11a sc_vtb_init(da8b5924,1,50,19,0,...) at 0xc0805142 = sc_vtb_init+0x72 sc_alloc_scr_buffer(c7a1b000,1,1,c0625ffb,c689b520,...) at 0xc0568385 = sc_alloc_scr_buffer+0x65 alloc_scp(c664,c0286b0a,da8b598c,c05cd3eb,c79a0310,...) at 0xc05684b4 = alloc_scp+0x54 sctty_open(c666b200,4,c088c568,4e,c78912d8,...) at 0xc0568c3b = sctty_open+0xeb ttydev_open(c68c8700,1,2000,c6c95b40,da8b5afc,...) at 0xc0638954 = ttydev_open+0x254 devfs_open(da8b5afc,c08b7391,c650b340,c650f440,c69ba984,...) at 0xc0573342 = devfs_open+0x102 VOP_OPEN_APV(c08d7600,da8b5afc,100,da8b5a84,0,...) at 0xc083ff80 = VOP_OPEN_APV+0x100 vn_open_cred(da8b5b74,da8b5c28,d88,0,c6575e80,...) at 0xc06843c7 = vn_open_cred+0x4f7 vn_open(da8b5b74,da8b5c28,d88,c78912d8,da8b5b74,...) at 0xc068450b = vn_open+0x3b kern_openat(c6c95b40,ff9c,28405bc8,0,1,...) at 0xc0681088 = kern_openat+0x128 kern_open(c6c95b40,28405bc8,0,0,bfbfdf98,...) at 0xc06814d5 = kern_open+0x35 open(c6c95b40,da8b5cec,0,da8b5d28,7,...) at 0xc0681550 = open+0x30 syscallenter(c6c95b40,da8b5ce4,da8b5ce4,0,c087ed17,...) at 0xc061e8b3 = syscallenter+0x2c3
Re: Non-sleepable locks PANIC in sf(4)
On Thu, Nov 11, 2010 at 02:30:59PM -0800, Pyun YongHyeon wrote: On Wed, Nov 10, 2010 at 04:32:54PM -0800, David O'Brien wrote: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex sf0 (network driver) r = 0 (0xc722b584) locked @ /usr/obj/4kib/modules/sf/../../dev/sf/if_sf.c:1862 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,c6be8a80,4,c0a83ba0,c704164c,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(746,0,,c0a83b94,daaa2ac0,...) at 0xc061152a = kdb_backtrace+0x2a _witness_debugger(c08898ba,daaa2ad4,4,1,0,...) at 0xc0626256 = _witness_debugger+0x26 witness_warn(5,0,c08b2265,246,c70415a0,...) at 0xc062776d = witness_warn+0x1fd trap(daaa2bac) at 0xc08214bd = trap+0x2ad calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125 ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac [..] thoughts? Does sf(4) use shared interrupt? Yes. sf0: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8800-0x88ff mem 0xfa48-0xfa4f irq 26 at device 4.0 on pci3 sf1: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8400-0x84ff mem 0xfa38-0xfa3f irq 27 at device 5.0 on pci3 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port 0x9880-0x98bf mem 0xfa5c-0xfa5d irq 27 at device 8.0 on pci2 sf2: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8000-0x80ff mem 0xfa30-0xfa37 irq 24 at device 6.0 on pci3 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x001002 mem 0xfa5b-0xfa5b irq 24 at device 9.0 on pci2 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port 0x9c00-0x9c3f mem 0xfa5e-0xfa5f irq 24 at device 8.1 on pci2 sf3: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x7800-0x78ff mem 0xfa20-0xfa27 irq 25 at device 7.0 on pci3 -- -- David (obr...@freebsd.org) ___ 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
Non-sleepable locks PANIC in sf(4)
Script started on Wed Nov 10 15:56:31 2010 FreeBSD 9.0-CURRENT #644 r215099M: Wed Nov 10 11:45:01 PST 2010 obr...@dragon:/usr/obj/4kib/i386/compile/DRAGON-WITNESS i386 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. [..] Setting hostname: dragon.NUXI.org. sf0: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8800-0x88ff mem 0xfa48-0xfa4f irq 26 at device 4.0 on pci3 miibus1: MII bus on sf0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf0: Ethernet address: 00:00:d1:ed:81:95 sf1: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8400-0x84ff mem 0xfa38-0xfa3f irq 27 at device 5.0 on pci3 miibus2: MII bus on sf1 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf1: Ethernet address: 00:00:d1:ed:81:96 sf2: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8000-0x80ff mem 0xfa30-0xfa37 irq 24 at device 6.0 on pci3 miibus3: MII bus on sf2 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus3 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf2: Ethernet address: 00:00:d1:ed:81:97 sf3: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x7800-0x78ff mem 0xfa20-0xfa27 irq 25 at device 7.0 on pci3 miibus4: MII bus on sf3 ukphy3: Generic IEEE 802.3u media interface PHY 1 on miibus4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf3: Ethernet address: 00:00:d1:ed:81:98 Expensive timeout(9) function: 0xc061b270(0xc65965a0) 1.987919972 s [..] Starting Network: lo0 bge0 sf0 em0. [..] sf0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU ether 00:00:d1:ed:81:95 inet 74.95.12.85 netmask 0xfffc broadcast 74.95.12.87 inet6 fe80::200:d1ff:feed:8195%sf0 prefixlen 64 tentative scopeid 0x5 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active [..] Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex sf0 (network driver) r = 0 (0xc722b584) locked @ /usr/obj/4kib/modules/sf/../../dev/sf/if_sf.c:1862 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,c6be8a80,4,c0a83ba0,c704164c,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(746,0,,c0a83b94,daaa2ac0,...) at 0xc061152a = kdb_backtrace+0x2a _witness_debugger(c08898ba,daaa2ad4,4,1,0,...) at 0xc0626256 = _witness_debugger+0x26 witness_warn(5,0,c08b2265,246,c70415a0,...) at 0xc062776d = witness_warn+0x1fd trap(daaa2bac) at 0xc08214bd = trap+0x2ad calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125 ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac fork_exit(c05b5500,c65dd830,daaa2d28) at 0xc05b24e8 = fork_exit+0xb8 fork_trampoline() at 0xc080b9e4 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdaaa2d60, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x40c fault code = supervisor read, page not present instruction pointer = 0x20:0xc08077c4 stack pointer = 0x28:0xdaaa2bec frame pointer = 0x28:0xdaaa2c00 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 = 12 (irq26: sf0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,d31206e,2c66000a,70797420,78302065,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(c08b0bbd,0,c086c89f,daaa2a88,0,...) at 0xc061152a = kdb_backtrace+0x2a panic(c086c89f,c08b226c,c7041748,1,1,...) at 0xc05de537 = panic+0x117 trap_fatal(5,0,c08b2265,246,c70415a0,...) at 0xc0820ee5 = trap_fatal+0x325 trap(daaa2bac) at 0xc08214ce = trap+0x2be calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125
Re: groff build failure
On Mon, Nov 08, 2010 at 05:11:19PM -0800, Garrett Cooper wrote: Tinderbox agrees :(... TB --- 2010-11-08 23:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-08 23:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-11-08 23:15:00 - cleaning the object tree TB --- 2010-11-08 23:15:10 - cvsupping the source tree TB --- 2010-11-08 23:15:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile Why is the tinderbox still using CVS source trees? To some degree the tinderbox agreeing is meaningless as the report from it does not give the GRN[*] the sources are based on. [*] specifically the output of: svn info | grep 'Last Changed Rev:' -- -- David (obr...@freebsd.org) ___ 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: groff build failure
On Tue, Nov 09, 2010 at 08:28:27AM +0800, Randy Bush wrote: On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote: === gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Can you update to r214990 and confirm things are OK for you? [..] Stop in /usr/src/usr.bin/yacc. *** Error code 1 Hi Randy, You may have mentioned this, so sorry if I missed it. Can you verify this is a 64-bit platform? thanks, -- -- David (obr...@freebsd.org) ___ 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: groff build failure
On Tue, Nov 09, 2010 at 10:52:23AM +0800, Randy Bush wrote: Can you verify this is a 64-bit platform? i can verify that this is am64 Ok, that explains why I could not reproduce this under i386. Please try r215027. -- -- David (obr...@freebsd.org) ___ 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: Files under src/ not used for building world
On Fri, Nov 05, 2010 at 09:42:27PM -0700, Garrett Cooper wrote: On Fri, Nov 5, 2010 at 1:25 PM, Ulrich Sp?rlein u...@spoerlein.net wrote: Hey folks, not sure why, but I had a stab at looking which files were actually read during building world. [..] usr.bin/cpio/test/* ? ? # move to tools/regression? Seems like a legitimate request. Not necessary. I prefer to have the tests under the thing being tested. It makes it much easier to test the util before committing. That said, the tests should be hooked up and referred to in tools/regression/usr.bin/ -- -- David (obr...@freebsd.org) ___ 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: groff build failure
On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote: very current amd64 === gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' Sorry, about this. I will fix my commit. -- -- David (obr...@freebsd.org) ___ 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: groff build failure
On Mon, Nov 08, 2010 at 03:14:02PM +0800, Randy Bush wrote: === gnu/usr.bin/groff/src/preproc/eqn (all) c++ -O2 -pipe -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -fstack-protector -fno-rtti -fno-exceptions -c eqn.cpp y.tab.c: In function 'int yygrowstack()': y.tab.c:703: error: invalid conversion from 'void*' to 'short int*' y.tab.c:709: error: invalid conversion from 'void*' to 'YYSTYPE*' *** Error code 1 Randy, Can you update to r214990 and confirm things are OK for you? thanks and sorry, -- -- David (obr...@freebsd.org) ___ 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: [PATCH] fix shell bug in ${var%pattern} expansion
On Wed, Oct 13, 2010 at 11:42:48PM +0200, Jilles Tjoelker wrote:
Style bug:
+growstrstackblock(int n) {
The opening brace should be on its own line.
Indeed. I'm surprised I did that. Thank you for catching it.
Your test is too fragile: it often fails to detect the bug. Calling like
sh -c '. expansion/trim4.0'
gives the correct output even with a buggy sh. I propose something like
this, or perhaps with an additional string comparison:
I also like this test better.
Thank you for the review.
--
-- David (obr...@freebsd.org)
___
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
[PATCH] fix shell bug in ${var%pattern} expansion
At $WORK we hit a bug where ${var%/*} was not producing the correct
expansion. There are two patches to fix this. I prefer the first
as I feel it is cleaner from an API perspective. I've also added
a regression testcase that shows the problem.
Thoughts?
--
-- David (obr...@freebsd.org)
Commit log:
Do not assume in growstackstr() that a precious character will be
immediately written into the stack after the call. Instead let the
caller manage the space left.
Currently growstackstr()'s assumption causes problems with
STACKSTRNUL() where we want to be able to turn a stack into a C
string, and later pretend the NUL is not there.
This fixes a bug in STACKSTRNUL() (that grew the stack) where:
1. STADJUST() called after a STACKSTRNUL() results in an improper
adjust. This can be seen in ${var%pattern} and ${var%%pattern}
evaluation.
2. Memory leak in STPUTC() called after a STACKSTRNUL().
--%--%--%--%--%--
Index: bin/sh/memalloc.h
===
--- bin/sh/memalloc.h (revision 213714)
+++ bin/sh/memalloc.h (working copy)
@@ -67,9 +67,16 @@ void ungrabstackstr(char *, char *);
#define stackblock() stacknxt
#define stackblocksize() stacknleft
#define STARTSTACKSTR(p) p = stackblock(), sstrnleft = stackblocksize()
-#define STPUTC(c, p) (--sstrnleft = 0? (*p++ = (c)) : (p = growstackstr(),
*p++ = (c)))
+#define STPUTC(c, p) (--sstrnleft = 0? (*p++ = (c)) : (p = growstackstr(),
--sstrnleft, *p++ = (c)))
#define CHECKSTRSPACE(n, p){ if (sstrnleft n) p = makestrspace(); }
#define USTPUTC(c, p) (--sstrnleft, *p++ = (c))
+/*
+ * STACKSTRNUL's use is where we want to be able to turn a stack
+ * (non-sentinel, character counting string) into a C string,
+ * and later pretend the NUL is not there.
+ * Note: Because of STACKSTRNUL's semantics, STACKSTRNUL cannot be used
+ * on a stack that will grabstackstr()ed.
+ */
#define STACKSTRNUL(p) (sstrnleft == 0? (p = growstackstr(), *p = '\0') : (*p
= '\0'))
#define STUNPUTC(p)(++sstrnleft, --p)
#define STTOPC(p) p[-1]
Index: bin/sh/histedit.c
===
--- bin/sh/histedit.c (revision 213714)
+++ bin/sh/histedit.c (working copy)
@@ -418,7 +418,7 @@ fc_replace(const char *s, char *p, char
} else
STPUTC(*s++, dest);
}
- STACKSTRNUL(dest);
+ STPUTC('\0', dest);
dest = grabstackstr(dest);
return (dest);
Index: bin/sh/memalloc.c
===
--- bin/sh/memalloc.c (revision 213714)
+++ bin/sh/memalloc.c (working copy)
@@ -295,6 +295,12 @@ grabstackblock(int len)
* is space for at least one character.
*/
+static char *
+growstrstackblock(int n) {
+ growstackblock();
+ sstrnleft = stackblocksize() - n;
+ return stackblock() + n;
+}
char *
growstackstr(void)
@@ -304,12 +310,10 @@ growstackstr(void)
len = stackblocksize();
if (herefd = 0 len = 1024) {
xwrite(herefd, stackblock(), len);
- sstrnleft = len - 1;
+ sstrnleft = len;
return stackblock();
}
- growstackblock();
- sstrnleft = stackblocksize() - len - 1;
- return stackblock() + len;
+ return growstrstackblock(len);
}
@@ -323,9 +327,7 @@ makestrspace(void)
int len;
len = stackblocksize() - sstrnleft;
- growstackblock();
- sstrnleft = stackblocksize() - len;
- return stackblock() + len;
+ return growstrstackblock(len);
}
--%--%--%--%--%--
ALTERNATE PATCH:
Index: bin/sh-1/memalloc.h
===
--- bin/sh-1/memalloc.h (revision 213696)
+++ bin/sh-1/memalloc.h (working copy)
@@ -70,7 +70,17 @@ void ungrabstackstr(char *, char *);
#define STPUTC(c, p) (--sstrnleft = 0? (*p++ = (c)) : (p = growstackstr(),
*p++ = (c)))
#define CHECKSTRSPACE(n, p){ if (sstrnleft n) p = makestrspace(); }
#define USTPUTC(c, p) (--sstrnleft, *p++ = (c))
-#define STACKSTRNUL(p) (sstrnleft == 0? (p = growstackstr(), *p = '\0') : (*p
= '\0'))
+/*
+ * growstackstr() has the assumption that a precious character will be
+ * immediately written into it, so it sets up 'sstrnleft' appropriately.
+ * But that is not the case for STACKSTRNUL, where we want to be able to
+ * turn a stack (non-sentinel, character counting string) into a C string,
+ * and later pretend the NUL is not there (without adjusting 'sstrnleft').
+ * Note: because of STACKSTRNUL's semantics, STACKSTRNUL cannot be used on
+ * a stack that will grabstackstr()ed.
+ */
+#define STACKSTRNUL(p) (sstrnleft == 0? (p = growstackstr(), *p = '\0',
++sstrnleft) : (*p = '\0'))
+//#define STACKSTRNUL(p)
trying /sbin/init = panic: bad pte
This happens on AMD64 for me, r212166 (2010-09-02 15:37:13 -0700) kernel sources. But, an i386 kernel of r212166 sources boots fine on the same hardware. Root mount waiting for: usbus6 usbus2 uhub2: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ad8s1a ct_to_ts([2010-09-03 23:27:18]) = 1283556438.0 start_init: trying /sbin/init panic: bad pte cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x802050aa = db_trace_self_wrapper+0x2a panic() at 0x805da702 = panic+0x182 pmap_remove_pages() at 0x808cdd6f = pmap_remove_pages+0x67f vmspace_exit() at 0x80840b69 = vmspace_exit+0x99 exit1() at 0x805aee0e = exit1+0x35e sys_exit() at 0x805afb1e = sys_exit+0xe syscallenter() at 0x8061b9bb = syscallel() at 0x808d59ac = syscall+0x4c Xfast_syscall() at 0xscall+0xe2 --- syscall (1, FreeBSD ELF64, sys_exit), rip = 0x800911d9c, rsp = 0x7f- Uptime: 8s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort -- -- David (obr...@freebsd.org) ___ 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: trying /sbin/init = panic: bad pte
On Fri, Sep 03, 2010 at 11:34:10PM -0700, David O'Brien (@FreeBSD) wrote: This happens on AMD64 for me, r212166 (2010-09-02 15:37:13 -0700) kernel sources. Sorry for the false alarm - this was a local environment problem. -- David ___ 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: SUJ deadlock
On Wed, May 05, 2010 at 12:54:07PM -1000, Jeff Roberson wrote:
On Mon, 3 May 2010, Fabien Thomas wrote:
I'm with r207548 now and since some days i've system deadlock.
It seems related to SUJ with process waiting on suspfs or ppwait.
I've also seen it stalled in suspfs, but this information is way better
than what I was able to garner. I was only able to tell via ctrl-t on
a stalled 'ls' process in a terminal before hard booting.
[..]
Can anyone who has experienced this hang test this patch:
Thanks,
Jeff
Index: ffs_softdep.c
===
--- ffs_softdep.c (revision 207480)
+++ ffs_softdep.c (working copy)
@@ -9301,7 +9301,7 @@
hadchanges = 1;
}
/* Leave this inodeblock dirty until it's in the list. */
- if ((inodedep-id_state (UNLINKED | DEPCOMPLETE)) == UNLINKED)
+ if ((inodedep-id_state (UNLINKED | UNLINKONLIST)) == UNLINKED)
Hi Jeff,
I didn't seem to experience this problem back in May, but I'm now
experiencing it on a regular basis.
I seem to trigger it almost every other or 3rd day during the daily run.
I wind up with cvsup or svnsync stalled and any 'ls' of my sources
partition waiting on suspfs.
(note, I am also running diskcheckd from ports.)
My kernel sources are at:
Last Changed Author: davidxu
Last Changed Rev: 211534
Last Changed Date: 2010-08-20 16:51:34 -0700 (Fri, 20 Aug 2010)
I have also experienced it back to at least:
Last Changed Author: yongari
Last Changed Rev: 210152
Last Changed Date: 2010-07-15 16:34:58 -0700 (Thu, 15 Jul 2010)
Weird thing is - I can still access this partition across NFS without
problems.
dragon$ cd /src/fbsd
Filesystem SizeUsed Avail Capacity Mounted on
/dev/da31s1f271G119G130G48%/src
dragon$ ls
load: 0.12 cmd: ls 77901 [suspfs] 2.26r 0.00u 0.00s 0% 1212k
quynh$ cd /src/fbsd
quynh$ df .
Filesystem SizeUsed Avail Capacity Mounted on
dragon:/src271G119G130G48%/src
quynh$ ls
.svn/ lib/
COPYRIGHT libexec/
..snip..
Processes also have a tendency to complete quite slowly at times - waiting
in vlruwk.
When I reboot, usually / and /src (but not 3 other partitions) give a
Bad cg number {negative number} error from fsck; so a full fsck is run.
This results in what seems tens of thousands iterations of:
UNREF FILE I=[..snip..]
RECONNECT? yes
SORRY no space in lost+found directory
unexpected soft update inconsistency
CLEAR? yes
thoughts?
--
-- David (obr...@freebsd.org)
___
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
[PATCH] rename COMPAT_FREEBSD32
On Mon, Mar 15, 2010 at 09:00:18AM -0700, Julian Elischer wrote: I certainly agree.. can it be changed please? I've waited a while to see what other opinions would be expressed on this topic. I believe there is sufficient support to rename COMPAT_FREEBSD32 to something else based on responses in the mailing lists. I am sorry if some may wish to label this a bikeshead. But we seem to have many folks disliking COMPAT_FREEBSD32. Based on responses to the topic of COMPAT_FREEBSD32, the following were the suggestions offered: COMPAT_ARCH32, COMPAT_ARCH_32BIT, COMPAT_32BIT_ARCH, COMPAT_32BIT, COMPAT_FREEBSD32BIT I went with the first as it seemed the most direct to me, but I find all but the last are suitable as well. (The last is probably too close to COMPAT_FREEBSDn given we do have other suggestions.) This patch was produced by checking out a fresh tree and running this command from the top level: wcfind sys -type f | xargs fgrep -l COMPAT_FREEBSD32 | xargs \ sed -i '' \ -e 's/COMPAT_FREEBSD32/COMPAT_ARCH32/g' \ -e 's/compat_freebsd32/compat_arch32/g' svn revert -R sys/compat/freebsd32 Thoughts? -- -- David (obr...@freebsd.org) Index: conf/options.amd64 === --- conf/options.amd64 (revision 205451) +++ conf/options.amd64 (working copy) @@ -11,7 +11,7 @@ MP_WATCHDOG # Options for emulators. These should only be used at config time, so # they are handled like options for static filesystems # (see src/sys/conf/options), except for broken debugging options. -COMPAT_FREEBSD32 opt_compat.h +COMPAT_ARCH32 opt_compat.h #IBCS2 opt_dontuse.h #COMPAT_LINUX opt_dontuse.h COMPAT_LINUX32 opt_compat.h Index: conf/options.ia64 === --- conf/options.ia64 (revision 205451) +++ conf/options.ia64 (working copy) @@ -9,7 +9,7 @@ LOG2_PAGE_SIZE opt_global.h UWX_TRACE_ENABLE opt_global.h -COMPAT_FREEBSD32 opt_compat.h +COMPAT_ARCH32 opt_compat.h EXCEPTION_TRACING opt_xtrace.h Index: conf/files.ia64 === --- conf/files.ia64 (revision 205451) +++ conf/files.ia64 (working copy) @@ -28,11 +28,11 @@ ukbdmap.h optional ukbd_dflt_keymap\ no-obj no-implicit-rule before-depend \ clean ukbdmap.h # -compat/freebsd32/freebsd32_ioctl.c optionalcompat_freebsd32 -compat/freebsd32/freebsd32_misc.c optionalcompat_freebsd32 -compat/freebsd32/freebsd32_syscalls.c optionalcompat_freebsd32 -compat/freebsd32/freebsd32_sysent.coptionalcompat_freebsd32 -compat/ia32/ia32_sysvec.c optionalcompat_freebsd32 +compat/freebsd32/freebsd32_ioctl.c optionalcompat_arch32 +compat/freebsd32/freebsd32_misc.c optionalcompat_arch32 +compat/freebsd32/freebsd32_syscalls.c optionalcompat_arch32 +compat/freebsd32/freebsd32_sysent.coptionalcompat_arch32 +compat/ia32/ia32_sysvec.c optionalcompat_arch32 contrib/ia64/libuwx/src/uwx_bstream.c standard contrib/ia64/libuwx/src/uwx_context.c standard contrib/ia64/libuwx/src/uwx_env.c standard @@ -68,10 +68,10 @@ ia64/acpica/madt.c optionalacpi ia64/disasm/disasm_decode.cstandard ia64/disasm/disasm_extract.c standard ia64/disasm/disasm_format.cstandard -ia64/ia32/ia32_misc.c optionalcompat_freebsd32 -ia64/ia32/ia32_reg.c optionalcompat_freebsd32 -ia64/ia32/ia32_signal.coptionalcompat_freebsd32 -ia64/ia32/ia32_trap.c optionalcompat_freebsd32 +ia64/ia32/ia32_misc.c optionalcompat_arch32 +ia64/ia32/ia32_reg.c optionalcompat_arch32 +ia64/ia32/ia32_signal.coptionalcompat_arch32 +ia64/ia32/ia32_trap.c optionalcompat_arch32 ia64/ia64/autoconf.c standard ia64/ia64/bus_machdep.cstandard ia64/ia64/busdma_machdep.c standard @@ -117,7 +117,7 @@ ia64/isa/isa_dma.c optionalisa ia64/pci/pci_cfgreg.c optionalpci isa/syscons_isa.c optionalsc isa/vga_isa.c optionalvga -kern/imgact_elf32.coptionalcompat_freebsd32 +kern/imgact_elf32.coptionalcompat_arch32 libkern/bcmp.c standard libkern/ffsl.c standard libkern/fls.c standard Index: conf/files.amd64 === --- conf/files.amd64(revision 205451) +++ conf/files.amd64(working copy) @@ -227,20 +227,20 @@ kern/link_elf_obj.c standard # # IA32
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote: : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote: So the issue isn't as cut and dried as you might think. There's multiple different conventions used here in addition to your simple example. I guess we'd have to take a poll to find out. Seems pretty cut and dried to me. COMPAT_FREEBSDn has an established context that does not match this new usage. That is - same bit'ness, compatibility with an older FreeBSD API for the same architecture. All the other COMPAT_* are for foreign ABI compatibility. COMPAT_LINUX32 possibly should have been COMPAT_LINUX_X86_64. (or is it MI and is usable as-is for PowerPC and MIPS? I haven't looked that deeply at the code.) Users of 64-bit systems that will be using COMPAT_FREEBSD32 are likely to find this a natural extension of the COMPAT_LINUX32 that they are likely already using. You know I am such a user - and I don't think it is so clear given the existence (and purpose) of COMPAT_FREEBSDn for the past many years. While it does match the directory name of 'sys/compat/freebsd32', it may be that freebsd32 was a poor choice for that directory's name. But given the recent discussion in another thread - I won't even suggest we rename it. -- -- David (obr...@freebsd.org) ___ 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: [PATCH] newvers.sh
On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote: In message: 20100312171206.ga31...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : * Simplify SRCDIR calculation by directly finding the kernel sources : based directly on one of them. : Reviewed by: dhw : This change does not increase the kernel build time. It also continues : to restrict the revision to just the kernel sources, and not the whole : tree. : Timing tests by: dhw patch omitted I have a better simplification, I think, that works for me for each of the tests that I've done (both traditional and buildkernel builds). I also have other simplifications. But want to do this in stages, least there be some corner case or misunderstanding by someone. Can you confirm this works for you and also comment on the change itself? It is a bigger change, but results in a simpler (I think) newvers.sh. Comments? I would prefer to do this in stages so things aren't misunderstood. This patch is one of the key parts that shows I am not making the 'svnversion' run take longer, and that it does not cover more of the tree than before. -- -- David (obr...@freebsd.org) ___ 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: [PATCH] newvers.sh
On Mon, Mar 15, 2010 at 08:44:26AM -0600, M. Warner Losh wrote: In message: 20100315142806.ga5...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote: : In message: 20100312171206.ga31...@dragon.nuxi.org : David O'Brien obr...@freebsd.org writes: : : * Simplify SRCDIR calculation by directly finding the kernel sources : : based directly on one of them. : : Reviewed by: dhw : : This change does not increase the kernel build time. It also continues : : to restrict the revision to just the kernel sources, and not the whole : : tree. : : Timing tests by: dhw : : patch omitted : : I have a better simplification, I think, that works for me for each of : the tests that I've done (both traditional and buildkernel builds). : : I also have other simplifications. But want to do this in stages, : least there be some corner case or misunderstanding by someone. Normally this is a sensible process. However, my patches change how we guess where sys is, and as such, I think we should go directly there and work out the corner cases and such there. Well that's what I was trying to do with the patch I sent you in Message-ID: 20100308010125.ga6...@dragon.nuxi.org on 7-March-2010. There you didn't care for that approach and would not give details as to the claims you made. I will reply in another email the issues with your patch. : I would prefer to do this in stages so things aren't misunderstood. : This patch is one of the key parts that shows I am not making the : 'svnversion' run take longer, and that it does not cover more of : the tree than before. That's exactly what my patch does by passing in SYSDIR directly. Why guess and then replace it with a different guess. Guess??? 'newvers.sh' is not going to be within the kernel sources tree?? Are you allowing for the person that did a 'mv sys/conf/newvers.sh' to elsewhere? Considering you have sh $S/conf/newvers.sh, I don't see where you are. Is $0 confusing you? -- -- David (obr...@freebsd.org) ___ 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: [PATCH] newvers.sh
On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote:
The Makefile already knows where the kernel src is located. Let's use
that knowledge to make things a little simpler. This also uses the
Makefile variable SYSDIR. It should also work with non-standard sys
directories.
..
Index: conf/kern.post.mk
vers.c: $S/conf/newvers.sh $S/sys/param.h ${SYSTEM_DEP}
- MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}
+ MAKE=${MAKE} SYSDIR=$S sh $S/conf/newvers.sh ${KERN_IDENT}
I'd rather not introduce yet more special things that have to be done
before invoking newvers.sh. (MAKE=${MAKE} sh is not an issue as the
script works if MAKE is not passed in given it has ${MAKE:-make}).
The script can be more self contained than this, and I think that is
technically better.
Index: conf/newvers.sh
===
--- conf/newvers.sh (revision 204938)
+++ conf/newvers.sh (working copy)
@@ -44,7 +44,7 @@
${PARAMFILE})
else
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
- $(dirname $0)/../sys/param.h)
+ ${SYSDIR}/sys/param.h)
I don't think we should depend on having SYSDIR defined before invoking
newvers.sh. Its worse than requiring that as a parameter. We don't set
KERN_IDENT=$KERN_IDENT before invoking newvers.sh.
Either
MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT} $S
or
MAKE=${MAKE} SYSDIR=$S KERN_IDENT=$KERN_IDENT sh $S/conf/newvers.sh
for regularity. But I really feel we can trust 'newvers.sh' to be within
the kernel sources directory - thus $(dirname $0)/.. is a
self-contained method to determining what the kernel directory is.
No guessing. This can be optimized to ${0%/*}/...
-v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
+v=`cat version` u=${USER:-root} h=${HOSTNAME:-`hostname`} t=`date`
Unfortunately, I don't believe you actually read the entire newvers.sh script.
(this is likely why you misread my patch in Message-ID:
20100308010125.ga6...@dragon.nuxi.org) Did you get the proper output
in your testing? From what I see, It causes a problem with the ${d}
usage in this part of newvers.sh:
#define VERSTR ${VERSION} #${v}${svn}${git}: ${t}\\n$...@${h}:${d}\\n
Thus when building with make buildkernel, your patch produces vers.c as:
#define VERSTR FreeBSD 9.0-CURRENT #0 r204912M: Mon Mar 15 12:46:05 PDT
2010\nro...@dragon.nuxi.org:\n
Instead of:
#define VERSTR FreeBSD 9.0-CURRENT #0 r204912M: Mon Mar 15 12:57:01 PDT
2010\nro...@dragon.nuxi.org:/usr/obj/MM/test/sys/GENERIC\n
-case $d in
-*/sys/*)
..
+for dir in /bin /usr/bin /usr/local/bin; do
+ if [ -d ${SYSDIR}/.svn -a -x ${dir}/svnversion ] ; then
+ svnversion=${dir}/svnversion
..
- for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d ${SRCDIR}/sys/.svn -a -x ${dir}/svnversion ] ; then
Are you implicitly depending on there not being a '.svn/' in the root
directory? The invocation of 'newvers.sh' elsewhere in the tree will not
have 'SYSDIR' (of your patch) set, so the test will be (last iteration):
if [ -d /.svn -a -x $/usr/local/bin/svnversion ] ; then
I'd rather not limit the user to not having '/.svn' that is used to
track configuration files, etc...
This patch is the end version I was working to (thru a series of
changes):
* Simplify SRCDIR calculation by directly finding the kernel sources
based directly on one of them.
* Rename SRCDIR to KERN_TOPDIR to be more clear which sources these are,
and at what level
* git isn't in the base system and being GPL'ed, likely never will.
* Revisit r196435 - rather than guess if 'newvers.sh' is being
invoked as part of the kernel build or not based on a path (proven
to be fragile), key off of having a KERN_IDENT.
Index: newvers.sh
===
--- newvers.sh (revision 204939)
+++ newvers.sh (working copy)
@@ -39,12 +39,13 @@ fi
RELEASE=${REVISION}-${BRANCH}
VERSION=${TYPE} ${RELEASE}
+KERN_TOPDIR=${0%/*}/..
if [ X${PARAMFILE} != X ]; then
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
${PARAMFILE})
else
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
- $(dirname $0)/../sys/param.h)
+ ${KERN_TOPDIR}/sys/param.h)
fi
@@ -87,27 +88,22 @@ touch version
v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
i=`${MAKE:-make} -V KERN_IDENT`
-case $d in
-*/sys/*)
- SRCDIR=${d##*obj}
- if [ -n $MACHINE ]; then
- SRCDIR=${SRCDIR##/$MACHINE}
- fi
- SRCDIR=${SRCDIR%%/sys/*}
-
+case $i in
+)
+ ;;
+*)
for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d ${SRCDIR}/sys/.svn -a -x ${dir}/svnversion ] ; then
+ if [ -d ${KERN_TOPDIR}/.svn -a -x ${dir}/svnversion ] ; then
PANIC w/h...@r204957: fork-...-uma_dbg_alloc
Details at http://trang.nuxi.org:8080/panics/DSC_0070.JPG Kernel sources at r203083 are stable for me. Unfortunately, I cannot get a dump for this. -- -- David (obr...@freebsd.org) ___ 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
PANIC w/h...@r204957: link_elf_lookup_symbol
Details at http://trang.nuxi.org:8080/panics/DSC_0010.JPG Kernel sources at r203083 are stable for me. Unfortunately, I cannot get a dump for this. -- -- David (obr...@freebsd.org) ___ 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
[PATCH] newvers.sh
* Simplify SRCDIR calculation by directly finding the kernel sources
based directly on one of them.
Reviewed by: dhw
This change does not increase the kernel build time. It also continues
to restrict the revision to just the kernel sources, and not the whole
tree.
Timing tests by: dhw
Index: newvers.sh
===
--- newvers.sh (revision 204939)
+++ newvers.sh (working copy)
@@ -89,25 +89,21 @@ i=`${MAKE:-make} -V KERN_IDENT`
case $d in
*/sys/*)
- SRCDIR=${d##*obj}
- if [ -n $MACHINE ]; then
- SRCDIR=${SRCDIR##/$MACHINE}
- fi
- SRCDIR=${SRCDIR%%/sys/*}
+ SRCDIR=$(dirname $0)/..
for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d ${SRCDIR}/sys/.svn -a -x ${dir}/svnversion ] ; then
+ if [ -d ${SRCDIR}/.svn -a -x ${dir}/svnversion ] ; then
svnversion=${dir}/svnversion
break
fi
- if [ -d ${SRCDIR}/.git -a -x ${dir}/git ] ; then
- git_cmd=${dir}/git --git-dir=${SRCDIR}/.git
+ if [ -d ${SRCDIR}/../.git -a -x ${dir}/git ] ; then
+ git_cmd=${dir}/git --git-dir=${SRCDIR}/../.git
break
fi
done
if [ -n $svnversion ] ; then
- svn= r`cd ${SRCDIR}/sys $svnversion`
+ svn= r`cd ${SRCDIR} $svnversion`
fi
if [ -n $git_cmd ] ; then
git=`$git_cmd rev-parse --verify --short HEAD 2/dev/null`
@@ -125,7 +121,7 @@ case $d in
git= ${git}
fi
fi
- if $git_cmd --work-tree=${SRCDIR} diff-index \
+ if $git_cmd --work-tree=${SRCDIR}/.. diff-index \
--name-only HEAD | read dummy; then
git=${git}-dirty
fi
--
-- David (obr...@freebsd.org)
___
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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote: In message: 7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel swhet...@gmail.com wrote: : On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik : mike.jaku...@intertainservices.com wrote: : On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: : As a result of importing 32-bit compatibility support for non-x86 : 64-bit platforms, the kernel options COMPAT_IA32 has been renamed : COMPAT_FREEBSD32 in revision 205014, so all kernel configurations : including this option must be modified accordingly. : : That sounds a bit confusing, compatibility with FreeBSD 3.2? : : I agree that the name COMPAT_FREEBSD32 is confusing, does it mean : compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. : : A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. : : Agreed. Is it possible to change the name again because it really : hasn't gotten much traction yet? What does the name matter, really? Yes names matter. Otherwise we would have made it DEF8931. #define names are chosen to be self-documenting. $ grep COMPAT_FREEBSD conf/* conf/NOTES:# Note that as a general rule, COMPAT_FREEBSDn depends on conf/NOTES:# COMPAT_FREEBSDn+1, COMPAT_FREEBSDn+2, etc. conf/NOTES:options COMPAT_FREEBSD4 conf/NOTES:options COMPAT_FREEBSD5 conf/NOTES:options COMPAT_FREEBSD6 conf/NOTES:options COMPAT_FREEBSD7 conf/options:COMPAT_FREEBSD4opt_compat.h conf/options:COMPAT_FREEBSD5opt_compat.h conf/options:COMPAT_FREEBSD6opt_compat.h conf/options:COMPAT_FREEBSD7opt_compat.h COMPAT_FREEBSD32 is not the same as any of the other well established COMPAT_FREEBSD macros. So I do see where this could lead to confusion to users. -- -- David (obr...@freebsd.org) ___ 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Thu, Mar 11, 2010 at 08:54:32PM -0700, Scott Long wrote: On Mar 11, 2010, at 6:14 PM, Scot Hetzel wrote: On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik mike.jaku...@intertainservices.com wrote: On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: As a result of importing 32-bit compatibility support for non-x86 64-bit platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 in revision 205014, so all kernel configurations including this option must be modified accordingly. That sounds a bit confusing, compatibility with FreeBSD 3.2? I agree that the name COMPAT_FREEBSD32 is confusing, does it mean compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. Seriously, this is being debated? FreeBSD 3.2? Is this a joke? I caught the humor in the first couple of replies, but you sound serious. Wow. Yes it is. Where was it discussed first? I do not see anything in my freebsd-arch or freebsd-current archive; or any other FreeBSD list. If there wasn't already a well established meaning to COMPAT_FREEBSD (grep for it in /usr/src/sys/conf/), there probably wouldn't be any real complaints. -- -- David (obr...@freebsd.org) ___ 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: propose: all arch move into a separate dir
On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
In message: 20100307054423.ge70...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
: On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
: In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org,
Robert
: Watso n writes:
: Doing that kind of rearrangement [...] would be a nightmare for anyone
: with large [...] patches, so I'd say we could pretty much rule that out
: outright.
:
: I would say that we should do it occasionally, to encourage these
: FreeBSD users to contribute as many of their local changes back to
: the project, as possible :-)
:
: Absolutely -- and rearranging a tree is a good way to invalidate
: all those patches as well :-).
:
: No, not it isn't. Provide a script to convert path's in the diff.
: This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
You are joking, right? This would be a nightmare for people that
integrate early and often.
No I am not joking. I was responding to the point that a large patch
(that is a the output of running '$SCM diff') can be easily modified to
match a new directory layout. Thus patches in GNATS aren't useless.
I'm not sure what operation you are specifically speaking to . But, if
FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
do:
cd sys
mkdir arch
svn add arch
svn mv {list of dirs} arch
svn ci
and be done with it. Branches would merge that change - get a trivial
tree conflict, resolve it - and move on with life.
I would expect folks working in project branches to do the same.
For merging changes from FreeBSD HEAD to FreeBSD stable - that is
trivial:
cd sys
svn merge -c $GRN ^/head/sys/arch/amd64 amd64
svn ci
Subversion makes this a lot easier than CVS did.
--
-- David (obr...@freebsd.org)
___
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: propose: all arch move into a separate dir
On Sun, Mar 07, 2010 at 08:51:22PM +, Robert Watson wrote: On Sat, 6 Mar 2010, David O'Brien wrote: No, not it isn't. Provide a script to convert path's in the diff. This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. It was done by creating a copy of the CVS repo and moved files around. Old releases stayed in the old repo, and new releases done from the new repo. 'diff | fixpatch | patch -p0' were used to move code between sandboxes. Indeed, this is precisely the problem: rearranging the tree upstream means that you most likely can't use the revision control system to manage your local difference set downstream. It does not mean downstream users cannot their revision control system manage changes - it only means those using CVS cannot easily. Lets say I'm a 3rd party based on FreeBSD. One vendor imports the FreeBSD sources for what ever version they are based on. When new FreeBSD version comes out with 'sys/arch/' that would be reflected in the SCM on that vendor branch. The SCM would track that directories moved. Now when the new FreeBSD import was merged into the working sources branch, the SCM would track that the directory moves would need to happen there also. Done deal. Instead, you have to manually extract your local changes, rework them to match arbitrary upstream rearrangement, and re-apply them as a single changeset creating a discontinuity in your revision history. No, you could use the SCM to do it. All modern SCM's that I'm familiar with track directory moves. Resulting in a situation where there is not lossage with log, blame, etc.. I am speaking as one of the downstream users of FreeBSD - $WORK could consume such a move - so please don't hold them up as a reason to not consider moving the CPU directories under arch/. I know of two 3rd parties with product based on FreeBSD - one uses subversion, and the other uses Perforce. Granted I don't know what the others use - but we could query them. However, other downstream users (including our own development branches in Subversion, P4, etc) reasonably expect to be able to use contemporary tools to manage the merge on a more frequent basis. Yes - have you had a bad experience with merging such changes from HEAD to a project branch in our own subversion tree? My experience is, given a HEADS UP to a directory move, it is not hard to handle merges in subversion. -- -- David (obr...@freebsd.org) ___ 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: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 11:16:41AM +, Doug Rabson wrote: I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. It always ends up the same way - a re-org might make the source tree marginally prettier but the consequences for long-term maintenance and supporting downstream contributors outweigh any possible benefit. Having the same conversation every two years with the same outcome gets annoying. To be fair - two years ago we were not using a source control system that understood moves within the repository. To do this two years ago, we had to make a choice between three poor paths of how to do CVS moves - repo copy (breaks date-based checkout), delete-add pairs (looses history), or copy the entire repository move files and use new repo for new releases and existing repo for old releases. Juniper now also uses Subversion - so with sufficient warning and planning, Juniper could consume a move of the CPU directories moving under arch/. Juniper also had a CVS based tree reorg 1.5 years go - taking the third path above. Please don't use Juniper as an reason to not move forward with this change. -- -- David (obr...@freebsd.org) ___ 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: propose: all arch move into a separate dir
On Sat, Mar 06, 2010 at 01:28:24AM -0800, Garrett Cooper wrote: FWIW, NetBSD's charter has been to run their OS on a number of architectures, not just a primary set of architectures; OpenBSD's charter differs -- if we all were NetBSD or OpenBSD, then we'd all be using the same thing. But we aren't and that's probably not going to change anytime soon [at least not without community backing and a We aren't? At this point it seems any architecture an be brought into FreeBSD without regard to critical mass or ability to support it to the standards of our past. I do believe FreeBSD's character does not include chasing every embedded platform where there is energy and talent for the initial port. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ 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: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 12:01:30PM +0100, Svein Skogen (Listmail Account) wrote: Oh, so because a lot of the programmers behind it receive wages, and the project itself won't commit ritual suicide by basically blocking the companies using FreeBSD from returning improvements they make to the project itself, it should be renamed. Svein, A source layout change is the lest of the problems pushing code back from companies using FreeBSD. When $WORK rearranged our FreeBSD-based tree, we simply provided a perl script to run over patch files that fixed up the patch. sed -e 's,sys/amd64,sys/arch/amd64,g' patchfile newpatchfile isn't that hard to do... The fact that we totally rototilled the bge and em drivers FreeBSD 6.1-6.2 is a MUCH bigger problem to the commercial users of FreeBSD and their patch sets. [medium seriousness bug fixes were done by a full MFC of the driver, vs. just spot fixing the needed changes] -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ 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: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote: On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org, Robert Watso n writes: Doing that kind of rearrangement [...] would be a nightmare for anyone with large [...] patches, so I'd say we could pretty much rule that out outright. I would say that we should do it occasionally, to encourage these FreeBSD users to contribute as many of their local changes back to the project, as possible :-) Absolutely -- and rearranging a tree is a good way to invalidate all those patches as well :-). No, not it isn't. Provide a script to convert path's in the diff. This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. It was done by creating a copy of the CVS repo and moved files around. Old releases stayed in the old repo, and new releases done from the new repo. 'diff | fixpatch | patch -p0' were used to move code between sandboxes. -- -- David (obr...@freebsd.org) ___ 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
Can we get rid of kerb5 redefining macros?
Ever since kerberos5 got hooked up to the build by default I'm getting *TONS* (758) of CPP macros. An example is: In file included from /usr/obj/usr/src/kerberos5/lib/libasn1/roken.h:77, from /usr/src/crypto/heimdal/lib/vers/print_version.c:38: /usr/src/crypto/heimdal/lib/roken/roken-common.h:183:1: warning: EAI_NODATA re defined In file included from /usr/obj/usr/src/kerberos5/lib/libasn1/roken.h:59, from /usr/src/crypto/heimdal/lib/vers/print_version.c:38: /usr/include/netdb.h:166:1: warning: this is the location of the previous defini tion Can a kerberos5 guy take a look at these? thanks, -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sun, Nov 30, 2003 at 11:47:24PM -0500, Robert Watson wrote: On Mon, 1 Dec 2003, Maxim M. Kazachek wrote: On Sun, 30 Nov 2003, Richard Coleman wrote: ..snip.. For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. I would like to show support for this option. I've been running /usr on the / partition on *all* my FBSD machines for the past 4 years. The reasons for having a separate / and /usr just don't apply today. Disks are large enough to hold both, and UFS(FFS) is stable. Sun and SGI both combine / and /usr on their pre-installed workstation machines. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bash2 linked dynamically
On Sun, Nov 30, 2003 at 09:27:03PM -0800, Sean McNeil wrote: Also, I do not see any reason why bash should remain linked -static for -current. Lucky for me (who wants a static Bash), I don't have to make the decission -- ports are frozen and have been for a while. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Fri, Nov 28, 2003 at 09:17:39PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Tim Kientzle writes: David O'Brien wrote: On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote: and [/usr/bin/ftp] doesn't support HTTP. $ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html Requesting http://www.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. For consistency, we should link ftp(1) to http(1) I guess... Good idea. I'll ask RE. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT: buildworld fails
On Sat, Nov 29, 2003 at 01:36:03AM +0100, Dag-Erling Sm?rgrav wrote: Kris Kennaway [EMAIL PROTECTED] writes: On Thu, Nov 27, 2003 at 01:02:18PM +0400, rihad wrote: CFLAGS= -O2 -pipe I'll try to build it without -O2, thanks. *sigh*, I see we need more figlet in the documentation. -O2 is bad, mmkay? It shouldn't be today. I'm convenced that all of our problems with 'gcc-3.3.3 -O2' are FreeBSD code bugs. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to fix this in 5.1-REL??
On Tue, Nov 25, 2003 at 09:14:10PM -0700, M. Warner Losh wrote: We recommend make buildworld make buildkernel make installkernel reboot -s - single user make installworld make buildkernel ; make installkernel can be shortened to just make kernel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Wed, Nov 26, 2003 at 10:16:37AM -0600, Matthew D. Fuller wrote: The advantage of this method is it's simple, cheap, automatic, and lets us say You can try setting ADDITIONAL_RESCUE=usr.sbin/foo in make.conf and it may work, Please send a tested patch for this. :-) If ADDITIONAL_RESCUE will end the thread I'm all for it. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: As a user, I like /rescue better than the step-child that /stand/* used to be. It's part of the world, which /stand wasn't. Except that we still have /stand. It should be shot, but some won't let it go... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 03:07:55PM +1030, Daniel O'Connor wrote: What about the newer version of gcc? That is considerably slower than previous versions, but I don't see people screaming to have it removed. Uh... you must not know what you are talking about. GCC *COMPILES* slower as it does a better job of optimizing (which adds time to the compiling time). The produced optimzied binaries have quicker *RUN-TIME*s. Why would any one want to call for a compiler to be removed that produces faster binaries?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 03:48:57PM -0800, Tim Kientzle wrote: ... I think [/rescue] only needs to support those recovery actions necessary to repair /bin and /sbin if they break. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. I'm willing to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. Either way -- keep it or not. But lets agree that the FTP client will be the last thing added to /rescue that is outside the original charter. * In exchange for this concession, would you be willing to support adding fetch? If we're going to add an FTP client, lets pick the one with the best functionality for the job -- /usr/bin/ftp. I may not know the complete URL to the bits I need, and if so with fetch you're still screwed. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote: Scenarios that require /rescue are ones in which /bin and /sbin are unusable, which is almost always going to imply a trashed file in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to involve locating a good copy of a trashed file to replace a damaged local copy. NO. /rescue was allowed in the system to handle the case of a trashed file in /lib[exec]. To allow a sysadmin to recover a system from the same type of mishaps they could before we went to a dynamic /. Not to continue to add to /rescue until the sysadmin could recover from every conceivable way of trashing a system. /rescue was not to become the all-in-compassing Swiss Army recover tool. We provide the Live-FS CD (disc 2) for that. I can only think of a few places where that good copy can come from: * CDROM: requires a CD-ROM drive, and a suitable CD. * floppy: requires a floppy drive * NFS: requires a local network and an NFS server * An HTTP or FTP server: requires a network connection and 'fetch.' I don't think we can safely assume that everyone has access to one of the first three options here. We have made the assumption for the first three options since day one. Why should we change the assumptions just because we now have a dynamic /? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
[ From: set to /dev/null as too many can't follow the Reply-To: ]
On Mon, Nov 24, 2003 at 11:00:24AM -0500, Rahul Siddharthan wrote:
NO. /rescue was allowed in the system to handle the case of a trashed
file in /lib[exec]. To allow a sysadmin to recover a system from the
same type of mishaps they could before we went to a dynamic /.
Ie, let's do things the same way we did in 1994? Other things have
changed since then, hard drives and typical root partitions are much
bigger, and Tim estimated the total bloat from this as 64k. Maybe
earlier, pre-/rescue, you couldn't recover from damaged files in the
root partition without a CD/floppy/NFS, it doesn't mean you should not
have that capability in /rescue.
Lets have /rescue/{[s]bin,usr/[s]bin}. Install static copies of every
thing in /[s]bin and /usr/[s]bin today. That will let you recover in
even more ways.
Where does it end if we don't go full-out and install a 2nd copy of every
binary?
For a *lot* of people today (like home users), an up-to-date FreeBSD
CD or floppy or a second machine to create the disk on may not be
handy (and forget about NFS), but a network connection may still be
available.
That network connection would most likely be a M$-Win box in that case,
which doesn't have an FTP server. Samba, not an FTP client should be in
/rescue then.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 11:46:54AM -0500, Garrett Wollman wrote: On Mon, 24 Nov 2003 03:40:06 -0800, David O'Brien [EMAIL PROTECTED] said: We have made the assumption for the first three options since day one. Why should we change the assumptions just because we now have a dynamic /? Because we are not all masochists. Why wasn't it enough of a problem to bring up until we went to a dynamic /? Not having a usable FTP client if your libs are FUBAR'ed isn't new with dynamic. Now that it is brought up, where does it end what goes into /rescue? Having what goes into /rescue bounded only by what is in /[s]bin, /usr/[s]bin is what worries some of us. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Mon, Nov 24, 2003 at 10:47:24AM -0500, Robert Watson wrote: It strikes me that this whole conversation has gotten a little confrontational... The middle ground of adding a static /sbin/sh for scripts soudds like a reasonable choice, and has precedent in other systems (Solaris). Time for a pdksh import! We can install it as the dynamic /bin/sh, and there is precedent in other systems (Solaris) for /bin/ksh. The issue with static /sbin/sh is that we have to fix all the base scripts (doable), and then try to educate people that they need to do the same to their scripts (very hard to do). Someone must be using /bin/sh as a shell, because apparently someone spent a lot of time adding things like character input editing, filename completion, etc. Filename complete isn't in stock /bin/sh as its a private hack someone did, it is a hack and isn't commitable. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote: Contrary to what David claims, I don't think /rescue does need to support all of the recovery actions that a static /s?bin would support. Rather, I think it only needs to support those recovery actions necessary to repair /bin and /sbin if they break. No, you're missing my stance. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. With a static / last month, if I needed to get a file onto the machine, I had to use a floppy, CDROM, or mount another file system (NFS counts in this). The argument flowing in this thread is about adding additional ways to repair a trashed machine. Those of us that agreed to the /rescue bloat didn't agree to that. We agreed to the claim that /rescue would hold those bits needed to repair a trashed system in the SAME ways one did with a static /. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote: I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. Would it be possible, through some make.conf magic, for the end-user to set extra programs to be put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch This list could easily need things added to librescue. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Mon, Nov 24, 2003 at 07:19:31PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : : M. Warner Losh writes: : In message: [EMAIL PROTECTED] : Andrew Gallatin [EMAIL PROTECTED] writes: : : I'll bet a larger percentage of our users build ports than need nss or : : ldap. : : I'll bet a larger percentage of the people are ignoring this thread : than reading it since it has been so devoid of concrete numbers. : : Aside from $SUBJECT.. I'm just saying that most of the developers I'm talking to on IRC say this tread is insane, has no content and they are blowing it off because of that. A concrete, real benchmark will go a long way towards changing that. Until then, you are as good as kill filed. What qualifies as a concrete, real benchmark? I take it you don't think Drew's qualifies. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 06:27:13PM -0800, Tim Kientzle wrote: The debate right now is over what programs from /usr/bin and /usr/sbin should be included. Right now, that includes tar, gzip, bzip2, and vi/ex. All but vi(ex) were built statically, but installed into /usr/bin. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote: At 5:22 PM -0800 2003/11/22, David O'Brien wrote: Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now. Why? Why cut your nose off to spite your face? Even though this capability may not have existed before, why shouldn't we have it now? Lets build all of /bin, /sbin, /usr/bin, /usr/sbin static then. You would have all kinds of capability you didn't before. /rescue is the consession made between those that want a dynamic / and those that want a static /. Its purpose is only to allow one to do the things they could before with a static /. It is not to become a can or worms that ends up being a duplicate of 50% of the system. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
As I pointed out earlier, some of the heat here comes from the fact that /bin/sh is currently overloaded: * It is the default system script interpreter, used by the rc scripts and many other things. As such, it must start quickly. * It is the default user shell for many users. As such, it must support NSS. So far, I haven't seen anyone in this thread seriously argue against either of these points. I'll seriously argue against the 2nd point above. I don't know of a SINGLE person that uses /bin/sh as their interactive shell when multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses Bash, ATT ksh, pdksh, zsh. Richard Coleman wrote: It seems /bin/sh is the real sticking point. There is a problem here: Unix systems have historically used /bin/sh for two somewhat contradictory purposes: * the system script interpreter * as a user shell The user shell must be dynamically linked in order to support centralized administration. I personally see no way around that. Given that many users do rely on /bin/sh, it seems that /bin/sh must be dynamically linked. There are good reasons to want the system script interpreter statically linked. Maybe it's time to separate these two functions? I argue the two functions are already separated as /bin/sh as interactive shell doesn't really exist outside of single user. We should build /bin/sh static and be done with the argument. Or rather, lets find a /bin/sh interactive user and have him argue that /bin/sh needs NSS support. I dare say that will be a thread two orders of magnitude shorter than this one. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Mon, Nov 24, 2003 at 12:14:39AM -, Duncan Barclay wrote: From: David O'Brien [EMAIL PROTECTED] I'll seriously argue against the 2nd point above. I don't know of a SINGLE person that uses /bin/sh as their interactive shell when multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses Bash, ATT ksh, pdksh, zsh. I don't know anyone that farms lama's, so there cannot be any lama farmers. One has to make a strong statement to get the people to come out of the woodwork. computer$ grep dmlb /etc/passwd dmlb:*:1166:1166:Duncan Barclay:/home/dmlb:/bin/sh Good. Now do you need NSS support? Do the benefits of supporting NSS in /bin/sh for you out-weigh the performance issue of building it dynamically? Couldn't you just as easily use the pdksh port? -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Sun, Nov 23, 2003 at 06:27:01PM -0500, Richard Coleman wrote: But it would be sorta odd to have statically linked versions of sh in both /bin and /rescue. We'd remove it from /rescue if the /bin/sh one was static. :-) -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Fri, Nov 21, 2003 at 03:33:51PM -0600, Guy Helmer wrote: Tim Kientzle wrote: Guy Helmer wrote: Thanks to /rescue and the live filesystem archives on current.freebsd.org, I was able to recover a machine that I hosed after the statfs change by trying to installworld without building booting a new kernel first. Great! Any changes you could suggest to /rescue based on that experience? Sure -- I could have used the ftp client (or fetch) in /rescue :-) (/me ducks) You wouldn't have had it pre-dynamic /: fetch is /usr/bin/fetch ftp is /usr/bin/ftp ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Fri, Nov 21, 2003 at 02:11:30PM -0800, Tim Kientzle wrote: Thanks to /rescue and the live filesystem archives on current.freebsd.org, I was able to recover ... I could have used the ftp client (or fetch) in /rescue :-) Yes, fetch would be useful. I imagine a lot of people in emergency situations will need to pull things over a network connection. Looks like it would only add about 65k (20k for fetch, another 45k for libfetch which isn't already in the crunched /rescue binary). Submit a PR on this Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-CURRENT totally broken on AMD64 in 32-bit mode
On Mon, Nov 17, 2003 at 10:12:03AM -0800, David O'Brien wrote: The kernel changes of the past week has totally turned my AMD64 machine that I use in 32-bit mode running FreeBSD/i386 (GENERIC): OK boot -v cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0 , pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 cuyrrent process= 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 You get a panic (trap 30) that you can hit 'center' and continue from. It's actually only a trap, not a panic. I am trying to figure out the exact problem now. It seems that the vm86 code is very buggy and enables interrupts during the early boot. You can try http://www.FreeBSD.org/~jhb/patches/vm86.patch -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: amd64 users! SMP code drop committed.
On Mon, Nov 17, 2003 at 01:51:53AM -0800, Peter Wemm wrote: sledge.freebsd.org is now running in SMP, as is the loaner 4-way Opteron that I have for testing. Now that you've got all 4 CPU's spinning up, producing maxium BTU's, aren't you glad I brought you that new useful space header for winter. ;-) -- -- David ([EMAIL PROTECTED]) P.S. YAY! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5-CURRENT totally broken on AMD64 in 32-bit mode
The kernel changes of the past week has totally turned my AMD64 machine that I use in 32-bit mode running FreeBSD/i386 (GENERIC): OK boot -v cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0 , pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 cuyrrent process= 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Alpha SMP panic
# cd /usr/src ; cvs -qR up -PdA ... U sys/netgraph/bluetooth/include/ng_btsocket_hci_raw.h U sys/netgraph/bluetooth/include/ng_btsocket_l2cap.h U sys/netgraph/bluetooth/include/ng_btsocket_rfcomm.h panic: Assertion td-td_turnstile != NULL failed at ../../../kern/subr_turnstile.c:427 cpuid = 1; panic spin lock sched lock held by 0xfc001f053c80 for 5 seconds ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 16, 2003 at 11:37:47PM -0500, Bill Vermillion wrote: 1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB static. Dynamically linked, they are only 4 MB. I don't think saving that little space on the / partition is as important as having everthing in sbin being able to stand alone no matter what is corrupted. You seem to be late comming to this discussion. #2 in the original email was also a huge reason for this change. On a non-FreeBSD system I had to recover, I had to physically take the server from the colo to a place where I could pull the drive to be able to run the recovery utitlities - as none of the dynamic binariies worked. /rescue What was done to programs like /bin/sh, /sbin/init and /sbin/fsck to make them work without access to /usr/lib? And even if they are accessible IF the libraries become corrupted then nothing will work. That's certainly not a 'fail-safe' environment. Again you are late coming to this discussion -- /resuce. For those who don't build the OS but install from binaries, this makes the system potentially less rugged. /rescue ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS-UP new statfs structure
On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote: Provided that we 2. replace the date with a convenient sequence number, which we can call the minor version number, and .. E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2... Please no -- it wouldn't be easy to see a.out libs from ELF ones. (yes I still have some a.out binaries) -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
