Re: FreeBSD Installer Roadmap
On Tue, Feb 22, 2011 at 10:41 PM, Garrett Cooper wrote:
> On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske wrote:
> >
> > On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote:
> >
> >> On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote:
> >>> That's the operative word here ("supports"). Lord help us when that
> >>> changes to "requires" (that is to say, if/when the FreeBSD kernel
> >>> becomes legacy-free with respect to supporting fdisk/disklabel
> >>> partitioned disks).
> >>
> >> When that does come, it will probably be driven by BIOS and hardware
> >> vendors dropping support for MBR. Current disks are at the upper
> >> limit of what MBR can be support (and that's after several revamps of
> >> MBR). Since GPT already provides a superior feature set without MBR's
> >> limits, the next step will be to just drop MBR support. And when it
> >> does come, FreeBSD needs to be ready with an installer that can cope
> >> with non-MBR disks.
>
> While I love a good discussion (and there have been a number of good
> points for either side on here), should we agree to switch the default
> over to bsdinstall, leave sysinstall in (lumps or no lumps), then over
> the period of the next 2~3 major (that amounts to 4~6 years) releases,
> and retire sysinstall to the happy hunting grounds? sysinstall didn't
> take up that much space on the release media I thought, and it might
> be doable to map both sets of media so that sysinstall can work in
> harmony on bsdinstall's release media?
>
> Preparing custom releases to use the sysinstall init_path isn't that
> bad, so it would at least give the legacy folks time to transition
> over while us guinea pigs burn in the new wax :)...
>
> Sound good?
>
> Thanks!
> -Garrett
>
Yes , very much .
My suggestion is to include the item
sysinstall
in BSD-Install by Nathan Whitehorn as an option in installation start up
menu .
In that way , existing installation works will be upward compatible with
bsdinstall .
My another suggestion is to move installation startup menu part into
/boot/install/ directory for each architecture and allow platform specific
installers by using common parts from common directories .
For example , in PC-based installations ( amd64 , i386 , ... ) PC-BSD
pc-sysinstall
will be usable from bsdinstall as an option at present .
In that form , the initial installation menu will be seen in PC environment
as follows :
bsdinstall ( by Nathan Whitehorn )
pc-sysinstall ( by Kris Moore )
sysinstall ( by John Hubbard )
Thank you very much .
Mehmet Erol Sanliturk
___
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: FreeBSD Installer Roadmap
On Tue, Feb 22, 2011 at 9:26 PM, Devin Teske wrote:
>
> On Feb 22, 2011, at 7:41 PM, Garrett Cooper wrote:
>
>> On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske wrote:
>>>
>>> On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote:
>>>
On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote:
> That's the operative word here ("supports"). Lord help us when that
> changes to "requires" (that is to say, if/when the FreeBSD kernel
> becomes legacy-free with respect to supporting fdisk/disklabel
> partitioned disks).
When that does come, it will probably be driven by BIOS and hardware
vendors dropping support for MBR. Current disks are at the upper
limit of what MBR can be support (and that's after several revamps of
MBR). Since GPT already provides a superior feature set without MBR's
limits, the next step will be to just drop MBR support. And when it
does come, FreeBSD needs to be ready with an installer that can cope
with non-MBR disks.
>>
>> While I love a good discussion (and there have been a number of good
>> points for either side on here), should we agree to switch the default
>> over to bsdinstall, leave sysinstall in (lumps or no lumps), then over
>> the period of the next 2~3 major (that amounts to 4~6 years) releases,
>> and retire sysinstall to the happy hunting grounds? sysinstall didn't
>> take up that much space on the release media I thought, and it might
>> be doable to map both sets of media so that sysinstall can work in
>> harmony on bsdinstall's release media?
>>
>> Preparing custom releases to use the sysinstall init_path isn't that
>> bad, so it would at least give the legacy folks time to transition
>> over while us guinea pigs burn in the new wax :)...
>>
>> Sound good?
>
> Love it. Absolutely love it. You are a uniter, sir (tips hat)!
Well, it's just a proposal. It needs to be presented to a) re@, b)
they need to tentatively accept, and someone needs to a) do the work
of integrating both pieces together and b) ensure it works in both
cases, c) test, test test, d) commit.
All of this needs to be done before 9.0-RELEASE.
So I wouldn't say "success!" just yet, but we're on the right path.
Switching stuff overnight is impossible for something like sysinstall.
I'm having to deal with similar issues transitioning acquisition MIBs
over to the acquiree company's style and requirements.
Providing an ample transition plan is one of the great things I've
noticed about BSD anyhow in areas like these :)... it shows real
planning and architecture.
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: FreeBSD Installer Roadmap
On Feb 22, 2011, at 7:41 PM, Garrett Cooper wrote:
> On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske wrote:
>>
>> On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote:
>>
>>> On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote:
That's the operative word here ("supports"). Lord help us when that
changes to "requires" (that is to say, if/when the FreeBSD kernel
becomes legacy-free with respect to supporting fdisk/disklabel
partitioned disks).
>>>
>>> When that does come, it will probably be driven by BIOS and hardware
>>> vendors dropping support for MBR. Current disks are at the upper
>>> limit of what MBR can be support (and that's after several revamps of
>>> MBR). Since GPT already provides a superior feature set without MBR's
>>> limits, the next step will be to just drop MBR support. And when it
>>> does come, FreeBSD needs to be ready with an installer that can cope
>>> with non-MBR disks.
>
> While I love a good discussion (and there have been a number of good
> points for either side on here), should we agree to switch the default
> over to bsdinstall, leave sysinstall in (lumps or no lumps), then over
> the period of the next 2~3 major (that amounts to 4~6 years) releases,
> and retire sysinstall to the happy hunting grounds? sysinstall didn't
> take up that much space on the release media I thought, and it might
> be doable to map both sets of media so that sysinstall can work in
> harmony on bsdinstall's release media?
>
> Preparing custom releases to use the sysinstall init_path isn't that
> bad, so it would at least give the legacy folks time to transition
> over while us guinea pigs burn in the new wax :)...
>
> Sound good?
Love it. Absolutely love it. You are a uniter, sir (tips hat)!
>
> Thanks!
> -Garrett
--
Cheers,
Devin Teske
-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.te...@fisglobal.com
-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.
-> END TRANSMISSION <-
___
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: FreeBSD Installer Roadmap
On Tue, Feb 22, 2011 at 7:23 PM, Devin Teske wrote:
>
> On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote:
>
>> On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote:
>>> That's the operative word here ("supports"). Lord help us when that
>>> changes to "requires" (that is to say, if/when the FreeBSD kernel
>>> becomes legacy-free with respect to supporting fdisk/disklabel
>>> partitioned disks).
>>
>> When that does come, it will probably be driven by BIOS and hardware
>> vendors dropping support for MBR. Current disks are at the upper
>> limit of what MBR can be support (and that's after several revamps of
>> MBR). Since GPT already provides a superior feature set without MBR's
>> limits, the next step will be to just drop MBR support. And when it
>> does come, FreeBSD needs to be ready with an installer that can cope
>> with non-MBR disks.
While I love a good discussion (and there have been a number of good
points for either side on here), should we agree to switch the default
over to bsdinstall, leave sysinstall in (lumps or no lumps), then over
the period of the next 2~3 major (that amounts to 4~6 years) releases,
and retire sysinstall to the happy hunting grounds? sysinstall didn't
take up that much space on the release media I thought, and it might
be doable to map both sets of media so that sysinstall can work in
harmony on bsdinstall's release media?
Preparing custom releases to use the sysinstall init_path isn't that
bad, so it would at least give the legacy folks time to transition
over while us guinea pigs burn in the new wax :)...
Sound good?
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: FreeBSD Installer Roadmap
On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote:
> On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote:
>> That's the operative word here ("supports"). Lord help us when that
>> changes to "requires" (that is to say, if/when the FreeBSD kernel
>> becomes legacy-free with respect to supporting fdisk/disklabel
>> partitioned disks).
>
> When that does come, it will probably be driven by BIOS and hardware
> vendors dropping support for MBR. Current disks are at the upper
> limit of what MBR can be support (and that's after several revamps of
> MBR). Since GPT already provides a superior feature set without MBR's
> limits, the next step will be to just drop MBR support. And when it
> does come, FreeBSD needs to be ready with an installer that can cope
> with non-MBR disks.
All very true.
Though admittedly we're [as a technological society] still a long long ways off
from dropping support for MBR in even the most modern BIOS'.
>
>> We've yet to see a "must have" technology that would require us to
>> shun sysinstall (as explained earlier, we have no desire whatsoever
>> to boot from ZFS, gmirror, geli, GPT, or anything else missing from
>> sysinstall).
>
> Whilst _you_ might not be interested, lots of other people _are_
> interested in using these features - I personally use a mixture of
> gmirror, GPT and ZFS root on different systems.
Excellent. And the likes of us (enterprise) will be watching the likes of you
(non-enterprise) for many years to come to see how you fare in your travels.
From time to time we'll be checking in on the list and perusing list archives
to see how well you fare.
I don't know if you remember, but I can remember 10+ years ago when ReiserFS
(the *killer* filesystem -- sorry, I couldn't resist) hit the Linux scene.
There were wild reports of comprehensive data loss even in the 3rd year of its
production cycle. It was stories like that which kept down the rate of adoption
because many enterprises adopt the same "wait and see" attitude. We call it the
"great shake out" and all new technologies must have one before being adopted
by the largest enterprises.
> Why should other
> people be forced to avoid these features just because you don't use
> them?
They shouldn't. We encourage others to dive head-long into the soupy mix and be
our guinea pigs for us.
Innovation is no place for the enterprises that run the market place (or even
the World).
(in a very serious tone) Would you rather your bank call you up and explain
that because they tried some new technology that caused a crash in the data
center, you won't have access to your bank account for the next few hours
whilst they reboot the master server?
Just as I suspect your answer would be no, it should be self-evident that when
a critical system goes down, there is not always the luxury of being able to
drop to gdb/kdb and diagnose the root-cause (rather, disaster recovery
procedures often demand focusing your efforts on getting said service -- if not
the original machine, a replacement machine -- back online as fast as humanly
possible). Whereas others may have the luxury of providing backtraces, core
dumps, and swapfiles to the authors of some new kernel device driver to
eventually have some critical bug fixed, the downtime required to cull those
resources would decimate any profit-driven business model which relies on
service uptime.
It's very easy to forget that -- while playing with new technologies is both
fun _and_ exciting -- businesses that make the world go-'round demand more than
just the promise of stability, they demand the numbers to prove it (and even
then, may still require their own engineers to perform an "in-house bake-out"
of their own which involves the added complexity of working with their own
code). Rolling in any replacement anytime anywhere requires "burn-in" metrics
to show that the technology can reproduce an acceptable fault-to-performance
ratio. Of course, it goes without saying that said stringent testing requires
both resources and man-hours.
> FreeBSD's installer should support the same features as FreeBSD
> itself for consistency.
I don't disagree. That's a laudable goal for all Operating Systems. Though with
due respect, I don't think any one installer for any operating system allows
you to achieve all permutations of which the OS itself supports.
>
>> pedestals... why would we ever need >8GB for the operating system?
>> all production data is being stored on enterprise class devices such
>> as the NEC-D210, and being backed up with tapes such as LTO;
>
> Not everyone uses FreeBSD in the same environment as you.
Oh how society would stagnate if we _did_. Thank goodness we _don't_ operate in
the same environments (for your sake and mine).
>
>> We're no stranger to putting even the Operating System on Life
>> Support for as long as it takes for our customers to bolster their
>> budgets for an integrated upgrade strategy.
>
> Given that y
Re: Wow... (<-- blown away at performance)
On Tue, Feb 22, 2011 at 6:00 PM, Alexander Best wrote: > On Tue Feb 22 11, Alexander Best wrote: >> On Tue Feb 22 11, Alexander Best wrote: >> > On Tue Feb 22 11, Brandon Gooch wrote: >> > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best >> > > wrote: >> > > > On Tue Feb 22 11, Garrett Cooper wrote: >> > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: >> > > >> > On 22 February 2011 11:15, Garrett Cooper >> > > >> > wrote: >> > > >> >> I don't know what to say, but r218938 screams with flash videos >> > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's >> > > >> >> the >> > > >> >> new linuxulator patches, but I can run multiple instances of >> > > >> >> youtube >> > > >> >> in parallel (5 total with other miscellaneous flash animation) >> > > >> >> without >> > > >> >> it totally lagging out Firefox/X11, and it appears to close the >> > > >> >> instances of firefox properly now. Hopefully this version fares >> > > >> >> better >> > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, >> > > >> >> where my system just hardlocked for no apparent reason). >> > > >> >> Anyhow, hope others have similar results. >> > > >> >> Cheers! >> > > >> >> -Garrett >> > > >> >> >> > > >> >> $ uname -a >> > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 >> > > >> >> r218938M: >> > > >> >> Mon Feb 21 23:10:51 PST 2011 >> > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >> > > >> > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant >> > > >> > performance changes in 10.2 (from 10.1). You can search for >> > > >> > StageVideo >> > > >> > performance to learn more about. Youtube already use them since 10.2 >> > > >> > beta >> > > >> >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are >> > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a >> > > >> more than 200% increase (now it actually scales between multiple >> > > >> instances, instead of croaks with one instance, tiling up and down the >> > > >> screen when moving the window slider for instance or switching tabs). >> > > >> Besides, it seems like it needs external support from the video >> > > >> driver, and I'm not sure that that bridge exists in the linuxulator. >> > > >> Also, it looks like npviewer.bin still hangs to resources on until >> > > >> Firefox closes (or I kill it :)..), so something still needs to be >> > > >> resolved there, but that isn't a regression (it's acted that way for >> > > >> ages), and shouldn't be too hard to do. >> > > > >> > > > i think the problem with npviewer.bin having to be killed by hand is a >> > > > futex >> > > > issue in combination with a high number of threads. this is the output >> > > > of a >> > > > test from darren hart's futex test suite under freebsd 9.0: >> > > > >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=1 >> > > > Result: 18622 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=2 >> > > > Result: 15469 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=3 >> > > > Result: 12713 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=4 >> > > > Result: 12247 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=5 >> > > > Result: 11814 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=6 >> > > > Result: 13468 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=8 >> > > > Result: 12061 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=10 >> > > > Result: 12854 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=12 >> > > > Result: 12999 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=16 >> > > > Result: 12402 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=24 >> > > > Result: 9815 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=32 >> > > > Result: 8518 Kiter/s >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > > Arguments: iterations=1 threads=64 >> > > > ERROR: Resource temporarily unavailable: pthread_create >> > > > Result: ERROR >> > > > futex_wait: Measure FUTEX_WAIT operations per second >> > > >
Re: binutils 2.17.50 and ctfconvert
On 2011-02-22 20:23, Jung-uk Kim wrote:
Since binutils 2.17.50 import, WITH_CTF=1& buildworld on amd64 stops
like this:
...
cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT
-isystem /usr/obj/usr/src/lib32/usr/include/
-L/usr/obj/usr/src/lib32/usr/lib32
-B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe
-fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include
-I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/aio.c -o
aio.So
ctfconvert -L VERSION aio.o
...
BFD: aio.So: invalid SHT_GROUP entry
BFD: aio.So: invalid SHT_GROUP entry
BFD: aio.So: no group info for section .text.__i686.get_pc_thunk.cx
BFD: aio.So: no group info for section .text.__i686.get_pc_thunk.bx
BFD: aio.So: unknown [0] section `' in group [__i686.get_pc_thunk.cx]
BFD: aio.So: unknown [0] section `' in group [__i686.get_pc_thunk.bx]
nm: aio.So: File format not recognized
...
Google found NetBSD has a similar looking PR but it is not exactly the
same:
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=42986
What I gather from that bug report is that apparently ctfconvert can
corrupt object files with debug info, if you do not pass -g to it.
There is some logic in bsd.lib.mk to add '-g' to CTFFLAGS, if
DEBUG_FLAGS contains '-g', but in lib/librt/Makefile you can see:
...
CFLAGS+=-Winline -Wall -g
...
It looks like the -g flag is not detected, so ctfconvert is run without
-g, and it corrupts the .So file. I have no clue yet why this suddenly
appears after upgrading to binutils 2.17.50, but it is likely due to a
slightly different output format.
In any case, just removing the -g from CFLAGS in lib/librt/Makefile made
the build32 stage complete successfully for me, and since that is the
lsat stage of the amd64 build, I assume the rest will be OK too.
For now, I propose to commit the attached diff, and then we try to find
out why:
1) ctfconvert does not get -g passed when it is needed
2) ctfconvert corrupts .o files when -g is not passed :)
Index: lib/librt/Makefile
===
--- lib/librt/Makefile (revision 218951)
+++ lib/librt/Makefile (working copy)
@@ -6,7 +6,7 @@
.ifndef NO_THREAD_STACK_UNWIND
CFLAGS+=-fexceptions
.endif
-CFLAGS+=-Winline -Wall -g
+CFLAGS+=-Winline -Wall
DPADD= ${LIBPTHREAD}
LDADD= -lpthread
___
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: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > > > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > > > >> >> the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > > > >> >> without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > > > >> >> better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > > > >> > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > > > > futex > > > > issue in combination with a high number of threads. this is the output > > > > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations pe
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best > > > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > > > >> >> the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > > > >> >> without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > > > >> >> better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > > > >> > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > > > > futex > > > > issue in combination with a high number of threads. this is the output > > > > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=1 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations pe
Re: Process timing issue
To debug weird scheduling issues I find it helpful to start by looking at a schedgraph. schedgraph is a tool that can display a graphical representation of what the scheduler was doing over a small slice of time. The one downside is that you have to recompile your kernel to get the hooks that collect the necessary data, but it sounds like your problem is pretty easy to reproduce and so that shouldn't be a big problem. To enable the hooks, put the following in your kernel conf: options KTR options KTR_COMPILE=KTR_SCHED options KTR_MASK=KTR_SCHED options KTR_ENTIRES=(128*1024) Then rebuild and install the new kernel. Next, run your test. The instant that your test has detected the long delay, set the sysctl debug.ktr.mask to 0. The scheduler hooks record data into a ring buffer, so the interesting data can be flushed out within seconds. Clearing that sysctl will stop any further events from being logged, which means that the interesting data will stay there until you go and collect it. You can get the raw data by redirecting the output of "ktrdump -ct" into a file. Then from any machine with a graphical interface(FreeBSD with X installed, Windows, Mac, whatever) and python installed, run: $ python schedgraph.py /path/to/ktrdump/output You can get schedgraph.py from /usr/src/tools/sched. If you want to collect the data again, set the sysctl debug.ktr.mask back to 0x2000 to restart gathering scheduler data. Ryan ___ 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: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Alexander Best wrote: > On Tue Feb 22 11, Brandon Gooch wrote: > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > > On Tue Feb 22 11, Garrett Cooper wrote: > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > > >> >> I don't know what to say, but r218938 screams with flash videos > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > >> >> in parallel (5 total with other miscellaneous flash animation) without > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > >> >> instances of firefox properly now. Hopefully this version fares better > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > >> >> where my system just hardlocked for no apparent reason). > > >> >> Anyhow, hope others have similar results. > > >> >> Cheers! > > >> >> -Garrett > > >> >> > > >> >> $ uname -a > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > >> >> Mon Feb 21 23:10:51 PST 2011 > > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > >> > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > > >> > performance to learn more about. Youtube already use them since 10.2 > > >> > beta > > >> > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > >> more than 200% increase (now it actually scales between multiple > > >> instances, instead of croaks with one instance, tiling up and down the > > >> screen when moving the window slider for instance or switching tabs). > > >> Besides, it seems like it needs external support from the video > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > >> Also, it looks like npviewer.bin still hangs to resources on until > > >> Firefox closes (or I kill it :)..), so something still needs to be > > >> resolved there, but that isn't a regression (it's acted that way for > > >> ages), and shouldn't be too hard to do. > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > > > futex > > > issue in combination with a high number of threads. this is the output of > > > a > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=1 > > > Result: 18622 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=2 > > > Result: 15469 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=3 > > > Result: 12713 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=4 > > > Result: 12247 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=5 > > > Result: 11814 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=6 > > > Result: 13468 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=8 > > > Result: 12061 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=10 > > > Result: 12854 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=12 > > > Result: 12999 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=16 > > > Result: 12402 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=24 > > > Result: 9815 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=32 > > > Result: 8518 Kiter/s > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=64 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=128 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=256 > > > ERROR: Resource temporarily unavailable: pthread_create > > > Result: ERROR > > > futex_wait: Measure FUTEX_WAIT operations per second > > > Arguments: iterations=1 threads=512 > > >
Re: FreeBSD Installer Roadmap
On 2011-Feb-22 02:50:54 -0800, Devin Teske wrote:
>That's the operative word here ("supports"). Lord help us when that
>changes to "requires" (that is to say, if/when the FreeBSD kernel
>becomes legacy-free with respect to supporting fdisk/disklabel
>partitioned disks).
When that does come, it will probably be driven by BIOS and hardware
vendors dropping support for MBR. Current disks are at the upper
limit of what MBR can be support (and that's after several revamps of
MBR). Since GPT already provides a superior feature set without MBR's
limits, the next step will be to just drop MBR support. And when it
does come, FreeBSD needs to be ready with an installer that can cope
with non-MBR disks.
>We've yet to see a "must have" technology that would require us to
>shun sysinstall (as explained earlier, we have no desire whatsoever
>to boot from ZFS, gmirror, geli, GPT, or anything else missing from
>sysinstall).
Whilst _you_ might not be interested, lots of other people _are_
interested in using these features - I personally use a mixture of
gmirror, GPT and ZFS root on different systems. Why should other
people be forced to avoid these features just because you don't use
them? FreeBSD's installer should support the same features as FreeBSD
itself for consistency.
>pedestals... why would we ever need >8GB for the operating system?
>all production data is being stored on enterprise class devices such
>as the NEC-D210, and being backed up with tapes such as LTO;
Not everyone uses FreeBSD in the same environment as you.
>We're no stranger to putting even the Operating System on Life
>Support for as long as it takes for our customers to bolster their
>budgets for an integrated upgrade strategy.
Given that you've already said you are staying with FreeBSD 4.11,
why are you at all worried about FreeBSD using a new installed in
FreeBSD 9 to support features that don't exist in FreeBSD 4?
FreeBSD is primarily a volunteer project. Whilst you may be an expert
on the innards of sysinstall, this seems to be a rare skill and no-one
(including yourself) has stepped up and offered to add the missing
functionality to sysinstall. It's worth noting that the original
author of sysinstall considered it to be a temporary stop-gap until
something better was developed. The increasing disparity between
FreeBSD's features, together with the opaqueness of sysinstall have
led to a replacement being developed. No-one is forcing you to
replace sysinstall on your legacy systems but if you want sysinstall
to remain the default installer, you are going to need to add the
missing functionality to it.
--
Peter Jeremy
pgpHyWlStxF6J.pgp
Description: PGP signature
Re: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Brandon Gooch wrote: > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > > On Tue Feb 22 11, Garrett Cooper wrote: > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > >> > On 22 February 2011 11:15, Garrett Cooper wrote: > >> >> I don't know what to say, but r218938 screams with flash videos > >> >> (native Linux speed). Not sure if it's the new binutils or if it's the > >> >> new linuxulator patches, but I can run multiple instances of youtube > >> >> in parallel (5 total with other miscellaneous flash animation) without > >> >> it totally lagging out Firefox/X11, and it appears to close the > >> >> instances of firefox properly now. Hopefully this version fares better > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > >> >> where my system just hardlocked for no apparent reason). > >> >> Anyhow, hope others have similar results. > >> >> Cheers! > >> >> -Garrett > >> >> > >> >> $ uname -a > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > >> >> Mon Feb 21 23:10:51 PST 2011 > >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > >> > > >> > Which FlashPlayer version do you test? Adobe has made significant > >> > performance changes in 10.2 (from 10.1). You can search for StageVideo > >> > performance to learn more about. Youtube already use them since 10.2 > >> > beta > >> > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > >> more than 200% increase (now it actually scales between multiple > >> instances, instead of croaks with one instance, tiling up and down the > >> screen when moving the window slider for instance or switching tabs). > >> Besides, it seems like it needs external support from the video > >> driver, and I'm not sure that that bridge exists in the linuxulator. > >> Also, it looks like npviewer.bin still hangs to resources on until > >> Firefox closes (or I kill it :)..), so something still needs to be > >> resolved there, but that isn't a regression (it's acted that way for > >> ages), and shouldn't be too hard to do. > > > > i think the problem with npviewer.bin having to be killed by hand is a futex > > issue in combination with a high number of threads. this is the output of a > > test from darren hart's futex test suite under freebsd 9.0: > > > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=1 > > Result: 18622 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=2 > > Result: 15469 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=3 > > Result: 12713 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=4 > > Result: 12247 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=5 > > Result: 11814 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=6 > > Result: 13468 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=8 > > Result: 12061 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=10 > > Result: 12854 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=12 > > Result: 12999 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=16 > > Result: 12402 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=24 > > Result: 9815 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=32 > > Result: 8518 Kiter/s > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=64 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=128 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=256 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=512 > > ERROR: Resource temporarily unavailable: pthread_create > > Result: ERROR > > futex_wait: Measure FUTEX_WAIT operations per second > > Arguments: iterations=1 threads=1024 > > ERROR: Resource temporarily unavailable:
Re: FreeBSD Installer Roadmap
On 02/22/11 11:14, John Baldwin wrote: On Tuesday, February 22, 2011 11:26:33 am Nathan Whitehorn wrote: On 02/22/11 06:45, John Baldwin wrote: On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: Sysinstall is fine, as I'm sure any replacement will be. So I'll just note a few things I'd like to see in any such replacement... 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separate.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. Actually, you can do that if you are a bit creative (add a few more tools to the mfsroot, and use the 'system' command in install.cfg to invoke a shell script that then generates a foo.cfg you later include via loadConfig, but I've covered that at multiple conferences by now). That said, I'm hopeful that the new installer will be more flexible in less hackish ways while letting you do things like PXE boot to a shell where you can use mfiutil to create a RAID-5 volume and then invoke the installer on that, etc. This is something that I very explicitly built in to the design of bsdinstall. When the installer starts (as well as at several other points), you are offered an option to bring up a shell specifically to do things like this. Scripted installs are just shell scripts instead of a configuration file, so it is trivial to interleave complicated things like this. Yes, I should have worded it a bit differently in that I do actually think that is true from what little I have seen and the "hopeful" bit more refers to my being able to adopt it locally. Ah, understood. Speaking of which, there is a new amd64 snapshot ISO with bsdinstall on it (an i386 ISO should follow in the next day or so): http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2 This is more or less the planned final form of the installer and layout of the install media, so I would very much appreciate testing at this point. Pending a small patch to the distributeworld target currently under review, this will be followed by patches to the release Makefile to change the default installer to bsdinstall in -CURRENT. Barring any objections, I hope to have that second patch in the tree by mid-March. -Nathan ___ 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: Wow... (<-- blown away at performance)
On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best wrote: > On Tue Feb 22 11, Garrett Cooper wrote: >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: >> > On 22 February 2011 11:15, Garrett Cooper wrote: >> >> I don't know what to say, but r218938 screams with flash videos >> >> (native Linux speed). Not sure if it's the new binutils or if it's the >> >> new linuxulator patches, but I can run multiple instances of youtube >> >> in parallel (5 total with other miscellaneous flash animation) without >> >> it totally lagging out Firefox/X11, and it appears to close the >> >> instances of firefox properly now. Hopefully this version fares better >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, >> >> where my system just hardlocked for no apparent reason). >> >> Anyhow, hope others have similar results. >> >> Cheers! >> >> -Garrett >> >> >> >> $ uname -a >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: >> >> Mon Feb 21 23:10:51 PST 2011 >> >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >> > >> > Which FlashPlayer version do you test? Adobe has made significant >> > performance changes in 10.2 (from 10.1). You can search for StageVideo >> > performance to learn more about. Youtube already use them since 10.2 >> > beta >> >> linux-f10-flashplugin-10.1r102.65 . The performance increases are >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a >> more than 200% increase (now it actually scales between multiple >> instances, instead of croaks with one instance, tiling up and down the >> screen when moving the window slider for instance or switching tabs). >> Besides, it seems like it needs external support from the video >> driver, and I'm not sure that that bridge exists in the linuxulator. >> Also, it looks like npviewer.bin still hangs to resources on until >> Firefox closes (or I kill it :)..), so something still needs to be >> resolved there, but that isn't a regression (it's acted that way for >> ages), and shouldn't be too hard to do. > > i think the problem with npviewer.bin having to be killed by hand is a futex > issue in combination with a high number of threads. this is the output of a > test from darren hart's futex test suite under freebsd 9.0: > > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=1 > Result: 18622 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=2 > Result: 15469 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=3 > Result: 12713 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=4 > Result: 12247 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=5 > Result: 11814 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=6 > Result: 13468 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=8 > Result: 12061 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=10 > Result: 12854 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=12 > Result: 12999 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=16 > Result: 12402 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=24 > Result: 9815 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=32 > Result: 8518 Kiter/s > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=64 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=128 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=256 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=512 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > futex_wait: Measure FUTEX_WAIT operations per second > Arguments: iterations=1 threads=1024 > ERROR: Resource temporarily unavailable: pthread_create > Result: ERROR > > cheers. > alex Have you found any method or workaround to mitigate this issue? -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freeb
Re: current repeateble crash in 2 places
On 21 February 2011 13:26, Andrey Smagin wrote: > today current > crash with loaded mpd5 > > 1st place: > ipwf_chk > ipfw_check_hook > pfil_run_hooks > ip_output > tcp_output repeated > tcp_mtudisc ~20 times > tcp_ctlinput > icmp_input > ip_input > swi_net > intr_event_execute_handlers > > 2nd place > flowtable_lookup > flowteble_lookup_mbuf > ip_output > tcp_output ~ repeated > tcp_mtudisc 20 times > tcp_ctlinput > icmp_input > ip_input > netisr_dispatch_src > ng_iface_rcvdata > ng_apply_item repeated > ng_snd_item 3 > ng_pppoe_rcvdata_ether times > ng_apply_item > ng_snd_item > ether_demux > ether_input > em_rxeof > em_msix_rx > inthr_event_execute_handlers > ithread_loop > > What does it mean? > ___ > 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: Process timing issue
Jerome Flesch wrote this message on Tue, Feb 22, 2011 at 10:22 +0100: > We expected both processes (the test program and openssl) to have each > half the CPU time and being scheduled quite often (at least once each > 10ms). According to the output of our test program, it works fine for > most of the calls to clock_gettime(), but from time to time (about 1 > loop in 20 on my computer), we have a latency pike (>= 100ms). Are you sure there isn't a cron task or something else that is suddenly waking up, causing a large CPU spike? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: Wow... (<-- blown away at performance)
On Tue Feb 22 11, Garrett Cooper wrote: > On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > > On 22 February 2011 11:15, Garrett Cooper wrote: > >> I don't know what to say, but r218938 screams with flash videos > >> (native Linux speed). Not sure if it's the new binutils or if it's the > >> new linuxulator patches, but I can run multiple instances of youtube > >> in parallel (5 total with other miscellaneous flash animation) without > >> it totally lagging out Firefox/X11, and it appears to close the > >> instances of firefox properly now. Hopefully this version fares better > >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > >> where my system just hardlocked for no apparent reason). > >> Anyhow, hope others have similar results. > >> Cheers! > >> -Garrett > >> > >> $ uname -a > >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > >> Mon Feb 21 23:10:51 PST 2011 > >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > > Which FlashPlayer version do you test? Adobe has made significant > > performance changes in 10.2 (from 10.1). You can search for StageVideo > > performance to learn more about. Youtube already use them since 10.2 > > beta > > linux-f10-flashplugin-10.1r102.65 . The performance increases are > claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > more than 200% increase (now it actually scales between multiple > instances, instead of croaks with one instance, tiling up and down the > screen when moving the window slider for instance or switching tabs). > Besides, it seems like it needs external support from the video > driver, and I'm not sure that that bridge exists in the linuxulator. > Also, it looks like npviewer.bin still hangs to resources on until > Firefox closes (or I kill it :)..), so something still needs to be > resolved there, but that isn't a regression (it's acted that way for > ages), and shouldn't be too hard to do. i think the problem with npviewer.bin having to be killed by hand is a futex issue in combination with a high number of threads. this is the output of a test from darren hart's futex test suite under freebsd 9.0: futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1 Result: 18622 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=2 Result: 15469 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=3 Result: 12713 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=4 Result: 12247 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=5 Result: 11814 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=6 Result: 13468 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=8 Result: 12061 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=10 Result: 12854 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=12 Result: 12999 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=16 Result: 12402 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=24 Result: 9815 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=32 Result: 8518 Kiter/s futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=64 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=128 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=256 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=512 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR futex_wait: Measure FUTEX_WAIT operations per second Arguments: iterations=1 threads=1024 ERROR: Resource temporarily unavailable: pthread_create Result: ERROR cheers. alex > Thanks, > -Garrett -- a13x ___ 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: Process timing issue
On Feb 22, 2011, at 1:22 AM, Jerome Flesch wrote: >> A scheduler quantum of 10ms (or HZ=100) is a common granularity; probably >> some other process got the CPU and your timer process didn't run until the >> next or some later scheduler tick. If you are maxing out the available CPU >> by running many "openssl speed" tasks, then this behavior is more-or-less >> expected. >> > > We did most of our tests with kern.hz=1000 (the default FreeBSD value as far > as I know) and we also tried with kern.hz=2000 and kern.hz=1. It didn't > change a thing. For a long time kern.hz=100 was the default; more recent versions have switched to kern.hz=1000, which is beneficial for minimizing latency for things like ipfw/dummynet processing, but also involve greater scheduler overhead. kern.hz=1 is likely to reduce performance and may have odd effects upon certain kernel timers. > Also, we are talking about a process not being scheduled for more than 100ms > with only 1 instance of openssl on the same CPU core. Even with a scheduler > quantum of 10ms, I find that worrying :/ It depends on what else the machine is doing. Gathering some data via acct/sa might be informative, as you might be running some other tasks via cron or whatever which your testing isn't expecting. > We expected both processes (the test program and openssl) to have each half > the CPU time and being scheduled quite often (at least once each 10ms). > According to the output of our test program, it works fine for most of the > calls to clock_gettime(), but from time to time (about 1 loop in 20 on my > computer), we have a latency pike (>= 100ms). > > Thing is, these pikes wouldn't worry us much if they wouldn't last longer > than 1s, but they do on some occasions. Also, are you sure that you don't have ntpdate or ntpd or something else adjusting your system clock underneath you...? Regards, -- -Chuck ___ 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"
binutils 2.17.50 and ctfconvert
Since binutils 2.17.50 import, WITH_CTF=1 & buildworld on amd64 stops like this: ===> lib/librt (all) cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/aio.c cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -pg -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/aio.c -o aio.po ctfconvert -L VERSION aio.po cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/aio.c -o aio.So ctfconvert -L VERSION aio.o cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/mq.c ctfconvert -L VERSION aio.So cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -pg -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/mq.c -o mq.po ctfconvert -L VERSION mq.o cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/mq.c -o mq.So ctfconvert -L VERSION mq.po cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/sigev_thread.c ctfconvert -L VERSION mq.So cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -pg -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/sigev_thread.c -o sigev_thread.po ctfconvert -L VERSION sigev_thread.o cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/librt/sigev_thread.c -o sigev_thread.So ctfconvert -L VERSION sigev_thread.po cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -fno-omit-frame-pointer -I/usr/src/lib/librt/../libc/include -I/usr/src/lib/librt -fexceptions -Winline -Wall -g -std=gnu99 -fstack-protector -Wsystem-h
Re: Can't buildworld since Clang update
On 22 February 2011 21:11, Dimitry Andric wrote: > On 2011-02-22 18:38, datastream datastream.freecity wrote: >> >> In /etc/make.conf, I only add 'CFLAGS+=-fno-omit-frame-pointer'.And >> removed >> all files in /usr/obj. /usr/src sync with >> http://svn.freebsd.org/base/head. >> #make buildkernel > > Before you do "make buildkernel", always run "make buildworld", or at > least "make kernel-toolchain". This ensures you have an up-to-date ld > (and other tools) under /usr/obj. > > That said, these steps are normally only needed when e.g. binutils or > other toolchain components have been upgraded. This has happened so > seldom in the past few years, that people seem to have forgotten how > bootstrapping works. :) Nope! `make kernel-toolchain` is also important for cross-compile builds to be sure that anything is done. > ___ > 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: Can't buildworld since Clang update
On 2011-02-22 18:38, datastream datastream.freecity wrote: In /etc/make.conf, I only add 'CFLAGS+=-fno-omit-frame-pointer'.And removed all files in /usr/obj. /usr/src sync with http://svn.freebsd.org/base/head. #make buildkernel Before you do "make buildkernel", always run "make buildworld", or at least "make kernel-toolchain". This ensures you have an up-to-date ld (and other tools) under /usr/obj. That said, these steps are normally only needed when e.g. binutils or other toolchain components have been upgraded. This has happened so seldom in the past few years, that people seem to have forgotten how bootstrapping works. :) ___ 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: Can't buildworld since Clang update
In /etc/make.conf, I only add 'CFLAGS+=-fno-omit-frame-pointer'.And removed
all files in /usr/obj. /usr/src sync with http://svn.freebsd.org/base/head.
#make buildkernel
MAKE=make sh /usr/src/sys/conf/newvers.sh G9laptop
/usr/local/bin/svnversion
clang -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -nostdinc -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone
-mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector vers.c
clang: warning: argument unused during compilation: '-frename-registers'
clang: warning: argument unused during compilation: '-mfpmath=387'
linking kernel
ld:/usr/src/sys/conf/ldscript.amd64:9: syntax error
*** Error code 1
On Tue, Feb 22, 2011 at 11:44 PM, Manfred Antar wrote:
> At 07:07 AM 2/21/2011, Dimitry Andric wrote:
> >On 2011-02-21 11:33, Olivier Smedts wrote:
> >>I can't buildworld with Clang since the last update.
> >...
> >>%cat /etc/src.conf
> >>.if !defined(CC) || ${CC} == "cc"
> >>CC=clang
> >>.endif
> >>.if !defined(CXX) || ${CXX} == "c++"
> >>CXX=clang++
> >>.endif
> >># Don't die on warnings
> >>NO_WERROR=
> >>WERROR=
> >
> >Try putting these lines in /etc/make.conf instead. Unfortunately, due
> >to the way src.conf is read, it isn't usable for the few cases we need
> >to disable clang's integrated assembler, using the '-no-integrated-as'
> >option.
> >
> >
> >>/tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now
> >>.intel_syntax noprefix
> >>^
> >
> >I too am having trouble with buildworld
> >I switched back to standard /usr/bin/cc, but make buildworld stops here:
> >
> >c++ -O2 -pipe
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd9.0\"
> -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -c
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp
> >building static llvmsupport library
> >ranlib libllvmsupport.a
> >===> lib/clang/libllvmsystem (obj,depend,all,install)
> >cd: can't cd to /usr/src/lib/clang/libllvmsystem
> >*** Error code 2
> >
> >Stop in /usr/src.
> >*** Error code 1
> >
> >Stop in /usr/src.
> >*** Error code 1
> >
> >Stop in /usr/src.
> >
> >Last night i deleted /usr/src and did a fresh cvsup
> >Still same problem
>
> Turns out that cvsup10.us.freebsd.org which i was using is not up to date.
> I'm using cvsup.us.freebsd.org now and am getting many new updates.
>
>
> >==
> >|| n...@pozo.com ||
> >|| Ph. (415) 681-6235 ||
> >==
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> ___
> 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: FreeBSD Installer Roadmap
On Tuesday, February 22, 2011 11:26:33 am Nathan Whitehorn wrote: > On 02/22/11 06:45, John Baldwin wrote: > > On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: > >> Sysinstall is fine, as I'm sure any replacement will be. So I'll > >> just note a few things I'd like to see in any such replacement... > >> > >> 1 - I used install.cfg's on floppies to clone systems, a lot. Hands > >> on the box were needed with that. Operators skills were in question, > >> so having them use the dialog menus properly was a pain and often > >> resulted in non-zeroed disk or half built systems. And though all > >> else was cloned, it needed a separate.cfg for each box due > >> to: > >> > >> fqdn, gateway, ip/mask > >> interface - sometimes changed > >> root disk - sometimes changed > >> > >> Would have killed for a simple console shell script to ask those > >> questions of the operator, per machine. > > > > Actually, you can do that if you are a bit creative (add a few more tools to > > the mfsroot, and use the 'system' command in install.cfg to invoke a shell > > script that then generates a foo.cfg you later include via loadConfig, but > > I've covered that at multiple conferences by now). That said, I'm hopeful > > that the new installer will be more flexible in less hackish ways while > > letting you do things like PXE boot to a shell where you can use mfiutil to > > create a RAID-5 volume and then invoke the installer on that, etc. > > This is something that I very explicitly built in to the design of > bsdinstall. When the installer starts (as well as at several other > points), you are offered an option to bring up a shell specifically to > do things like this. Scripted installs are just shell scripts instead of > a configuration file, so it is trivial to interleave complicated things > like this. Yes, I should have worded it a bit differently in that I do actually think that is true from what little I have seen and the "hopeful" bit more refers to my being able to adopt it locally. -- 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: Wow... (<-- blown away at performance)
On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym wrote: > On 22 February 2011 11:15, Garrett Cooper wrote: >> I don't know what to say, but r218938 screams with flash videos >> (native Linux speed). Not sure if it's the new binutils or if it's the >> new linuxulator patches, but I can run multiple instances of youtube >> in parallel (5 total with other miscellaneous flash animation) without >> it totally lagging out Firefox/X11, and it appears to close the >> instances of firefox properly now. Hopefully this version fares better >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, >> where my system just hardlocked for no apparent reason). >> Anyhow, hope others have similar results. >> Cheers! >> -Garrett >> >> $ uname -a >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: >> Mon Feb 21 23:10:51 PST 2011 >> gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > Which FlashPlayer version do you test? Adobe has made significant > performance changes in 10.2 (from 10.1). You can search for StageVideo > performance to learn more about. Youtube already use them since 10.2 > beta linux-f10-flashplugin-10.1r102.65 . The performance increases are claimed to be "up to 85%" on the Stage Video site, but I'm seeing a more than 200% increase (now it actually scales between multiple instances, instead of croaks with one instance, tiling up and down the screen when moving the window slider for instance or switching tabs). Besides, it seems like it needs external support from the video driver, and I'm not sure that that bridge exists in the linuxulator. Also, it looks like npviewer.bin still hangs to resources on until Firefox closes (or I kill it :)..), so something still needs to be resolved there, but that isn't a regression (it's acted that way for ages), and shouldn't be too hard to do. 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: FreeBSD Installer Roadmap
On 02/22/11 06:45, John Baldwin wrote: On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: Sysinstall is fine, as I'm sure any replacement will be. So I'll just note a few things I'd like to see in any such replacement... 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separate.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. Actually, you can do that if you are a bit creative (add a few more tools to the mfsroot, and use the 'system' command in install.cfg to invoke a shell script that then generates a foo.cfg you later include via loadConfig, but I've covered that at multiple conferences by now). That said, I'm hopeful that the new installer will be more flexible in less hackish ways while letting you do things like PXE boot to a shell where you can use mfiutil to create a RAID-5 volume and then invoke the installer on that, etc. This is something that I very explicitly built in to the design of bsdinstall. When the installer starts (as well as at several other points), you are offered an option to bring up a shell specifically to do things like this. Scripted installs are just shell scripts instead of a configuration file, so it is trivial to interleave complicated things like this. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Force stdio output streams to line-buffered mode
On Saturday, February 19, 2011 1:50:43 pm Jeremie Le Hen wrote: > Hi, > > I've been annoyed multiple time when running a command such like > iostat -x 1 | grep -v ad10 | cat -n > > The problem stems from two factors: > - grep's stdio sees that its stdout is not a terminal, so stdout is > full buffered and not line-buffered; > - iostat produces output too slowly so the aforementioned buffer takes > numerous seconds to be filled and flushed to the last command. > > This problems is not specific to FreeBSD, it is actually a consequence > of POSIX specification. I've checked this on Solaris and Linux. > > I've attached a small patch for stdio, so if the environment variable > STDIO_IOLBF is set, the output streams will be line-oriented by default. > iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n > > Before send it as a PR, I would like to hear your comments about this, > especially: > - the variable name (no bikeshed please, I just ask this if there is a > naming convention I'm not aware of); > - the documentation: I've put a hint in stdio(3) manpage and put the > full explanation in setvbuf(3). Many people would find this useful I think. -- 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: Use meaningful directory prefixes in lib32 build
On Friday, February 18, 2011 8:17:31 am Ulrich Spörlein wrote:
> On Tue, 15.02.2011 at 16:18:21 -0500, John Baldwin wrote:
> > This patch adjusts the various lib32 targets to use a suitable DIRPRFX so
> > that
> > when lib32 builds certain areas of the tree the full path to those areas
> > shows
> > up in the make output:
> >
> > Index: Makefile.inc1
> > ===
> > --- Makefile.inc1 (revision 218554)
> > +++ Makefile.inc1 (working copy)
> > @@ -457,36 +457,38 @@ build32:
> > .for _t in obj depend all
> > cd ${.CURDIR}/kerberos5/tools; \
> > MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS= DESTDIR= \
> > - ${_t}
> > + DIRPRFX=kerberos5/tools/ ${_t}
> > .endfor
> > .endif
> > .for _t in obj includes
> > - cd ${.CURDIR}/include; ${LIB32WMAKE} ${_t}
> > - cd ${.CURDIR}/lib; ${LIB32WMAKE} ${_t}
> > + cd ${.CURDIR}/include; ${LIB32WMAKE} DIRPRFX=include/ ${_t}
> > + cd ${.CURDIR}/lib; ${LIB32WMAKE} DIRPRFX=lib/ ${_t}
> > .if ${MK_CDDL} != "no"
> > - cd ${.CURDIR}/cddl/lib; ${LIB32WMAKE} ${_t}
> > + cd ${.CURDIR}/cddl/lib; ${LIB32WMAKE} DIRPRFX=cddl/lib/ ${_t}
> > .endif
> > - cd ${.CURDIR}/gnu/lib; ${LIB32WMAKE} ${_t}
> > + cd ${.CURDIR}/gnu/lib; ${LIB32WMAKE} DIRPRFX=gnu/lib/ ${_t}
> > .if ${MK_CRYPT} != "no"
> > - cd ${.CURDIR}/secure/lib; ${LIB32WMAKE} ${_t}
> > + cd ${.CURDIR}/secure/lib; ${LIB32WMAKE} DIRPRFX=secure/lib/ ${_t}
> > .endif
> > .if ${MK_KERBEROS} != "no"
> > - cd ${.CURDIR}/kerberos5/lib; ${LIB32WMAKE} ${_t}
> > + cd ${.CURDIR}/kerberos5/lib; ${LIB32WMAKE} DIRPRFX=kerberos5/lib ${_t}
> > .endif
> > .endfor
> > .for _dir in usr.bin/lex/lib
> > - cd ${.CURDIR}/${_dir}; ${LIB32WMAKE} obj
> > + cd ${.CURDIR}/${_dir}; ${LIB32WMAKE} DIRPRFX=${_dir}/ obj
> > .endfor
> > .for _dir in lib/ncurses/ncurses lib/ncurses/ncursesw lib/libmagic
> > cd ${.CURDIR}/${_dir}; \
> > MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS= DESTDIR= \
> > - build-tools
> > + DIRPRFX=${_dir}/ build-tools
> > .endfor
> > cd ${.CURDIR}; \
> > ${LIB32WMAKE} -f Makefile.inc1 libraries
> > .for _t in obj depend all
> > - cd ${.CURDIR}/libexec/rtld-elf; PROG=ld-elf32.so.1 ${LIB32WMAKE} ${_t}
> > - cd ${.CURDIR}/usr.bin/ldd; PROG=ldd32 ${LIB32WMAKE} ${_t}
> > + cd ${.CURDIR}/libexec/rtld-elf; PROG=ld-elf32.so.1 ${LIB32WMAKE} \
> > + DIRPRFX=libexec/rtld-elf/ ${_t}
> > + cd ${.CURDIR}/usr.bin/ldd; PROG=ldd32 ${LIB32WMAKE} \
> > + DIRPRFX=usr.bin/ldd ${_t}
> > .endfor
> >
> > distribute32 install32:
>
> I have no idea what DIRPRFX actually does, but will it also move the
> actual OBJDIR location to something more sensible, or is only make's
> (terminal) output affected?
It just affects terminal output:
bsd.subdir.mk: ${ECHODIR} "===>
${DIRPRFX}$${entry}.${MACHINE_ARCH} (${.TARGET:realinstall=install})"; \
bsd.subdir.mk: ${ECHODIR} "===> ${DIRPRFX}$$entry
(${.TARGET:realinstall=install})"; \
bsd.subdir.mk: DIRPRFX=${DIRPRFX}$$edir/; \
--
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: FreeBSD Installer Roadmap
On Saturday, February 19, 2011 4:34:11 am grarpamp wrote: > Sysinstall is fine, as I'm sure any replacement will be. So I'll > just note a few things I'd like to see in any such replacement... > > 1 - I used install.cfg's on floppies to clone systems, a lot. Hands > on the box were needed with that. Operators skills were in question, > so having them use the dialog menus properly was a pain and often > resulted in non-zeroed disk or half built systems. And though all > else was cloned, it needed a separate .cfg for each box due > to: > > fqdn, gateway, ip/mask > interface - sometimes changed > root disk - sometimes changed > > Would have killed for a simple console shell script to ask those > questions of the operator, per machine. Actually, you can do that if you are a bit creative (add a few more tools to the mfsroot, and use the 'system' command in install.cfg to invoke a shell script that then generates a foo.cfg you later include via loadConfig, but I've covered that at multiple conferences by now). That said, I'm hopeful that the new installer will be more flexible in less hackish ways while letting you do things like PXE boot to a shell where you can use mfiutil to create a RAID-5 volume and then invoke the installer on that, etc. -- 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: Can't buildworld since Clang update
At 07:07 AM 2/21/2011, Dimitry Andric wrote:
>On 2011-02-21 11:33, Olivier Smedts wrote:
>>I can't buildworld with Clang since the last update.
>...
>>%cat /etc/src.conf
>>.if !defined(CC) || ${CC} == "cc"
>>CC=clang
>>.endif
>>.if !defined(CXX) || ${CXX} == "c++"
>>CXX=clang++
>>.endif
>># Don't die on warnings
>>NO_WERROR=
>>WERROR=
>
>Try putting these lines in /etc/make.conf instead. Unfortunately, due
>to the way src.conf is read, it isn't usable for the few cases we need
>to disable clang's integrated assembler, using the '-no-integrated-as'
>option.
>
>
>>/tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now
>>.intel_syntax noprefix
>>^
>
>I too am having trouble with buildworld
>I switched back to standard /usr/bin/cc, but make buildworld stops here:
>
>c++ -O2 -pipe
>-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
>-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
>-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
>-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
>-D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd9.0\"
>-I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -c
>/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp
>building static llvmsupport library
>ranlib libllvmsupport.a
>===> lib/clang/libllvmsystem (obj,depend,all,install)
>cd: can't cd to /usr/src/lib/clang/libllvmsystem
>*** Error code 2
>
>Stop in /usr/src.
>*** Error code 1
>
>Stop in /usr/src.
>*** Error code 1
>
>Stop in /usr/src.
>
>Last night i deleted /usr/src and did a fresh cvsup
>Still same problem
Turns out that cvsup10.us.freebsd.org which i was using is not up to date.
I'm using cvsup.us.freebsd.org now and am getting many new updates.
>==
>|| n...@pozo.com ||
>|| Ph. (415) 681-6235 ||
>==
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
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: Can't buildworld since Clang update
On 2011-02-22 16:16, Manfred Antar wrote: I too am having trouble with buildworld I switched back to standard /usr/bin/cc, but make buildworld stops here: c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd9.0\" -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp building static llvmsupport library ranlib libllvmsupport.a ===> lib/clang/libllvmsystem (obj,depend,all,install) cd: can't cd to /usr/src/lib/clang/libllvmsystem libllvmsystem does not exist anymore, and has been eliminated from lib/clang/Makefile. Your tree is out of date, or inconsistently updated. Try using another cvsup mirror. ___ 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: Can't buildworld since Clang update
At 07:07 AM 2/21/2011, Dimitry Andric wrote:
>On 2011-02-21 11:33, Olivier Smedts wrote:
>>I can't buildworld with Clang since the last update.
>...
>>%cat /etc/src.conf
>>.if !defined(CC) || ${CC} == "cc"
>>CC=clang
>>.endif
>>.if !defined(CXX) || ${CXX} == "c++"
>>CXX=clang++
>>.endif
>># Don't die on warnings
>>NO_WERROR=
>>WERROR=
>
>Try putting these lines in /etc/make.conf instead. Unfortunately, due
>to the way src.conf is read, it isn't usable for the few cases we need
>to disable clang's integrated assembler, using the '-no-integrated-as'
>option.
>
>
>>/tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now
>>.intel_syntax noprefix
>>^
>
>I too am having trouble with buildworld
>I switched back to standard /usr/bin/cc, but make buildworld stops here:
>
>c++ -O2 -pipe
>-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
>-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
>-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
>-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
>-D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd9.0\"
>-I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -c
>/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp
>building static llvmsupport library
>ranlib libllvmsupport.a
>===> lib/clang/libllvmsystem (obj,depend,all,install)
>cd: can't cd to /usr/src/lib/clang/libllvmsystem
>*** Error code 2
>
>Stop in /usr/src.
>*** Error code 1
>
>Stop in /usr/src.
>*** Error code 1
>
>Stop in /usr/src.
>
>Last night i deleted /usr/src and did a fresh cvsup
>Still same problem
>
>==
>|| n...@pozo.com ||
>|| Ph. (415) 681-6235 ||
>==
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
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: Can't buildworld since Clang update
On 2011-02-22 15:37, datastream datastream.freecity wrote: I add '-no-integrated-as' in /etc/make.conf,but I still failed. Don't do that. The few instances where the integrated assembler needs to be disabled are already covered. ... /usr/obj/usr/src/tmp/lib/libthr.so.3: undefined reference to `_rtld_get_stack_prot' Something seems to be seriously wrong in your tree. Can you try to blow away /usr/obj entirely, remove the -no-integrated-as flag from make.conf, and try again? ___ 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: Can't buildworld since Clang update
I add '-no-integrated-as' in /etc/make.conf,but I still failed.
#clang -v
FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007
Target: x86_64-undermydesk-freebsd9.0
Thread model: posix
#make buildworld
..
===> cddl/usr.bin/zinject (all)
clang -O2 -pipe -fno-omit-frame-pointer -no-integrated-as
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris
-I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/include
-I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head
-I/usr/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN
-std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -c
/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c
clang -O2 -pipe -fno-omit-frame-pointer -no-integrated-as
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris
-I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/include
-I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head
-I/usr/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN
-std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -c
/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c
/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:209:10:
warning:
10 enumeration values not handled in switch: 'TYPE_MOS',
'TYPE_MOSDIR',
'TYPE_METASLAB'... [-Wswitch-enum]
switch (type) {
^
/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:323:11:
warning:
5 enumeration values not handled in switch: 'TYPE_DATA', 'TYPE_DNODE',
'TYPE_LABEL_UBERBLOCK'... [-Wswitch-enum]
switch (type) {
^
/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:449:10:
warning:
10 enumeration values not handled in switch: 'TYPE_DATA',
'TYPE_DNODE',
'TYPE_MOS'... [-Wswitch-enum]
switch (label_type) {
^
3 warnings generated.
clang -O2 -pipe -fno-omit-frame-pointer -no-integrated-as
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris
-I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/include
-I/usr/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys
-I/usr/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common
-I/usr/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head
-I/usr/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN
-std=gnu89 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas -o
zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs
-lzpool
clang: warning: argument unused during compilation: '-std=gnu89'
/usr/obj/usr/src/tmp/lib/libthr.so.3: undefined reference to
`_rtld_get_stack_prot'
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
*** Error code 1
Stop in /usr/src/cddl/usr.bin/zinject.
*** Error code 1
Stop in /usr/src/cddl/usr.bin.
*** Error code 1
Stop in /usr/src/cddl.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
On Mon, Feb 21, 2011 at 11:07 PM, Dimitry Andric wrote:
> On 2011-02-21 11:33, Olivier Smedts wrote:
>
>> I can't buildworld with Clang since the last update.
>>
> ...
>
> %cat /etc/src.conf
>> .if !defined(CC) || ${CC} == "cc"
>> CC=clang
>> .endif
>> .if !defined(CXX) || ${CXX} == "c++"
>> CXX=clang++
>> .endif
>> # Don't die on warnings
>> NO_WERR
Re: OpenSSL 1.0.0d for Freebsd HEAD
Dears, After several research, i have removed the problematic part. You can find the new version here: http://people.freebsd.org/~fabient/patch-head20110222-openssl1.0.0d Regards, -- Alexandre Martins Research engineer NETASQ On Monday 14 February 2011 17:18:24 Alexandre Martins wrote: > Dear, > > Thank you for your feed-back. > > I'll look for this issu, and i hope deliver a better patch quickly. > > Regards, > > > Alexandre Martins writes: > > > For those interested in testing, you can find a patch that add OpenSSL > > > 1.0d to head. > > > > [...] > > > > Hmm, doesn't build with ld(1) from /projects/binutils-2.17. > > > > $ make -dl all > > as -o rc4-amd64.o /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > > rc4-amd64.o > > > > && ctfconvert -L VERSION rc4-amd64.o) echo building static crypto > > library > > > > building static crypto library > > rm -f libcrypto.a > > ar cq libcrypto.a `lorder ...` > > ranlib libcrypto.a > > as -o rc4-amd64.po /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > > > > rc4-amd64.po && ctfconvert -L VERSION rc4-amd64.po) echo building > > profiled crypto library > > > > building profiled crypto library > > rm -f libcrypto_p.a > > ar cq libcrypto_p.a `lorder ...` > > ranlib libcrypto_p.a > > as -o rc4-amd64.So /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > > > > rc4-amd64.So && ctfconvert -L VERSION rc4-amd64.So) echo building shared > > library libcrypto.so.7 > > > > building shared library libcrypto.so.7 > > rm -f libcrypto.so.7 libcrypto.so > > ln -fs libcrypto.so.7 libcrypto.so > > cc -fstack-protector -shared -Wl,-x -o libcrypto.so.7 > > > > -Wl,-soname,libcrypto.so.7 `lorder ...` /usr/bin/ld: rc4-amd64.So: > > relocation R_X86_64_PC32 against `OPENSSL_ia32cap_P' can not be used when > > making a shared object; recompile with -fPIC /usr/bin/ld: final link > > failed: Bad value > > > > *** Error code 1 > > > > Reverting back to binutils-2.15 makes build fail with another error. > > libcrypto builds fine but linking against it always fails > > > > $ cc foo.c -lcrypto > > /usr/lib/libcrypto.so: undefined reference to > > `_x86_64_Camellia_decrypt' /usr/lib/libcrypto.so: undefined reference > > to `.Ldloop' > > > > Indeed, some parts are missing > > > > %% diff against output from cmll-x86_64.pl > > --- secure/lib/libcrypto/amd64/cmll_amd64.s > > +++ crypto/openssl/crypto/camellia/asm/cmll-x86_64.pl.out > > > > @@ -312,6 +312,170 @@ Camellia_DecryptBlock_Rounds: > > call_x86_64_Camellia_decrypt > > signature.asc Description: This is a digitally signed message part.
Re: FreeBSD Installer Roadmap
On Feb 21, 2011, at 11:03 PM, Josh Paetzel wrote:
> On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote:
>
>>
>> Really, the crux of the issue is that our organization is **just now**
>> migrating off of FreeBSD-4 (yes, it's true... there are over 1,000
>> FreeBSD-4.11 machines running in production at this very moment spanning
>> the entire United States, parts of India, and parts of the Indo-pacific
>> rim). Worse? We just added yet-another 200+ to those ranks in the past 2
>> months.
>>
>> My hat is off to you sir... as I envy your position that you can be so
>> free-moving. We are encumbered by entrenched methods and do not have the
>> luxury of trying new things for the sake of change (case in-point, since
>> bsdinstall brings nothing new to the table that we rely upon, it truly
>> would be change for the sake of change in our organization).
>>
>> Fin de dialectics.
>>
>>
>>
>>
>> --
>> Cheers,
>> Devin Teske
>
> Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't being
> added to it, and the featureset that sysinstall supports is pretty much in
> line with the featureset in 4...no ZFS, no geom_*, etc etc etc.
>
> On the other hand, maintaining sysinstall for the next N years of new FreeBSD
> releases seems hard
Actually, it's trivial to anyone that has mastered release engineering (see
release(7) and the handbook).
> , when it's already missing features compared to what
> FreeBSD supports,
That's the operative word here ("supports"). Lord help us when that changes to
"requires" (that is to say, if/when the FreeBSD kernel becomes legacy-free with
respect to supporting fdisk/disklabel partitioned disks).
> and that's likely to continue to grow.
We've yet to see a "must have" technology that would require us to shun
sysinstall (as explained earlier, we have no desire whatsoever to boot from
ZFS, gmirror, geli, GPT, or anything else missing from sysinstall).
One such possible motivation would be if we needed to create a boot partition
that exceeds 4TB (the limits of MBR partitioning versus GPT). I just don't see
that happening (workstations, servers, pedestals... why would we ever need >8GB
for the operating system? all production data is being stored on enterprise
class devices such as the NEC-D210, and being backed up with tapes such as LTO;
In our organization every machine is expendable and we have disaster recovery
procedures for any/all failures).
>
> I totally agree that for internal use, migrating thousands of lines of code
> makes no sense whatsoever, especially if sysinstall meets your needs and you
> don't care about the functionality it doesn't have. Exporting that to the
> community seems to be a questionable use of resources.
>
> I'm no stranger to large deployments. With my ${WORK} hat on we can install
> a
> thousand FreeBSD systems in a week. In my 16+ years of involvement with
> FreeBSD I've written three automated installers...quite frankly, ditching
> sysinstall for that happened really fast.
Good work.
However, it's a shame that you found the need to ditch sysinstall. We found no
such need and have created an automated network installation process literally
on the assembly line in a factory the size of a football stadium -- responsible
for churning out thousands of machines per year with FreeBSD-4.11 pre-installed
before they arrive on-site (all using sysinstall). The hardware gets assembled
to-spec, slides down an assembly-line, a technician jacks power, network, video
and keyboard to the box, netboots it by pressing F12, waits 5 minutes for the
screen to finish installation, powers it off, and slides it down the line.
> I do admit to being a tad curious where you find systems that can run FreeBSD
> 4 at this point.
We're installing FreeBSD-4.11 onto modern systems, including:
Intel Server Chassis SC5299
Intel Server Chassis SR2500
just to name a couple.
Albeit, we've back-ported many drivers, such as mfi(3) from RELENG_6 to support
the LSI MegaSAS controller.
We're no stranger to putting even the Operating System on Life Support for as
long as it takes for our customers to bolster their budgets for an integrated
upgrade strategy.
We have a very small yet largely talented group of individuals (including
myself) within our organization that quickly and efficiently remediate lost
functionality required to maintain hardware compatibility simply because our
customers cannot stomach upgrading the OS every 18-months (or whatever the
life-cycle may be). We can't be forcing our customers to upgrade their entire
organization everytime the OS can't boot from some new controller -- not when
adding the lost functionality into the OS is only a matter of a couple weeks
work (at most).
So in earnest, I should have clarified that despite running FreeBSD-4.11 on
thousands of machines... it's actually a highly customized kernel _and_ install
process that allows us to run on moder
Re: Wow... (<-- blown away at performance)
On 22 February 2011 11:15, Garrett Cooper wrote: > I don't know what to say, but r218938 screams with flash videos > (native Linux speed). Not sure if it's the new binutils or if it's the > new linuxulator patches, but I can run multiple instances of youtube > in parallel (5 total with other miscellaneous flash animation) without > it totally lagging out Firefox/X11, and it appears to close the > instances of firefox properly now. Hopefully this version fares better > than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > where my system just hardlocked for no apparent reason). > Anyhow, hope others have similar results. > Cheers! > -Garrett > > $ uname -a > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > Mon Feb 21 23:10:51 PST 2011 > gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > ___ > 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" > Which FlashPlayer version do you test? Adobe has made significant performance changes in 10.2 (from 10.1). You can search for StageVideo performance to learn more about. Youtube already use them since 10.2 beta ___ 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: Process timing issue
On Feb 21, 2011, at 8:24 AM, Jerome Flesch wrote: While investigating a timing issue with one of our program, we found out something weird: We've written a small test program that just calls clock_gettime() a lot of times and checks that the time difference between calls makes sense. In the end, it seems it doesn't always do. Calling twice in a row clock_gettime() takes usually less than 1ms. But with an average load, about 1 time in 20, more than 10ms are spent between both calls for no apparent reason. According to our tests, when it happens, the time between both calls can go from few milliseconds to many seconds (our best score so far is 10 seconds :). Same goes for gettimeofday(). A scheduler quantum of 10ms (or HZ=100) is a common granularity; probably some other process got the CPU and your timer process didn't run until the next or some later scheduler tick. If you are maxing out the available CPU by running many "openssl speed" tasks, then this behavior is more-or-less expected. We did most of our tests with kern.hz=1000 (the default FreeBSD value as far as I know) and we also tried with kern.hz=2000 and kern.hz=1. It didn't change a thing. Also, we are talking about a process not being scheduled for more than 100ms with only 1 instance of openssl on the same CPU core. Even with a scheduler quantum of 10ms, I find that worrying :/ We expected both processes (the test program and openssl) to have each half the CPU time and being scheduled quite often (at least once each 10ms). According to the output of our test program, it works fine for most of the calls to clock_gettime(), but from time to time (about 1 loop in 20 on my computer), we have a latency pike (>= 100ms). Thing is, these pikes wouldn't worry us much if they wouldn't last longer than 1s, but they do on some occasions. We tried setting the test program to the highest priority possible (rtprio(REALTIME, RTP_PRIO_MAX)) and it doesn't seem to change a thing. Does anyone know if there is a reason for this behavior ? Is there something that can be done to improve things ? FreeBSD doesn't offer hard realtime guarantees, and it values maximizing throughput for all tasks more than it does providing absolute minimum latency even for something wanting RT. There has been some discussion in the past about making RT tasks with very high priority less pre-emptible by lower priority tasks by removing or reducing the priority lowering that occurs when a task gets allocated CPU time. What problem are you trying to solve where continuous CPU load and minimum latency realtime are both required? We are not looking for hard realtime guarantees. Most of our tests were done in normal priority. Using real time priority on our test program was just a try to see it improves things. From what I can tell, it doesn't :/ Regards, ___ 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: FreeBSD Installer Roadmap
On Tue, 2011-02-22 at 01:03 -0600, Josh Paetzel wrote: > I suppose my last question is along the lines of, "If adding geom_mirror > support to sysinstall was easy, why has it been 6+ years since gmirror made > it's appearance in FreeBSD and you still can't create or install to a gmirror > with sysinstall?" It's not been added because everyone thinks sysinstall code is horrible and won't touch it. -- Bruce Cran ___ 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"
Wow... (<-- blown away at performance)
I don't know what to say, but r218938 screams with flash videos (native Linux speed). Not sure if it's the new binutils or if it's the new linuxulator patches, but I can run multiple instances of youtube in parallel (5 total with other miscellaneous flash animation) without it totally lagging out Firefox/X11, and it appears to close the instances of firefox properly now. Hopefully this version fares better than r218113 did (I think I hit a kernel bug after 2 weeks uptime, where my system just hardlocked for no apparent reason). Anyhow, hope others have similar results. Cheers! -Garrett $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: Mon Feb 21 23:10:51 PST 2011 gcooper@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 ___ 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"
