Re: More if_ath churn coming your way!
On 20 January 2011 17:44, Max Khon f...@samodelkin.net wrote: Any chances for proper support for Atheros 802.11n cards? Should not we just port ath9k (Linux) or athn (OpenBSD) drivers? *grin* I have the beginnings of functioning 802.11n support. This stuff is just structural precursors to that. I'm just tidying up bits and pieces and including some updates from ath9k before I begin enabling the 802.11n hooks for others to play with. But I do actually have 802.11n working on FreeBSD at home, at least in station mode. So nyeah. :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: More if_ath churn coming your way!
Adrian, On Thu, Jan 20, 2011 at 11:51 AM, Adrian Chadd adrian.ch...@gmail.comwrote: I'm in the process of merging in the non-intrusive changes to the if_ath code into -HEAD. I'd appreciate some testing just to ensure I haven't broken anything terribly obvious. Any chances for proper support for Atheros 802.11n cards? Should not we just port ath9k (Linux) or athn (OpenBSD) drivers? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: More if_ath churn coming your way!
Dnia czwartek, 20 stycznia 2011 o 10:44:27 Max Khon napisał(a): Adrian, On Thu, Jan 20, 2011 at 11:51 AM, Adrian Chadd adrian.ch...@gmail.comwrote: I'm in the process of merging in the non-intrusive changes to the if_ath code into -HEAD. I'd appreciate some testing just to ensure I haven't broken anything terribly obvious. Any chances for proper support for Atheros 802.11n cards? Should not we just port ath9k (Linux) or athn (OpenBSD) drivers? AFAIK OpenBSD support is limited on these cards. From man athn(4)[1] CAVEATS The athn driver does not support any of the 802.11n capabilities offered by the adapters. Additional work is required in ieee80211(9) before those features can be supported. [1] http://www.openbsd.org/cgi- bin/man.cgi?query=athnapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html Regards, Maciej Milewski ___ 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 sparc64/sparc64
TB --- 2011-01-20 11:38:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-20 11:38:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-01-20 11:38:04 - cleaning the object tree TB --- 2011-01-20 11:38:15 - cvsupping the source tree TB --- 2011-01-20 11:38:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-01-20 11:38:27 - building world TB --- 2011-01-20 11:38:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 11:38:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 11:38:27 - TARGET=sparc64 TB --- 2011-01-20 11:38:27 - TARGET_ARCH=sparc64 TB --- 2011-01-20 11:38:27 - TZ=UTC TB --- 2011-01-20 11:38:27 - __MAKE_CONF=/dev/null TB --- 2011-01-20 11:38:27 - cd /src TB --- 2011-01-20 11:38:27 - /usr/bin/make -B buildworld World build started on Thu Jan 20 11:38:27 UTC 2011 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 Jan 20 12:40:12 UTC 2011 TB --- 2011-01-20 12:40:12 - generating LINT kernel config TB --- 2011-01-20 12:40:12 - cd /src/sys/sparc64/conf TB --- 2011-01-20 12:40:12 - /usr/bin/make -B LINT TB --- 2011-01-20 12:40:13 - building LINT kernel TB --- 2011-01-20 12:40:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 12:40:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 12:40:13 - TARGET=sparc64 TB --- 2011-01-20 12:40:13 - TARGET_ARCH=sparc64 TB --- 2011-01-20 12:40:13 - TZ=UTC TB --- 2011-01-20 12:40:13 - __MAKE_CONF=/dev/null TB --- 2011-01-20 12:40:13 - cd /src TB --- 2011-01-20 12:40:13 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jan 20 12:40:13 UTC 2011 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 [...] /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -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 cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285_attach.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285_reset.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9280.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285.c: No such file or directory /src/sys/dev/ath/ath_hal/ar5416/ar9280_attach.c:31:31: error: ar5416/ar9280v1.ini: No such file or directory /src/sys/dev/ath/ath_hal/ar5416/ar9280_attach.c:32:31: error: ar5416/ar9280v2.ini: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-20 12:41:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-20 12:41:29 - ERROR: failed to build lint kernel TB --- 2011-01-20 12:41:30 - 2888.48 user 589.44 system 3805.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.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 sparc64/sun4v
TB --- 2011-01-20 11:50:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-20 11:50:46 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2011-01-20 11:50:46 - cleaning the object tree TB --- 2011-01-20 11:50:55 - cvsupping the source tree TB --- 2011-01-20 11:50:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2011-01-20 11:51:08 - building world TB --- 2011-01-20 11:51:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 11:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 11:51:08 - TARGET=sun4v TB --- 2011-01-20 11:51:08 - TARGET_ARCH=sparc64 TB --- 2011-01-20 11:51:08 - TZ=UTC TB --- 2011-01-20 11:51:08 - __MAKE_CONF=/dev/null TB --- 2011-01-20 11:51:08 - cd /src TB --- 2011-01-20 11:51:08 - /usr/bin/make -B buildworld World build started on Thu Jan 20 11:51:09 UTC 2011 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 Jan 20 12:51:42 UTC 2011 TB --- 2011-01-20 12:51:42 - generating LINT kernel config TB --- 2011-01-20 12:51:42 - cd /src/sys/sun4v/conf TB --- 2011-01-20 12:51:42 - /usr/bin/make -B LINT TB --- 2011-01-20 12:51:42 - building LINT kernel TB --- 2011-01-20 12:51:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 12:51:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 12:51:42 - TARGET=sun4v TB --- 2011-01-20 12:51:42 - TARGET_ARCH=sparc64 TB --- 2011-01-20 12:51:42 - TZ=UTC TB --- 2011-01-20 12:51:42 - __MAKE_CONF=/dev/null TB --- 2011-01-20 12:51:42 - cd /src TB --- 2011-01-20 12:51:42 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jan 20 12:51:42 UTC 2011 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/dev/ath/ath_hal/ar9002/ar9280_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal 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/dev/ath/ath_hal/ar9002/ar9285_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:248: error: 'AR2427_DEVID_PCIE' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:248: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:248: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Probe': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:410: error: 'AR2427_DEVID_PCIE' undeclared (first use in this function) *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-20 12:55:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-20 12:55:44 - ERROR: failed to build lint kernel TB --- 2011-01-20 12:55:44 - 3001.88 user 628.48 system 3897.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.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 powerpc/powerpc
TB --- 2011-01-20 11:22:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-20 11:22:12 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-01-20 11:22:12 - cleaning the object tree TB --- 2011-01-20 11:22:25 - cvsupping the source tree TB --- 2011-01-20 11:22:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-01-20 11:22:39 - building world TB --- 2011-01-20 11:22:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 11:22:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 11:22:39 - TARGET=powerpc TB --- 2011-01-20 11:22:39 - TARGET_ARCH=powerpc TB --- 2011-01-20 11:22:39 - TZ=UTC TB --- 2011-01-20 11:22:39 - __MAKE_CONF=/dev/null TB --- 2011-01-20 11:22:39 - cd /src TB --- 2011-01-20 11:22:39 - /usr/bin/make -B buildworld World build started on Thu Jan 20 11:22:40 UTC 2011 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 Jan 20 12:57:43 UTC 2011 TB --- 2011-01-20 12:57:44 - generating LINT kernel config TB --- 2011-01-20 12:57:44 - cd /src/sys/powerpc/conf TB --- 2011-01-20 12:57:44 - /usr/bin/make -B LINT TB --- 2011-01-20 12:57:44 - building LINT kernel TB --- 2011-01-20 12:57:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 12:57:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 12:57:44 - TARGET=powerpc TB --- 2011-01-20 12:57:44 - TARGET_ARCH=powerpc TB --- 2011-01-20 12:57:44 - TZ=UTC TB --- 2011-01-20 12:57:44 - __MAKE_CONF=/dev/null TB --- 2011-01-20 12:57:44 - cd /src TB --- 2011-01-20 12:57:44 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jan 20 12:57:44 UTC 2011 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 [...] /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -I/src/sys/contrib/libfdt -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 cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285_attach.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285_reset.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9280.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285.c: No such file or directory /src/sys/dev/ath/ath_hal/ar5416/ar9280_attach.c:31:31: error: ar5416/ar9280v1.ini: No such file or directory /src/sys/dev/ath/ath_hal/ar5416/ar9280_attach.c:32:31: error: ar5416/ar9280v2.ini: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-20 12:58:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-20 12:58:49 - ERROR: failed to build lint kernel TB --- 2011-01-20 12:58:49 - 4710.82 user 772.41 system 5796.65 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-01-20 11:35:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-20 11:35:10 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-01-20 11:35:10 - cleaning the object tree TB --- 2011-01-20 11:35:24 - cvsupping the source tree TB --- 2011-01-20 11:35:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-01-20 11:35:40 - building world TB --- 2011-01-20 11:35:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 11:35:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 11:35:40 - TARGET=powerpc TB --- 2011-01-20 11:35:40 - TARGET_ARCH=powerpc64 TB --- 2011-01-20 11:35:40 - TZ=UTC TB --- 2011-01-20 11:35:40 - __MAKE_CONF=/dev/null TB --- 2011-01-20 11:35:40 - cd /src TB --- 2011-01-20 11:35:40 - /usr/bin/make -B buildworld World build started on Thu Jan 20 11:35:41 UTC 2011 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 stage 5.1: building 32 bit shim libraries World build completed on Thu Jan 20 13:05:30 UTC 2011 TB --- 2011-01-20 13:05:31 - generating LINT kernel config TB --- 2011-01-20 13:05:31 - cd /src/sys/powerpc/conf TB --- 2011-01-20 13:05:31 - /usr/bin/make -B LINT TB --- 2011-01-20 13:05:31 - building LINT kernel TB --- 2011-01-20 13:05:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 13:05:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 13:05:31 - TARGET=powerpc TB --- 2011-01-20 13:05:31 - TARGET_ARCH=powerpc64 TB --- 2011-01-20 13:05:31 - TZ=UTC TB --- 2011-01-20 13:05:31 - __MAKE_CONF=/dev/null TB --- 2011-01-20 13:05:31 - cd /src TB --- 2011-01-20 13:05:31 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jan 20 13:05:31 UTC 2011 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 [...] /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -I/src/sys/contrib/libfdt -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 cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285_attach.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285_reset.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9280.c: No such file or directory cc: /src/sys/dev/ath/ath_hal/ar5416/ar9285.c: No such file or directory /src/sys/dev/ath/ath_hal/ar5416/ar9280_attach.c:31:31: error: ar5416/ar9280v1.ini: No such file or directory /src/sys/dev/ath/ath_hal/ar5416/ar9280_attach.c:32:31: error: ar5416/ar9280v2.ini: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-20 13:06:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-20 13:06:38 - ERROR: failed to build lint kernel TB --- 2011-01-20 13:06:38 - 4316.88 user 873.93 system 5488.27 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
Re: [head tinderbox] failure on amd64/amd64
As far as I can tell this is another cvsup / tinderbox bug. Both sysctl.h and tsc.c were modified in r217616 but somehow tsc.c is seeing the old version of sysctl.h. This happened on another of my commits a few weeks ago. Hmm, does bumping __FreeBSD_version have anything to do with this? I belatedly realize that I should have done it for that rev since the name of a kernel interface changed. Thanks, matthew On Wed, Jan 19, 2011 at 10:18 PM, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-01-20 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-20 03:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-01-20 03:55:00 - cleaning the object tree TB --- 2011-01-20 03:55:27 - cvsupping the source tree TB --- 2011-01-20 03:55:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-01-20 03:55:39 - building world TB --- 2011-01-20 03:55:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 03:55:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 03:55:39 - TARGET=amd64 TB --- 2011-01-20 03:55:39 - TARGET_ARCH=amd64 TB --- 2011-01-20 03:55:39 - TZ=UTC TB --- 2011-01-20 03:55:39 - __MAKE_CONF=/dev/null TB --- 2011-01-20 03:55:39 - cd /src TB --- 2011-01-20 03:55:39 - /usr/bin/make -B buildworld World build started on Thu Jan 20 03:55:43 UTC 2011 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 stage 5.1: building 32 bit shim libraries World build completed on Thu Jan 20 06:04:21 UTC 2011 TB --- 2011-01-20 06:04:21 - generating LINT kernel config TB --- 2011-01-20 06:04:21 - cd /src/sys/amd64/conf TB --- 2011-01-20 06:04:21 - /usr/bin/make -B LINT TB --- 2011-01-20 06:04:21 - building LINT kernel TB --- 2011-01-20 06:04:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 06:04:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 06:04:21 - TARGET=amd64 TB --- 2011-01-20 06:04:21 - TARGET_ARCH=amd64 TB --- 2011-01-20 06:04:21 - TZ=UTC TB --- 2011-01-20 06:04:21 - __MAKE_CONF=/dev/null TB --- 2011-01-20 06:04:21 - cd /src TB --- 2011-01-20 06:04:21 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jan 20 06:04:21 UTC 2011 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 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/nexus.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/tsc.c cc1: warnings being treated as errors /src/sys/x86/x86/tsc.c: In function 'sysctl_machdep_tsc_freq': /src/sys/x86/x86/tsc.c:266: warning: implicit declaration of function 'sysctl_handle_64' /src/sys/x86/x86/tsc.c:266: warning: nested extern declaration of 'sysctl_handle_64' /src/sys/x86/x86/tsc.c: At top level: /src/sys/x86/x86/tsc.c:274: error: 'CTLTYPE_U64' undeclared here (not in a function) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-20 06:18:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-20 06:18:49 - ERROR: failed to build lint kernel TB --- 2011-01-20 06:18:49 - 6881.73 user 1196.77
Re: [head tinderbox] failure on amd64/amd64
On 1/20/2011 9:30 AM, Matthew Fleming wrote: As far as I can tell this is another cvsup / tinderbox bug. Both sysctl.h and tsc.c were modified in r217616 but somehow tsc.c is seeing the old version of sysctl.h. This happened on another of my commits a few weeks ago. Sometimes it takes a bit to get all the updates. The tinderbox syncs off my local cvsup server which gets its updates from cvsup18 once per hr. You can check its progress at http://tinderbox.freebsd.org/ It has since built amd64 ---Mike Hmm, does bumping __FreeBSD_version have anything to do with this? I belatedly realize that I should have done it for that rev since the name of a kernel interface changed. Thanks, matthew On Wed, Jan 19, 2011 at 10:18 PM, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-01-20 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-20 03:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-01-20 03:55:00 - cleaning the object tree TB --- 2011-01-20 03:55:27 - cvsupping the source tree TB --- 2011-01-20 03:55:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-01-20 03:55:39 - building world TB --- 2011-01-20 03:55:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 03:55:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 03:55:39 - TARGET=amd64 TB --- 2011-01-20 03:55:39 - TARGET_ARCH=amd64 TB --- 2011-01-20 03:55:39 - TZ=UTC TB --- 2011-01-20 03:55:39 - __MAKE_CONF=/dev/null TB --- 2011-01-20 03:55:39 - cd /src TB --- 2011-01-20 03:55:39 - /usr/bin/make -B buildworld World build started on Thu Jan 20 03:55:43 UTC 2011 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 stage 5.1: building 32 bit shim libraries World build completed on Thu Jan 20 06:04:21 UTC 2011 TB --- 2011-01-20 06:04:21 - generating LINT kernel config TB --- 2011-01-20 06:04:21 - cd /src/sys/amd64/conf TB --- 2011-01-20 06:04:21 - /usr/bin/make -B LINT TB --- 2011-01-20 06:04:21 - building LINT kernel TB --- 2011-01-20 06:04:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-20 06:04:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-20 06:04:21 - TARGET=amd64 TB --- 2011-01-20 06:04:21 - TARGET_ARCH=amd64 TB --- 2011-01-20 06:04:21 - TZ=UTC TB --- 2011-01-20 06:04:21 - __MAKE_CONF=/dev/null TB --- 2011-01-20 06:04:21 - cd /src TB --- 2011-01-20 06:04:21 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jan 20 06:04:21 UTC 2011 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 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/nexus.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/tsc.c cc1: warnings being treated as errors /src/sys/x86/x86/tsc.c: In function 'sysctl_machdep_tsc_freq': /src/sys/x86/x86/tsc.c:266: warning: implicit declaration of function 'sysctl_handle_64' /src/sys/x86/x86/tsc.c:266: warning: nested extern declaration of 'sysctl_handle_64' /src/sys/x86/x86/tsc.c: At top level: /src/sys/x86/x86/tsc.c:274: error: 'CTLTYPE_U64' undeclared here (not in a function)
Re: BSDInstall: merging to HEAD
On Sat, Jan 15, 2011 at 12:58:33AM -0600, Ade Lovett wrote: On Jan 14, 2011, at 19:31 , Marcel Moolenaar wrote: On Jan 14, 2011, at 10:26 AM, Nathan Whitehorn wrote: The final architecture on which we use sysinstall, ia64, is currently unsupported, because I don't know how to set up booting on those systems -- patches to solve this are very much welcome. Don't let this stop you. I'll work with you on this after the dust has settled. Just out of random curiosity. Seriously. Exactly why, short of of course it runs, in which case NetBSD is -- way, why are we even trying to handle ia64 as a platform, regardless of tier, when it is patently obvious that it is going absolutely _nowhere_ in terms of a viable platform? I was waiting for a developer to reply, but anyway.. I don't know why you, the FreeBSD project, offer ia64 distribution, but as a user I'm very grateful to you for providing it. I think NetBSD is nowhere near FreeBSD on ia64 support. I've learnt things with FreeBSD/ia64 (and with FreeBSD/alpha before it) which I woudn't have leart otherwise. I've 3 FreeBSD/ia64 boxes and by and large I'm very happy with this platform. I can do all I need to do with it. The ~400 or so ports installed on my system is good enough. At least I can pick up a box for $50 from ebay and run /sparc64 on it. Say the same for /ia64? Didn't think so. Well.. ia64 is more expensive, yes. But.. I think it can give you more. I'm quite tempted to get this server, for example: http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItemitem=280618792191 But sparc64 is good as well. In fact, I use a FreeBSD/sparc64 box as an Xserver to view clients running on FreeBSD/ia64. many thanks for your excellent work anton -- 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
RFC vgrind in base (and buildworld)
Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli ___ 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 vgrind in base (and buildworld)
On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. -- Alexander Kabaev signature.asc Description: PGP signature
Re: BSDInstall: merging to HEAD
On 14/01/2011 19:26, Nathan Whitehorn wrote: As those of you who have been reading freebsd-sysinstall and freebsd-arch know, I have been working for a few weeks on a lightweight new installer named 'bsdinstall'. This is designed to replace sysinstall for the 9.0 release. After two weeks of testing and bug fixes on the sysinstall list, I believe this now has all required functionality and is ready to be merged into the main source tree. I would like to do this on Tuesday, 18 January. Switching this to be the default installer would happen a few weeks after that, pending discussion on release formats with the release engineering team. This should provide a sufficient testing period before 9.0 and allow a maximal number of bugs to be discovered and solved before the release is shipped. Demo ISO for i386: http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110114.iso.bz2 SVN repository: svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall Wiki page: http://wiki.freebsd.org/BSDInstall Goals - The primary goal of BSDInstall is to provide an easily extensible installer without the limitations of sysinstall, in order to allow more modern installations of FreeBSD. This means that it should have additional features to support modern setups, but simultaneously frees us to remove complicating features of sysinstall like making sure everything fits in floppy disk-sized chunks. New Features: - Allows installation onto GPT disks on x86 systems - Can do installations spanning multiple disks - Allows installation into jails - Eases PXE installation - Virtualization friendly: can install from a live system onto disk images - Works on PowerPC - Streamlined system installation - More flexible scripting - Easily tweakable - All install CDs are live CDs Architecture BSDInstall is a set of tools that are called in sequence by a master script. These tools are, for example, the partition editor, the thing that fetches the distributions from the network, the thing that untars them, etc. Since these are just called in sequence from a shell script, a scripted installation can easily replace them with other things, (e.g. hard-coded gpart commands), leave steps out, add new ones, or interleave additional system modifications. Status -- This provides functionality most similar to the existing sysinstall 'Express' track. It installs working, bootable systems you can ssh into immediately after reboot on i386, amd64, sparc64, powerpc, and powerpc64. There is untested support for pc98. The final architecture on which we use sysinstall, ia64, is currently unsupported, because I don't know how to set up booting on those systems -- patches to solve this are very much welcome. There are still some missing features that I would like to see in the release, but these do not significantly impact the functionality of the installer. Some will be addressed before merging to HEAD, in particular the lack of a man page for bsdinstall. Others, like configuration of wireless networking and ZFS installation, can happen between merge and release. The test ISOs are also lacking a ports tree at the moment, which is a statement about the slow upload speed of my DSL line and not about the final layout of releases. Please send any questions, comments, or patches you may have, and please be aware when replying that this email has been cross-posted to three lists. Technical discussion (bug reports, for instance) should be directed to the freebsd-sysinstall list only. Most other discussion belongs on -sysinstall and -current. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Why does the installer use GPT partition by default? Do you know that GPT is not supported on every (even modern) computer ? -- David Demelier ___ 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 vgrind in base (and buildworld)
On Thu, 20.01.2011 at 15:31:03 -0500, Alexander Kabaev wrote:
On Thu, 20 Jan 2011 21:17:40 +0100
Ulrich Spörlein u...@freebsd.org wrote:
Hello,
Currently our buildworld relies on groff(1) and vgrind(1) being
present in the host system. I have a patch ready that at least makes
sure these are built during bootstrap-tools and completes the
WITHOUT_GROFF flag.
vgrind(1) is only used for two papers under share/doc and we could
easily expand the results and commit them to svn directly, alleviating
the need to run vgrind(1) during buildworld.
OTOH, there are much more useful tools to vgrind(1) for source code
formatting. So do we still have vgrind(1) users out there?
Regards,
Uli
Why it needs to be in bootsrap tools at all? We have build tools for
this exact purpose.
Because the legacy target has the nice semantics of calling a tool's
obj,depend,all,install targets instead of doing only `all' or
`build-tool'.
We also currently set GROFF_BIN_PATH, GROFF_FONT_PATH, and
GROFF_TMAC_PATH to point to ${WORLDTMP}/legacy/... so it was trivial to
get groff working that way. I don't know the history of why we actually
do this for groff (it is broken currently), therefore I simply
piggy-backed onto that solution.
I forgot the link earlier:
https://www.spoerlein.net/cgit/cgit.cgi/freebsd.work/log/?h=groff
I wish there was an easy way to cleanly have this as a build-tool. While
we're at it: strfile similarly should be moved to a build-tool, not a
bootstrap-tool, as it is also only used to as a pre-requisite to
building fortune(6).
If someone can come up with a policy of what should go where, I'll
happily try to shoehorn the groff/vgrind/strfile things into it ...
Uli
pgp2YEZ8iYaCk.pgp
Description: PGP signature
Re: BSDInstall: merging to HEAD
On Jan 20, 2011, at 1:37 PM, David Demelier wrote: [ ... ] Why does the installer use GPT partition by default? Do you know that GPT is not supported on every (even modern) computer ? Sure. Legacy PC/BIOS platforms can work with a hybrid GPT which includes the legacy or protective MBR used by pre-EFI systems; FreeBSD 7 and later, recent Linux, MacOS X 10.4 and later should be able to boot from disks with that hybrid format. If you need to dual-boot into Windows, however, and your hardware doesn't provide EFI then you're likely stuck using MBR + PC/BIOS only. Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BSDInstall: merging to HEAD
2011/1/20 Chuck Swiger cswi...@mac.com: On Jan 20, 2011, at 1:37 PM, David Demelier wrote: [ ... ] Why does the installer use GPT partition by default? Do you know that GPT is not supported on every (even modern) computer ? Sure. Legacy PC/BIOS platforms can work with a hybrid GPT which includes the legacy or protective MBR used by pre-EFI systems; FreeBSD 7 and later, recent Linux, MacOS X 10.4 and later should be able to boot from disks with that hybrid format. If you need to dual-boot into Windows, however, and your hardware doesn't provide EFI then you're likely stuck using MBR + PC/BIOS only. I use a GPT partitioning scheme for FreeBSD and Linux, and manually edited the protective MBR in order to declare MBR partitions on the same sectors than the GPT partition I wanted to use for Windows. Working really nice. There are tools like gptsync which are simpler to use than a low-level MBR editor. Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: BSDInstall: merging to HEAD
On 01/20/2011 14:15, Chuck Swiger wrote:
On Jan 20, 2011, at 1:37 PM, David Demelier wrote:
[ ... ]
Why does the installer use GPT partition by default? Do you know that GPT is
not supported on every (even modern) computer ?
Sure. Legacy PC/BIOS platforms can work with a hybrid GPT which includes the legacy or
protective MBR used by pre-EFI systems; FreeBSD 7 and later, recent Linux,
MacOS X 10.4 and later should be able to boot from disks with that hybrid format.
If you need to dual-boot into Windows, however, and your hardware doesn't
provide EFI then you're likely stuck using MBR + PC/BIOS only.
We should not do anything by default that damages the ability to
dual-boot windows (and by windows I really mean xp or later since
we'll have xp around through 2014). If there are significant advantages
to gpt as a default when possible then it will be necessary to ask the
user some intelligent questions such as Will this system be
multi-booted? and if yes, Will ${lowest_common_denominator:-windows}
be installed?
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) 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: BSDInstall: merging to HEAD
On 01/20/11 16:44, Doug Barton wrote:
On 01/20/2011 14:15, Chuck Swiger wrote:
On Jan 20, 2011, at 1:37 PM, David Demelier wrote:
[ ... ]
Why does the installer use GPT partition by default? Do you know
that GPT is not supported on every (even modern) computer ?
Sure. Legacy PC/BIOS platforms can work with a hybrid GPT which
includes the legacy or protective MBR used by pre-EFI systems;
FreeBSD 7 and later, recent Linux, MacOS X 10.4 and later should be
able to boot from disks with that hybrid format.
If you need to dual-boot into Windows, however, and your hardware
doesn't provide EFI then you're likely stuck using MBR + PC/BIOS only.
We should not do anything by default that damages the ability to
dual-boot windows (and by windows I really mean xp or later since
we'll have xp around through 2014). If there are significant
advantages to gpt as a default when possible then it will be necessary
to ask the user some intelligent questions such as Will this system
be multi-booted? and if yes, Will
${lowest_common_denominator:-windows} be installed?
It does do exactly what you suggest. It only uses GPT by default if you
have a totally unformatted disk or indicate you intend to run only
FreeBSD on the machine. Otherwise, you get MBR+bsdlabel just like now.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BSDInstall: merging to HEAD
On 01/20/2011 14:47, Nathan Whitehorn wrote:
On 01/20/11 16:44, Doug Barton wrote:
On 01/20/2011 14:15, Chuck Swiger wrote:
On Jan 20, 2011, at 1:37 PM, David Demelier wrote:
[ ... ]
Why does the installer use GPT partition by default? Do you know
that GPT is not supported on every (even modern) computer ?
Sure. Legacy PC/BIOS platforms can work with a hybrid GPT which
includes the legacy or protective MBR used by pre-EFI systems;
FreeBSD 7 and later, recent Linux, MacOS X 10.4 and later should be
able to boot from disks with that hybrid format.
If you need to dual-boot into Windows, however, and your hardware
doesn't provide EFI then you're likely stuck using MBR + PC/BIOS only.
We should not do anything by default that damages the ability to
dual-boot windows (and by windows I really mean xp or later since
we'll have xp around through 2014). If there are significant
advantages to gpt as a default when possible then it will be necessary
to ask the user some intelligent questions such as Will this system
be multi-booted? and if yes, Will
${lowest_common_denominator:-windows} be installed?
It does do exactly what you suggest. It only uses GPT by default if you
have a totally unformatted disk or indicate you intend to run only
FreeBSD on the machine. Otherwise, you get MBR+bsdlabel just like now.
That isn't exactly what I suggested. :) Imagine the following scenario
(which is what I used to do, until our fdisk started using wacky
geometries):
1. Get new computer and/or new hard drive
2. Boot freebsd from installation/live media (aka, disc1)
3. Unceremoniously (and in some cases gleefully) delete all existing
partition/slices
4. Slice the disk, and write out the changes with regular MBR
5. Boot windows, install into the first unused slice/partition
Now if by indicate you intend to run only FreeBSD on the machine above
you mean that you already have questions built into the process that
covers what I proposed above, then fine. My point is simply that running
the installer on a blank (or newly blank'ed) disk is not by itself a
sign that everything that will be installed understands gpt.
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) 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: BSDInstall: merging to HEAD
On Thu, Jan 20, 2011 at 1:37 PM, David Demelier demelier.da...@gmail.com wrote: On 14/01/2011 19:26, Nathan Whitehorn wrote: As those of you who have been reading freebsd-sysinstall and freebsd-arch know, I have been working for a few weeks on a lightweight new installer named 'bsdinstall'. This is designed to replace sysinstall for the 9.0 release. After two weeks of testing and bug fixes on the sysinstall list, I believe this now has all required functionality and is ready to be merged into the main source tree. I would like to do this on Tuesday, 18 January. Switching this to be the default installer would happen a few weeks after that, pending discussion on release formats with the release engineering team. This should provide a sufficient testing period before 9.0 and allow a maximal number of bugs to be discovered and solved before the release is shipped. Demo ISO for i386: http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110114.iso.bz2 SVN repository: svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall Wiki page: http://wiki.freebsd.org/BSDInstall Goals - The primary goal of BSDInstall is to provide an easily extensible installer without the limitations of sysinstall, in order to allow more modern installations of FreeBSD. This means that it should have additional features to support modern setups, but simultaneously frees us to remove complicating features of sysinstall like making sure everything fits in floppy disk-sized chunks. New Features: - Allows installation onto GPT disks on x86 systems - Can do installations spanning multiple disks - Allows installation into jails - Eases PXE installation - Virtualization friendly: can install from a live system onto disk images - Works on PowerPC - Streamlined system installation - More flexible scripting - Easily tweakable - All install CDs are live CDs Architecture BSDInstall is a set of tools that are called in sequence by a master script. These tools are, for example, the partition editor, the thing that fetches the distributions from the network, the thing that untars them, etc. Since these are just called in sequence from a shell script, a scripted installation can easily replace them with other things, (e.g. hard-coded gpart commands), leave steps out, add new ones, or interleave additional system modifications. Status -- This provides functionality most similar to the existing sysinstall 'Express' track. It installs working, bootable systems you can ssh into immediately after reboot on i386, amd64, sparc64, powerpc, and powerpc64. There is untested support for pc98. The final architecture on which we use sysinstall, ia64, is currently unsupported, because I don't know how to set up booting on those systems -- patches to solve this are very much welcome. There are still some missing features that I would like to see in the release, but these do not significantly impact the functionality of the installer. Some will be addressed before merging to HEAD, in particular the lack of a man page for bsdinstall. Others, like configuration of wireless networking and ZFS installation, can happen between merge and release. The test ISOs are also lacking a ports tree at the moment, which is a statement about the slow upload speed of my DSL line and not about the final layout of releases. Please send any questions, comments, or patches you may have, and please be aware when replying that this email has been cross-posted to three lists. Technical discussion (bug reports, for instance) should be directed to the freebsd-sysinstall list only. Most other discussion belongs on -sysinstall and -current. GPT makes more sense on modern machines given the limitation of disk sizes and the MBR partition schemes (and FWIW MBR is less portable outside of the PC world anyhow), but it would be nice if it was a knob that defaulted to appropriate values for certain architectures as well, like PC98 - MBR? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BSDInstall: merging to HEAD
On 01/20/11 17:44, Garrett Cooper wrote: On Thu, Jan 20, 2011 at 1:37 PM, David Demelier demelier.da...@gmail.com wrote: On 14/01/2011 19:26, Nathan Whitehorn wrote: As those of you who have been reading freebsd-sysinstall and freebsd-arch know, I have been working for a few weeks on a lightweight new installer named 'bsdinstall'. This is designed to replace sysinstall for the 9.0 release. After two weeks of testing and bug fixes on the sysinstall list, I believe this now has all required functionality and is ready to be merged into the main source tree. I would like to do this on Tuesday, 18 January. Switching this to be the default installer would happen a few weeks after that, pending discussion on release formats with the release engineering team. This should provide a sufficient testing period before 9.0 and allow a maximal number of bugs to be discovered and solved before the release is shipped. Demo ISO for i386: http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110114.iso.bz2 SVN repository: svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall Wiki page: http://wiki.freebsd.org/BSDInstall Goals - The primary goal of BSDInstall is to provide an easily extensible installer without the limitations of sysinstall, in order to allow more modern installations of FreeBSD. This means that it should have additional features to support modern setups, but simultaneously frees us to remove complicating features of sysinstall like making sure everything fits in floppy disk-sized chunks. New Features: - Allows installation onto GPT disks on x86 systems - Can do installations spanning multiple disks - Allows installation into jails - Eases PXE installation - Virtualization friendly: can install from a live system onto disk images - Works on PowerPC - Streamlined system installation - More flexible scripting - Easily tweakable - All install CDs are live CDs Architecture BSDInstall is a set of tools that are called in sequence by a master script. These tools are, for example, the partition editor, the thing that fetches the distributions from the network, the thing that untars them, etc. Since these are just called in sequence from a shell script, a scripted installation can easily replace them with other things, (e.g. hard-coded gpart commands), leave steps out, add new ones, or interleave additional system modifications. Status -- This provides functionality most similar to the existing sysinstall 'Express' track. It installs working, bootable systems you can ssh into immediately after reboot on i386, amd64, sparc64, powerpc, and powerpc64. There is untested support for pc98. The final architecture on which we use sysinstall, ia64, is currently unsupported, because I don't know how to set up booting on those systems -- patches to solve this are very much welcome. There are still some missing features that I would like to see in the release, but these do not significantly impact the functionality of the installer. Some will be addressed before merging to HEAD, in particular the lack of a man page for bsdinstall. Others, like configuration of wireless networking and ZFS installation, can happen between merge and release. The test ISOs are also lacking a ports tree at the moment, which is a statement about the slow upload speed of my DSL line and not about the final layout of releases. Please send any questions, comments, or patches you may have, and please be aware when replying that this email has been cross-posted to three lists. Technical discussion (bug reports, for instance) should be directed to the freebsd-sysinstall list only. Most other discussion belongs on -sysinstall and -current. GPT makes more sense on modern machines given the limitation of disk sizes and the MBR partition schemes (and FWIW MBR is less portable outside of the PC world anyhow), but it would be nice if it was a knob that defaulted to appropriate values for certain architectures as well, like PC98 - MBR? Such a knob exists, and is used. On PC98, the default partition scheme is the PC98 one, on sparc64 VTOC8, etc. On x86, it is GPT. If you try to put / on a partition scheme that is known not to be bootable on your platform, you will get a warning. The bootable schemes on i386/amd64 are GPT, MBR, and bsdlabel. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BSDInstall: merging to HEAD
On 01/20/11 17:21, Doug Barton wrote:
On 01/20/2011 14:47, Nathan Whitehorn wrote:
On 01/20/11 16:44, Doug Barton wrote:
On 01/20/2011 14:15, Chuck Swiger wrote:
On Jan 20, 2011, at 1:37 PM, David Demelier wrote:
[ ... ]
Why does the installer use GPT partition by default? Do you know
that GPT is not supported on every (even modern) computer ?
Sure. Legacy PC/BIOS platforms can work with a hybrid GPT which
includes the legacy or protective MBR used by pre-EFI systems;
FreeBSD 7 and later, recent Linux, MacOS X 10.4 and later should be
able to boot from disks with that hybrid format.
If you need to dual-boot into Windows, however, and your hardware
doesn't provide EFI then you're likely stuck using MBR + PC/BIOS only.
We should not do anything by default that damages the ability to
dual-boot windows (and by windows I really mean xp or later since
we'll have xp around through 2014). If there are significant
advantages to gpt as a default when possible then it will be necessary
to ask the user some intelligent questions such as Will this system
be multi-booted? and if yes, Will
${lowest_common_denominator:-windows} be installed?
It does do exactly what you suggest. It only uses GPT by default if you
have a totally unformatted disk or indicate you intend to run only
FreeBSD on the machine. Otherwise, you get MBR+bsdlabel just like now.
That isn't exactly what I suggested. :) Imagine the following
scenario (which is what I used to do, until our fdisk started using
wacky geometries):
1. Get new computer and/or new hard drive
2. Boot freebsd from installation/live media (aka, disc1)
3. Unceremoniously (and in some cases gleefully) delete all existing
partition/slices
4. Slice the disk, and write out the changes with regular MBR
5. Boot windows, install into the first unused slice/partition
Now if by indicate you intend to run only FreeBSD on the machine
above you mean that you already have questions built into the process
that covers what I proposed above, then fine. My point is simply that
running the installer on a blank (or newly blank'ed) disk is not by
itself a sign that everything that will be installed understands gpt.
It does. It only does GPT by default if you say I want to erase my hard
disk (or it is already blank), then select Automatic partitioning. If
you have an existing partition scheme, it is kept even if you select
automatic (assuming it is bootable on your platform).
If you want something more complicated (i.e. any kind of dual-booting
scenario), then you will want to specify partition sizes with the editor
anyway. Once you exit automatic mode to invoke the editor, it allows you
to set up bsdlabel-only, MBR+bsdlabel, GPT, installations spanning
multiple disks, and whatever else you might want to do. If that isn't
enough flexibility, there is also a I don't need no stinking partition
editor option, where you can set up whatever you like with a shell.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC vgrind in base (and buildworld)
On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. Actually no. The buildtools target is there to allow building programs that are not installed, but are otehrwise needed to compile a program. These are typically little tools that create source files. The bootstrap target is the to deal with compatibility in case we can't use the version on the host or we don't want to depend on the version on the host. -- Marcel Moolenaar xcl...@mac.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: BSDInstall: merging to HEAD
On 1/20/2011 3:37 PM, David Demelier wrote: Why does the installer use GPT partition by default? Do you know that GPT is not supported on every (even modern) computer ? GPT is fully compatible with the universe of PC/AT BIOS-compatible computers, which is essentially all PCs going back to the IBM model 5170 released in 1984. GPT contains a valid boot sector which is sufficient for a PC/AT-compatible to boot the OS. There's also a valid MBR should anyone look for that. There have been reports of computers with buggy BIOSs that fail with GPT. It's not clear how to make them work since they're failing with a *valid* MBR, i.e., the failure indicates they fail with some correct MBRs and we can't be sure they'll work even if we write an MBR instead of GPT. PS. In a previous life I did PCs. Every system I released after 1988 or so would work with GPT. It's hard to get this one wrong and still be PC-compatible./ / ___ 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
