Re: [okuno.ko...@jp.panasonic.com: about XHCI_PS_PP]
On Wednesday 14 December 2011 08:15:19 Joel Dahl wrote: Just in case you didn't see the message to current@ : - Forwarded message from Kohji Okuno okuno.ko...@jp.panasonic.com - Date: Wed, 14 Dec 2011 11:35:23 +0900 (JST) From: Kohji Okuno okuno.ko...@jp.panasonic.com To: freebsd-current@freebsd.org Subject: about XHCI_PS_PP X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Hi Selasky, Hi, Your fix is correct! http://svn.freebsd.org/changeset/base/228493 --HPS ___ 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: CVS removal from the base
From: Doug Barton do...@freebsd.org Having things in ports doesn't make them less available. :) From Julian H. Stacey j...@berklix.com It didn't used to. It risks it now, since in last months, some ports/ have been targeted by a few rogue commiters purging, who want to toss ports out from one release to another without warning of a DEPRECATED= in previous release Makefiles. From: Julian Elischer jul...@freebsd.org which brings up teh possibility of 1st class ports.. which are kept more as part of the system.. (sorry for sounding like a broken record..) Interesting idea, to bounce the idea around a bit: It would extend the spectrum to /usr/src/ ..Most.. /usr/src/ contrib 1st class ports ... in src or ports or elsewhere ? ... (if elsewhere, work to reconfig mirrors to. doc new struct later) /usr/ports currently 22906 An empty current ports tree takes 485 M ( a lot of inodes which occasionaly trips people). A current src tree takes 705 M Ports has lots of commiters Src has less partly different commiters stricter watched more release aligned. Maybe sometime we will see a project arise that will be a replacement ports/ for more than one BSD, perhaps even extending to Linux, (to avoid reinventing of the wheel that must go on with ports skeletal structs for each OS) ( maybe with an RFC for a port/ skeleton struct ? If so, that may have ramifications on bits of src moved to ports. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. EU tax to kill London Vetoed http://berklix.com/~jhs/blog/2011_12_11 ___ 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
dogfooding over in clusteradm land
We're seeing what looks like a syncher/ufs resource starvation on 9.0 on the cvs2svn ports conversion box. I'm not sure what resource is tapped out. Effectively, I cannot access the directory under use and the converter application stalls out waiting for some resource that isn't clear. (Peter had posited kmem of some kind). I've upped maxvnodes a bit on the host, turned off SUJ and mounted the f/s in question with async and noatime for performance reasons. Can someone hit me up with the cluebat? I can give you direct access to the box for debuginationing. Sean ___ 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: CVS removal from the base
On Wed, Dec 14, 2011 at 2:00 PM, Julian H. Stacey j...@berklix.com wrote: Maybe sometime we will see a project arise that will be a replacement ports/ for more than one BSD, perhaps even extending to Linux, (to avoid reinventing of the wheel that must go on with ports skeletal structs for each OS) ( maybe with an RFC for a port/ skeleton struct ? If so, that may have ramifications on bits of src moved to ports. NetBSD's pkgsrc is already cross-OS (kind of), but it contains fewer ports than FreeBSD's ports collection: http://www.netbsd.org/docs/software/packages.html Cheers, Julian -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: CVS removal from the base
There is also mirports from MirBSD that is supported on MirBSD, MidnightBSD, and Mac OS X. They also got a pkgsrc port going recently. The problem is that projects have specific needs that other systems don't have. FreeBSD ports are by far the largest and very fast to build. Pkgsrc comes out quarterly so it takes a long time to get patches in or updates as Dragonfly goes through. With MidnightBSD, we wanted all ports to go through fake install so our packages would work all the time and we could write package tools customized for the ports tree. Every BSD has different needs and different users. Lucas Holt On Dec 14, 2011, at 10:07 AM, C. P. Ghost cpgh...@cordula.ws wrote: On Wed, Dec 14, 2011 at 2:00 PM, Julian H. Stacey j...@berklix.com wrote: Maybe sometime we will see a project arise that will be a replacement ports/ for more than one BSD, perhaps even extending to Linux, (to avoid reinventing of the wheel that must go on with ports skeletal structs for each OS) ( maybe with an RFC for a port/ skeleton struct ? If so, that may have ramifications on bits of src moved to ports. NetBSD's pkgsrc is already cross-OS (kind of), but it contains fewer ports than FreeBSD's ports collection: http://www.netbsd.org/docs/software/packages.html Cheers, Julian -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: CVS removal from the base
Lucas Holt l...@foolishgames.com writes: There is also mirports from MirBSD that is supported on MirBSD, MidnightBSD, and Mac OS X. They also got a pkgsrc port going recently. The problem is that projects have specific needs that other systems don't have. FreeBSD ports are by far the largest and very fast to build. Pkgsrc comes out quarterly so it takes a long time to get patches in or updates as Dragonfly goes through. With MidnightBSD, we wanted all ports to go through fake install so our packages would work all the time and we could write package tools customized for the ports tree. Every BSD has different needs and different users. You can use pkgsrc-current, which is updated all the time. It also supports installation to fake DESTDIR, from where binary packages are made and then installed. It is useful, if you are building as unprivileged user. And pkgsrc already supports FreeBSD. Lucas Holt On Dec 14, 2011, at 10:07 AM, C. P. Ghost cpgh...@cordula.ws wrote: On Wed, Dec 14, 2011 at 2:00 PM, Julian H. Stacey j...@berklix.com wrote: Maybe sometime we will see a project arise that will be a replacement ports/ for more than one BSD, perhaps even extending to Linux, (to avoid reinventing of the wheel that must go on with ports skeletal structs for each OS) ( maybe with an RFC for a port/ skeleton struct ? If so, that may have ramifications on bits of src moved to ports. NetBSD's pkgsrc is already cross-OS (kind of), but it contains fewer ports than FreeBSD's ports collection: http://www.netbsd.org/docs/software/packages.html Cheers, Julian -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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 -- Daniel Horecki http://morr.pl http://linux.pl http://netbsd.pl http://netbsd.org HAIL ERIS! BOFH since 1999. ___ 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: SCHED_ULE should not be the default
On 12/13/2011 7:01 PM, m...@freebsd.org wrote: Has anyone experiencing problems tried to set sysctl kern.sched.steal_thresh=1 ? I don't remember what our specific problem at $WORK was, perhaps it was just interrupt threads not getting serviced fast enough, but we've hard-coded this to 1 and removed the code that sets it in sched_initticks(). The same effect should be had by setting the sysctl after a box is up. FWIW, this does impact the performance of pbzip2 on an i7. Using a 1.1G file pbzip2 -v -c big /dev/null with burnP6 running in the background, sysctl kern.sched.steal_thresh=1 vs sysctl kern.sched.steal_thresh=3 N Min MaxMedian AvgStddev x 10 38.005022 38.42238 38.194648 38.1650520.15546188 + 9 38.695417 40.595544 39.392127 39.4353840.59814114 Difference at 95.0% confidence 1.27033 +/- 0.412636 3.32852% +/- 1.08119% (Student's t, pooled s = 0.425627) a value of 1 is *slightly* faster. -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: SCHED_ULE should not be the default
On Tue, Dec 13, 2011 at 02:22:48AM -0800, Adrian Chadd wrote: On 13 December 2011 01:00, Andrey Chernov a...@freebsd.org wrote: If the algorithm ULE does not contain problems - it means the problem has Core2Duo, or in a piece of code that uses the ULE scheduler. I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. Are you able to provide KTR traces of the scheduler results? Something that can be fed to schedgraph? Sorry, this machine is not mine anymore. I try SCHED_ULE on Core 2 Duo instead and don't notice this effect, but it is overall pretty fast comparing to that Pentium 4. -- http://ache.vniz.net/ ___ 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: SCHED_ULE should not be the default
В Wed, 14 Dec 2011 21:34:35 +0400 Andrey Chernov a...@freebsd.org пишет: On Tue, Dec 13, 2011 at 02:22:48AM -0800, Adrian Chadd wrote: On 13 December 2011 01:00, Andrey Chernov a...@freebsd.org wrote: If the algorithm ULE does not contain problems - it means the problem has Core2Duo, or in a piece of code that uses the ULE scheduler. I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. Are you able to provide KTR traces of the scheduler results? Something that can be fed to schedgraph? Sorry, this machine is not mine anymore. I try SCHED_ULE on Core 2 Duo instead and don't notice this effect, but it is overall pretty fast comparing to that Pentium 4. Give me, please, detailed instructions on how to do it - I'll do it ... Be a shame if this the theme is will end again just only the discussions ... :( ___ 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: dogfooding over in clusteradm land [cvs2svn for ports]
On Wed, 2011-12-14 at 05:20 -0800, Sean Bruno wrote: We're seeing what looks like a syncher/ufs resource starvation on 9.0 on the cvs2svn ports conversion box. I'm not sure what resource is tapped out. Effectively, I cannot access the directory under use and the converter application stalls out waiting for some resource that isn't clear. (Peter had posited kmem of some kind). I've upped maxvnodes a bit on the host, turned off SUJ and mounted the f/s in question with async and noatime for performance reasons. Can someone hit me up with the cluebat? I can give you direct access to the box for debuginationing. Sean BTW, this project is sort of stalled out by this problem. Sean signature.asc Description: This is a digitally signed message part
ports: clang: error: unsupported option '-dumpspecs'
Since a couple of days now I see this happen on FreeBSD 10.0-CURRENT/amd64 (CLANG) (most recent buildworld and potstree) and also on FreeBSD 9.0-RC[2|3]/amd64 (also CLANG built, most recent portstree): Building new INDEX files... DESCRIBE.7 INDEX-8 not provided by portsnap server; INDEX-7 not being generated. done. === Gathering distinfo list for installed ports === Starting check of installed ports for available updates clang: error: unsupported option '-dumpspecs' clang: error: no input files === All ports are up to date Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: dogfooding over in clusteradm land [cvs2svn for ports]
On Wed, Dec 14, 2011 at 10:39 AM, Sean Bruno sean...@yahoo-inc.com wrote: On Wed, 2011-12-14 at 05:20 -0800, Sean Bruno wrote: We're seeing what looks like a syncher/ufs resource starvation on 9.0 on the cvs2svn ports conversion box. I'm not sure what resource is tapped out. Effectively, I cannot access the directory under use and the converter application stalls out waiting for some resource that isn't clear. (Peter had posited kmem of some kind). I've upped maxvnodes a bit on the host, turned off SUJ and mounted the f/s in question with async and noatime for performance reasons. Can someone hit me up with the cluebat? I can give you direct access to the box for debuginationing. Sean BTW, this project is sort of stalled out by this problem. A few things come to mind (in no particular order): 1. What does svn say before it dies? 2. What does df for the affected partition output? 3. Do you have syslog output that indicates where the starvation is occurring? 4. What do the following sysctls print out? kern.maxvnodes kern.minvnodes vfs.freevnodes vfs.wantfreevnodes vfs.numvnodes 5. What does top / vmstat -z say for memory right before svn goes south? 6. Are you running the import as an unprivileged user, or root? 7. Has the login.conf been changed on the box? 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: 9.0-RC1 panic in tcp_input: negative winow.
On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Baldwin wrote: An update. I've sent Pawel a testing patch to see if my hypothesis is correct (www.freebsd.org/~jhb/patches/tcp_negwin_test.patch). If it is then I intend to commit www.freebsd.org/~jhb/patches/tcp_negwin2.patch as the fix. Sorry for the delay, but I'm just rebooting the box that triggered the panic with John's patch. I should know more in a day or two. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgp4LFFZCMTh1.pgp Description: PGP signature
Re: ports: clang: error: unsupported option '-dumpspecs'
-dumpspecs is a gcc internal thing that clang will never support (it doesnt use specs). It's wrong for ports to mess with the internals of the compiler and this should be fixed in a clean way. Ie. we have to replace the -dumpspec | grep something with a saner check. On Wed, Dec 14, 2011 at 08:07:43PM +0100, O. Hartmann wrote: Since a couple of days now I see this happen on FreeBSD 10.0-CURRENT/amd64 (CLANG) (most recent buildworld and potstree) and also on FreeBSD 9.0-RC[2|3]/amd64 (also CLANG built, most recent portstree): Building new INDEX files... DESCRIBE.7 INDEX-8 not provided by portsnap server; INDEX-7 not being generated. done. === Gathering distinfo list for installed ports === Starting check of installed ports for available updates clang: error: unsupported option '-dumpspecs' clang: error: no input files === All ports are up to date Regards, Oliver ___ 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: dogfooding over in clusteradm land
In message 1323868832.5283.9.ca...@hitfishpass-lx.corp.yahoo.com, Sean Bruno writes: We're seeing what looks like a syncher/ufs resource starvation on 9.0 on the cvs2svn ports conversion box. I'm not sure what resource is tapped out. Search mailarcive for lemming-syncer -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: ports: clang: error: unsupported option '-dumpspecs'
On Wed, Dec 14, 2011 at 1:52 PM, Roman Divacky rdiva...@freebsd.org wrote: -dumpspecs is a gcc internal thing that clang will never support (it doesnt use specs). It's wrong for ports to mess with the internals of the compiler and this should be fixed in a clean way. Ie. we have to replace the -dumpspec | grep something with a saner check. The fact that gcc -dumpspecs is looked at at all is a really bad idea. Do you know which port in the tree is calling this? 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: CVS removal from the base
On Wed, Dec 14, 2011 at 05:31:15PM +0100, Daniel Horecki wrote: Lucas Holt l...@foolishgames.com writes: There is also mirports from MirBSD that is supported on MirBSD, MidnightBSD, and Mac OS X. They also got a pkgsrc port going recently. The problem is that projects have specific needs that other systems don't have. FreeBSD ports are by far the largest and very fast to build. Pkgsrc comes out quarterly so it takes a long time to get patches in or updates as Dragonfly goes through. With MidnightBSD, we wanted all ports to go through fake install so our packages would work all the time and we could write package tools customized for the ports tree. Every BSD has different needs and different users. You can use pkgsrc-current, which is updated all the time. It also supports installation to fake DESTDIR, from where binary packages are made and then installed. It is useful, if you are building as unprivileged user. And pkgsrc already supports FreeBSD. What you are pointing here: fake DESTDIR, binary packages and building as unpriviledged, are fairly easy to add to FreeBSD, I'm working on all this. it is not complicated, but it takes a lot of time, no need to go elsewhere to get those features, the ports tree is almost able to handle it. regards, Bapt pgpG5JpqeJjOI.pgp Description: PGP signature
Re: ports: clang: error: unsupported option '-dumpspecs'
Am 12/14/11 23:28, schrieb Garrett Cooper: On Wed, Dec 14, 2011 at 1:52 PM, Roman Divacky rdiva...@freebsd.org wrote: -dumpspecs is a gcc internal thing that clang will never support (it doesnt use specs). It's wrong for ports to mess with the internals of the compiler and this should be fixed in a clean way. Ie. we have to replace the -dumpspec | grep something with a saner check. The fact that gcc -dumpspecs is looked at at all is a really bad idea. Do you know which port in the tree is calling this? Thanks, -Garrett Sorry for being so sloppy. Of course, I know the port. The problem occured when I installed port port multimedia/vdpau-video: === vdpau-video-0.7.3 clang: error: unsupported option '-dumpspecs' clang: error: no input files Regards, Oliver signature.asc Description: OpenPGP digital signature
NEWS: NVIDIA Open-Sources Its CUDA Compiler
Just read this on phoronix.com Is this finally a chance to get GPGPU on FreeBSD natively supported? nVidia has a binary driver, supporting well their higher end graphics cards on FreeBSD 64bit natively. I do not understand much about the compiler itself, it's nvcc as far as I know, and it is also doing well OpenCL (with some serious bugs we revealed). What would be needed to bring FreeBSd finally back to the HPC scenario with being capable of dealing natively with GPGPU stuff on nVidia graphics cards? There are libraries installed by the driver or the SDK. With a OpenSource compiler it should also be possible for nVidia, assumed the compiler works with freeBSD natively, to provide OpenCL stuff as well as CUDA stuff. Please correct me and destroy me dreams having FreeBSD in my lab working on GPUs ... The decission sounds like some pitfall in a contract. Is nVidia dropping CUDA in favour of OpenCL or is the CUDA compiler only a tiny piece of the whole thing that could be easily considered open source without changing the great restricted Linux-only picture? Maybe LLVM, now part of FreeBSD's backbone, is capable of taking advantage of the opening of the CUDA compiler so we will see a combination of CLANG/OpenCL/CUDA soon on FreeBSD introduced by LLVM? Well, well, this is awesome ... ;-) Oliver signature.asc Description: OpenPGP digital signature
Re: [CFT] pkgng alpha2
On Tue, 13 Dec 2011 19:56:05 +0200 Andriy Gapon a...@freebsd.org wrote: on 13/12/2011 19:22 Julien Laffaye said the following: On 12/13/2011 06:16 PM, Andriy Gapon wrote: on 30/11/2011 22:32 Julien Laffaye said the following: [1] : https://github.com/pkgng/pkgng/issues [2] : https://github.com/pkgng/pkgng [3] : http://wiki.freebsd.org/pkgng [4] : http://people.freebsd.org/~bapt/pkgng-bsdcan2011.pdf [5] : http://wiki.freebsd.org/201110DevSummit/Ports?action=AttachFiledo=gettarget=pkgng-devsummit.pdf [6] : http://wiki.freebsd.org/201110DevSummit?action=AttachFiledo=gettarget=pkgng-devsummit-track.pdf Couple of questions/suggestions: 1. Do you plan to have a pkgng port to issue the preview releases pkgng? Current pkgng installation/bootstrap procedure is really easy, but the port would be even more convenient for prospective testers. Yes, this is planned. The ports will bootstrap pkgng. Great! The current idea is to have everything in ports so that we don't depend on the base OS for any kind of changes; we'll only have a bootstrap in base. One more step forward to decoupling ports from src releases. 2. Is there a public pre-built package repository with pkgng-format packages that could be used for testing and getting a taste of a packages-only pkgng-managed system? Unfortunately, no. I think I now have the resources to do that for the next CFT. But it will only be 9.0 amd64 I am afraid. We cant build packages for the entire matrix. I understand. Those would take an immense amount of compilation time and storage space. Storage and especially storage / propagation to mirrors are the biggest problems. After pkgNG goes in, we plan to switch HEAD to it and provide only pkgNG packages for it; then probably the same for 9-STABLE and further 9 releases, but we'll probably need to provide current style of pacakges during 9.x life time :( -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
complete LLVM toolset in 10.0?
LLVM is now partially installed in the base system, but for some development and research purposes I need other parts of LLVM like llc, lli, llvm-as and buddies. I miss them. Is there a chance to get them reeled into the build tree via a knob in /etc/src.conf? I'd like to see them available in 10.0. I also file a PR not to loose track on that. Oliver signature.asc Description: OpenPGP digital signature
Re: Remove debug echo
Garrett,
On Thu, Dec 1, 2011 at 2:15 PM, Garrett Cooper yaneg...@gmail.com wrote:
I've attached a patch that makes make do what I would like it to do;
there are some other items that require cleanup to achieve the `argv0'
prefixing that's available in gmake, but this is good enough for a
meaningful traceback when things fail. Pastebin available here, just
in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv
$ cat ~/Makefile
all:
cd $$HOME/foo; ${MAKE} $@
$ cat ~/foo/Makefile
all: foo bar barf yadda
foo bar yadda:
@true
baz:
@false
barf: baz
$ $PWD/make -j4 -f ~/Makefile all
cd $HOME/foo; /usr/src/usr.bin/make/make all
*** [baz] Error code 1
1 error
*** [all] Error code 2
1 error
$
If someone would please, PLEASE commit this.. I will give you beer, or
wine, or a copy of Skyrim, or a few months subscription to WoW, or
something else of value to you that we could negotiate :)... I'm quite
frankly tired of having to playing guessing games fishing through logs
trying to determine build errors on FreeBSD if and when they do occur
with pmake, and I'm sure that a number of developers and build/release
engineers out there are in the same boat as I am.
Can you explain why did you remove MESSAGE() invocations in your patch?
Other than that the patch looks good to me.
Max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Remove debug echo
On Wed, Dec 14, 2011 at 7:27 PM, Max Khon f...@samodelkin.net wrote:
Garrett,
On Thu, Dec 1, 2011 at 2:15 PM, Garrett Cooper yaneg...@gmail.com wrote:
I've attached a patch that makes make do what I would like it to do;
there are some other items that require cleanup to achieve the `argv0'
prefixing that's available in gmake, but this is good enough for a
meaningful traceback when things fail. Pastebin available here, just
in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv
$ cat ~/Makefile
all:
cd $$HOME/foo; ${MAKE} $@
$ cat ~/foo/Makefile
all: foo bar barf yadda
foo bar yadda:
@true
baz:
@false
barf: baz
$ $PWD/make -j4 -f ~/Makefile all
cd $HOME/foo; /usr/src/usr.bin/make/make all
*** [baz] Error code 1
1 error
*** [all] Error code 2
1 error
$
If someone would please, PLEASE commit this.. I will give you beer, or
wine, or a copy of Skyrim, or a few months subscription to WoW, or
something else of value to you that we could negotiate :)... I'm quite
frankly tired of having to playing guessing games fishing through logs
trying to determine build errors on FreeBSD if and when they do occur
with pmake, and I'm sure that a number of developers and build/release
engineers out there are in the same boat as I am.
Can you explain why did you remove MESSAGE() invocations in your patch?
Other than that the patch looks good to me.
I thought that printing out MESSAGE and the more informative
*printf was kind of redundant.
Thanks!
-Garrett
PS A sidenote why I bypassed MESSAGE(..): if I used the macro, make
would segfault as MESSAGE depends on targFmt and targPrefix being set
to something sane (they both default to NULL -- one explicitly, the
other implicitly because it's in the .BSS). These vars are only set in
one section of code, but I took the easy route out to avoid
accidentally breaking other code paths and because what I did in the
previously attached patch was simple to implement and test.
___
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
Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Just saw this shot benchmark on Phoronix dot com today: http://www.phoronix.com/scan.php?page=news_itempx=MTAyNzA It may be worth to discuss the sad performance of FBSD in some parts of the benchmark. A difference of a factor 10 or 100 is simply far beyond disapointing, it is more than inacceptable and by just reading those benchmarks, I'd like to drop thinking of using FreeBSD even as a backend server in scientific and business environments. In detail, some of the SciMark benches look disappointing. The overall image can't help over the fact that in C-Ray FreeBSD is better performing. From the compiler, I'd like say there couldn't be a drop of more than 10 - 15% in performance - but not 10 or 100 times. I'm just thinking about the discussion of SCHED_ULE and all the saur spots we discussed when I stumbled over the test. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 14 December 2011 23:32, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Just saw this shot benchmark on Phoronix dot com today: http://www.phoronix.com/scan.php?page=news_itempx=MTAyNzA It may be worth to discuss the sad performance of FBSD in some parts of the benchmark. A difference of a factor 10 or 100 is simply far beyond Well, the only way it's going to get fixed is if someone sits down, replicates it, and starts to document exactly what it is that these benchmarks are/aren't doing. Sometimes it's because the benchmark is very much tickling things incorrectly. In a lot of cases though, the benchmark is testing something synthetic that Linux just happens to have micro-optimised. So if you care about this a lot, someone needs to stand up, work with Phronix to get some actual feedback about what's going on, and see if it can be fixed. Maybe you'll find ULE is broken in some instances; I bet you'll find something like the disk driver is suboptimal. For example, I remember seeing someone mess up a test because they split their filesystems across raid5 boundaries, and this was hidden by the choice of raid controller and stripe size. This made FreeBSD look worse; when this was corrected for, it sped up far past Linux. 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
