Re: boot0.S empty #ifdef
On Mon, 5 Dec 2011 12:54:15 -0800 some body bsd.mh...@gmail.com wrote: I sent this to freebsd-drives too but I think that might not be the right list for it so here it is: I am starting to learn how the kernel works and have started by going through the boot loader and I've noticed that between lines 21-32 in boot0.S there are some empty #ifdef statements. I was wondering a) where are these paramaters defined and if they are defined, what difference does it make since it looks like it doesn't change anything since they're empty? #ifdef SIO #endif #ifdef CHECK_DRIVE #endif #ifdef ONLY_F_KEYS #endif These seem to be there to act as reminders for command line options which can be used to build boot0. They're also documented in Makefile. These are actually used later in the code. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CPUTYPE and friends, from 'make.conf' benchmark
# /bin/sh -c gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//' generic For target machine, it returned 'generic' Now only with CPUTYPE in 'make.conf': -- CPUTYPE?=core2 -- Also, you should set these in src.conf. Sticking them in make.conf is going to annoy people when you ask why your ports are breaking ;) Chris I want my ports, to also be optimized for target CPU, not just base. None of my ports got broken yet. Rebuilded can ... Tests are started AFTER a reboot! There is no bgfsck, as per rc.conf: -- background_fsck=NO fsck_y_enable=YES fsck_y_flags=-C -- Same multiuser enviroment Test done once. After running: '# time unixbench', final score was: 395.4 Completed in 22.8 min Time is SAME as with generic binaries, but score is just a 1.2 higher, which is too small to be relevant. What do you think about this? Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CPUTYPE and friends, from 'make.conf' benchmark
On 6 Dec 2011 17:04, rank1see...@gmail.com wrote: # /bin/sh -c gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//' generic For target machine, it returned 'generic' Now only with CPUTYPE in 'make.conf': -- CPUTYPE?=core2 -- Also, you should set these in src.conf. Sticking them in make.conf is going to annoy people when you ask why your ports are breaking ;) Chris I want my ports, to also be optimized for target CPU, not just base. None of my ports got broken yet. I was referring to the other stuff, but CPUTYPE is fine, yes. Rebuilded can ... Tests are started AFTER a reboot! There is no bgfsck, as per rc.conf: -- background_fsck=NO fsck_y_enable=YES fsck_y_flags=-C -- Same multiuser enviroment Test done once. After running: '# time unixbench', final score was: 395.4 Completed in 22.8 min Time is SAME as with generic binaries, but score is just a 1.2 higher, which is too small to be relevant. What do you think about this? I think this is why most people don't bother with setting CPUTYPE ;) Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CPUTYPE and friends, from 'make.conf' benchmark
2011/12/6 rank1see...@gmail.com: # /bin/sh -c gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//' Test done once. What do you think about this? As usual, it very well *may* be true, but please use ministat(1) to confirm. This requires more than one test. I'm not trying to be difficult - but statistics and benchmarking is non-trivial. -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CPUTYPE and friends, from 'make.conf' benchmark
On Tue, Dec 6, 2011 at 1:34 PM, Eitan Adler li...@eitanadler.com wrote: 2011/12/6 rank1see...@gmail.com: # /bin/sh -c gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//' Test done once. What do you think about this? As usual, it very well *may* be true, but please use ministat(1) to confirm. This requires more than one test. I'm not trying to be difficult - but statistics and benchmarking is non-trivial. A few other good suggestions: http://wiki.freebsd.org/BenchmarkAdvice - Max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: strange printf(9) format specifier (Z) in dev/drm code
On Sun, Dec 04, 2011, Alexander Best wrote: ... i couldn't find a reference to an upercase Z in the printf(9) man page. i talked to dinoex on #freebsd-clang (EFNet) and he said that the Z might come from linux'es libc5 and is the equaivalent to glibc's z. can we adjust those lines, so the clang warnings disappear? Yes, 'Z' is an alias for 'z' that is deprecated in glibc and unsupported in FreeBSD, so changing the case should fix it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: strange printf(9) format specifier (Z) in dev/drm code
On Tue Dec 6 11, David Schultz wrote: On Sun, Dec 04, 2011, Alexander Best wrote: ... i couldn't find a reference to an upercase Z in the printf(9) man page. i talked to dinoex on #freebsd-clang (EFNet) and he said that the Z might come from linux'es libc5 and is the equaivalent to glibc's z. can we adjust those lines, so the clang warnings disappear? Yes, 'Z' is an alias for 'z' that is deprecated in glibc and unsupported in FreeBSD, so changing the case should fix it. i guess turning the Z's into z's would be the best procedure then. cheers. alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
64bit build errors
I'm trying to build some newer versions of ffserver. But I keep getting asm build errors when I get to libavcodec/vp*. Error: `(%esi,%eax)' is not a valid 64 bit base/index expression If I set it to build static it fails at h264. Error: `-1(%edi)' is not a valid 64 bit base/index expression Googling hasn't proved helpful in finding an answer. I've tried setting some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, ebx, etc. Any ideas how to fix this? Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
