Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23.12.11 03:17, O. Hartmann wrote: Or even look at the thread regarding to SCHED_ULE. Why has a user, experiencing really worse performance with SCHED_ULE, in a nearly scientific manner some engineer the fault? I'd expect the developer or care-taking engineer taking care in a more user friendly manner. You remember that those developers are not paid to do what they do? You remember that nobody has sold you this OS and promised support in whatever form? Still, this issue is discussed publicly and experiments are being made, I guess also new code is being experimented. If you are interested in the outcome, just follow the discussion. If you can help with something and you are willing, please do. There will be good solution to the SCHED_ULE shortcomings. FreeBSD is unique group of people, who all sit on their eggs, be it eggs they themselves produced, or they inherited one way or another. These people include all the developers and most of the system administrators and users of FreeBSD. There is no they and us. If your preference for the OS is different, you might feel more comfortable in choosing another OS, probably a commercial OS with support from the vendor. If a benchmark reveals some severe weak points in FreeBSD and I have to read about obscure tweaks of non documented sysctl, then this OS would be a no-go if I was a manager to make decissions. Luckily, managers do not care about knobs or how difficult it is for the system administrator to achieve specific goal. All they care is the bottom line in general and in short therm the goals they have set. No sane manager will care about benchmarks, as long as he gets what he wants. Back, to the Phoronix benchmarks. There has already been communication. Phoronix were given advices on how to better do some things on FreeBSD (which will make the quality of their benchmarks better and therefore more trusted). Phoronix has made their updated test suite available to FreeBSD users (that include developers) to try on their own hardware. By the way, it is in /usr/ports/benchmarks/phoronix-test-suite. Linux and FreeBSD are not enemies, they both solve the same problems with different means. Daniel ___ 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: r228700 can't dhclient em0
On 23. Dec 2011, at 01:40 , Doug Barton wrote: On 12/21/2011 23:20, Gleb Smirnoff wrote: On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: D So does that mean that if I upgrade to the latest HEAD from a system D built before the ifconfig changes that when I reboot my network will D come up? Yes, older infconfig will work in head r228571 || head r228768. I just tried with r228122 and got the same result. dhclient errors out with can't find em0 although 'ifconfig em0' does produce results. Which is due to getifaddrs() most likely; please go back and read up the other half of the thread; I am working on this. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23.12.11 08:47, Martin Sugioarto wrote: A further thing is that I cannot understand the people here sometimes. I would like that the -RELEASE versions of FreeBSD perform well without any further optimizations. The -RELEASE things is just a freeze (or, let's say tested freeze) of the corresponding branch at some time. It is the code available and tested at that time. Thus, it is safe to say that FreeBSD 8.0-RELEASE is much worse than FreeBSD RELENG_8 (still 8.2 at the moment), because years have passed between both code bases, lots of bugs have been discovered and fixed and new technologies have been integrated. Especially in this line, the compiler has changed from 4.2.1 to 4.2.2. When the distribution does not compile with the latest compiler it's simply a bug. FreeBSD is not a distribution. It also compiles with the latest compiler - LLVM. :) I find it amusing, that people want everything compiled with GCC 4.7, which is still very much developing, therefore highly unstable and (probably) full of bugs. Why should one try to penalize the other distribution and downgrade their binaries? Many suggested that the Linux binaries be run via the FreeBSD Linux emulation. Unchanged. There is one problem here though, the emulation is still 32 bit. When FreeBSD has a bad default setup, there must be a reason for that. Tell me this reason and show me that it's justified in form of some other benchmark. FreeBSD has safe default. It is supposed to work out of the box on whatever hardware you put it. As much as it has drives for that hardware, of course. Once you have working installation, you may tweak it all the way you wish. If your installation is pre-optimized, chances are it will crash all the time on you and there will be no easy way for you to fix, short of installing another distribution. Daniel ___ 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: r228700 can't dhclient em0
On 12/23/2011 01:14, Bjoern A. Zeeb wrote: On 23. Dec 2011, at 01:40 , Doug Barton wrote: On 12/21/2011 23:20, Gleb Smirnoff wrote: On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: D So does that mean that if I upgrade to the latest HEAD from a system D built before the ifconfig changes that when I reboot my network will D come up? Yes, older infconfig will work in head r228571 || head r228768. I just tried with r228122 and got the same result. dhclient errors out with can't find em0 although 'ifconfig em0' does produce results. Which is due to getifaddrs() most likely; please go back and read up the other half of the thread; I read the whole thread. It's my thread after all. :) I was taking Gleb at his word when he answered my question with yes. I am working on this. Excellent. ETA? Normally I wouldn't be worried about updating, but I want to try the newly updated code to recognize music CDs. If it works I would like to encourage re@ to include it in the new release since I think it will save our users a lot of pain. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23/12/2011 02:56, Garrett Cooper wrote: On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: On 12/21/11 19:41, Alexander Leidinger wrote: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. Take the advice in tuning(7) with a grain of salt because a number of suggestions are really outdated. I know because I filed a PR last night after I saw how out of synch some of the defaults it claimed were with reality on 9.x+. And I know other suggestions in the manpage are dated as well ;/. There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Vince Thanks, -Garrett___ 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 ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23.12.11 12:48, O. Hartmann wrote: Look at Steve Kargls problem. He investigated a SCHED_ULE problem in a way that is far beyond enough! He gave tests, insights of his setup, bad performance compared to SCHED_4BSD and what happend? We are still stuck with this problem and more and more people realise, that FreeBSD does have somewhere a problem and this seems to be a nasty problem not easy to find or investigate. This has made me to realize, that I was having a problem with SCHED_ULE that I was not aware of until now. WOW! :) Every scheduler has some problem, some fail here some fail there. I am confident, that the case that Steve Kargls has reported will be resolved. Another problem is this very elite-feeling closed club. Once you managed it getting into the club of committers or core team members, you'll probably fight for your seat ... I dont propose for that socialists crap Linux people tend to be like, [..] You never heard of the People's Republic of Berkeley? :) As for commiter access, this sort of comments trigger the system administrator in me. I have seen enough people, who for the lack of other excuses always use but I don't have enough RIGHTS!. I am evil, I know But I follow the illusion that if people can see what benchmarks reveal, they start thinking and if the facts are starting to give a heavy load load on those rejecting the facts, they migght change their opinion or get hopefully replaced by more openminded people. Here is now it works: If you see an problem and have a solution: go fix it. Many will be grateful. If you can't fix it, but have an idea how to fix it, share it. May will be grateful. If you can't fix it and don't have any idea, just say there is a problem and stop there. There are many, many, many like you who just hold their breath. We all learn, every day. Daniel ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Fri Dec 23 11, Daniel Kalchev wrote: On 23.12.11 08:47, Martin Sugioarto wrote: A further thing is that I cannot understand the people here sometimes. I would like that the -RELEASE versions of FreeBSD perform well without any further optimizations. The -RELEASE things is just a freeze (or, let's say tested freeze) of the corresponding branch at some time. It is the code available and tested at that time. Thus, it is safe to say that FreeBSD 8.0-RELEASE is much worse than FreeBSD RELENG_8 (still 8.2 at the moment), because years have passed between both code bases, lots of bugs have been discovered and fixed and new technologies have been integrated. Especially in this line, the compiler has changed from 4.2.1 to 4.2.2. When the distribution does not compile with the latest compiler it's simply a bug. FreeBSD is not a distribution. It also compiles with the latest compiler - LLVM. :) I find it amusing, that people want everything compiled with GCC 4.7, which is still very much developing, therefore highly unstable and (probably) full of bugs. Why should one try to penalize the other distribution and downgrade their binaries? Many suggested that the Linux binaries be run via the FreeBSD Linux emulation. Unchanged. There is one problem here though, the emulation is still 32 bit. plus the current emulation layer is far from complete. a lot of stuff hasn't been implemented yet (meaning it's missing or implemented as dummy code). try running recent firefox linux binaries on freebsd. they will all crash almost instantly. cheers. alex When FreeBSD has a bad default setup, there must be a reason for that. Tell me this reason and show me that it's justified in form of some other benchmark. FreeBSD has safe default. It is supposed to work out of the box on whatever hardware you put it. As much as it has drives for that hardware, of course. Once you have working installation, you may tweak it all the way you wish. If your installation is pre-optimized, chances are it will crash all the time on you and there will be no easy way for you to fix, short of installing another distribution. Daniel ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/23/11 07:47, Martin Sugioarto wrote: Am Fri, 23 Dec 2011 02:17:00 +0100 schrieb O. Hartmann ohart...@zedat.fu-berlin.de: Benchmarks also could lead developers to look into more details of the weak points of their OS, if they're open for that. Therefore, benchmarks are very useful. But not if any real fault of the OS is excused by a faulty becnhmarking. Hi, it is important for the project to be known and I think that the benchmarks made by Phoronix help FreeBSD to gain popularity, even they look bad sometimes. Furthermore, to make a benchmark is a lot of work and the results are useful, because at the end someone will look at it and will try to improve the results. Thank you for investing your time. I remember that I've made some tests with different platforms i386 vs amd64 with simple tools like openssl speed some time ago and got some bad results for amd64 that no one cared to explain. These bad results weren't reflected on Linux that I tested later for comparison. And most people have a weird attitude to think that the tester measures wrong instead of taking a look at it. They forget that as a FreeBSD user you would rather see FreeBSD win over Linux. I've seen that Phoronix made various benchmarks about FreeBSD compared to Linux and I can tell you that _subjectively_ the benchmarks reflect what I always thought about FreeBSD. I simply _know_ that FreeBSD is worse in concurrency behavior, I know that it has I/O trouble, I know that it is mostly faster emulating 3D games than Linux runs them natively. I knew this already _before_ you published the benchmark about the 3D performance. I cannot see any evil intentions in these benchmarks. All I can see is the wrong attitude _here_. If anyone thinks that Phoronix makes bad benchmarks, they should do these benchmarks by themselves and publish the results. As long as no one tries, Phoronix stays the best reference for me and for everyone else. There IS NO EVIL INTENTION, except, hypothetical, the benchmarker is of the age were he is called a beardless. But: In many articles, there is a very distinguished and underlined emphasizing of Linux that makes me feeling people have their Linux-glasses on. Linux is not UNIX! And if today someone tells me about the Linux-graphical subsystem X11, I turn green in my face ... X11 was, in former days, a development made on UNIX and is adopted by Linux. Ok, we all know that, most of all ... And the aspect of reference: I agree. They do something and this thread arose while they did. And don't forget, benchmarks can never be objective enough and someone will always be mad about the results. Especially, when you present them a versus battle. A further thing is that I cannot understand the people here sometimes. I would like that the -RELEASE versions of FreeBSD perform well without any further optimizations. When the distribution does not compile with the latest compiler it's simply a bug. Why should one try to penalize the other distribution and downgrade their binaries? When FreeBSD has a bad default setup, there must be a reason for that. Tell me this reason and show me that it's justified in form of some other benchmark. Well, look at the mailing list. FreeBSD is handled via this list since we are spread around the globe and even the developers are spread worldwide. But when it comes to detecting worse performnce and someone isn't capable of giving a detailed insight and mostly scientific way of investigating the fault he experienced, the discussion, if it starts, get drowned by allegations like bad testing, worse optimizations blabla. Look at Steve Kargls problem. He investigated a SCHED_ULE problem in a way that is far beyond enough! He gave tests, insights of his setup, bad performance compared to SCHED_4BSD and what happend? We are still stuck with this problem and more and more people realise, that FreeBSD does have somewhere a problem and this seems to be a nasty problem not easy to find or investigate. But look at how Steve has been silenced in the past ... Benchmarks, especially published ones, reveal those pits and soemone could look into it. Another problem is this very elite-feeling closed club. Once you managed it getting into the club of committers or core team members, you'll probably fight for your seat ... I dont propose for that socialists crap Linux people tend to be like, overcrowded townhalls full of important people with non-consense opinions. The other extreme end of this spectrum. I can not change this. And I do not know whether there is a real way-in-the-middle. But I follow the illusion that if people can see what benchmarks reveal, they start thinking and if the facts are starting to give a heavy load load on those rejecting the facts, they migght change their opinion or get hopefully replaced by more openminded people. A Vision. Oliver ___ freebsd-current@freebsd.org mailing list
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/23/11 10:07, Daniel Kalchev wrote: On 23.12.11 03:17, O. Hartmann wrote: Or even look at the thread regarding to SCHED_ULE. Why has a user, experiencing really worse performance with SCHED_ULE, in a nearly scientific manner some engineer the fault? I'd expect the developer or care-taking engineer taking care in a more user friendly manner. You remember that those developers are not paid to do what they do? You remember that nobody has sold you this OS and promised support in whatever form? Well, as far as I know, the FreeBSD project is funding people doing a certain work! So, the implied opposit, FreeBSD is developed free isn't true. Still, this issue is discussed publicly and experiments are being made, I guess also new code is being experimented. If you are interested in the outcome, just follow the discussion. If you can help with something and you are willing, please do. There will be good solution to the SCHED_ULE shortcomings. FreeBSD is unique group of people, who all sit on their eggs, be it eggs they themselves produced, or they inherited one way or another. These people include all the developers and most of the system administrators and users of FreeBSD. There is no they and us. What I am in this terminology? I can hardly write some scientific code for my science, I'm able to patch software a bit, that has been developed only for Linux these days (ISIS3 from the USGS, for instance, but I do not dare to publish the crap of port I produced since it is not professional). I'm with FreeBSD now since 1996/97. I'm still with the system, although I desperately need scientific grade compilers or GPGPU support. So, even if Linux offers me a really much more convenient way to do my work, I stayed with FreeBSD since there is no real alternative in terms of cleaness of the system. I have also to administer an Ubuntu and Suse server and I feel not amused by this script hell that covers the real system just to get kiddies or Windows-Admins into the admin-position. And, I dare to put some critics herein! Since I see that FreeBSD is free, why not trying to make it better and more towards perfect? If your preference for the OS is different, you might feel more comfortable in choosing another OS, probably a commercial OS with support from the vendor. This is nonesense, you know that, regarding to my case. If a benchmark reveals some severe weak points in FreeBSD and I have to read about obscure tweaks of non documented sysctl, then this OS would be a no-go if I was a manager to make decissions. Luckily, managers do not care about knobs or how difficult it is for the system administrator to achieve specific goal. All they care is the bottom line in general and in short therm the goals they have set. No sane manager will care about benchmarks, as long as he gets what he wants. Well, in real world and beyond this armchair polemics, managers at last do the decissions. Those people dropping math, physics, with no glue to how things work in nature get a degree in law, business and whatsowever and then decide. In my eyes, those are enemies of every development and progress, but this is polemics, too. I faced this many times and it is hard to convince those people not taking care of knobs. But as an admin myself, I need to know about knobs and if essential knobs are not documented, than there is a potential gone for the OS in question. Look at FreeBSD and the problem of how well sysctls and their working are documented. It needs to be fixed. Back, to the Phoronix benchmarks. There has already been communication. Phoronix were given advices on how to better do some things on FreeBSD (which will make the quality of their benchmarks better and therefore more trusted). Phoronix has made their updated test suite available to FreeBSD users (that include developers) to try on their own hardware. By the way, it is in /usr/ports/benchmarks/phoronix-test-suite. Yes, everyone interseted in this thread and communicating is aware of that fact. Linux and FreeBSD are not enemies, they both solve the same problems with different means. Daniel ___ 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
scheduler panic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been getting these in a VirtualBox VM. I'm not sure what to do. I CAN give VNC access to this VM in this state. panic: sched_priority: invalid priority 331: nice 0, ticks 56612596 ftick 1213618 itick 1214628 tick pri 159 cpuid = 0 KDB: enter: panic Ideas? (repost without the screenshot). - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO9IBlAAoJENC8dtAvA1zmAJAIAL67TPUdIigtumkBLHZM1qCo 7JFfBXpyEjH8vs0bkCk+GYSCke67IGMUpiR5XeZ8UsKjiTtyyhw1SQZYIw/EiVvf 7Nf+DOxbKIYEPezeEqpaskejItfOM6h7ajZovRNTJsrNH+ha0csGgFk46iEFH5Qq LTQ7D5GrFj+hCzNDLcbxWOiTqxGMlTboZun5C0Y6BYK09RpLqMtU6bIh/37zj7kr u4VSh94hPW8t8qTnL5rlETMAjvmtIivphEVv/R5jOv0cGtNP/o2QaM66w3TaxyJ0 Z9ixNuzq3MAft20VRrVdUEnZ43DASv7Aisl2GNoaTNRW/MVuaULG/PdA9hj2vZ8= =G2La -END PGP SIGNATURE- ___ 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: scheduler panic
В Fri, 23 Dec 2011 07:21:41 -0600 Larry Rosenman l...@lerctr.org пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been getting these in a VirtualBox VM. I'm not sure what to do. I CAN give VNC access to this VM in this state. panic: sched_priority: invalid priority 331: nice 0, ticks 56612596 ftick 1213618 itick 1214628 tick pri 159 cpuid = 0 KDB: enter: panic Ideas? (repost without the screenshot). uname -a ??? ___ 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: scheduler panic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/23/2011 7:31 AM, Ivan Klymenko wrote: В Fri, 23 Dec 2011 07:21:41 -0600 Larry Rosenman l...@lerctr.org пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been getting these in a VirtualBox VM. I'm not sure what to do. I CAN give VNC access to this VM in this state. panic: sched_priority: invalid priority 331: nice 0, ticks 56612596 ftick 1213618 itick 1214628 tick pri 159 cpuid = 0 KDB: enter: panic Ideas? (repost without the screenshot). uname -a ??? Oops. It's running the same kernel as it's host: $ uname -a FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #31 r228802: Thu Dec 22 11:21:25 CST 2011 r...@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 $ I can also give SSH access to the host as well. - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO9IRMAAoJENC8dtAvA1zmxJEIALP7wzsx9Co9QaE+Cx3JK2vx pCRJqLBTkpsnzdYmGsczBAUpEXJ/POx+7UsWycd48zQlT64FZubeHGi2yIIZNOzL zpYdaY/70cacFuyouMtZyLOrCTLiJe4AVBOluA79zCNgJKIcIhGyGSObsO7CqiiR oS2MHyWy9n5oLo6Qf79708gar4QXHDZwVkgRZ3heWeZY+wPt8CVrzX5k8uf7dSlz Yq4+A1G9atfuprp6iRUTIT7aHKKv6IwM3QAg2wuaUqatUYsJv8ushRrsZHfJmmft /LmMmHMlaqqsDy4Wjm0v5souid6vIuGv7zyOxfILCnk/9UnWEEThqpP31mu362k= =skwU -END PGP SIGNATURE- ___ 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: scheduler panic
В Fri, 23 Dec 2011 07:38:21 -0600 Larry Rosenman l...@lerctr.org пишет: BORG-DTRACE Show, please, the kernel config BORG-DTRACE ___ 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: scheduler panic
On Fri, 23 Dec 2011, Ivan Klymenko wrote: ? Fri, 23 Dec 2011 07:38:21 -0600 Larry Rosenman l...@lerctr.org ?: BORG-DTRACE Show, please, the kernel config BORG-DTRACE include GENERIC ident BORG-DTRACE options KDTRACE_HOOKS# all architectures - enable general DTrace hooks options DDB_CTF # all architectures - kernel ELF linker loads CTF data options KDTRACE_FRAME# amd64 - ensure frames are compiled in #makeoptions DEBUG=-g # amd64? - build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 #options COMPAT_FREEBSD8 nooptions WITNESS nodevice mvs nodevice siis nodevice ahc nodevice ahd nodevice amd nodevice hptiop nodevice isp nodevice mpt nodevice mps nodevice sym nodevice trm nodevice adv nodevice adw nodevice aic nodevice bt nodevice amr nodevice arcmsr nodevice asr nodevice ciss nodevice dpt nodevice hptmv nodevice hptrr nodevice iir nodevice ips nodevice mly nodevice twa nodevice aac nodevice aacp nodevice ida nodevice mfi nodevice mlx nodevice twe nodevice tws nodevice cbb nodevice pccard nodevice cardbus nodevice plip nodevice puc nodevice bxe nodevice de nodevice igb nodevice ixgbe nodevice le nodevice ti nodevice txp nodevice vx nodevice ae nodevice age nodevice alc nodevice ale nodevice bce nodevice bfe nodevice bge nodevice dc nodevice et nodevice fxp nodevice jme nodevice lge nodevice msk nodevice mge nodevice pcn nodevice re nodevice rl nodevice sf nodevice sge nodevice sis nodevice sk nodevice ste nodevice stge nodevice tl nodevice tx nodevice vge nodevice vr nodevice wb nodevice xl nodevice cs nodevice ed nodevice ex nodevice ep nodevice fe nodevice sn nodevice xe nodevice wlan nodevice wlan_wep nodevice wlan_ccmp nodevice wlan_tkip nodevice wlan_amrr nodevice an nodevice ath nodevice ath_pci nodevice ath_hal nodevice ath_rate_sample nodevice ipw nodevice iwi nodevice iwn nodevice malo nodevice mwl nodevice ral nodevice wi nodevice wpi nodevice urio# Diamond Rio 500 MP3 player # USB Serial devices nodevice u3g # USB-based 3G modems (Option, Huawei, Sierra) nodevice uark# Technologies ARK3116 based serial adapters nodevice ubsa# Belkin F5U103 and compatible serial adapters nodevice uftdi # For FTDI usb serial adapters nodevice uipaq # Some WinCE based devices nodevice uplcom # Prolific PL-2303 serial adapters nodevice uslcom # SI Labs CP2101/CP2102 serial adapters nodevice uvisor # Visor and Palm devices nodevice uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus nodevice aue # ADMtek USB Ethernet nodevice axe # ASIX Electronics USB Ethernet nodevice cdce# Generic USB over Ethernet nodevice cue # CATC USB Ethernet nodevice kue # Kawasaki LSI USB Ethernet nodevice rue # RealTek RTL8150 USB Ethernet nodevice udav# Davicom DM9601E USB # USB Wireless nodevice rum # Ralink Technology RT2501USB wireless NICs nodevice run # Ralink Technology RT2700/RT2800/RT3000 NICs. nodevice uath# Atheros AR5523 wireless NICs nodevice upgt# Conexant/Intersil PrismGT wireless NICs. nodevice ural# Ralink Technology RT2500USB wireless NICs nodevice urtw# Realtek RTL8187B/L wireless NICs nodevice zyd # ZyDAS zd1211/zd1211b wireless NICs # FireWire support nodevice firewire# FireWire bus code nodevice sbp # SCSI over FireWire (Requires scbus and da) nodevice fwe # Ethernet over FireWire (non-standard!) nodevice fwip# IP over FireWire (RFC 2734,3146) nodevice dcons # Dumb console driver nodevice dcons_crom # Configuration ROM for dcons # Sound support nodevice sound # Generic sound driver (required) nodevice snd_es137x # Ensoniq AudioPCI ES137x nodevice snd_hda # Intel High Definition Audio nodevice snd_ich # Intel, NVidia and other ICH AC'97 Audio nodevice snd_uaudio # USB Audio nodevice snd_via8233 # VIA VT8233x Audio devicenetmap options FFCLOCK I've also seen it with GENERIC, FWIW. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ 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
scheduler panic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been getting these in a VirtualBox VM. I'm not sure what to do. I CAN give VNC access to this VM in this state. panic: sched_priority: invalid priority 331: nice 0, ticks 56612596 ftick 1213618 itick 1214628 tick pri 159 cpuid = 0 KDB: enter: panic Ideas? - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO9H7aAAoJENC8dtAvA1zmXg8H/3lmAWQBszmBCPv2ucbH4JE8 c7M20HHmtJZtISal/FAkjFD324xDDAIwwZhBlB5bJZzXw3RE+BuCuJy+yYdIcGQd 3DGUvli2ryhOpE8xzkG1i9qIyBvMV8B2lxgdpnAGTtuCnMQPEMGUNPST6RrTivHs gSk+KxtrmuEtpIowKxeg4HC2JIyF2VQikd0eximYM2b9pRQg5eYiO6HG4xoKJCxh OQJ3hbITveoSlevd9QddKUQeD7y80KnBT2KNIZsr9HtErZCIDcZYJAXIAgcGUPDW F9lXVTj7+vaX8YEgZc1i/WExKnyvq3qyQQQktSWSnInzHlMg8nItovZduwtE23E= =nqba -END PGP SIGNATURE- paninc.PNG.sig Description: Binary data ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Am Fri, 23 Dec 2011 11:18:03 +0200 schrieb Daniel Kalchev dan...@digsys.bg: The -RELEASE things is just a freeze (or, let's say tested freeze) of the corresponding branch at some time. It is the code available and tested at that time. Hi Daniel, obviously performance is not a quality aspect, only stability. FreeBSD is not a distribution. It also compiles with the latest compiler - LLVM. :) I thought that the D in FreeBSD stands for distribution. Yes, it's ok that it compiles with LLVM. Does it also run faster in benchmarks? I find it amusing, that people want everything compiled with GCC 4.7, which is still very much developing, therefore highly unstable and (probably) full of bugs. When you don't use the software don't complain that it is buggy, because you won't find the bugs. You cannot always tell the others to make everything perfect. I don't want to have everything compiled on $COMPILER. I want that there is a reasonable quality. And for me quality is not only stability, but also speed. Many suggested that the Linux binaries be run via the FreeBSD Linux emulation. Unchanged. There is one problem here though, the emulation is still 32 bit. I'm not talking about emulation. I don't use FreeBSD to run emulated binaries. I (any many people) want efficient servers and eventually desktops. You should not expect people to tune the system for speed, when it's clear that default setting does not make any sense. People will use default settings, because they trust developers that they thought about balanced stability, security and performance. FreeBSD has safe default. This is what I am talking about. Don't complain that the benchmark does not show efficience. No one is interested in tuning FreeBSD just for a benchmark application. It is supposed to work out of the box on whatever hardware you put it. As much as it has drives for that hardware, of course. Once you have working installation, you may tweak it all the way you wish. But if you don't tweak, you get a fair result in a benchmark. This is what you will see as a user of the system. These are the default settings, that means developers chose them as the BEST choice for the system. If your installation is pre-optimized, chances are it will crash all the time on you and there will be no easy way for you to fix, short of installing another distribution. Sorry, no. If optimization makes bugs appear, there are bugs in the code (somewhere). And you will never find them when you hide them like this. You will also never see many advances in performance. -- Martin signature.asc Description: PGP signature
Re: [patch] Cleaning up amd64 kernel optimization options
On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote: On Dec 22, 2011, at 4:59 PM, Alexander Best arun...@freebsd.org wrote: On Thu Dec 22 11, Benjamin Kaduk wrote: On Thu, 22 Dec 2011, Alexander Best wrote: On Thu Dec 22 11, Dimitry Andric wrote: Hi, I would like to ask some feedback on the attached patch, which cleans up the kernel optimization options for amd64. This was touched upon earlier by Alexander Best in freebsd-toolchain, here: i've been using such settings for a few months now and haven't noticed any problems. however bruce evans raised a good point (in a private mail). when you compile a kernel without debugging enabled, -O2 is the default. if you experience issues, and enable debugging, -O0 now becomes the default. in case the problems with the kernel were caused by the -O2 option and aren't present with the -O0 option, the newly built kernel with debugging enabled will not help you fix the problems. in that case you would need to set -O2 explicitly in CFLAGS. his exact words were: I don't like -O2 for anything. However, if it is only a default, it is not a problem provided it can be canceled easily. And for debugging, you want the default to be the same as without debugging, so that (by default) you debug the same code that caused the problem. however i don't think this is fixable. using -O0 for debuggable and non-debuggable kernels will cause too much of a slowdown. having -O2 as the default flag for non-debuggable kernels and -O2 -g for debuggable kernels might cause situations, where debugging isn't possible, where with -O0 -g it would have been. so i guess although bruces concerns are valid, they are impossible to solve. Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. sorry. of course i meant -O: .if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g .else [..] Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. I still leave -O2 in, but what I do is this: make DEBUG_FLAGS=-g -fno-inline Just adding -fno-inline makes a world of difference. -- John Baldwin ___ 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: scheduler panic
On Friday, December 23, 2011 8:21:41 am Larry Rosenman wrote:
I've been getting these in a VirtualBox VM. I'm not sure what to do.
I CAN give VNC access to this VM in this state.
panic: sched_priority: invalid priority 331: nice 0, ticks 56612596
ftick 1213618 itick 1214628 tick pri 159
In the past this happened because the 'ticks' value was bananas. Priority
values should only be from 0 to 255, so 331 is definitely too large. The
priority is computed like so:
pri = SCHED_PRI_MIN;
if (td-td_sched-ts_ticks)
pri += SCHED_PRI_TICKS(td-td_sched);
pri += SCHED_PRI_NICE(td-td_proc-p_nice);
KASSERT(pri = PRI_MIN_BATCH pri = PRI_MAX_BATCH,
(sched_priority: invalid priority %d: nice %d,
ticks %d ftick %d ltick %d tick pri %d,
pri, td-td_proc-p_nice, td-td_sched-ts_ticks,
td-td_sched-ts_ftick, td-td_sched-ts_ltick,
SCHED_PRI_TICKS(td-td_sched)));
Note that you have:
kern/sched_ule.c:
#define PRI_TIMESHARE_RANGE (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE + 1)
#define PRI_INTERACT_RANGE ((PRI_TIMESHARE_RANGE - SCHED_PRI_NRESV) / 2)
#define PRI_BATCH_RANGE (PRI_TIMESHARE_RANGE - PRI_INTERACT_RANGE)
#define PRI_MIN_INTERACTPRI_MIN_TIMESHARE
#define PRI_MAX_INTERACT(PRI_MIN_TIMESHARE + PRI_INTERACT_RANGE - 1)
#define PRI_MIN_BATCH (PRI_MIN_TIMESHARE + PRI_INTERACT_RANGE)
#define PRI_MAX_BATCH PRI_MAX_TIMESHARE
#define SCHED_PRI_NRESV (PRIO_MAX - PRIO_MIN)
sys/resource.h:
#define PRIO_MIN-20
#define PRIO_MAX20
sys/priority.h:
#define PRI_MIN_TIMESHARE (120)
#define PRI_MAX_TIMESHARE (PRI_MIN_IDLE - 1)
#define PRI_MIN_IDLE(224)
So PRI_MAX_BATCH is 223.
PRI_MIN_BATCH is 120 + (((223 - 120 + 1) - (20 - -20)) / 2) which is 152.
So given SCHED_PRI_TICKS() of 159, you end up with 152 + 159 = 311, and
since your nice is 0, SCHED_PRI_NICE() ends up being 20, hence 331. It
seems the largets value SCHED_PRI_TICKS() should ever generate is
(PRI_BATCH_RANGE - SCHED_PRI_NRESV), though ULE doesn't quite compute it
that way (it might be off by one):
#define SCHED_PRI_NRESV (PRIO_MAX - PRIO_MIN)
#define SCHED_PRI_NHALF (SCHED_PRI_NRESV / 2)
#define SCHED_PRI_MIN (PRI_MIN_BATCH + SCHED_PRI_NHALF)
#define SCHED_PRI_MAX (PRI_MAX_BATCH - SCHED_PRI_NHALF)
#define SCHED_PRI_RANGE (SCHED_PRI_MAX - SCHED_PRI_MIN + 1)
However, it's not clear that SCHED_PRI_TICKS() will cap its value to
SCHED_PRI_RANGE:
#define SCHED_PRI_TICKS(ts) \
(SCHED_TICK_HZ((ts)) / \
(roundup(SCHED_TICK_TOTAL((ts)), SCHED_PRI_RANGE) / SCHED_PRI_RANGE))
The sloppiest fix might be to do this:
Index: sched_ule.c
===
--- sched_ule.c (revision 228777)
+++ sched_ule.c (working copy)
@@ -1434,7 +1434,8 @@ sched_priority(struct thread *td)
} else {
pri = SCHED_PRI_MIN;
if (td-td_sched-ts_ticks)
- pri += SCHED_PRI_TICKS(td-td_sched);
+ pri += min(SCHED_PRI_TICKS(td-td_sched),
+ SCHED_PRI_RANGE);
pri += SCHED_PRI_NICE(td-td_proc-p_nice);
KASSERT(pri = PRI_MIN_BATCH pri = PRI_MAX_BATCH,
(sched_priority: invalid priority %d: nice %d,
--
John Baldwin
___
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
FreeBSD funding [was: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1] Server
I have slightly reordered your email in my reply, in order to put the most important item last. On Fri, Dec 23, 2011 at 12:01:33PM +0100, O. Hartmann wrote: I'm still with the system, although I desperately need scientific grade compilers or GPGPU support. Your use-case, while valid, is clearly not the use-case that most of the committers working on FreeBSD face. But see below. And, I dare to put some critics herein! Since I see that FreeBSD is free, why not trying to make it better and more towards perfect? Everyone wants the product to improve. The question is, what is achievable with the current committers? That's where you see the pushback and frustration from the current committers. Look at FreeBSD and the problem of how well sysctls and their working are documented. It needs to be fixed. There's no argument that some of the FreeBSD documentation is stale. We do, however, have one committer (eadler@) who has been trying to move the sysctl documentation forwards. Participation from the wider community is key. Although sending PRs does not guarantee things will get fixed, it's currently the best way that we have. Well, as far as I know, the FreeBSD project is funding people doing a certain work! So, the implied opposite, FreeBSD is developed free isn't true. So here's the key point of your email IMHO, and the key misunderstanding. First, let me nit-pick the legalities. The FreeBSD Foundation (http://www.freebsdfoundation.org/) is a US non-profit that does fund some activities, and that's what I'll talk about here. The FreeBSD Project is the collective term for all of the committers and developers and is not an entity for US legal purposes. Second, the disclaimers: I am not a member of the FreeBSD Foundation Board of Directors, so I am not speaking for them. I have also directly benefited from Foundation funding (both travel, and via equipment they bought for portmgr), so am hardly unbiased. Now on to the gist of that matter. As a US non-profit, the Foundation is required to post its financial information to the public, and it does on its website: http://www.freebsdfoundation.org/documents/Budget2011.pdf You'll see here that the total budget for 2011 is $400k (USD). This, frankly, is miniscule. The largest line item for 2011 is $125k for project funding, which has gone towards 9 different projects (see http://www.freebsdfoundation.org/activities.shtml). For comparison, keep in mind that a commercial developers' salary in the US is upwards of $100k/yr. Even with this being a substantial increase from 2010's $83k, these numbers are tiny comared to real-world budgets. The projects that were sponsored were primarily networking-related, but also the GEM/KMS/DRI project, jails, the libc++ replacement, and clocks. I've listed those in the order that I think the most consumers of FreeBSD will be affected by. Note the absence of any work towards performance, schedulers, compilers, or numerical analysis. With a $125k budget, you're simply not going to see those on the list. The other notable line items are: hardware purchases (explicit disclaimer: portmgr has been one of the primary beneficiaries); conference sponsorship; conference travel; and salary for one employee to try to help coordinate all the above. Legal fees (things involving trademarking and licensing issues) takes up most of the remaining. I can't figure out the Linux Foundation's budget from their website, but I can tell immediately that their budget is a great many times more than $400k. Summary: on a fraction of the budget that Linux has available, we _nearly keep up_. I can't imagine what we could do with comparable funding. So, for everyone who thinks we are being well funded, here's your reality check. And please note that the Foundation is in its year-end fund drive, too. Thanks for listening. mcl ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote: On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: On 12/21/11 19:41, Alexander Leidinger wrote: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one- word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. Eh, normal make variables can go in src.conf as well. They do not have to be listed in bsd.own.mk. World builds include /etc/src.conf whereas every make invocation includes /etc/make.conf via sys.mk. The only reason to use /etc/src.conf is to have a place to put variables only affect make buildworld / buildkernel but do not affect other make invocations. Also, MALLOC_PRODUCTION is generally enabled in a stable branch as part of making the stable branch, there should be no need to set it manually in a stable branch. -- John Baldwin ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23.12.11 16:47, Martin Sugioarto wrote: I thought that the D in FreeBSD stands for distribution. Yes, it's ok that it compiles with LLVM. Does it also run faster in benchmarks? It does. From a language perspective. It is a distribution, because at the times BSD was developed, it was not a complete operating system. It was supposed to be added to say ATT System V to make it networking capable etc. The Linux people use the word distribution in a different context. I don't want to have everything compiled on $COMPILER. I want that there is a reasonable quality. And for me quality is not only stability, but also speed. You can always have faster algorithm if it is not necessary to produce the right answer. But if you don't tweak, you get a fair result in a benchmark. This is what you will see as a user of the system. These are the default settings, that means developers chose them as the BEST choice for the system. Developers are not Gods. Developers have no clue on what system and for what purpose you will use the software. All they may do for you is to provide enough knobs for you to tune your system for your hardware/application and also make sure that the system scales, when you turn the knobs. Daniel ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Fri, Dec 23, 2011 at 10:00:05AM -0500, John Baldwin wrote:
On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote:
On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote:
On 12/21/11 19:41, Alexander Leidinger wrote:
Hi,
while the discussion continued here, some work started at some other
place. Now... in case someone here is willing to help instead of talking,
feel
free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what
can
be improved. The page is far from perfect and needs some additional people
which are willing to improve it.
This is only part of the problem. A tuning page in the wiki - which
could be referenced from the benchmark page - would be great too. Any
volunteers? A first step would be to take he tuning-man-page and wikify it.
Other tuning sources are welcome too.
Every FreeBSD dev with a wiki account can hand out write access to the
wiki. The benchmark page gives contributor-access. If someone wants write
access create a FirstnameLastname account and ask here for contributor-access.
Don't worry if you think your english is not good enough, even some one-
word notes can help (and _my_ english got already corrected by other people
on
the benchmark page).
Bye,
Alexander.
Nice to see movement ;-)
But there seems something unclear:
man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in
/etc/make.conf.
The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf.
What's right and what's wrong now?
I can say with certainty that this value belongs in /etc/make.conf
(on RELENG_8 and earlier at least).
src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION,
so, this is definitely a make.conf variable.
Eh, normal make variables can go in src.conf as well. They do not have
to be listed in bsd.own.mk. World builds include /etc/src.conf whereas
every make invocation includes /etc/make.conf via sys.mk. The only reason
to use /etc/src.conf is to have a place to put variables only affect
make buildworld / buildkernel but do not affect other make invocations.
I was always under the impression src.conf(5) variables had to be
manually added to bsd.own.mk and similar bits (e.g.
src/tools/build/options/WITH_xxx which is what's used to create the
src.conf(5) man page), but upon your comment and manual investigation on
my part, I found you're indeed right. Taken from bsd.own.mk:
107 .if !defined(_WITHOUT_SRCCONF)
108 SRCCONF?= /etc/src.conf
109 .if exists(${SRCCONF})
110 .include ${SRCCONF}
111 .endif
112 .endif
As long as third-party software doesn't depend on MALLOC_PRODUCTION for
something (I don't know why something would, but who knows; maybe
there's a third-party malloc implementation which might?), then putting
it in src.conf would be fine (src/lib/libc/stdlib files reference it).
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/23/11 15:47, Martin Sugioarto wrote: Am Fri, 23 Dec 2011 11:18:03 +0200 schrieb Daniel Kalchev dan...@digsys.bg: The -RELEASE things is just a freeze (or, let's say tested freeze) of the corresponding branch at some time. It is the code available and tested at that time. Hi Daniel, obviously performance is not a quality aspect, only stability. FreeBSD is not a distribution. It also compiles with the latest compiler - LLVM. :) I thought that the D in FreeBSD stands for distribution. Yes, it's ok that it compiles with LLVM. Does it also run faster in benchmarks? I find it amusing, that people want everything compiled with GCC 4.7, which is still very much developing, therefore highly unstable and (probably) full of bugs. When you don't use the software don't complain that it is buggy, because you won't find the bugs. You cannot always tell the others to make everything perfect. As with GCC4.7, CLANG/LLVM is still considered experimental and definitely has some issues with CPU architectures beyond Core2. Personally, I compile everthing now with CLANG on FreeBSD 9.0/10.0 as far as I don't realise any conerns towards correctness and stability. Well, the GCC 4.7 came somewhere up and I picked it up, sorry. It is much easier to replace gcc 4.7 in this thread by 4.6.2, which is now considered stable and in production. And as some of the writers in this thread mentioned, the performance gain could be enormous since gcc 4.6 does support either core i7 architectures and its new facilities, the optimizer is aware of the core/uncore design an, maybe, of the three-folded cache levels. Is the legacy gcc 4.2 aware of that? I guess not, since it does not support architectures beyond Core2. I tried using gcc 4.6.2 from ports to compile world, but I failed. Simply replacing/setting CC, CXX and CPP isn't obviosuly enough. I don't want to have everything compiled on $COMPILER. I want that there is a reasonable quality. And for me quality is not only stability, but also speed. Yes, agree. I think quality could inherit also a reasonable speed. Speed at all costs, even stability, is no option. Even for HPC systems, where jobs run uninetrupted for weeks or months (in our case). Many suggested that the Linux binaries be run via the FreeBSD Linux emulation. Unchanged. There is one problem here though, the emulation is still 32 bit. With the usage of even 32bit Linux binaries you introduce all the mess you want to avoid by using FreeBSD. But it is very often recommended to use the so called Linuxulator. I'm happy to have this opportunity (I can not run FreeBSD binaries on some Ubuntu or Centos distros). But in some cases people of the FreeBSD community rely to much on this 32bit-limited option. I always prefer native BLOBs over emulated BLOBs. I'm not talking about emulation. I don't use FreeBSD to run emulated binaries. I (any many people) want efficient servers and eventually desktops. You should not expect people to tune the system for speed, when it's clear that default setting does not make any sense. People will use default settings, because they trust developers that they thought about balanced stability, security and performance. FreeBSD has safe default. This is what I am talking about. Don't complain that the benchmark does not show efficience. No one is interested in tuning FreeBSD just for a benchmark application. It is supposed to work out of the box on whatever hardware you put it. As much as it has drives for that hardware, of course. Once you have working installation, you may tweak it all the way you wish. But if you don't tweak, you get a fair result in a benchmark. This is what you will see as a user of the system. These are the default settings, that means developers chose them as the BEST choice for the system. Well, it is a very nice moce to have conservative settings to make FreeBSD stable for everyone intend to use it out of the box. But what I really miss is a certain, group of people dedicated to HPC and secure, stable tweak achieving that. The operating system is a nature and live. It is a balance of a limited resource. One can try to balance out every potential workload that can occur and the result is a very good allround syste, But in the server or HPC area, it might be necessary to push some parts in favor of some others. When computing, I do not need high USB performance, except a responsive keyboard. I/O and CPU performance is the main goal, but this seems the most difficult part. A file or network server, for instance, would balance more towards network I/O or delivering small data pieces instead of large streaming blocks of memory. I'm certain that the tweaks would differ for both scenarios. At home or at the desktop, the situation is more complicated, since people tend to use a lot of multimedia stuff and jumping audio is also not a very pleasant thing as stuck video. If your installation is
Re: [patch] Cleaning up amd64 kernel optimization options
On Fri Dec 23 11, John Baldwin wrote: On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote: On Dec 22, 2011, at 4:59 PM, Alexander Best arun...@freebsd.org wrote: On Thu Dec 22 11, Benjamin Kaduk wrote: On Thu, 22 Dec 2011, Alexander Best wrote: On Thu Dec 22 11, Dimitry Andric wrote: Hi, I would like to ask some feedback on the attached patch, which cleans up the kernel optimization options for amd64. This was touched upon earlier by Alexander Best in freebsd-toolchain, here: i've been using such settings for a few months now and haven't noticed any problems. however bruce evans raised a good point (in a private mail). when you compile a kernel without debugging enabled, -O2 is the default. if you experience issues, and enable debugging, -O0 now becomes the default. in case the problems with the kernel were caused by the -O2 option and aren't present with the -O0 option, the newly built kernel with debugging enabled will not help you fix the problems. in that case you would need to set -O2 explicitly in CFLAGS. his exact words were: I don't like -O2 for anything. However, if it is only a default, it is not a problem provided it can be canceled easily. And for debugging, you want the default to be the same as without debugging, so that (by default) you debug the same code that caused the problem. however i don't think this is fixable. using -O0 for debuggable and non-debuggable kernels will cause too much of a slowdown. having -O2 as the default flag for non-debuggable kernels and -O2 -g for debuggable kernels might cause situations, where debugging isn't possible, where with -O0 -g it would have been. so i guess although bruces concerns are valid, they are impossible to solve. Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. sorry. of course i meant -O: .if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g .else [..] Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. I still leave -O2 in, but what I do is this: make DEBUG_FLAGS=-g -fno-inline would making -O2 -fno-inline the default flags introduce any major slowdown? all that would be needed then to build a debugging kernel would be to add -g. cheers. alex Just adding -fno-inline makes a world of difference. -- John Baldwin ___ 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: scheduler panic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/23/2011 8:54 AM, John Baldwin wrote:
The sloppiest fix might be to do this:
Index: sched_ule.c
===
- --- sched_ule.c (revision 228777)
+++ sched_ule.c (working copy) @@ -1434,7 +1434,8 @@
sched_priority(struct thread *td) } else { pri = SCHED_PRI_MIN; if
(td-td_sched-ts_ticks) -pri +=
SCHED_PRI_TICKS(td-td_sched);
+ pri += min(SCHED_PRI_TICKS(td-td_sched), +
SCHED_PRI_RANGE); pri += SCHED_PRI_NICE(td-td_proc-p_nice);
KASSERT(pri = PRI_MIN_BATCH pri = PRI_MAX_BATCH,
(sched_priority: invalid priority %d: nice %d,
I've applied this to both the host and the guest, and am recompiling
the guest kernel (hopefully it'll stay up long enough...).
I'll report back.
Do y'all (FreeBSD Devs) want a PR?
- --
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO9K9cAAoJENC8dtAvA1zmruAIAL0udaYatGWp5E/Th9YYD8Hh
FHVri/G/Va8YsivqfZLFYUZd8SyqO/0vxEIoG73iKJJmjW/CpYIjgOvCRvsCrefm
ABOYmRX0dvC8GLHDgN9XFt4J9GmNTDcneNV7rOvWKisygkHw0GlK5DxKtSo3PsE8
6MQSnUuVmUMggsVQfBUiPTyTmJigcJ9KuEdfbHQ2o7+sCWx+gAKCyfVFcwkNIrYv
M7j21dJ8hjHUteHZ3YttVjYku0/YISSmtvGVCMlm2xBGD+tTu5g2ZcqZsxzlRFst
HyLGDP3mKSQJRMHcvl+OXMmwnFO7m31fLhj04LIWardV93S3CYF0c54LNEHYEN4=
=/imM
-END PGP SIGNATURE-
___
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] Cleaning up amd64 kernel optimization options
On 2011-12-23 17:00, Alexander Best wrote: ... Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. I still leave -O2 in, but what I do is this: make DEBUG_FLAGS=-g -fno-inline would making -O2 -fno-inline the default flags introduce any major slowdown? Not major, but a minor slowdown is quite possible, especially on arches like x86, where call overhead is relatively high, and code caches are relatively large. Anyway, I'd rather get the thread back to my original patch instead of messing around with the default flags for release, which have been -O2 for a long time now. If people want to override those for specific reasons, they can always set COPTFLAGS or DEBUG_FLAGS manually, like John shows. The only thing my patch makes sure of, is that amd64 does the same thing as all other arches, e.g.: compile with a low optimization settings for debug (-O, which is equivalent to -O1), compile with arch-specific high optimization settings for release (-O2 plus whatever is required for the arch, or lower if optimization breaks things). ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/23/11 16:24, Jeremy Chadwick wrote:
On Fri, Dec 23, 2011 at 10:00:05AM -0500, John Baldwin wrote:
On Thursday, December 22, 2011 6:58:46 pm Jeremy Chadwick wrote:
On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote:
On 12/21/11 19:41, Alexander Leidinger wrote:
Hi,
while the discussion continued here, some work started at some other
place. Now... in case someone here is willing to help instead of talking,
feel
free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what
can
be improved. The page is far from perfect and needs some additional people
which are willing to improve it.
This is only part of the problem. A tuning page in the wiki - which
could be referenced from the benchmark page - would be great too. Any
volunteers? A first step would be to take he tuning-man-page and wikify it.
Other tuning sources are welcome too.
Every FreeBSD dev with a wiki account can hand out write access to the
wiki. The benchmark page gives contributor-access. If someone wants write
access create a FirstnameLastname account and ask here for
contributor-access.
Don't worry if you think your english is not good enough, even some one-
word notes can help (and _my_ english got already corrected by other people
on
the benchmark page).
Bye,
Alexander.
Nice to see movement ;-)
But there seems something unclear:
man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in
/etc/make.conf.
The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf.
What's right and what's wrong now?
I can say with certainty that this value belongs in /etc/make.conf
(on RELENG_8 and earlier at least).
src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION,
so, this is definitely a make.conf variable.
Eh, normal make variables can go in src.conf as well. They do not have
to be listed in bsd.own.mk. World builds include /etc/src.conf whereas
every make invocation includes /etc/make.conf via sys.mk. The only reason
to use /etc/src.conf is to have a place to put variables only affect
make buildworld / buildkernel but do not affect other make invocations.
I was always under the impression src.conf(5) variables had to be
manually added to bsd.own.mk and similar bits (e.g.
src/tools/build/options/WITH_xxx which is what's used to create the
src.conf(5) man page), but upon your comment and manual investigation on
my part, I found you're indeed right. Taken from bsd.own.mk:
107 .if !defined(_WITHOUT_SRCCONF)
108 SRCCONF?= /etc/src.conf
109 .if exists(${SRCCONF})
110 .include ${SRCCONF}
111 .endif
112 .endif
As long as third-party software doesn't depend on MALLOC_PRODUCTION for
something (I don't know why something would, but who knows; maybe
there's a third-party malloc implementation which might?), then putting
it in src.conf would be fine (src/lib/libc/stdlib files reference it).
Then the manpage should reflect this. man src.conf does not show up
MALLOC_PRODUCTIOn, but man make.conf does. If the latter is right, then
it should be worth mentioned that make.conf is incorporating src.conf.
Just a suggestion.
Regards,
Oliver
signature.asc
Description: OpenPGP digital signature
Re: [patch] Cleaning up amd64 kernel optimization options
On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: On 2011-12-23 17:00, Alexander Best wrote: ... Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. I still leave -O2 in, but what I do is this: make DEBUG_FLAGS=-g -fno-inline would making -O2 -fno-inline the default flags introduce any major slowdown? Not major, but a minor slowdown is quite possible, especially on arches like x86, where call overhead is relatively high, and code caches are relatively large. Anyway, I'd rather get the thread back to my original patch instead of messing around with the default flags for release, which have been -O2 for a long time now. If people want to override those for specific reasons, they can always set COPTFLAGS or DEBUG_FLAGS manually, like John shows. The only thing my patch makes sure of, is that amd64 does the same thing as all other arches, e.g.: compile with a low optimization settings for debug (-O, which is equivalent to -O1), compile with arch-specific high optimization settings for release (-O2 plus whatever is required for the arch, or lower if optimization breaks things). Release is built with -g for long time, this is where the symbol files in /boot/kernel comes from. pgp5KdmN3MSqu.pgp Description: PGP signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Hi, I think this thread has gone far, far off the rails. If you're able to provide some solid debugging or willing to put in the effort to provide said solid debugging, then great. The easier you can make it for someone to fix for you (whether they're a FreeBSD committer or otherwise) the more likely it'll be fixed. There's no-one notionally in charge and paid to look after the scheduler. This is the unfortunate truth. No amount of saying but but people are paid to do this! will fix that particular point. The way that 99% of FreeBSD work gets done is when someone (who is a committer or otherwise) gets angry at how something doesn't quite work for them, and they decide to go and do something about it. The only point where a committer needs be involved is when someone wants to push their code into upstream (to borrow a Linux-ism) FreeBSD. If you're able to setup KTR and drive it + schedgraph (just like Steve has) and run this on a workload that is _repeatedly_ broken for you, then you're immediately going to have a better chance at getting it fixed. Bonus points if you can run the same benchmark on 4BSD and ULE, reporting KTR + schedgraph traces for both. That is going to be _by far_ the most helpful thing anyone can do in this ridiculously overly-verbose thread. Come on guys/girls/fuzzy creatures, you want to fix the problem? Bitching about it won't help. Unless you're like me and have an interest in Linguistics and end up writing a flame war to code generator. Then we'll likely be fine. :) Adrian ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Hi, I think this thread has gone far, far off the rails. If you're able to provide some solid debugging or willing to put in the effort to provide said solid debugging, then great. The easier you can make it for someone to fix for you (whether they're a FreeBSD committer or otherwise) the more likely it'll be fixed. There's no-one notionally in charge and paid to look after the scheduler. This is the unfortunate truth. No amount of saying but but people are paid to do this! will fix that particular point. The way that 99% of FreeBSD work gets done is when someone (who is a committer or otherwise) gets angry at how something doesn't quite work for them, and they decide to go and do something about it. The only point where a committer needs be involved is when someone wants to push their code into upstream (to borrow a Linux-ism) FreeBSD. If you're able to setup KTR and drive it + schedgraph (just like Steve has) and run this on a workload that is _repeatedly_ broken for you, then you're immediately going to have a better chance at getting it fixed. Bonus points if you can run the same benchmark on 4BSD and ULE, reporting KTR + schedgraph traces for both. That is going to be _by far_ the most helpful thing anyone can do in this ridiculously overly-verbose thread. Come on guys/girls/fuzzy creatr ___ 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] Cleaning up amd64 kernel optimization options
On 2011-12-23 18:55, Kostik Belousov wrote: On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: ... The only thing my patch makes sure of, is that amd64 does the same thing as all other arches, e.g.: compile with a low optimization settings for debug (-O, which is equivalent to -O1), compile with arch-specific high optimization settings for release (-O2 plus whatever is required for the arch, or lower if optimization breaks things). Release is built with -g for long time, this is where the symbol files in /boot/kernel comes from. Ah, that is done via 'makeoptions DEBUG=-g' in the kernel configuration file, right? I didn't realize that was kept in for a release. But even in that case, amd64 is somehow different from the other arches, which all get compiled with -O instead. If people prefer that to stay as it is, I'll change the diff so only -frename-registers gets removed when clang is used, as clang does not support this flag. ___ 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] Cleaning up amd64 kernel optimization options
On Fri Dec 23 11, Dimitry Andric wrote: On 2011-12-23 18:55, Kostik Belousov wrote: On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: ... The only thing my patch makes sure of, is that amd64 does the same thing as all other arches, e.g.: compile with a low optimization settings for debug (-O, which is equivalent to -O1), compile with arch-specific high optimization settings for release (-O2 plus whatever is required for the arch, or lower if optimization breaks things). Release is built with -g for long time, this is where the symbol files in /boot/kernel comes from. Ah, that is done via 'makeoptions DEBUG=-g' in the kernel configuration file, right? I didn't realize that was kept in for a release. But even in that case, amd64 is somehow different from the other arches, which all get compiled with -O instead. If people prefer that to stay as it is, I'll change the diff so only -frename-registers gets removed when clang is used, as clang does not support this flag. i think you should go ahead with the changes: 1) get amd64 in line with the other archs when debugging was requested (turning the default optimisation from -O2 to -O) 2) only specify -frename-registers on amd64, when gcc is the requested compiler i'd say: commit it. :) ...sorry we got carried away, but optimisation flags tend to trigger a lot of discussion. ;) cheers. alex ___ 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] Cleaning up amd64 kernel optimization options
On Fri, Dec 23, 2011 at 08:04:32PM +0100, Dimitry Andric wrote: On 2011-12-23 18:55, Kostik Belousov wrote: On Fri, Dec 23, 2011 at 06:03:42PM +0100, Dimitry Andric wrote: ... The only thing my patch makes sure of, is that amd64 does the same thing as all other arches, e.g.: compile with a low optimization settings for debug (-O, which is equivalent to -O1), compile with arch-specific high optimization settings for release (-O2 plus whatever is required for the arch, or lower if optimization breaks things). Release is built with -g for long time, this is where the symbol files in /boot/kernel comes from. Ah, that is done via 'makeoptions DEBUG=-g' in the kernel configuration file, right? I didn't realize that was kept in for a release. But even in that case, amd64 is somehow different from the other arches, which all get compiled with -O instead. Yes. If people prefer that to stay as it is, I'll change the diff so only -frename-registers gets removed when clang is used, as clang does not support this flag. This question cannot be answered without measurement. I think that even the 'default' benchmark of buildworld over -O and -O2 kernels can be useful to continue the discussion. pgpCNEdA1st9j.pgp Description: PGP signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Fri, Dec 23, 2011 at 2:38 AM, Vincent Hoffman vi...@unsane.co.uk wrote: On 23/12/2011 02:56, Garrett Cooper wrote: On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: On 12/21/11 19:41, Alexander Leidinger wrote: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. Take the advice in tuning(7) with a grain of salt because a number of suggestions are really outdated. I know because I filed a PR last night after I saw how out of synch some of the defaults it claimed were with reality on 9.x+. And I know other suggestions in the manpage are dated as well ;/. There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Sure. Please take my suggestions (apart from the networking sysctls) with a grain of salt as I didn't look at the sourcecode for the filesystem ones (I was going off the top of my head and other emails I had seen passed around). I'll update the tuning 'wiki' with mention of the new networking defaults. If we want to make this manpage 'timeless', should we remove mention of defaults and go off basic guidelines (if you set this higher, you'll get better performance in scenario, X.Y.Z, etc)? Thanks! -Garrett ___ 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 debug flags cleanup
On Thu, Dec 22, 2011 at 6:52 AM, Erik Cederstrand e...@cederstrand.dk wrote: Hi, I've created a patch that cleans up FreeBSD Makefiles that unconditionally set the -g flag for GCC. The motivation for this is that it should be possible to add or remove this flag globally via e.g. CFLAGS (it's part of my quest to produce deterministic builds). I'm not very familiar with GCC or the build infrastructure, so I'd be grateful if someone would review it and possibly commit. http://dev.affect-it.dk/gcc_debug_flags.diff Generally include your patches inline, it makes reviewing them easier. Index: sys/amd64/conf/GENERIC === --- sys/amd64/conf/GENERIC (revision 228312) +++ sys/amd64/conf/GENERIC (working copy) @@ -21,7 +21,7 @@ ... -makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols ... This is intentionally left in the config files. This is where the .symbols file comes from in /boot/kernel/. -- Eitan Adler ___ 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] allow local-tools to include local directories
Hi,
This patch allows for user-defined extra local tools directories, a la
what LOCAL_DIRS does for adding local build directories to the source.
This is needed for cross-compiling as some local tools may need to be
first built.
I've used this successfully to cross-compile my busybox stuff.
Thanks,
Adrian
--
[adrian@pcbsd-macvm] ~/work/freebsd/head/src svn diff Makefile.inc1
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 228757)
+++ Makefile.inc1 (working copy)
@@ -15,6 +15,8 @@
# -DNO_WWWUPDATE do not update www in ${MAKE} update
# -DNO_CTF do not run the DTrace CTF conversion tools on built objects
# LOCAL_DIRS=list of dirs to add additional dirs to the SUBDIR list
+# LOCAL_TOOL_DIRS=list of dirs to add additional dirs to the build-tools
+# list
# TARGET=machine to crossbuild world for a different machine type
# TARGET_ARCH= may be required when a TARGET supports multiple endians
@@ -104,6 +106,8 @@
CLEANDIR= cleandir
.endif
+LOCAL_TOOL_DIRS?= ''
+
CVS?= cvs
CVSFLAGS?= -A -P -d -I!
SVN?= svn
@@ -1102,6 +1106,7 @@
bin/csh \
bin/sh \
${_rescue} \
+${LOCAL_TOOL_DIRS} \
lib/ncurses/ncurses \
lib/ncurses/ncursesw \
${_share} \
___
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
[head tinderbox] failure on i386/i386
TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-12-23 19:00:00 - cleaning the object tree TB --- 2011-12-23 19:00:50 - cvsupping the source tree TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-12-23 19:06:15 - building world TB --- 2011-12-23 19:06:15 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 19:06:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 19:06:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 19:06:15 - SRCCONF=/dev/null TB --- 2011-12-23 19:06:15 - TARGET=i386 TB --- 2011-12-23 19:06:15 - TARGET_ARCH=i386 TB --- 2011-12-23 19:06:15 - TZ=UTC TB --- 2011-12-23 19:06:15 - __MAKE_CONF=/dev/null TB --- 2011-12-23 19:06:15 - cd /src TB --- 2011-12-23 19:06:15 - /usr/bin/make -B buildworld World build started on Fri Dec 23 19:06:16 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Dec 23 21:16:07 UTC 2011 TB --- 2011-12-23 21:16:07 - generating LINT kernel config TB --- 2011-12-23 21:16:07 - cd /src/sys/i386/conf TB --- 2011-12-23 21:16:07 - /usr/bin/make -B LINT TB --- 2011-12-23 21:16:07 - cd /src/sys/i386/conf TB --- 2011-12-23 21:16:07 - /usr/sbin/config -m LINT TB --- 2011-12-23 21:16:07 - building LINT kernel TB --- 2011-12-23 21:16:07 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 21:16:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 21:16:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 21:16:07 - SRCCONF=/dev/null TB --- 2011-12-23 21:16:07 - TARGET=i386 TB --- 2011-12-23 21:16:07 - TARGET_ARCH=i386 TB --- 2011-12-23 21:16:07 - TZ=UTC TB --- 2011-12-23 21:16:07 - __MAKE_CONF=/dev/null TB --- 2011-12-23 21:16:07 - cd /src TB --- 2011-12-23 21:16:07 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Dec 23 21:16:07 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri Dec 23 21:48:06 UTC 2011 TB --- 2011-12-23 21:48:06 - cd /src/sys/i386/conf TB --- 2011-12-23 21:48:06 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-23 21:48:06 - building LINT-NOINET kernel TB --- 2011-12-23 21:48:06 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 21:48:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 21:48:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 21:48:06 - SRCCONF=/dev/null TB --- 2011-12-23 21:48:06 - TARGET=i386 TB --- 2011-12-23 21:48:06 - TARGET_ARCH=i386 TB --- 2011-12-23 21:48:06 - TZ=UTC TB --- 2011-12-23 21:48:06 - __MAKE_CONF=/dev/null TB --- 2011-12-23 21:48:06 - cd /src TB --- 2011-12-23 21:48:06 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Fri Dec 23 21:48:06 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Fri Dec 23 22:18:26 UTC 2011 TB --- 2011-12-23 22:18:26 - cd /src/sys/i386/conf TB --- 2011-12-23 22:18:26 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-23 22:18:26 - building LINT-NOINET6 kernel TB --- 2011-12-23 22:18:26 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:18:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:18:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:18:26 - SRCCONF=/dev/null TB --- 2011-12-23 22:18:26 - TARGET=i386 TB --- 2011-12-23 22:18:26 - TARGET_ARCH=i386 TB --- 2011-12-23 22:18:26 - TZ=UTC TB --- 2011-12-23 22:18:26 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:18:26 - cd /src TB --- 2011-12-23 22:18:26 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Fri Dec 23 22:18:27 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Fri Dec 23 22:48:53 UTC 2011 TB --- 2011-12-23 22:48:53 - cd /src/sys/i386/conf TB --- 2011-12-23 22:48:53 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-23 22:48:53 - building LINT-NOIP kernel TB --- 2011-12-23 22:48:53 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:48:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:48:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:48:53 - SRCCONF=/dev/null TB --- 2011-12-23 22:48:53 - TARGET=i386 TB --- 2011-12-23 22:48:53 -
[head tinderbox] failure on amd64/amd64
TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-12-23 19:00:00 - cleaning the object tree TB --- 2011-12-23 19:00:50 - cvsupping the source tree TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-12-23 19:01:13 - building world TB --- 2011-12-23 19:01:13 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 19:01:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 19:01:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 19:01:13 - SRCCONF=/dev/null TB --- 2011-12-23 19:01:13 - TARGET=amd64 TB --- 2011-12-23 19:01:13 - TARGET_ARCH=amd64 TB --- 2011-12-23 19:01:13 - TZ=UTC TB --- 2011-12-23 19:01:13 - __MAKE_CONF=/dev/null TB --- 2011-12-23 19:01:13 - cd /src TB --- 2011-12-23 19:01:13 - /usr/bin/make -B buildworld World build started on Fri Dec 23 19:01:14 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Fri Dec 23 21:40:55 UTC 2011 TB --- 2011-12-23 21:40:55 - generating LINT kernel config TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 21:40:55 - /usr/bin/make -B LINT TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 21:40:55 - /usr/sbin/config -m LINT TB --- 2011-12-23 21:40:55 - building LINT kernel TB --- 2011-12-23 21:40:55 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 21:40:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 21:40:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 21:40:55 - SRCCONF=/dev/null TB --- 2011-12-23 21:40:55 - TARGET=amd64 TB --- 2011-12-23 21:40:55 - TARGET_ARCH=amd64 TB --- 2011-12-23 21:40:55 - TZ=UTC TB --- 2011-12-23 21:40:55 - __MAKE_CONF=/dev/null TB --- 2011-12-23 21:40:55 - cd /src TB --- 2011-12-23 21:40:55 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Dec 23 21:40:55 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri Dec 23 22:10:55 UTC 2011 TB --- 2011-12-23 22:10:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 22:10:55 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-23 22:10:56 - building LINT-NOINET kernel TB --- 2011-12-23 22:10:56 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:10:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:10:56 - SRCCONF=/dev/null TB --- 2011-12-23 22:10:56 - TARGET=amd64 TB --- 2011-12-23 22:10:56 - TARGET_ARCH=amd64 TB --- 2011-12-23 22:10:56 - TZ=UTC TB --- 2011-12-23 22:10:56 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:10:56 - cd /src TB --- 2011-12-23 22:10:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Fri Dec 23 22:10:56 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Fri Dec 23 22:39:01 UTC 2011 TB --- 2011-12-23 22:39:01 - cd /src/sys/amd64/conf TB --- 2011-12-23 22:39:01 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-23 22:39:01 - building LINT-NOINET6 kernel TB --- 2011-12-23 22:39:01 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:39:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:39:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:39:01 - SRCCONF=/dev/null TB --- 2011-12-23 22:39:01 - TARGET=amd64 TB --- 2011-12-23 22:39:01 - TARGET_ARCH=amd64 TB --- 2011-12-23 22:39:01 - TZ=UTC TB --- 2011-12-23 22:39:01 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:39:01 - cd /src TB --- 2011-12-23 22:39:01 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Fri Dec 23 22:39:01 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Fri Dec 23 23:08:33 UTC 2011 TB --- 2011-12-23 23:08:33 - cd /src/sys/amd64/conf TB --- 2011-12-23 23:08:33 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-23 23:08:33 - building LINT-NOIP kernel TB --- 2011-12-23 23:08:33 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 23:08:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 23:08:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 23:08:33 - SRCCONF=/dev/null TB ---
[rfc] removing -mpreferred-stack-boundary=2 flag for i386?
hi there, is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer? i built GENERIC (including modules) with and without that flag. the results are: 1654496 bytes with the flag set vs. 1654952 bytes with the flag unset the gcc(1) man page states the following: This extra alignment does consume extra stack space, and generally increases code size. Code that is sensitive to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to -mpreferred-stack-boundary=2. the comment in sys/conf/kern.mk however sorta suggests that the default alignment of 4 bytes might improve performance. cheers. alex ___ 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: [head tinderbox] failure on amd64/amd64
On 24 December 2011 03:39, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-12-23 19:00:00 - cleaning the object tree TB --- 2011-12-23 19:00:50 - cvsupping the source tree TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-12-23 19:01:13 - building world TB --- 2011-12-23 19:01:13 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 19:01:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 19:01:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 19:01:13 - SRCCONF=/dev/null TB --- 2011-12-23 19:01:13 - TARGET=amd64 TB --- 2011-12-23 19:01:13 - TARGET_ARCH=amd64 TB --- 2011-12-23 19:01:13 - TZ=UTC TB --- 2011-12-23 19:01:13 - __MAKE_CONF=/dev/null TB --- 2011-12-23 19:01:13 - cd /src TB --- 2011-12-23 19:01:13 - /usr/bin/make -B buildworld World build started on Fri Dec 23 19:01:14 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Fri Dec 23 21:40:55 UTC 2011 TB --- 2011-12-23 21:40:55 - generating LINT kernel config TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 21:40:55 - /usr/bin/make -B LINT TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 21:40:55 - /usr/sbin/config -m LINT TB --- 2011-12-23 21:40:55 - building LINT kernel TB --- 2011-12-23 21:40:55 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 21:40:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 21:40:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 21:40:55 - SRCCONF=/dev/null TB --- 2011-12-23 21:40:55 - TARGET=amd64 TB --- 2011-12-23 21:40:55 - TARGET_ARCH=amd64 TB --- 2011-12-23 21:40:55 - TZ=UTC TB --- 2011-12-23 21:40:55 - __MAKE_CONF=/dev/null TB --- 2011-12-23 21:40:55 - cd /src TB --- 2011-12-23 21:40:55 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Dec 23 21:40:55 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri Dec 23 22:10:55 UTC 2011 TB --- 2011-12-23 22:10:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 22:10:55 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-23 22:10:56 - building LINT-NOINET kernel TB --- 2011-12-23 22:10:56 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:10:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:10:56 - SRCCONF=/dev/null TB --- 2011-12-23 22:10:56 - TARGET=amd64 TB --- 2011-12-23 22:10:56 - TARGET_ARCH=amd64 TB --- 2011-12-23 22:10:56 - TZ=UTC TB --- 2011-12-23 22:10:56 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:10:56 - cd /src TB --- 2011-12-23 22:10:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Fri Dec 23 22:10:56 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Fri Dec 23 22:39:01 UTC 2011 TB --- 2011-12-23 22:39:01 - cd /src/sys/amd64/conf TB --- 2011-12-23 22:39:01 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-23 22:39:01 - building LINT-NOINET6 kernel TB --- 2011-12-23 22:39:01 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:39:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:39:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:39:01 - SRCCONF=/dev/null TB --- 2011-12-23 22:39:01 - TARGET=amd64 TB --- 2011-12-23 22:39:01 - TARGET_ARCH=amd64 TB --- 2011-12-23 22:39:01 - TZ=UTC TB --- 2011-12-23 22:39:01 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:39:01 - cd /src TB --- 2011-12-23 22:39:01 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Fri Dec 23 22:39:01 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Fri Dec 23 23:08:33 UTC 2011 TB --- 2011-12-23 23:08:33 - cd /src/sys/amd64/conf TB --- 2011-12-23 23:08:33 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-23 23:08:33 - building LINT-NOIP kernel TB --- 2011-12-23 23:08:33 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 23:08:33 -
Re: [head tinderbox] failure on amd64/amd64
On 24 December 2011 04:02, Sergey Kandaurov pluk...@gmail.com wrote: On 24 December 2011 03:39, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-12-23 19:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-23 19:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-12-23 19:00:00 - cleaning the object tree TB --- 2011-12-23 19:00:50 - cvsupping the source tree TB --- 2011-12-23 19:00:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-12-23 19:01:13 - building world TB --- 2011-12-23 19:01:13 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 19:01:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 19:01:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 19:01:13 - SRCCONF=/dev/null TB --- 2011-12-23 19:01:13 - TARGET=amd64 TB --- 2011-12-23 19:01:13 - TARGET_ARCH=amd64 TB --- 2011-12-23 19:01:13 - TZ=UTC TB --- 2011-12-23 19:01:13 - __MAKE_CONF=/dev/null TB --- 2011-12-23 19:01:13 - cd /src TB --- 2011-12-23 19:01:13 - /usr/bin/make -B buildworld World build started on Fri Dec 23 19:01:14 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Fri Dec 23 21:40:55 UTC 2011 TB --- 2011-12-23 21:40:55 - generating LINT kernel config TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 21:40:55 - /usr/bin/make -B LINT TB --- 2011-12-23 21:40:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 21:40:55 - /usr/sbin/config -m LINT TB --- 2011-12-23 21:40:55 - building LINT kernel TB --- 2011-12-23 21:40:55 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 21:40:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 21:40:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 21:40:55 - SRCCONF=/dev/null TB --- 2011-12-23 21:40:55 - TARGET=amd64 TB --- 2011-12-23 21:40:55 - TARGET_ARCH=amd64 TB --- 2011-12-23 21:40:55 - TZ=UTC TB --- 2011-12-23 21:40:55 - __MAKE_CONF=/dev/null TB --- 2011-12-23 21:40:55 - cd /src TB --- 2011-12-23 21:40:55 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Dec 23 21:40:55 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri Dec 23 22:10:55 UTC 2011 TB --- 2011-12-23 22:10:55 - cd /src/sys/amd64/conf TB --- 2011-12-23 22:10:55 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-23 22:10:56 - building LINT-NOINET kernel TB --- 2011-12-23 22:10:56 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:10:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:10:56 - SRCCONF=/dev/null TB --- 2011-12-23 22:10:56 - TARGET=amd64 TB --- 2011-12-23 22:10:56 - TARGET_ARCH=amd64 TB --- 2011-12-23 22:10:56 - TZ=UTC TB --- 2011-12-23 22:10:56 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:10:56 - cd /src TB --- 2011-12-23 22:10:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Fri Dec 23 22:10:56 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Fri Dec 23 22:39:01 UTC 2011 TB --- 2011-12-23 22:39:01 - cd /src/sys/amd64/conf TB --- 2011-12-23 22:39:01 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-23 22:39:01 - building LINT-NOINET6 kernel TB --- 2011-12-23 22:39:01 - CROSS_BUILD_TESTING=YES TB --- 2011-12-23 22:39:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-23 22:39:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-23 22:39:01 - SRCCONF=/dev/null TB --- 2011-12-23 22:39:01 - TARGET=amd64 TB --- 2011-12-23 22:39:01 - TARGET_ARCH=amd64 TB --- 2011-12-23 22:39:01 - TZ=UTC TB --- 2011-12-23 22:39:01 - __MAKE_CONF=/dev/null TB --- 2011-12-23 22:39:01 - cd /src TB --- 2011-12-23 22:39:01 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Fri Dec 23 22:39:01 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Fri Dec 23 23:08:33 UTC 2011 TB --- 2011-12-23 23:08:33 - cd /src/sys/amd64/conf TB --- 2011-12-23 23:08:33 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-23 23:08:33 - building LINT-NOIP kernel TB ---
[patch] bsdbox changes for base system: add LOCAL_
Hi,
Here are two patches which implement some useful features for crunch building:
* Add LOCAL_TOOLS_DIR in src/Makefile.inc1, which adds entries to the
'build-tools' target. This is needed for cross-building bsdbox (and
any external directory added by LOCAL_DIRS)
* If CRUNCH_SUPPRESS_ALL_LINKS is set to 'yes', don't auto-populate
the crunch-gen hard links.
I may end up changing the latter to CRUNCH_GENERATE_LINKS and default
that to yes, then allow the bsdbox build system to change that to
'no', but the intent is the same.
I'd like to commit this tomorrow if possible, so I can then follow it
up with the bsdbox import.
Thanks,
Adrian
[adrian@pcbsd-macvm] ~/work/freebsd/head/src svn diff Makefile.inc1 share/mk
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 228757)
+++ Makefile.inc1 (working copy)
@@ -15,6 +15,8 @@
# -DNO_WWWUPDATE do not update www in ${MAKE} update
# -DNO_CTF do not run the DTrace CTF conversion tools on built objects
# LOCAL_DIRS=list of dirs to add additional dirs to the SUBDIR list
+# LOCAL_TOOL_DIRS=list of dirs to add additional dirs to the build-tools
+# list
# TARGET=machine to crossbuild world for a different machine type
# TARGET_ARCH= may be required when a TARGET supports multiple endians
@@ -104,6 +106,8 @@
CLEANDIR= cleandir
.endif
+LOCAL_TOOL_DIRS?= ''
+
CVS?= cvs
CVSFLAGS?= -A -P -d -I!
SVN?= svn
@@ -1102,6 +1106,7 @@
bin/csh \
bin/sh \
${_rescue} \
+${LOCAL_TOOL_DIRS} \
lib/ncurses/ncurses \
lib/ncurses/ncursesw \
${_share} \
Index: share/mk/bsd.crunchgen.mk
===
--- share/mk/bsd.crunchgen.mk (revision 228757)
+++ share/mk/bsd.crunchgen.mk (working copy)
@@ -22,6 +22,8 @@
# Specific links can be suppressed by setting
# CRUNCH_SUPPRESS_LINK_$(NAME) to 1.
#
+# If CRUNCH_SUPPRESS_ALL_LINKS is set to yes, no links will be generated.
+#
# $FreeBSD$
@@ -39,6 +41,7 @@
.else
CANONICALOBJDIR:= /usr/obj${.CURDIR}
.endif
+CRUNCH_SUPPRESS_ALL_LINKS?=no
CLEANFILES+= $(CONF) *.o *.lo *.c *.mk *.cache *.a *.h
@@ -51,6 +54,7 @@
.else
$(OUTPUTS): $(.CURDIR)/../../$(D)/$(P)/Makefile
.endif
+.if ${CRUNCH_SUPPRESS_ALL_LINKS} != yes
.ifndef CRUNCH_SUPPRESS_LINK_${P}
LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(P)
.endif
@@ -59,6 +63,7 @@
LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(A)
.endif
.endfor
+.endif
.endfor
.endfor
___
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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23/12/2011 20:23, Garrett Cooper wrote: On Fri, Dec 23, 2011 at 2:38 AM, Vincent Hoffman vi...@unsane.co.uk wrote: On 23/12/2011 02:56, Garrett Cooper wrote: snip There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Sure. Please take my suggestions (apart from the networking sysctls) with a grain of salt as I didn't look at the sourcecode for the filesystem ones (I was going off the top of my head and other emails I had seen passed around). I'll update the tuning 'wiki' with mention of the new networking defaults. If we want to make this manpage 'timeless', should we remove mention of defaults and go off basic guidelines (if you set this higher, you'll get better performance in scenario, X.Y.Z, etc)? Thanks! -Garrett Good point, for tuning the defaults are probably not so important as they are likely to change at some point (as the current man page will attest) so maybe its less important to document them. Happy Christmas (or holiday of your choice ;) to you all and I hope everyone has a good new year. Vince ___ 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 ___ 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 debug flags cleanup
On Thu, 22 Dec 2011 12:52:45 +0100 Erik Cederstrand e...@cederstrand.dk wrote: Hi, I've created a patch that cleans up FreeBSD Makefiles that unconditionally set the -g flag for GCC. The motivation for this is that it should be possible to add or remove this flag globally via e.g. CFLAGS (it's part of my quest to produce deterministic builds). I'm not very familiar with GCC or the build infrastructure, so I'd be grateful if someone would review it and possibly commit. http://dev.affect-it.dk/gcc_debug_flags.diff Thanks, Erik___ gnu/usr.bin/cc/cc_tools/Makefile just builds tools that are used for building gcc itself and are non installed anywhere outside of $OBJDIR. I doubt disabling -g there buys you much, but having it there is also of questionable value. Verdict: could not care less either way. All of the gcc/contrib changes are useless - we are not using any of stock Makefiles. sys/amd64/conf/GENERIC - please understang _why_ it is there before you remove it. When you do, you will probably will drop the idea. -- Alexander Kabaev signature.asc Description: PGP signature
[head tinderbox] failure on i386/i386
TB --- 2011-12-24 02:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-24 02:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-12-24 02:20:00 - cleaning the object tree TB --- 2011-12-24 02:20:52 - cvsupping the source tree TB --- 2011-12-24 02:20:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-12-24 02:21:06 - building world TB --- 2011-12-24 02:21:06 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 02:21:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 02:21:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 02:21:06 - SRCCONF=/dev/null TB --- 2011-12-24 02:21:06 - TARGET=i386 TB --- 2011-12-24 02:21:06 - TARGET_ARCH=i386 TB --- 2011-12-24 02:21:06 - TZ=UTC TB --- 2011-12-24 02:21:06 - __MAKE_CONF=/dev/null TB --- 2011-12-24 02:21:06 - cd /src TB --- 2011-12-24 02:21:06 - /usr/bin/make -B buildworld World build started on Sat Dec 24 02:21:06 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sat Dec 24 04:27:27 UTC 2011 TB --- 2011-12-24 04:27:27 - generating LINT kernel config TB --- 2011-12-24 04:27:27 - cd /src/sys/i386/conf TB --- 2011-12-24 04:27:27 - /usr/bin/make -B LINT TB --- 2011-12-24 04:27:27 - cd /src/sys/i386/conf TB --- 2011-12-24 04:27:27 - /usr/sbin/config -m LINT TB --- 2011-12-24 04:27:27 - building LINT kernel TB --- 2011-12-24 04:27:27 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 04:27:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 04:27:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 04:27:27 - SRCCONF=/dev/null TB --- 2011-12-24 04:27:27 - TARGET=i386 TB --- 2011-12-24 04:27:27 - TARGET_ARCH=i386 TB --- 2011-12-24 04:27:27 - TZ=UTC TB --- 2011-12-24 04:27:27 - __MAKE_CONF=/dev/null TB --- 2011-12-24 04:27:27 - cd /src TB --- 2011-12-24 04:27:27 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Dec 24 04:27:27 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Sat Dec 24 04:58:20 UTC 2011 TB --- 2011-12-24 04:58:20 - cd /src/sys/i386/conf TB --- 2011-12-24 04:58:20 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-24 04:58:20 - building LINT-NOINET kernel TB --- 2011-12-24 04:58:20 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 04:58:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 04:58:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 04:58:20 - SRCCONF=/dev/null TB --- 2011-12-24 04:58:20 - TARGET=i386 TB --- 2011-12-24 04:58:20 - TARGET_ARCH=i386 TB --- 2011-12-24 04:58:20 - TZ=UTC TB --- 2011-12-24 04:58:20 - __MAKE_CONF=/dev/null TB --- 2011-12-24 04:58:20 - cd /src TB --- 2011-12-24 04:58:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Sat Dec 24 04:58:20 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Sat Dec 24 05:27:39 UTC 2011 TB --- 2011-12-24 05:27:39 - cd /src/sys/i386/conf TB --- 2011-12-24 05:27:39 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-24 05:27:39 - building LINT-NOINET6 kernel TB --- 2011-12-24 05:27:39 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 05:27:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 05:27:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 05:27:39 - SRCCONF=/dev/null TB --- 2011-12-24 05:27:39 - TARGET=i386 TB --- 2011-12-24 05:27:39 - TARGET_ARCH=i386 TB --- 2011-12-24 05:27:39 - TZ=UTC TB --- 2011-12-24 05:27:39 - __MAKE_CONF=/dev/null TB --- 2011-12-24 05:27:39 - cd /src TB --- 2011-12-24 05:27:39 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Sat Dec 24 05:27:39 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Sat Dec 24 05:57:37 UTC 2011 TB --- 2011-12-24 05:57:37 - cd /src/sys/i386/conf TB --- 2011-12-24 05:57:37 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-24 05:57:37 - building LINT-NOIP kernel TB --- 2011-12-24 05:57:38 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 05:57:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 05:57:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 05:57:38 - SRCCONF=/dev/null TB --- 2011-12-24 05:57:38 - TARGET=i386 TB --- 2011-12-24 05:57:38 -
Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386?
Well, the whole kernel is bloated at the moment, sorry. I've been trying to build the _bare minimum_ required to bootstrap -HEAD on these embedded boards and I can't get the kernel down below 5 megabytes - ie, one with FFS (with options disabled), MIPS, INET (no INET6), net80211, ath (which admittedly is big, but I need it no matter what, right?) comes in at: -r-xr-xr-x 1 root wheel 5307021 Nov 29 19:14 kernel.LSSR71 And with INET6, on another board (and this includes MSDOS and the relevant geom modules): -r-xr-xr-x 1 root wheel 5916759 Nov 28 12:00 kernel.RSPRO .. honestly, that's what should be addressed. That's honestly a bit ridiculous. 2c, Adrian ___ 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
[head tinderbox] failure on amd64/amd64
TB --- 2011-12-24 02:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-24 02:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-12-24 02:20:00 - cleaning the object tree TB --- 2011-12-24 02:20:54 - cvsupping the source tree TB --- 2011-12-24 02:20:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-12-24 02:21:08 - building world TB --- 2011-12-24 02:21:08 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 02:21:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 02:21:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 02:21:08 - SRCCONF=/dev/null TB --- 2011-12-24 02:21:08 - TARGET=amd64 TB --- 2011-12-24 02:21:08 - TARGET_ARCH=amd64 TB --- 2011-12-24 02:21:08 - TZ=UTC TB --- 2011-12-24 02:21:08 - __MAKE_CONF=/dev/null TB --- 2011-12-24 02:21:08 - cd /src TB --- 2011-12-24 02:21:08 - /usr/bin/make -B buildworld World build started on Sat Dec 24 02:21:08 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Sat Dec 24 04:58:32 UTC 2011 TB --- 2011-12-24 04:58:32 - generating LINT kernel config TB --- 2011-12-24 04:58:32 - cd /src/sys/amd64/conf TB --- 2011-12-24 04:58:32 - /usr/bin/make -B LINT TB --- 2011-12-24 04:58:32 - cd /src/sys/amd64/conf TB --- 2011-12-24 04:58:32 - /usr/sbin/config -m LINT TB --- 2011-12-24 04:58:32 - building LINT kernel TB --- 2011-12-24 04:58:32 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 04:58:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 04:58:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 04:58:32 - SRCCONF=/dev/null TB --- 2011-12-24 04:58:32 - TARGET=amd64 TB --- 2011-12-24 04:58:32 - TARGET_ARCH=amd64 TB --- 2011-12-24 04:58:32 - TZ=UTC TB --- 2011-12-24 04:58:32 - __MAKE_CONF=/dev/null TB --- 2011-12-24 04:58:32 - cd /src TB --- 2011-12-24 04:58:32 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Dec 24 04:58:32 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Sat Dec 24 05:27:37 UTC 2011 TB --- 2011-12-24 05:27:37 - cd /src/sys/amd64/conf TB --- 2011-12-24 05:27:37 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-24 05:27:37 - building LINT-NOINET kernel TB --- 2011-12-24 05:27:37 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 05:27:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 05:27:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 05:27:37 - SRCCONF=/dev/null TB --- 2011-12-24 05:27:37 - TARGET=amd64 TB --- 2011-12-24 05:27:37 - TARGET_ARCH=amd64 TB --- 2011-12-24 05:27:37 - TZ=UTC TB --- 2011-12-24 05:27:37 - __MAKE_CONF=/dev/null TB --- 2011-12-24 05:27:37 - cd /src TB --- 2011-12-24 05:27:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Sat Dec 24 05:27:37 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Sat Dec 24 05:55:16 UTC 2011 TB --- 2011-12-24 05:55:16 - cd /src/sys/amd64/conf TB --- 2011-12-24 05:55:16 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-12-24 05:55:16 - building LINT-NOINET6 kernel TB --- 2011-12-24 05:55:16 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 05:55:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 05:55:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 05:55:16 - SRCCONF=/dev/null TB --- 2011-12-24 05:55:16 - TARGET=amd64 TB --- 2011-12-24 05:55:16 - TARGET_ARCH=amd64 TB --- 2011-12-24 05:55:16 - TZ=UTC TB --- 2011-12-24 05:55:16 - __MAKE_CONF=/dev/null TB --- 2011-12-24 05:55:16 - cd /src TB --- 2011-12-24 05:55:16 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Sat Dec 24 05:55:16 UTC 2011 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Sat Dec 24 06:23:37 UTC 2011 TB --- 2011-12-24 06:23:37 - cd /src/sys/amd64/conf TB --- 2011-12-24 06:23:37 - /usr/sbin/config -m LINT-NOIP TB --- 2011-12-24 06:23:37 - building LINT-NOIP kernel TB --- 2011-12-24 06:23:37 - CROSS_BUILD_TESTING=YES TB --- 2011-12-24 06:23:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-24 06:23:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-24 06:23:37 - SRCCONF=/dev/null TB ---
