New FreeBSD Kenel Theme
Hi all, I would like to share with you my work in Summer of Code for Producing a New FreeBSD Kernel Theme in the field of Reducing Size of Kernel for Embedded and I will be glad to receive your comments. Download the attached file please and I will be happy to connect with you or download it http://www.4shared.com/document/U237Abgs/description.html Good Luck, Mohammed Farrag ___ 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: New FreeBSD Kenel Theme
exactly and I explained with an example how I would do that practically. ___ 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: [sparc64] [panic] mutex vm object not owned
On Wednesday 09 June 2010 5:27:47 pm Nathaniel W Filardo wrote: Attempting to boot on (2-way SMP; SUN Fire V240) sparc64 a 9.0-CURRENT kernel built on Jun 9 at 14:41, and fully csup'd before building (I don't have the SVN revision number, sorry) yields, surprisingly late in the boot process, this panic: panic: mutex vm object not owned at /systank/src/sys/vm/vm_object.c:1692 cpuid = 0 KDB: stack backtrace: panic() at panic+0x1c8 _mtx_assert() at _mtx_assert+0xb0 vm_object_collapse() at vm_object_collapse+0x28 vm_object_deallocate() at vm_object_deallocate+0x538 _vm_map_unlock() at _vm_map_unlock+0x64 vm_map_remove() at vm_map_remove+0x64 vmspace_exit() at vmspace_exit+0x100 exit1() at exit1+0x788 sys_exit() at sys_exit+0x10 syscallenter() at syscallenter+0x268 syscall() at syscall+0x74 -- syscall (1, FreeBSD ELF64, sys_exit) %o7=0x11980c -- userland() at 0x406fe8c8 user trace: trap %o7=0x11980c pc 0x406fe8c8, sp 0x7fd7611 done Uptime: 4m7s The system was, at the time, attempting to bring up its jails. Anything else that would be helpful to know? Can you get a crashdump? If so, it would be good to pull up gdb and check the value sof 'object' and 'robject' in the vm_object_deallocate() frame. -- 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: [RFC] Macro to sum DPCPU vars
On Wednesday 09 June 2010 11:54:53 pm Lawrence Stewart wrote: Does anyone have objections to or feedback on the following patch? The macro simplifies the act of calculating an aggregate from DPCPU counters. http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/dpcpu_sum_9.x.r208900.patch If anyone is curious how you would use it, take a look at: I think this is fine, though I'm about to make it smaller. At Robert's request I've come up with some macros to iterate over CPUs to abstract out the CPU_ABSENT(), etc. bits. It is at www.freebsd.org/~jhb/patches/cpu_iter.patch Using CPU_FOREACH() should try your macro down slightly. -- 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: [RFC] Macro to sum DPCPU vars
On 06/10/10 22:23, John Baldwin wrote: On Wednesday 09 June 2010 11:54:53 pm Lawrence Stewart wrote: Does anyone have objections to or feedback on the following patch? The macro simplifies the act of calculating an aggregate from DPCPU counters. http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/dpcpu_sum_9.x.r208900.patch If anyone is curious how you would use it, take a look at: I think this is fine, though I'm about to make it smaller. At Robert's request I've come up with some macros to iterate over CPUs to abstract out the CPU_ABSENT(), etc. bits. It is at www.freebsd.org/~jhb/patches/cpu_iter.patch Using CPU_FOREACH() should try your macro down slightly. Nice, I'll rework my patch and commit once your new bits hit the tree. Cheers, Lawrence ___ 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: Our aging base system heimdal
On 06/07/2010 02:29 PM, Jos Backus wrote: On Mon, Jun 07, 2010 at 03:15:27PM +0100, Doug Rabson wrote: On 6 June 2010 21:09, Jos Backus j...@catnook.com wrote: Any chance the kadmin protocol will ever be standardized? My understanding is that the MIT kadmin protocol is based GSS-API authenticated RPC which FreeBSD didn't support until recently. I added working RPCSEC_GSS to our userland RPC library in 2008 and it should be available in FreeBSD 8.x and later. In theory, if MIT actually document their protocol, it should be reasonably straightforward to support it. I doubt if I will be able to do the work either for this or for upgrading heimdal. Thanks, Doug. It would be great if the Heimdal and MIT folks would cooperate on this standardization/documentation effort, but perhaps it's not seen as a priority. I think there was a little bit of compatibility work done for the 1.3.2 release of heimdal. Of course this is not the same as standardization. ___ 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: Our aging base system heimdal
On 06/06/2010 12:41 PM, b. f. wrote: Is anybody planning to update the base system heimdal, which has been largely untouched since May 2008? In addition to the many other bug-fixes and improvements in the current version 1.3.3 (see, for example: http://www.h5l.org/releases.html ), there are patches for heimdal vulnerabilities 2010-05-27 and 2010-03-21 (CVE-2010-1321), which are described at: http://www.h5l.org/advisories.html Others have mentioned that they have problems using our base system heimdal -- problems that cannot be easily circumvented by rebuilding WITHOUT_KERBEROS, and using security/krb5 (security/heimdal is badly outdated), because this leaves various dependent base system utilities behind, if they are not modified. If you adjust distinfo, pkg-list and the port Makefile, the current 1.3.3 release does build in security/heimdal - it even seems to work! YMMV, I did no serious testing, used no LDAP, etc. etc. More to the point, does using/testing as a port help pave the way for an eventual import into base ? Maintaining a port for a RELEASE might help upstream maintainers @ h5l.org stay connected to FreeBSD without having to track CURRENT (which seems somewhat more tricky cf. the utmpx issue). Since there's no active dedicated security/heimdal port maintainer, maybe the h5l.org developers could be cajoled into adding a FreeBSD machine/VM to their builds/tests/releases. With a high profile project like FreeBSD they'd at least get more up to date bug reports :-) Please excuse any ignorance of the mechanics of importing things into base and maintaining software across multiple platforms that the above post may betray ;-) cheers, gtodd ___ 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
r208985 /usr/src/sys/dev/pci/pci.c:3730: error: 'struct resource_list_entry' has no member named 'flags'
Just checked out r208985 i386. On buildkernel I get this error: cc -c -O -pipe -std=c99 -g -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-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/x86/cpufreq/hwpstate.c /usr/src/sys/dev/pci/pci.c: In function 'pci_reserve_map': /usr/src/sys/dev/pci/pci.c:3730: error: 'struct resource_list_entry' has no member named 'flags' /usr/src/sys/dev/pci/pci.c:3730: error: 'RLE_RESERVED' undeclared (first use in this function) /usr/src/sys/dev/pci/pci.c:3730: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/pci/pci.c:3730: error: for each function it appears in.) /usr/src/sys/dev/pci/pci.c: In function 'pci_delete_child': /usr/src/sys/dev/pci/pci.c:3856: warning: implicit declaration of function 'resource_list_busy' /usr/src/sys/dev/pci/pci.c:3856: warning: nested extern declaration of 'resource_list_busy' /usr/src/sys/dev/pci/pci.c:3865: warning: implicit declaration of function 'resource_list_unreserve' /usr/src/sys/dev/pci/pci.c:3865: warning: nested extern declaration of 'resource_list_unreserve' *** Error code 1 Please advise Apologies if this is a known issue many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: New event timers infrastructure
In message: 4c0e5646.1060...@freebsd.org Alexander Motin m...@freebsd.org writes: : Brandon Gooch wrote: : Alexander, do you feel that the code is at a stage where meaningful : user testing can occur? : : I think yes. I've touched a lot of legacy code, so it would be nice to : know what I may have broken. For example, i8254 and RTC drivers now more : dependent on attaching to PnP/ACPI reported hardware. I am not sure if : there still any legacy system which not doing that. The oldest system I : have tested was P-III Celeron. Unluckily my small development SSD is too : large for my Pentium board's BIOS. :) The only issue I'm aware of is that on older systems PnP and ACPI can sometimes interfere. But I thought we'd fixed those issues... I can test on my older pentium too... Warner : There is still work planned, but I hope it won't require major changes : in already written code. : : -- : Alexander Motin : ___ : 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
AK-san, PseudoCylon wrote: Hello, Sorry for taking long. But, please try following update (if_run.c and if_runvar.h) http://gitorious.org/run/run/blobs/raw/a74fa9ba5a16f1d1f058efa724261351e267a474/dev/usb/wlan/if_run.c http://gitorious.org/run/run/blobs/raw/a74fa9ba5a16f1d1f058efa724261351e267a474/dev/usb/wlan/if_runvar.h If any of client running 8.0-RELEASE please apply this patch http://svn.freebsd.org/viewvc/base/stable/8/sys/net80211/ieee80211_crypto_tkip.c?r1=199583r2=204215 Otherwise TKIP might not work. (That was the last piece of puzzle I had.) Oops, please use this if_run.c instead. http://gitorious.org/run/run/blobs/raw/b1976c8333721f88368a32dbf04f04e19ef487fc/dev/usb/wlan/if_run.c It seems like it is running without any problem so far, no more adsl modem problem. I can see arp packets in wlan0 interface as well as in macbook. I will continue testing and let you know if there comes any problem. thanks again, Ganbold AK -- Let us treat men and women well; Treat them as if they were real; Perhaps they are. -- Ralph Waldo Emerson ___ 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
clang and 'make -j' problem
nice make -j3 d DiagnosticCommonKinds.inc.h tblgen: not found *** Error code 127 *** Error code 127 tblgen -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis -I. -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/include -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST -gen-clang-stmt-nodes /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST/StmtNodes.td StmtNodes.inc.h tblgen: not found *** Error code 127 3 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Please fix. -- Steve ___ 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: [sparc64] [panic] mutex vm object not owned
On Thu, Jun 10, 2010 at 7:16 AM, John Baldwin j...@freebsd.org wrote: On Wednesday 09 June 2010 5:27:47 pm Nathaniel W Filardo wrote: Attempting to boot on (2-way SMP; SUN Fire V240) sparc64 a 9.0-CURRENT kernel built on Jun 9 at 14:41, and fully csup'd before building (I don't have the SVN revision number, sorry) yields, surprisingly late in the boot process, this panic: panic: mutex vm object not owned at /systank/src/sys/vm/vm_object.c:1692 cpuid = 0 KDB: stack backtrace: panic() at panic+0x1c8 _mtx_assert() at _mtx_assert+0xb0 vm_object_collapse() at vm_object_collapse+0x28 vm_object_deallocate() at vm_object_deallocate+0x538 _vm_map_unlock() at _vm_map_unlock+0x64 vm_map_remove() at vm_map_remove+0x64 vmspace_exit() at vmspace_exit+0x100 exit1() at exit1+0x788 sys_exit() at sys_exit+0x10 syscallenter() at syscallenter+0x268 syscall() at syscall+0x74 -- syscall (1, FreeBSD ELF64, sys_exit) %o7=0x11980c -- userland() at 0x406fe8c8 user trace: trap %o7=0x11980c pc 0x406fe8c8, sp 0x7fd7611 done Uptime: 4m7s The system was, at the time, attempting to bring up its jails. Anything else that would be helpful to know? Can you get a crashdump? If so, it would be good to pull up gdb and check the value sof 'object' and 'robject' in the vm_object_deallocate() frame. That would be useful. None of the locking changes of the last few weeks have altered the vm object locking, so this assertion failure and stack trace come as something of a surprise. Alan ___ 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
RFC: etcupdate tool in base?
I've had several folks ask me recently about importing etcupdate (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate tool for updating /etc during upgrades. Do folks have any strong objections to doing so? More details about how it works and an HTML version of the manpage can be found at the URL above. -- 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: RFC: etcupdate tool in base?
On 10-06-2010 13:46, John Baldwin wrote: I've had several folks ask me recently about importing etcupdate (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate tool for updating /etc during upgrades. Do folks have any strong objections to doing so? More details about how it works and an HTML version of the manpage can be found at the URL above. +1 for importing it into base. -- Joel ___ 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: etcupdate tool in base?
On 6/10/10 10:46 AM, John Baldwin wrote: I've had several folks ask me recently about importing etcupdate (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate tool for updating /etc during upgrades. Do folks have any strong objections to doing so? More details about how it works and an HTML version of the manpage can be found at the URL above. well mergemaster is in base so the options are: replace mergemaster, have both, move one to ports, or move both to ports. It does bring up the question (yet again) if we shouldn't have something that is between base and ports.. the keep base from bloating too much bit to still indicate that they are supported. ___ 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: etcupdate tool in base?
I've had several folks ask me recently about importing etcupdate (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate tool for updating /etc during upgrades. Do folks have any strong objections to doing so? More details about how it works and an HTML version of the manpage can be found at the URL above. -1 unless mergemaster is replaced. I'm ***not*** saying that mergemaster should be replaced. The base system would get too bloated if too many tools are added. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
kernel make noise with clang suppression
Comments? (yes, I know -fformat-extensions have just been added...)
diff -r ea5e09d013e7 sys/conf/kern.mk
--- a/sys/conf/kern.mk Thu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kern.mk Thu Jun 10 11:35:50 2010 -0700
@@ -9,6 +9,10 @@
.if ${CC} == icc
#CWARNFLAGS= -w2 # use this if you are terribly bored
CWARNFLAGS=
+.elif ${CC} == clang
+CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
+ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
+ -Wundef -Wno-pointer-sign
.else
CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
@@ -63,9 +67,15 @@
# reserved for user applications.
#
.if ${MACHINE_ARCH} == amd64
+.if ${CC} == clang
+CFLAGS+= -mcmodel=kernel -mno-red-zone \
+ -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
+ -msoft-float -fno-asynchronous-unwind-tables
+.else
CFLAGS+= -mcmodel=kernel -mno-red-zone \
-mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
-msoft-float -fno-asynchronous-unwind-tables
+.endif
INLINE_LIMIT?= 8000
.endif
diff -r ea5e09d013e7 sys/conf/kern.pre.mk
--- a/sys/conf/kern.pre.mk Thu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kern.pre.mk Thu Jun 10 11:35:50 2010 -0700
@@ -30,7 +30,11 @@
_MINUS_O= -O2
. endif
. if ${MACHINE_ARCH} == amd64
+. if ${CC} == clang
+COPTFLAGS?=-O2 -pipe
+. else
COPTFLAGS?=-O2 -frename-registers -pipe
+. endif
. else
COPTFLAGS?=${_MINUS_O} -pipe
. endif
@@ -89,7 +93,7 @@
CFLAGS=${COPTFLAGS} ${C_DIALECT} ${DEBUG} ${CWARNFLAGS}
CFLAGS+= ${INCLUDES} -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h
-.if ${CC} != icc
+.if ${CC} != icc ${CC} != clang
CFLAGS+= -fno-common -finline-limit=${INLINE_LIMIT}
CFLAGS+= --param inline-unit-growth=100
CFLAGS+= --param large-function-growth=1000
diff -r ea5e09d013e7 sys/conf/kmod.mk
--- a/sys/conf/kmod.mk Thu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kmod.mk Thu Jun 10 11:35:50 2010 -0700
@@ -111,7 +111,7 @@
# for example.
CFLAGS+= -I@/contrib/altq
-.if ${CC} != icc
+.if ${CC} != icc ${CC} != clang
CFLAGS+= -finline-limit=${INLINE_LIMIT}
CFLAGS+= --param inline-unit-growth=100
CFLAGS+= --param large-function-growth=1000
___
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: etcupdate tool in base?
on 10/06/2010 21:29 Eitan Adler said the following: I've had several folks ask me recently about importing etcupdate (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate tool for updating /etc during upgrades. Do folks have any strong objections to doing so? More details about how it works and an HTML version of the manpage can be found at the URL above. -1 unless mergemaster is replaced. Have you tried etcupdate? etcupdate and mergemaster have a similar function but do things in quite a different way. While one is intended to be more interactive, the other is more automated. They can not replace each other. I'm ***not*** saying that mergemaster should be replaced. The base system would get too bloated if too many tools are added. -- Andriy Gapon ___ 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: kernel make noise with clang suppression
On 6/10/2010 12:29 PM, Anonymous wrote:
Matthew Jacobm...@feral.com writes:
Comments? (yes, I know -fformat-extensions have just been added...)
diff -r ea5e09d013e7 sys/conf/kern.mk
--- a/sys/conf/kern.mk Thu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kern.mk Thu Jun 10 11:35:50 2010 -0700
@@ -63,9 +67,15 @@
# reserved for user applications.
#
.if ${MACHINE_ARCH} == amd64
+.if ${CC} == clang
+CFLAGS+= -mcmodel=kernel -mno-red-zone \
+ -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
Shouldn't be there all supported -msse* by clang? I for one have ssse3
and sse4.1 that are not supported by basegcc.
SSE instructions are disabled in the kernel.
___
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: etcupdate tool in base?
On 06/10/10 13:31, Mike Jakubik wrote: How does this differ from a mergemaster -iFU ? That's pretty much as automated as it can get. FYI, the -F option is usually only needed once, when switching from cvs checkout to svn checkout, or vice versa. It won't hurt anything to combine it with -U, but it may make your update slower. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of clang/LLVM about to start
Am I just being stupid or should I expect my fresh svn co to build using Clang on i386 targets? It seems to use gcc still. Do I still need src.conf set up as per the wiki page? Thanks David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2010-06-10 21:35:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-10 21:35:24 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-06-10 21:35:24 - cleaning the object tree TB --- 2010-06-10 21:35:45 - cvsupping the source tree TB --- 2010-06-10 21:35:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-06-10 21:36:22 - building world TB --- 2010-06-10 21:36:22 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-10 21:36:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-10 21:36:22 - TARGET=ia64 TB --- 2010-06-10 21:36:22 - TARGET_ARCH=ia64 TB --- 2010-06-10 21:36:22 - TZ=UTC TB --- 2010-06-10 21:36:22 - __MAKE_CONF=/dev/null TB --- 2010-06-10 21:36:22 - cd /src TB --- 2010-06-10 21:36:22 - /usr/bin/make -B buildworld World build started on Thu Jun 10 21:36:23 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 10 22:58:23 UTC 2010 TB --- 2010-06-10 22:58:23 - generating LINT kernel config TB --- 2010-06-10 22:58:23 - cd /src/sys/ia64/conf TB --- 2010-06-10 22:58:23 - /usr/bin/make -B LINT TB --- 2010-06-10 22:58:23 - building LINT kernel TB --- 2010-06-10 22:58:23 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-10 22:58:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-10 22:58:23 - TARGET=ia64 TB --- 2010-06-10 22:58:23 - TARGET_ARCH=ia64 TB --- 2010-06-10 22:58:23 - TZ=UTC TB --- 2010-06-10 22:58:23 - __MAKE_CONF=/dev/null TB --- 2010-06-10 22:58:23 - cd /src TB --- 2010-06-10 22:58:23 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 10 22:58:24 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_radiotap.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_ratectl.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_regdomain.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_scan.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param
Re: RFC: etcupdate tool in base?
On 06/10/2010 13:46, John Baldwin wrote: I've had several folks ask me recently about importing etcupdate (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate tool for updating /etc during upgrades. Do folks have any strong objections to doing so? More details about how it works and an HTML version of the manpage can be found at the URL above. Though I love the idea, I think the proper approach please dont get me wrong would be to move it into /usr/src/tools/ somewhere and create a makefile that when run just creates a symlink to it in a predetermined directory allowing folks to not really have it installed yet still update it for critical fixes while they are found without a re-install of it. MIB: +1 year Regards, -- jhell ___ 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: etcupdate tool in base?
Den 10/06/2010 kl. 22.31 skrev Mike Jakubik: On 6/10/2010 2:47 PM, Andriy Gapon wrote: on 10/06/2010 21:29 Eitan Adler said the following: -1 unless mergemaster is replaced. Have you tried etcupdate? etcupdate and mergemaster have a similar function but do things in quite a different way. While one is intended to be more interactive, the other is more automated. They can not replace each other. -1 Also. How does this differ from a mergemaster -iFU ? That's pretty much as automated as it can get. I find the ability to do 'etcupdate diff' to quickly get an overview of which changes I have made to a standard installation very useful. Looking from the outside, I think the two tools could be merged to a single upgrade tool. I see three uses for such a tool: * Show me which local modifications I have, so I can see if they're still relevant for the upgraded system * Just do all the hard work for me (i.e. mergemaster -iFU) on files I didn't change * Guide me through merging updates to files I did modify myself (and please, don't ask me innocently if I want to delete my local account when it's 4 AM :-) I may be answering 'yes' in my sleep) +1 from me on etcupdate in base. Erik
Re: RFC: etcupdate tool in base?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/10/10 10:46, John Baldwin wrote: | I've had several folks ask me recently about importing etcupdate | (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate | tool for updating /etc during upgrades. Do folks have any strong objections | to doing so? More details about how it works and an HTML version of the | manpage can be found at the URL above. Initially mergemaster was a port which gave lots of people the opportunity to gain familiarity with it easily. At some point after it had been a port for a while there was a critical mass of people suggesting that it be moved into the base system since it was one of those ports that almost everyone installed anyway. That said, I have no objection to whatever the community decides should be done with etcupdate. Given that they approach the problems of updating differently I think that there will be people who are more attracted to it instead of mergemaster, and that's fine too. :) hth, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBCAAGBQJMEUmdAAoJEFzGhvEaGryEf4UH/jj+mXScik9Oo1kQWEBRn4b6 qLpVFKScsEX5OXKXAzgu48tDA9P9rkZOsL9thlyhPR2G4CsPyIl7EpYk0o91uvV7 +GUwBhI/MXh4GFwq0p42U92wbO9lRslg9vXkV0m+KoSXnswlIuqYLkfmwhuXu1QV Mc7cE4L3Ud6xnvvcmt3NTvyKatEYqvoIgF5FjXXgMUOjpWxWnLkgV/iq7/KFA4uf o+a2yWwRVrXVv73QX5UBcjFUBbO9jDhgK/RCa5z6g7csggkK9rdzsYJedrfYMkoz 3LOGqOkC64HeJBAHhUKUl+1V/CNvK6vkbDbLRvu/FV7mHPrRB6COzw0LuRFcEWA= =msL6 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: etcupdate tool in base?
On Thursday 10 June 2010 4:22:54 pm Doug Barton wrote: On 06/10/10 10:46, John Baldwin wrote: | I've had several folks ask me recently about importing etcupdate | (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate | tool for updating /etc during upgrades. Do folks have any strong objections | to doing so? More details about how it works and an HTML version of the | manpage can be found at the URL above. Initially mergemaster was a port which gave lots of people the opportunity to gain familiarity with it easily. At some point after it had been a port for a while there was a critical mass of people suggesting that it be moved into the base system since it was one of those ports that almost everyone installed anyway. That said, I have no objection to whatever the community decides should be done with etcupdate. Given that they approach the problems of updating differently I think that there will be people who are more attracted to it instead of mergemaster, and that's fine too. :) My inclination is to simply add a port, but I had a rash of folks contact me today, so I was testing the waters to see what level of critical mass was present. -- 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: Import of clang/LLVM about to start
On Thursday 10 June 2010 23:28:03 David Sanders wrote: Am I just being stupid or should I expect my fresh svn co to build using Clang on i386 targets? It seems to use gcc still. Do I still need src.conf set up as per the wiki page? as far as i understand, only the clang binary and libraries have been added. the modifications needed to build world with clang aren't there yet -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla An optimist is a guy that has never had much experience. -- Don Marquis signature.asc Description: This is a digitally signed message part.
Re: RFC: etcupdate tool in base?
On 6/10/2010 2:47 PM, Andriy Gapon wrote: on 10/06/2010 21:29 Eitan Adler said the following: -1 unless mergemaster is replaced. Have you tried etcupdate? etcupdate and mergemaster have a similar function but do things in quite a different way. While one is intended to be more interactive, the other is more automated. They can not replace each other. -1 Also. How does this differ from a mergemaster -iFU ? That's pretty much as automated as it can get. ___ 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: kernel make noise with clang suppression
Matthew Jacob m...@feral.com writes:
Comments? (yes, I know -fformat-extensions have just been added...)
diff -r ea5e09d013e7 sys/conf/kern.mk
--- a/sys/conf/kern.mkThu Jun 10 07:40:51 2010 -0700
+++ b/sys/conf/kern.mkThu Jun 10 11:35:50 2010 -0700
@@ -63,9 +67,15 @@
# reserved for user applications.
#
.if ${MACHINE_ARCH} == amd64
+.if ${CC} == clang
+CFLAGS+= -mcmodel=kernel -mno-red-zone \
+ -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
Shouldn't be there all supported -msse* by clang? I for one have ssse3
and sse4.1 that are not supported by basegcc.
$ clang -dM -E -march=native - - | awk '/SSE/ !/MATH/'
#define __SSE2__ 1
#define __SSE3__ 1
#define __SSE4_1__ 1
#define __SSE__ 1
#define __SSSE3__ 1
If my guess is right then extracting possible GCC flags should be enough
$ gcc45 -Q --help=target -march=native | grep 'sse[[:digit:]].*'
-mno-sse4 [disabled]
-msse2 [enabled]
-msse2avx [disabled]
-msse3 [enabled]
-msse4 [disabled]
-msse4.1[enabled]
-msse4.2[disabled]
-msse4a [disabled]
-mssse3 [enabled]
and you're missing only `-mno-ssse3 -mno-sse4 -mno-sse4a'.
+ -msoft-float -fno-asynchronous-unwind-tables
+.else
CFLAGS+= -mcmodel=kernel -mno-red-zone \
-mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
-msoft-float -fno-asynchronous-unwind-tables
+.endif
INLINE_LIMIT?= 8000
.endif
___
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: etcupdate tool in base?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/10/10 11:18, Julian Elischer wrote: | It does bring up the question (yet again) if we shouldn't | have something that is between base and ports.. | the keep base from bloating too much bit to still indicate | that they are supported. Julian, This statement perpetuates the idea that somehow anything in ports is lesser than things that are in src, which frankly I'm way past being sick of. The ports tree is part of FreeBSD, period. If you don't believe me, try installing just the base without installing any ports, and then see how much work you're able to get done. Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBCAAGBQJMEUpSAAoJEFzGhvEaGryE7DMIALLAQ3oituvWpboIVi3kqkU/ G4jH4tmasyOaWXqP5qH/xtcJDFfbNEKORlDrJem8q0XKluXaw8jZKW+8dgsdBAqJ IcGVfIOWDXID4ZdMAU1wvLiqB3Ozkt0RnOnrgR+lAbstTZlX886HUpPFU0AyNJj3 EQKOIwk2SVAa5Y6lF+NPf/+M56RSnzezgU2QVGYdbnjOLqsl91SEYgBAYQN50sqi meIWJeL3iGuZ0krkkwQ3/zFlKsq5o/x76pClv+yqevVdo/EIRvaG0AfcGEPwXMdO RdN1sMkl8E+2IVpr2ruIwjN8JtAqzkC/6EhOZcvsXheeoKQLgwR4D0O58uvEUPs= =XzyJ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: etcupdate tool in base?
On 6/10/2010 4:47 PM, Erik Cederstrand wrote: -1 Also. How does this differ from a mergemaster -iFU ? That's pretty much as automated as it can get. I find the ability to do 'etcupdate diff' to quickly get an overview of which changes I have made to a standard installation very useful. Looking from the outside, I think the two tools could be merged to a single upgrade tool. I see three uses for such a tool: * Show me which local modifications I have, so I can see if they're still relevant for the upgraded system * Just do all the hard work for me (i.e. mergemaster -iFU) on files I didn't change * Guide me through merging updates to files I did modify myself (and please, don't ask me innocently if I want to delete my local account when it's 4 AM :-) I may be answering 'yes' in my sleep) That actually sounds like a great idea to me. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on ia64/ia64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/10 19:11, FreeBSD Tinderbox wrote:
cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-finline-limit=15000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13
-mfixed-range=f32-f127 -fpic -ffreestanding -Werror
/src/sys/net80211/ieee80211_sta.c
/src/sys/net80211/ieee80211_sta.c: In function 'sta_input':
/src/sys/net80211/ieee80211_sta.c:587: error: expected ')' before '!' token
*** Error code 1
I *think* this is supposed to be ..
if (HAS_SEQ(type) !IEEE80211_IS_MULTICAST(wh-i_addr1)) {
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkwRdRsACgkQQv9rrgRC1JLQ9ACfVPINlwHR8g0hXt0wenp5esfj
FooAnidIAWqJr9fJ3wQ8nhtEZtj9d0VG
=errN
-END PGP SIGNATURE-
*** /usr/src/sys/net80211/ieee80211_sta.c~ Thu Jun 10 17:53:24 2010
--- /usr/src/sys/net80211/ieee80211_sta.c Thu Jun 10 19:15:42 2010
***
*** 584,590
}
IEEE80211_RSSI_LPF(ni-ni_avgrssi, rssi);
ni-ni_noise = nf;
! if (HAS_SEQ(type) !IEEE80211_IS_MULTICAST(wh-i_addr1)) {
uint8_t tid = ieee80211_gettid(wh);
if (IEEE80211_QOS_HAS_SEQ(wh)
TID_TO_WME_AC(tid) = WME_AC_VI)
--- 584,590
}
IEEE80211_RSSI_LPF(ni-ni_avgrssi, rssi);
ni-ni_noise = nf;
! if (HAS_SEQ(type) !IEEE80211_IS_MULTICAST(wh-i_addr1)) {
uint8_t tid = ieee80211_gettid(wh);
if (IEEE80211_QOS_HAS_SEQ(wh)
TID_TO_WME_AC(tid) = WME_AC_VI)
___
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: etcupdate tool in base?
On 6/10/10 1:25 PM, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/10/10 11:18, Julian Elischer wrote: | It does bring up the question (yet again) if we shouldn't | have something that is between base and ports.. | the keep base from bloating too much bit to still indicate | that they are supported. Julian, This statement perpetuates the idea that somehow anything in ports is lesser than things that are in src, which frankly I'm way past being sick of. The ports tree is part of FreeBSD, period. If you don't believe me, try installing just the base without installing any ports, and then see how much work you're able to get done. unfortunately it is true. code in the base tree gets fixed by people making sweeping changes but things from ports often do not. Ports are not installed by default so you can't assume they are there. Like it or not Ports are, no matter how little, second class citizens. I do not belittle the importance of having them, just stating the facts as I see them. ___ 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: etcupdate tool in base?
On 06/11/10 03:46, John Baldwin wrote: I've had several folks ask me recently about importing etcupdate (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate tool for updating /etc during upgrades. Do folks have any strong objections to doing so? More details about how it works and an HTML version of the manpage can be found at the URL above. +1 for adding to base (and updating handbook chapters makeworld.html and small-lan.html, plus maybe /usr/src/Makefile and an UPDATING entry). Cheers, Lawrence ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2010-06-10 23:11:28 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-10 23:11:28 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-06-10 23:11:28 - cleaning the object tree TB --- 2010-06-10 23:11:45 - cvsupping the source tree TB --- 2010-06-10 23:11:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-06-10 23:12:11 - building world TB --- 2010-06-10 23:12:11 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-10 23:12:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-10 23:12:11 - TARGET=powerpc TB --- 2010-06-10 23:12:11 - TARGET_ARCH=powerpc TB --- 2010-06-10 23:12:11 - TZ=UTC TB --- 2010-06-10 23:12:11 - __MAKE_CONF=/dev/null TB --- 2010-06-10 23:12:11 - cd /src TB --- 2010-06-10 23:12:11 - /usr/bin/make -B buildworld World build started on Thu Jun 10 23:12:11 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jun 11 00:50:04 UTC 2010 TB --- 2010-06-11 00:50:04 - generating LINT kernel config TB --- 2010-06-11 00:50:04 - cd /src/sys/powerpc/conf TB --- 2010-06-11 00:50:04 - /usr/bin/make -B LINT TB --- 2010-06-11 00:50:04 - building LINT kernel TB --- 2010-06-11 00:50:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-11 00:50:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-11 00:50:04 - TARGET=powerpc TB --- 2010-06-11 00:50:04 - TARGET_ARCH=powerpc TB --- 2010-06-11 00:50:04 - TZ=UTC TB --- 2010-06-11 00:50:04 - __MAKE_CONF=/dev/null TB --- 2010-06-11 00:50:04 - cd /src TB --- 2010-06-11 00:50:04 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Jun 11 00:50:04 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_radiotap.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_ratectl.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_regdomain.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_scan.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float
[head tinderbox] failure on sparc64/sparc64
TB --- 2010-06-10 23:52:30 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-10 23:52:30 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-06-10 23:52:30 - cleaning the object tree TB --- 2010-06-10 23:52:50 - cvsupping the source tree TB --- 2010-06-10 23:52:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-06-10 23:53:16 - building world TB --- 2010-06-10 23:53:16 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-10 23:53:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-10 23:53:16 - TARGET=sparc64 TB --- 2010-06-10 23:53:16 - TARGET_ARCH=sparc64 TB --- 2010-06-10 23:53:16 - TZ=UTC TB --- 2010-06-10 23:53:16 - __MAKE_CONF=/dev/null TB --- 2010-06-10 23:53:16 - cd /src TB --- 2010-06-10 23:53:16 - /usr/bin/make -B buildworld World build started on Thu Jun 10 23:53:16 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jun 11 00:52:43 UTC 2010 TB --- 2010-06-11 00:52:43 - generating LINT kernel config TB --- 2010-06-11 00:52:43 - cd /src/sys/sparc64/conf TB --- 2010-06-11 00:52:43 - /usr/bin/make -B LINT TB --- 2010-06-11 00:52:43 - building LINT kernel TB --- 2010-06-11 00:52:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-11 00:52:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-11 00:52:43 - TARGET=sparc64 TB --- 2010-06-11 00:52:43 - TARGET_ARCH=sparc64 TB --- 2010-06-11 00:52:43 - TZ=UTC TB --- 2010-06-11 00:52:43 - __MAKE_CONF=/dev/null TB --- 2010-06-11 00:52:43 - cd /src TB --- 2010-06-11 00:52:43 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Jun 11 00:52:43 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_radiotap.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_ratectl.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_regdomain.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_scan.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_scan_sta.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall
[head tinderbox] failure on sparc64/sun4v
TB --- 2010-06-10 23:57:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-10 23:57:47 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-06-10 23:57:47 - cleaning the object tree TB --- 2010-06-10 23:57:58 - cvsupping the source tree TB --- 2010-06-10 23:57:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-06-10 23:58:23 - building world TB --- 2010-06-10 23:58:23 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-10 23:58:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-10 23:58:23 - TARGET=sun4v TB --- 2010-06-10 23:58:23 - TARGET_ARCH=sparc64 TB --- 2010-06-10 23:58:23 - TZ=UTC TB --- 2010-06-10 23:58:23 - __MAKE_CONF=/dev/null TB --- 2010-06-10 23:58:23 - cd /src TB --- 2010-06-10 23:58:23 - /usr/bin/make -B buildworld World build started on Thu Jun 10 23:58:24 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jun 11 00:57:31 UTC 2010 TB --- 2010-06-11 00:57:31 - generating LINT kernel config TB --- 2010-06-11 00:57:31 - cd /src/sys/sun4v/conf TB --- 2010-06-11 00:57:31 - /usr/bin/make -B LINT TB --- 2010-06-11 00:57:31 - building LINT kernel TB --- 2010-06-11 00:57:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-11 00:57:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-11 00:57:31 - TARGET=sun4v TB --- 2010-06-11 00:57:31 - TARGET_ARCH=sparc64 TB --- 2010-06-11 00:57:31 - TZ=UTC TB --- 2010-06-11 00:57:31 - __MAKE_CONF=/dev/null TB --- 2010-06-11 00:57:31 - cd /src TB --- 2010-06-11 00:57:31 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Jun 11 00:57:31 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_radiotap.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_ratectl.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_regdomain.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_scan.c cc -c -O2 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_scan_sta.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall
Re: RFC: etcupdate tool in base?
On Thu, Jun 10, 2010 at 05:28:01PM -0700, Julian Elischer wrote: code in the base tree gets fixed by people making sweeping changes but things from ports often do not. By 'sweeping changes', I take it you mean to src? And if by 'things from ports', I take you mean that ports break on -current all the time, due to changes in src? mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message From: Ganbold ganb...@gmail.com To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu ganb...@mobicom.mn Sent: Thu, June 10, 2010 10:53:30 AM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless It seems like it is running without any problem so far, no more adsl modem problem. I can see arp packets in wlan0 interface as well as in macbook. I will continue testing and let you know if there comes any problem. thanks again, Ganbold Hello, Glad to hear. It was an encryption problem. A client was dropping packets.. Please let me know if you find another bug. (Hope there won't be) Thank you for testing AK ___ 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: etcupdate tool in base?
On 6/10/2010 5:28 PM, Julian Elischer wrote: code in the base tree gets fixed by people making sweeping changes but things from ports often do not. Code will either be maintained well, or it will not. I've seen plenty of stuff in src break, and the src build is often broken by under-tested changes (even in -stable branches). As I said in my original post, your attitude is anachronistic, and needs to change. It's not ok for people to make random sweeping src changes, even in -current, that break things in ports. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
