[head tinderbox] failure on i386/i386
TB --- 2010-08-26 08:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-26 08:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-08-26 08:30:00 - cleaning the object tree TB --- 2010-08-26 08:30:56 - cvsupping the source tree TB --- 2010-08-26 08:30:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-08-26 08:33:47 - building world TB --- 2010-08-26 08:33:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-26 08:33:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-26 08:33:47 - TARGET=i386 TB --- 2010-08-26 08:33:47 - TARGET_ARCH=i386 TB --- 2010-08-26 08:33:47 - TZ=UTC TB --- 2010-08-26 08:33:47 - __MAKE_CONF=/dev/null TB --- 2010-08-26 08:33:47 - cd /src TB --- 2010-08-26 08:33:47 - /usr/bin/make -B buildworld World build started on Thu Aug 26 08:33:48 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 Aug 26 10:23:47 UTC 2010 TB --- 2010-08-26 10:23:47 - generating LINT kernel config TB --- 2010-08-26 10:23:47 - cd /src/sys/i386/conf TB --- 2010-08-26 10:23:47 - /usr/bin/make -B LINT TB --- 2010-08-26 10:23:48 - building LINT kernel TB --- 2010-08-26 10:23:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-26 10:23:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-26 10:23:48 - TARGET=i386 TB --- 2010-08-26 10:23:48 - TARGET_ARCH=i386 TB --- 2010-08-26 10:23:48 - TZ=UTC TB --- 2010-08-26 10:23:48 - __MAKE_CONF=/dev/null TB --- 2010-08-26 10:23:48 - cd /src TB --- 2010-08-26 10:23:48 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Aug 26 10:23:48 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 [...] : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel trap.o(.text+0xca9): In function `trap': : undefined reference to `dtrace_fasttrap_probe_ptr' *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-26 10:40:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-26 10:40:55 - ERROR: failed to build lint kernel TB --- 2010-08-26 10:40:55 - 5631.01 user 1312.59 system 7855.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ 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 mips/mips
TB --- 2010-08-26 10:40:55 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-26 10:40:55 - starting HEAD tinderbox run for mips/mips
TB --- 2010-08-26 10:40:55 - cleaning the object tree
TB --- 2010-08-26 10:41:16 - cvsupping the source tree
TB --- 2010-08-26 10:41:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/mips/mips/supfile
TB --- 2010-08-26 10:41:48 - building world
TB --- 2010-08-26 10:41:48 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-26 10:41:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-26 10:41:48 - TARGET=mips
TB --- 2010-08-26 10:41:48 - TARGET_ARCH=mips
TB --- 2010-08-26 10:41:48 - TZ=UTC
TB --- 2010-08-26 10:41:48 - __MAKE_CONF=/dev/null
TB --- 2010-08-26 10:41:48 - cd /src
TB --- 2010-08-26 10:41:48 - /usr/bin/make -B buildworld
World build started on Thu Aug 26 10:41:49 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
[...]
/src/share/mk/bsd.arch.inc.mk, line 7: if-less elif
/src/Makefile.mips, line 3: Malformed conditional (${TARGET_ABI} == n64)
/src/Makefile.mips, line 5: if-less endif
/src/share/mk/bsd.arch.inc.mk, line 9: if-less elif
/src/Makefile.mips, line 3: Malformed conditional (${TARGET_ABI} == n64)
/src/Makefile.mips, line 5: if-less endif
/src/share/mk/bsd.arch.inc.mk, line 11: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-08-26 10:44:46 - WARNING: /usr/bin/make returned exit code 1
TB --- 2010-08-26 10:44:46 - ERROR: failed to build world
TB --- 2010-08-26 10:44:46 - 151.11 user 54.55 system 231.52 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full
___
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 powerpc64/powerpc
TB --- 2010-08-26 11:11:39 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-26 11:11:39 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-26 11:11:39 - cleaning the object tree TB --- 2010-08-26 11:11:51 - cvsupping the source tree TB --- 2010-08-26 11:11:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-26 11:12:20 - building world TB --- 2010-08-26 11:12:20 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-26 11:12:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-26 11:12:20 - TARGET=powerpc TB --- 2010-08-26 11:12:20 - TARGET_ARCH=powerpc64 TB --- 2010-08-26 11:12:20 - TZ=UTC TB --- 2010-08-26 11:12:20 - __MAKE_CONF=/dev/null TB --- 2010-08-26 11:12:20 - cd /src TB --- 2010-08-26 11:12:20 - /usr/bin/make -B buildworld World build started on Thu Aug 26 11:12:21 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 [...] === gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-26 11:40:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-26 11:40:24 - ERROR: failed to build world TB --- 2010-08-26 11:40:24 - 1145.02 user 348.07 system 1724.74 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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
concerning GCC GPLv2 vs. GPLv3
hi there, the FreeBSD base GCC version is dated 20070719 which is the release date of GCC 4.2.1. after this release the 4.2 branch got GPLv3'ed which is the reason anything after 20070719 in the 4.2 branch cannot be imported into the FreeBSD. Also all the other branches 4.2 are GPLv3'ed too. however i noticed a lot of commits to the 4.2 and later branches have been backported into the 4.1 branch which is still licensed under GPLv2. the last snapshot of the 4.1 branch is dated 29/06/2008 [1], so it's possible to import all those backported changes into the FreeBSD source tree without any legal issues. i'm not sure how many problems that would fix though. one of them is PR 118188. i've attached an excerpt of the 4.1 branches Changelog file which documents the commits to that branch which aren't in the FreeBSD source tree yet. cheers. alex [1] ftp://ftp.fu-berlin.de/unix/languages/gcc/snapshots/4.1-20080630/ -- a13x 2008-05-29 Eric Botcazou ebotca...@adacore.com * gcc.dg/nested-func-6.c: New test. 2008-04-08 Richard Guenther rguent...@suse.de * gcc.c-torture/execute/20080408-1.c: New testcase. 2008-03-25 Richard Guenther rguent...@suse.de Backport from mainline: 2008-02-12 Richard Guenther rguent...@suse.de PR middle-end/35163 * gcc.c-torture/execute/pr35163.c: New testcase. 2008-02-13 Kaveh R. Ghazi gh...@caip.rutgers.edu Backport: 2005-11-30 Richard Guenther rguent...@suse.de PR tree-optimization/21655 * g++.dg/tree-ssa/pr14814.C: Remove XFAIL. 2008-02-12 Kaveh R. Ghazi gh...@caip.rutgers.edu * obj-c++.dg/bitfield-1.mm: Expect failures. * obj-c++.dg/bitfield-4.mm: Likewise. * obj-c++.dg/cxx-ivars-2.mm: Likewise. * obj-c++.dg/encode-8.mm: Likewise. * obj-c++.dg/isa-field-1.mm: Likewise. * obj-c++.dg/layout-1.mm: Likewise. * obj-c++.dg/lookup-2.mm: Likewise. * obj-c++.dg/try-catch-2.mm: Likewise. * obj-c++.dg/try-catch-9.mm: Likewise. 2008-02-12 Kaveh R. Ghazi gh...@caip.rutgers.edu PR objc++/34193 * obj-c++.dg/gnu-runtime-2.mm: Fix signature of function main(). 2008-02-10 Kaveh R. Ghazi gh...@caip.rutgers.edu PR objc++/27232 Backport: 2006-09-22 Mike Stump m...@apple.com * obj-c++.dg/encode-3.mm: Fix for 64-bit support. 2008-02-04 Richard Guenther rguent...@suse.de PR middle-end/33631 * gcc.c-torture/execute/pr33631.c: New testcase. 2008-01-31 Andreas Krebbel krebb...@de.ibm.com * gcc.dg/tf_to_di-1.c: New testcase. 2008-01-24 Kaveh R. Ghazi gh...@caip.rutgers.edu Backport: 2008-01-10 Kaveh R. Ghazi gh...@caip.rutgers.edu * gcc.dg/pr33826.c: Require nonpic. 2007-11-08 Kenneth Zadeck zad...@naturalbridge.com PR middle-end/33826 * gcc.dg/pr33826.c: New. * gcc.dg/tree-ssa/20030714-1.c: Removed two tests that depend on recursive functions being marked pure or const. 2008-01-22 Kaveh R. Ghazi gh...@caip.rutgers.edu * gcc.dg/vect/vect-ifcvt-9.c: Use inline. 2008-01-19 John David Anglin dave.ang...@nrc-cnrc.gc.ca * g++.dg/eh/ia64-2.C: Add dg-require-weak statement. Place dg-do run statement before dg-require-weak statement. * g++.dg/eh/weak1.C: Likewise. 2008-01-19 Kaveh R. Ghazi gh...@caip.rutgers.edu Backport: 2007-03-21 Richard Sandiford rich...@codesourcery.com * gcc.target/i386/pr21291.c: Require nonpic or ! ilp32. 2008-01-17 Eric Botcazou ebotca...@adacore.com * gcc.c-torture/compile/20080114-1.c: Use empty asm statements. 2008-01-14 Eric Botcazou ebotca...@adacore.com * gcc.c-torture/compile/20080114-1.c: New test. 2008-01-09 Kaveh R. Ghazi gh...@caip.rutgers.edu * gcc.c-torture/execute/builtins/chk.h: Don't check !__PIE__. Also check __pic__. * lib/target-supports.exp (check_effective_target_nonpic): Likewise. * gcc.dg/assign-warn-3.c: Use static inline instead of inline. Backport: 2007-03-21 Richard Sandiford rich...@codesourcery.com * gcc.c-torture/execute/builtins/chk.h (LOCAL): Define. * gcc.c-torture/execute/builtins/sprintf-chk.c (s1): Make LOCAL. * gcc.c-torture/execute/builtins/stpcpy-chk.c (s1): Likewise. * gcc.c-torture/execute/builtins/strcpy-chk.c (s1): Likewise. 2007-07-26 Nathan Froyd froy...@codesourcery.com PR/19232 * gcc.dg/assign-warn-3.c (f0): Declare as inline. (f1): Likewise. 2007-01-15 Dale Johannesen da...@apple.com * gcc.dg/tree-ssa/loop-3.c: Disable with -fpic or -fPIC. 2007-03-21 Richard Sandiford rich...@codesourcery.com * lib/target-supports.exp (check_effective_target_nonpic): New procedure. 2007-12-20 Jakub Jelinek ja...@redhat.com PR bootstrap/34003
[RFC] ifconfig description support in rc.d
[cc'ing current@ as rc@ looks too quite]
Hi.
Since ifconfig has grown to label interfaces with
ifconfig $ifname description foobar, what about
to give it more life and store i/face descriptions
semi-permanently, so they will survive between reboots?
This patch adds a functionality to rc.d to label
interfaces at boot time.
Comments are welcome.
%%%
Index: etc/rc.d/netif
===
--- etc/rc.d/netif (revision 211280)
+++ etc/rc.d/netif (working copy)
@@ -75,6 +75,9 @@
# Rename interfaces.
ifnet_rename
+
+ # Give description to interfaces.
+ ifnet_descr
fi
# Configure the interface(s).
Index: etc/network.subr
===
--- etc/network.subr(revision 211280)
+++ etc/network.subr(working copy)
@@ -1187,6 +1187,24 @@
return 0
}
+# ifnet_descr
+# Add description to all requested interfaces.
+#
+ifnet_descr()
+{
+ local _if _ifdescr
+
+ # ifconfig_IF_descr
+ for _if in `ifconfig -l`; do
+ _ifdescr=`get_if_var $_if ifconfig_IF_descr`
+ if [ ! -z $_ifdescr ]; then
+ ifconfig $_if descr $_ifdescr
+ fi
+ done
+
+ return 0
+}
+
# list_net_interfaces type
# List all network interfaces. The type of interface returned
# can be controlled by the type argument. The type
Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf(revision 211280)
+++ etc/defaults/rc.conf(working copy)
@@ -215,6 +215,7 @@
#ifconfig_ed0_ipv6=inet6 2001:db8:1::1 prefixlen 64 # Sample IPv6 addr entry
#ifconfig_ed0_alias0=inet6 2001:db8:2::1 prefixlen 64 # Sample IPv6 alias
#ifconfig_fxp0_name=net0 # Change interface name from fxp0 to net0.
+#ifconfig_fxp0_descr=Uplink to Gigabit Switch 2 # Label fxp0 interface
#vlans_fxp0=101 vlan0# vlan(4) interfaces for fxp0 device
#create_arg_vlan0=vlan 102 # vlan tag for vlan0 device
#wlans_ath0=wlan0# wlan(4) interfaces for ath0 device
%%%
--
wbr,
pluknet
Index: etc/rc.d/netif
===
--- etc/rc.d/netif (revision 211280)
+++ etc/rc.d/netif (working copy)
@@ -75,6 +75,9 @@
# Rename interfaces.
ifnet_rename
+
+ # Give description to interfaces.
+ ifnet_descr
fi
# Configure the interface(s).
Index: etc/network.subr
===
--- etc/network.subr (revision 211280)
+++ etc/network.subr (working copy)
@@ -1187,6 +1187,24 @@
return 0
}
+# ifnet_descr
+# Add description to all requested interfaces.
+#
+ifnet_descr()
+{
+ local _if _ifdescr
+
+ # ifconfig_IF_descr
+ for _if in `ifconfig -l`; do
+ _ifdescr=`get_if_var $_if ifconfig_IF_descr`
+ if [ ! -z $_ifdescr ]; then
+ ifconfig $_if descr $_ifdescr
+ fi
+ done
+
+ return 0
+}
+
# list_net_interfaces type
# List all network interfaces. The type of interface returned
# can be controlled by the type argument. The type
Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf (revision 211280)
+++ etc/defaults/rc.conf (working copy)
@@ -215,6 +215,7 @@
#ifconfig_ed0_ipv6=inet6 2001:db8:1::1 prefixlen 64 # Sample IPv6 addr entry
#ifconfig_ed0_alias0=inet6 2001:db8:2::1 prefixlen 64 # Sample IPv6 alias
#ifconfig_fxp0_name=net0 # Change interface name from fxp0 to net0.
+#ifconfig_fxp0_descr=Uplink to Gigabit Switch 2 # Label fxp0 interface
#vlans_fxp0=101 vlan0 # vlan(4) interfaces for fxp0 device
#create_arg_vlan0=vlan 102 # vlan tag for vlan0 device
#wlans_ath0=wlan0 # wlan(4) interfaces for ath0 device
___
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
sched_pin() bug in SCHED_ULE
Back at the beginning of August I posted about issues with sched_pin() and witness_warn(): http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032553.html After a lot of debugging I think I've basically found the issue. I found this bug on stable/7, but looking at the commit log for CURRENT I don't see any reason the bug doesn't exist there. This analysis is specific to amd64/i386 but the problem is likely to exist on most arches. The basic problem is that in both tdq_move() and sched_setcpu() can manipulate the ts-ts_cpu variable of another process, which may be running. This means that a process running on CPU N may be set to run on CPU M the next context switch. Then, that process may call sched_pin(), then grab a PCPU variable. An IPI_PREEMPT can come in, causing the thread to call mi_switch() in ipi_bitmap_handler(). sched_switch() will then notice that ts-ts_cpu is not PCPU_GET(cpuid), and call sched_switch_migrate(), migrating the thread to the intended CPU. Thus after sched_pin() and potentially before using any PCPU variable the process can get migrated to another CPU, and now it is using a PCPU variable for the wrong processor. Given that ts_cpu can be set by other threads, it doesn't seem worth checking at sched_pin time whether ts_cpu is not the same as td_oncpu, because to make the check would require taking the thread_lock. Instead, I propose adding a check for !THREAD_CAN_MIGRATE() before calling sched_switch_migrate(). However, sched_pin() is also used by sched_bind(9) to force the thread to stay on the intended cpu. I would handle this by adding a TSF_BINDING state that is different from TSF_BOUND. The thing that has me wondering whether this is all correct is that I don't see any checks in tdq_move() or sched_setcpu() for either TSF_BOUND or THREAD_CAN_MIGRATE(). Perhaps that logic is managed in the various calling functions; in that case I would propose adding asserts that the thread is THREAD_CAN_MIGRATE() unless it's marked TSF_BINDING. Does this analysis seem correct? Thanks, matthew ___ 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] ifconfig description support in rc.d
On 08/26/2010 12:53 PM, pluknet wrote:
[cc'ing current@ as rc@ looks too quite]
Hi.
Since ifconfig has grown to label interfaces with
ifconfig $ifname description foobar, what about
to give it more life and store i/face descriptions
semi-permanently, so they will survive between reboots?
This patch adds a functionality to rc.d to label
interfaces at boot time.
Comments are welcome.
This seems like a good addition, thanks. Please also write a patch for
rc.conf.5 to describe this new functionality and I'll be happy to commit
it. One note below.
--- etc/network.subr(revision 211280)
+++ etc/network.subr(working copy)
@@ -1187,6 +1187,24 @@
return 0
}
+# ifnet_descr
+# Add description to all requested interfaces.
+#
+ifnet_descr()
+{
+ local _if _ifdescr
+
+ # ifconfig_IF_descr
+ for _if in `ifconfig -l`; do
+ _ifdescr=`get_if_var $_if ifconfig_IF_descr`
+ if [ ! -z $_ifdescr ]; then
This is probably better as [ -n $_ifdescr ]
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
Computers are useless. They can only give you answers.
-- Pablo Picasso
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sched_pin() bug in SCHED_ULE
On Thursday, August 26, 2010 4:03:38 pm m...@freebsd.org wrote: Back at the beginning of August I posted about issues with sched_pin() and witness_warn(): http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032553.html After a lot of debugging I think I've basically found the issue. I found this bug on stable/7, but looking at the commit log for CURRENT I don't see any reason the bug doesn't exist there. This analysis is specific to amd64/i386 but the problem is likely to exist on most arches. The basic problem is that in both tdq_move() and sched_setcpu() can manipulate the ts-ts_cpu variable of another process, which may be running. This means that a process running on CPU N may be set to run on CPU M the next context switch. Then, that process may call sched_pin(), then grab a PCPU variable. An IPI_PREEMPT can come in, causing the thread to call mi_switch() in ipi_bitmap_handler(). sched_switch() will then notice that ts-ts_cpu is not PCPU_GET(cpuid), and call sched_switch_migrate(), migrating the thread to the intended CPU. Thus after sched_pin() and potentially before using any PCPU variable the process can get migrated to another CPU, and now it is using a PCPU variable for the wrong processor. Given that ts_cpu can be set by other threads, it doesn't seem worth checking at sched_pin time whether ts_cpu is not the same as td_oncpu, because to make the check would require taking the thread_lock. Instead, I propose adding a check for !THREAD_CAN_MIGRATE() before calling sched_switch_migrate(). However, sched_pin() is also used by sched_bind(9) to force the thread to stay on the intended cpu. I would handle this by adding a TSF_BINDING state that is different from TSF_BOUND. The thing that has me wondering whether this is all correct is that I don't see any checks in tdq_move() or sched_setcpu() for either TSF_BOUND or THREAD_CAN_MIGRATE(). Perhaps that logic is managed in the various calling functions; in that case I would propose adding asserts that the thread is THREAD_CAN_MIGRATE() unless it's marked TSF_BINDING. Does this analysis seem correct? Calling code does check THREAD_CAN_MIGRATE(), but the problem is that it is not safe to call that on anything but curthread as td_pinned is not locked. It is assumed that only curthread would ever check td_pinned, not other threads. I suspect what is happening is that another CPU is seeing a stale value of td_pinned. You could fix this by grabbing the thread lock in sched_pin()/unpin() for ULE, but that is a bit expensive perhaps. You could test your theory by disabling thread stealing btw. There are a few sysctl knobs to turn it off. -- 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] ifconfig description support in rc.d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/08/26 13:09, Doug Barton wrote:
On 08/26/2010 12:53 PM, pluknet wrote:
[cc'ing current@ as rc@ looks too quite]
Hi.
Since ifconfig has grown to label interfaces with
ifconfig $ifname description foobar, what about
to give it more life and store i/face descriptions
semi-permanently, so they will survive between reboots?
This patch adds a functionality to rc.d to label
interfaces at boot time.
Comments are welcome.
This seems like a good addition, thanks. Please also write a patch for
rc.conf.5 to describe this new functionality and I'll be happy to commit
it. One note below.
I have drafted one.
(Note that fxp is a 100Mbps card so it might be sensible to replace it
with just Switch 2?)
--- etc/network.subr(revision 211280)
+++ etc/network.subr(working copy)
@@ -1187,6 +1187,24 @@
return 0
}
+# ifnet_descr
+# Add description to all requested interfaces.
+#
+ifnet_descr()
+{
+ local _if _ifdescr
+
+ # ifconfig_IF_descr
+ for _if in `ifconfig -l`; do
+ _ifdescr=`get_if_var $_if ifconfig_IF_descr`
+ if [ ! -z $_ifdescr ]; then
This is probably better as [ -n $_ifdescr ]
Doug
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBCAAGBQJMdtgjAAoJEATO+BI/yjfBywEIALQZMUFUKlkQ/DZjrqBgymFx
Mnj6YkLaPXcvNI5OI15Q3hy730pIZzzNPGKV9ecXLSQ1PikZUIXy5fuRfYh9iXE3
d9f4UgDId0Sn55WmD6/Sfza0oSlH3C1fus6e9NSmm/aR3ekWyLWZzW0wGTgEXFxK
bo0ZcQw7AxRxDLc7EifWUfxV/Ej5pga5YjVyhBBdCoAHl2bPJuFFuxd140Y6+Mlf
gH4zgf2rdGpCWNpWF6L8PsGoVNBoK0R1fUwJZT+GB2ANvMuuQ+jsks+R8h8XFIO6
TE4O8onVcOaoTGZ3873M3CqcO1jfaK5rBfGg3Cr9wUjOkvkQ8SL+k4uvBm4CuX4=
=VtCo
-END PGP SIGNATURE-
Index: rc.conf.5
===
--- rc.conf.5 (revision 211847)
+++ rc.conf.5 (working copy)
@@ -1128,6 +1128,19 @@
variables.
.Pp
If a
+.Va ifconfig_ Ns Ao Ar interface Ac Ns Va _descr
+variable is set, the interface would be assigned the description
+specified by the variable.
+.Pp
+To assign an description of
+.Dq Uplink to Gigabit Switch 1
+on the interface named
+.Li em0 :
+.Bd -literal
+ifconfig_em0_descr=Uplink to Gigabit Switch 1
+.Ed
+.Pp
+If a
.Va vlans_ Ns Aq Ar interface
variable is set,
a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sched_pin() bug in SCHED_ULE
On Thu, Aug 26, 2010 at 1:49 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, August 26, 2010 4:03:38 pm m...@freebsd.org wrote:
Back at the beginning of August I posted about issues with sched_pin()
and witness_warn():
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032553.html
After a lot of debugging I think I've basically found the issue. I
found this bug on stable/7, but looking at the commit log for CURRENT
I don't see any reason the bug doesn't exist there. This analysis is
specific to amd64/i386 but the problem is likely to exist on most
arches.
The basic problem is that in both tdq_move() and sched_setcpu() can
manipulate the ts-ts_cpu variable of another process, which may be
running. This means that a process running on CPU N may be set to run
on CPU M the next context switch.
Then, that process may call sched_pin(), then grab a PCPU variable.
An IPI_PREEMPT can come in, causing the thread to call mi_switch() in
ipi_bitmap_handler(). sched_switch() will then notice that ts-ts_cpu
is not PCPU_GET(cpuid), and call sched_switch_migrate(), migrating the
thread to the intended CPU. Thus after sched_pin() and potentially
before using any PCPU variable the process can get migrated to another
CPU, and now it is using a PCPU variable for the wrong processor.
Given that ts_cpu can be set by other threads, it doesn't seem worth
checking at sched_pin time whether ts_cpu is not the same as td_oncpu,
because to make the check would require taking the thread_lock.
Instead, I propose adding a check for !THREAD_CAN_MIGRATE() before
calling sched_switch_migrate(). However, sched_pin() is also used by
sched_bind(9) to force the thread to stay on the intended cpu. I
would handle this by adding a TSF_BINDING state that is different from
TSF_BOUND.
The thing that has me wondering whether this is all correct is that I
don't see any checks in tdq_move() or sched_setcpu() for either
TSF_BOUND or THREAD_CAN_MIGRATE(). Perhaps that logic is managed in
the various calling functions; in that case I would propose adding
asserts that the thread is THREAD_CAN_MIGRATE() unless it's marked
TSF_BINDING.
Does this analysis seem correct?
Calling code does check THREAD_CAN_MIGRATE(), but the problem is that it is
not safe to call that on anything but curthread as td_pinned is not locked.
It is assumed that only curthread would ever check td_pinned, not other
threads. I suspect what is happening is that another CPU is seeing a stale
value of td_pinned. You could fix this by grabbing the thread lock in
sched_pin()/unpin() for ULE, but that is a bit expensive perhaps.
I tried making sched_pin() a real function which used
intr_disable/intr_restore around saving off td-td_oncpu,
td-td_lastcpu and ts-ts_cpu, and the stack at the time of call. In
sched_switch when I saw an unexpected migration I printed all that
out. I found that on my boxes, at sched_pin() time ts_cpu was already
different from td-td_oncpu, so the specific problem I was having was
that while another thread can change ts_cpu it has no way to force
that thread to immediately migrate.
I believe the below patch fixes the issue, though I'm open to other methods:
Index: kern/sched_ule.c
===
--- kern/sched_ule.c(.../head/src/sys) (revision 158279)
+++ kern/sched_ule.c(.../branches/BR_BUG_67957/src/sys) (revision
158279)
@@ -112,6 +112,7 @@
/* flags kept in ts_flags */
#defineTSF_BOUND 0x0001 /* Thread can not migrate. */
#defineTSF_XFERABLE0x0002 /* Thread was added as
transferable. */
+#defineTSF_BINDING 0x0004 /* Thread is being bound. */
static struct td_sched td_sched0;
@@ -1859,6 +1858,7 @@
struct mtx *mtx;
int srqflag;
int cpuid;
+ int do_switch;
THREAD_LOCK_ASSERT(td, MA_OWNED);
@@ -1888,10 +1888,21 @@
srqflag = (flags SW_PREEMPT) ?
SRQ_OURSELF|SRQ_YIELDING|SRQ_PREEMPTED :
SRQ_OURSELF|SRQ_YIELDING;
- if (ts-ts_cpu == cpuid)
+ /*
+* Allow the switch to another processor as requested
+* only if the thread can migrate or we are in the
+* middle of binding for sched_bind(9). This keeps
+* sched_pin() quick, since other threads can
+* manipulate ts_cpu.
+*/
+ do_switch = (ts-ts_cpu != cpuid);
+ if (!THREAD_CAN_MIGRATE(td)
+ (ts-ts_flags TSF_BINDING) == 0)
+ do_switch = 0;
+ if (do_switch)
+ mtx = sched_switch_migrate(tdq, td, srqflag);
+ else
tdq_add(tdq, td, srqflag);
- else
- mtx = sched_switch_migrate(tdq, td, srqflag);
} else {
Re: sched_pin() bug in SCHED_ULE
on 27/08/2010 00:20 m...@freebsd.org said the following: I tried making sched_pin() a real function which used intr_disable/intr_restore around saving off td-td_oncpu, td-td_lastcpu and ts-ts_cpu, and the stack at the time of call. In sched_switch when I saw an unexpected migration I printed all that out. I found that on my boxes, at sched_pin() time ts_cpu was already different from td-td_oncpu, so the specific problem I was having was that while another thread can change ts_cpu it has no way to force that thread to immediately migrate. Like e.g. in sched_affinity where ts_cpu is first changed and then the old cpu is ipi-ed? I believe the below patch fixes the issue, though I'm open to other methods: Index: kern/sched_ule.c === --- kern/sched_ule.c (.../head/src/sys) (revision 158279) +++ kern/sched_ule.c (.../branches/BR_BUG_67957/src/sys) (revision 158279) @@ -112,6 +112,7 @@ /* flags kept in ts_flags */ #define TSF_BOUND 0x0001 /* Thread can not migrate. */ #define TSF_XFERABLE0x0002 /* Thread was added as transferable. */ +#define TSF_BINDING 0x0004 /* Thread is being bound. */ I don't really follow why TSF_BINDING is needed, i.e. why TSF_BOUND is not sufficient in this case? -- 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: sched_pin() bug in SCHED_ULE
On Thu, Aug 26, 2010 at 3:10 PM, Andriy Gapon a...@icyb.net.ua wrote: on 27/08/2010 00:20 m...@freebsd.org said the following: I tried making sched_pin() a real function which used intr_disable/intr_restore around saving off td-td_oncpu, td-td_lastcpu and ts-ts_cpu, and the stack at the time of call. In sched_switch when I saw an unexpected migration I printed all that out. I found that on my boxes, at sched_pin() time ts_cpu was already different from td-td_oncpu, so the specific problem I was having was that while another thread can change ts_cpu it has no way to force that thread to immediately migrate. Like e.g. in sched_affinity where ts_cpu is first changed and then the old cpu is ipi-ed? That could do it. I didn't follow the stack of the places that were touching ts_cpu for non-curthread. I believe the below patch fixes the issue, though I'm open to other methods: Index: kern/sched_ule.c === --- kern/sched_ule.c (.../head/src/sys) (revision 158279) +++ kern/sched_ule.c (.../branches/BR_BUG_67957/src/sys) (revision 158279) @@ -112,6 +112,7 @@ /* flags kept in ts_flags */ #define TSF_BOUND 0x0001 /* Thread can not migrate. */ #define TSF_XFERABLE 0x0002 /* Thread was added as transferable. */ +#define TSF_BINDING 0x0004 /* Thread is being bound. */ I don't really follow why TSF_BINDING is needed, i.e. why TSF_BOUND is not sufficient in this case? I wanted to tighten up the asserts, so that the only time it was okay for a td_pinned thread to migrate was the one time it was moving to the target cpu. Having a separate flag allows that. Thanks, matthew ___ 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
Apparent regression in extended/logical partition handling
Howdy, Summary: FreeBSD 9-current can't see logical drives inside an extended partition unless all space is assigned to a logical volume, and all logical volumes are formatted with a file system. 7.3-RELEASE does not have this problem. Background: So I got a new HD, and wanted to put Windows, a fat 32 data partition, 2 FreeBSDs, and Linux on it. After much juggling, cursing, etc. I finally hit upon a solution. Windows and FreeBSDs in primary partitions, and fat32-data and Linux in an extended partition. Voila! My first pass at this configuration had the 3 primary partitions first, but the linux (ubuntu gnome to be specific) Disk Utility tool was showing all the freebsd-style partitions (ad[12]s[a-f]) as linux-style partitions (sdaN) under the extended dos-style partition, which not only looked odd, but other tools on the linux desktop (such as Nautilus) were confused by this. So I looked on line and found a how-to that said this is caused by having the extended partition last, and the confusion can be avoided if I put the extended partition 2nd, and the 2 FreeBSD partitions after it. So I did that, and unfortunately it did not help Nautilus be any less confused. However, it did lead to what I think is a regression in -current. Specifically what I did was to boot Windows XP, delete all the partitions other than the XP partition (first primary dos-style partition) and then create a dos-style extended partition, and a logical drive inside of it, leaving room for linux in that same extended partition. Since I want that data volume to be fat32, and it is too large for windows to do it, I next installed FreeBSD 9-current, in a dos-style primary partition. I got it installed fine, but when I booted into FreeBSD 9 to format the logical volume it could not see it. fdisk showed the right information about the extended partition, but in /dev instead of seeing no ad0s2 and seeing ad0s5 like I expected instead there was no ad0s5 and there were ad0s2 entries that mirrored the ad0s3 that FreeBSD 9 was installed on. IOW, I had ad0s3 and ad0s3[a-f] as expected, but I had the same for ad0s2 even though they were obviously not valid. Well that's odd I thought, but undaunted I proceeded to install FreeBSD 7.3-RELEASE in the last dos-style primary partition. When I booted it I could see the expected set of entries in /dev, and was finally able to newfs the fat32 volume. After confirming that Windows can see the fat32 volume I proceeded to boot FreeBSD 9 again. Still no joy. So then I proceeded with the Linux install (using up the last of the space inside the extended partition) and now FreeBSD 9 has the expected entries in /dev, and I can mount the fat32 volume. Haven't tried mounting the Linux volumes yet, although the right number of entries are there in /dev. So this appears to be an actual bug/regression. FYI, after getting everything installed and working I did not nuke it all again to see if moving the extended partition last fixed the issue for FreeBSD 9, but I sort of vaguely recall that when I did the install the first time (with extended at the end) I couldn't see it in FreeBSD 9 either; but didn't dwell on it. One side note, I was taught back in the day that dos-style extended partitions always had to be at the end of the disk. Before trying the configuration I have I searched quite a few places to find a reference to that rule and couldn't find one. Perhaps this is something that's actually improved in the PC world in the last 25 years? :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] Use MACHINE_ARCH for boot loader
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and
FreeBSD/amd64 on amd64.
Comments welcome! I'll commit it in by the weekend if there is no
objection on this.
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBCAAGBQJMdwu5AAoJEATO+BI/yjfBe+4H/i/LVqSlVP4XbQ8Xfzs2x0Xr
pv+sOtSMOKOBmtKb6KrTxyZ/GyLTAxxERlJCDLuxFZ1fVZ+E+q3BrhNRyJGcCjYx
6B3gdFwgiOlZbbFw/FGrI0W32xbeTnzd4oHqZWli4Nn6L7h+smX+O11aFaAg4ktG
y8E3ngJrG3ublbUskJ6/Vbi2xIbkTt0iPPa7jZlGGU2rTrLGTtB7E/5GNIXbiOWe
NwfKW+c2vaNCWTzwrUM/jHAkVgM3ZFXVEwx0BFGuhY4Rc2z5sGLwvpbueNT7xkTv
Y6goyuw6vwxnxA6ps2eka38Dz1JsoDNXsdFgpkgEF57c1hROSHF39lJhIfEB5t8=
=HL2J
-END PGP SIGNATURE-
Index: sys/boot/i386/boot2/boot2.c
===
--- sys/boot/i386/boot2/boot2.c (revision 211847)
+++ sys/boot/i386/boot2/boot2.c (working copy)
@@ -283,7 +283,7 @@ main(void)
for (;;) {
if (!autoboot || !OPT_CHECK(RBX_QUIET))
- printf(\nFreeBSD/x86 boot\n
+ printf(\nFreeBSD/ MACHINE_ARCH boot\n
Default: %u:%s(%u,%c)%s\n
boot: ,
dsk.drive DRV_MASK, dev_nm[dsk.type], dsk.unit,
Index: sys/boot/i386/boot2/Makefile
===
--- sys/boot/i386/boot2/Makefile(revision 211847)
+++ sys/boot/i386/boot2/Makefile(working copy)
@@ -34,6 +34,7 @@ CFLAGS= -Os \
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 \
-D${BOOT2_UFS} \
-DFLAGS=${BOOT_BOOT1_FLAGS} \
+ -DMACHINE_ARCH=\${MACHINE_ARCH}\ \
-DSIOPRT=${BOOT_COMCONSOLE_PORT} \
-DSIOFMT=${B2SIOFMT} \
-DSIOSPD=${BOOT_COMCONSOLE_SPEED} \
Index: sys/boot/i386/zfsboot/zfsboot.c
===
--- sys/boot/i386/zfsboot/zfsboot.c (revision 211847)
+++ sys/boot/i386/zfsboot/zfsboot.c (working copy)
@@ -731,7 +731,7 @@ main(void)
for (;;) {
if (!autoboot || !OPT_CHECK(RBX_QUIET))
- printf(\nFreeBSD/x86 boot\n
+ printf(\nFreeBSD/ MACHINE_ARCH boot\n
Default: %s:%s\n
boot: ,
spa-spa_name, kname);
Index: sys/boot/i386/zfsboot/Makefile
===
--- sys/boot/i386/zfsboot/Makefile (revision 211847)
+++ sys/boot/i386/zfsboot/Makefile (working copy)
@@ -26,6 +26,7 @@ CFLAGS= -Os -g \
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 \
-DBOOT2 \
-DFLAGS=${BOOT_BOOT1_FLAGS} \
+ -DMACHINE_ARCH=\${MACHINE_ARCH}\ \
-DSIOPRT=${BOOT_COMCONSOLE_PORT} \
-DSIOFMT=${B2SIOFMT} \
-DSIOSPD=${BOOT_COMCONSOLE_SPEED} \
Index: sys/boot/i386/zfsloader/Makefile
===
--- sys/boot/i386/zfsloader/Makefile(revision 211847)
+++ sys/boot/i386/zfsloader/Makefile(working copy)
@@ -3,7 +3,7 @@
.PATH: ${.CURDIR}/../loader
LOADER=zfsloader
-NEWVERSWHAT= ZFS enabled bootstrap loader i386
+NEWVERSWHAT= ZFS enabled bootstrap loader ${MACHINE_ARCH}
LOADER_ZFS_SUPPORT=yes
LOADER_ONLY= yes
NO_MAN=yes
Index: sys/boot/i386/loader/Makefile
===
--- sys/boot/i386/loader/Makefile (revision 211847)
+++ sys/boot/i386/loader/Makefile (working copy)
@@ -6,7 +6,7 @@ MK_SSP= no
LOADER?= loader
PROG= ${LOADER}.sym
INTERNALPROG=
-NEWVERSWHAT?= bootstrap loader i386
+NEWVERSWHAT?= bootstrap loader ${MACHINE_ARCH}
# architecture-specific loader code
SRCS= main.c conf.c vers.c
Index: sys/boot/i386/gptboot/gptboot.c
===
--- sys/boot/i386/gptboot/gptboot.c (revision 211847)
+++ sys/boot/i386/gptboot/gptboot.c (working copy)
@@ -281,7 +281,7 @@ main(void)
for (;;) {
if (!autoboot || !OPT_CHECK(RBX_QUIET))
- printf(\nFreeBSD/x86 boot\n
+ printf(\nFreeBSD/ MACHINE_ARCH boot\n
Default: %u:%s(%up%u)%s\n
boot: ,
dsk.drive DRV_MASK, dev_nm[dsk.type], dsk.unit,
Index: sys/boot/i386/gptboot/Makefile
===
--- sys/boot/i386/gptboot/Makefile (revision 211847)
+++ sys/boot/i386/gptboot/Makefile (working copy)
@@ -27,6 +27,7 @@ CFLAGS= -Os \
-mrtd \
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 \
-D${GPTBOOT_UFS} \
+ -DMACHINE_ARCH=\${MACHINE_ARCH}\ \
-DSIOPRT=${BOOT_COMCONSOLE_PORT} \
-DSIOFMT=${B2SIOFMT} \
-DSIOSPD=${BOOT_COMCONSOLE_SPEED}
Re: Apparent regression in extended/logical partition handling
On Fri, Aug 27, 2010 at 5:35 AM, Doug Barton do...@freebsd.org wrote: Specifically what I did was to boot Windows XP, delete all the partitions other than the XP partition (first primary dos-style partition) and then create a dos-style extended partition, and a logical drive inside of it, leaving room for linux in that same extended partition. Since I want that data volume to be fat32, and it is too large for windows to do it, I next installed FreeBSD 9-current, in a dos-style primary partition. I got it installed fine, but when I booted into FreeBSD 9 to format the logical volume it could not see it. fdisk showed the right information about the extended partition, but in /dev instead of seeing no ad0s2 and seeing ad0s5 like I expected instead there was no ad0s5 and there were ad0s2 entries that mirrored the ad0s3 that FreeBSD 9 was installed on. IOW, I had ad0s3 and ad0s3[a-f] as expected, but I had the same for ad0s2 even though they were obviously not valid. how does it look like in # gpart show ? One side note, I was taught back in the day that dos-style extended partitions always had to be at the end of the disk. Before trying the configuration I have I searched quite a few places to find a reference to that rule and couldn't find one. Perhaps this is something that's actually improved in the PC world in the last 25 years? :) after 25 years, x86 world finally started adapting GPT :) -- O ascii ribbon campaign - stop html mail - www.asciiribbon.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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-08-27 03:49:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-27 03:49:08 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-27 03:49:08 - cleaning the object tree TB --- 2010-08-27 03:49:22 - cvsupping the source tree TB --- 2010-08-27 03:49:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-27 03:50:12 - building world TB --- 2010-08-27 03:50:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-27 03:50:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-27 03:50:12 - TARGET=powerpc TB --- 2010-08-27 03:50:12 - TARGET_ARCH=powerpc64 TB --- 2010-08-27 03:50:12 - TZ=UTC TB --- 2010-08-27 03:50:12 - __MAKE_CONF=/dev/null TB --- 2010-08-27 03:50:12 - cd /src TB --- 2010-08-27 03:50:12 - /usr/bin/make -B buildworld World build started on Fri Aug 27 03:50:12 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 [...] === gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-27 04:18:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-27 04:18:35 - ERROR: failed to build world TB --- 2010-08-27 04:18:35 - 1145.49 user 368.49 system 1766.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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
a question about FreeBSD
Dear all: A quick question about the FreeBSD. In my lab, there is a multicore machine and i install a FreeBSD system on it. I wonder to know how to see the utilization for each core? are there such tools? Thanks! -- Think big; Dream impossible; Make it happen. ___ 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: a question about FreeBSD
On Fri, Aug 27, 2010 at 12:07:11PM +0800, ccuiy...@gmail.com wrote: Dear all: A quick question about the FreeBSD. In my lab, there is a multicore machine and i install a FreeBSD system on it. I wonder to know how to see the utilization for each core? are there such tools? Thanks! Wrong mailing list. Try freebsd-quest...@freebsd.org. Also, try man top. -- 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
