Re: IPv6 accept_rtadv + bfe0
On Tuesday, October 18, 2011 11:16:57 pm Bjoern A. Zeeb wrote: > On 18. Oct 2011, at 20:00 , Johann Hugo wrote: > > Hi > > > > The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do > > it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to > > ifconfig_bge0 in rc.conf it does nothing. > > > > grep bfe /etc/rc.conf > > ifconfig_bfe0="DHCP accept_rtadv" > > ifconfig_bfe0="DHCP" > ifconfig_bfe0_ipv6="inet6 accept_rtadv" That works, but what is the function of ipv6_activate_all_interfaces="YES" in rc.conf Johann ___ 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-10-19 05:26:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 05:26:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-19 05:26:00 - cleaning the object tree TB --- 2011-10-19 05:26:04 - cvsupping the source tree TB --- 2011-10-19 05:26:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-19 05:26:15 - building world TB --- 2011-10-19 05:26:15 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 05:26:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 05:26:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 05:26:15 - SRCCONF=/dev/null TB --- 2011-10-19 05:26:15 - TARGET=powerpc TB --- 2011-10-19 05:26:15 - TARGET_ARCH=powerpc TB --- 2011-10-19 05:26:15 - TZ=UTC TB --- 2011-10-19 05:26:15 - __MAKE_CONF=/dev/null TB --- 2011-10-19 05:26:15 - cd /src TB --- 2011-10-19 05:26:15 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 19 05:26:16 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-19 06:10:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 06:10:39 - ERROR: failed to build world TB --- 2011-10-19 06:10:39 - 2022.01 user 455.10 system 2678.59 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 amd64/amd64
TB --- 2011-10-19 04:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 04:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-19 04:40:01 - cleaning the object tree TB --- 2011-10-19 04:40:08 - cvsupping the source tree TB --- 2011-10-19 04:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-19 04:40:25 - building world TB --- 2011-10-19 04:40:25 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 04:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 04:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 04:40:25 - SRCCONF=/dev/null TB --- 2011-10-19 04:40:25 - TARGET=amd64 TB --- 2011-10-19 04:40:25 - TARGET_ARCH=amd64 TB --- 2011-10-19 04:40:25 - TZ=UTC TB --- 2011-10-19 04:40:25 - __MAKE_CONF=/dev/null TB --- 2011-10-19 04:40:25 - cd /src TB --- 2011-10-19 04:40:25 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 19 04:40:26 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-19 05:25:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 05:25:59 - ERROR: failed to build world TB --- 2011-10-19 05:26:00 - 2118.74 user 477.88 system 2758.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.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 i386/pc98
TB --- 2011-10-19 04:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 04:40:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-19 04:40:01 - cleaning the object tree TB --- 2011-10-19 04:40:08 - cvsupping the source tree TB --- 2011-10-19 04:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-19 04:40:25 - building world TB --- 2011-10-19 04:40:25 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 04:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 04:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 04:40:25 - SRCCONF=/dev/null TB --- 2011-10-19 04:40:25 - TARGET=pc98 TB --- 2011-10-19 04:40:25 - TARGET_ARCH=i386 TB --- 2011-10-19 04:40:25 - TZ=UTC TB --- 2011-10-19 04:40:25 - __MAKE_CONF=/dev/null TB --- 2011-10-19 04:40:25 - cd /src TB --- 2011-10-19 04:40:25 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 19 04:40:25 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-19 05:25:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 05:25:25 - ERROR: failed to build world TB --- 2011-10-19 05:25:25 - 2092.46 user 475.00 system 2724.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.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 i386/i386
TB --- 2011-10-19 04:40:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 04:40:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-19 04:40:01 - cleaning the object tree TB --- 2011-10-19 04:40:08 - cvsupping the source tree TB --- 2011-10-19 04:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-19 04:40:25 - building world TB --- 2011-10-19 04:40:25 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 04:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 04:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 04:40:25 - SRCCONF=/dev/null TB --- 2011-10-19 04:40:25 - TARGET=i386 TB --- 2011-10-19 04:40:25 - TARGET_ARCH=i386 TB --- 2011-10-19 04:40:25 - TZ=UTC TB --- 2011-10-19 04:40:25 - __MAKE_CONF=/dev/null TB --- 2011-10-19 04:40:25 - cd /src TB --- 2011-10-19 04:40:25 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 19 04:40:26 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-19 05:25:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 05:25:10 - ERROR: failed to build world TB --- 2011-10-19 05:25:10 - 2090.01 user 465.27 system 2709.18 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 powerpc/powerpc
TB --- 2011-10-19 01:55:33 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 01:55:33 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-19 01:55:33 - cleaning the object tree TB --- 2011-10-19 01:55:38 - cvsupping the source tree TB --- 2011-10-19 01:55:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-19 01:55:49 - building world TB --- 2011-10-19 01:55:49 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 01:55:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 01:55:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 01:55:49 - SRCCONF=/dev/null TB --- 2011-10-19 01:55:49 - TARGET=powerpc TB --- 2011-10-19 01:55:49 - TARGET_ARCH=powerpc TB --- 2011-10-19 01:55:49 - TZ=UTC TB --- 2011-10-19 01:55:49 - __MAKE_CONF=/dev/null TB --- 2011-10-19 01:55:49 - cd /src TB --- 2011-10-19 01:55:49 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 19 01:55:49 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-19 02:40:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 02:40:46 - ERROR: failed to build world TB --- 2011-10-19 02:40:46 - 2044.12 user 459.25 system 2713.24 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"
config(8) does not add post-processing for source file with compile-with command in sys/conf/files
when I digged the a PR(bin/160275), I found in_proto.c and
if_ethersubr.c ( see sys/conf/files ) does not get
${NORMAL_CTFCONVERT} post-processing in Makefile
(/usr/obj/usr/src/sys/MYKERNEL/Makefile) generated by config(8), so
the objs does not contain ctf section
In /usr/src/usr.sbin/config/mkmakefile.c, line 746
}
compilewith = ftp->f_compilewith;
if (compilewith == 0) { // no compile-with
const char *ftype = NULL;
switch (ftp->f_type) {
case NORMAL:
ftype = "NORMAL";
break;
case PROFILING:
if (!profiling)
continue;
ftype = "PROFILE";
break;
default:
fprintf(stderr,
"config: don't know rules for %s\n", np);
break;
}
// only add post-processing for source file without compile-with
snprintf(cmd, sizeof(cmd),
"${%s_%c%s}\n\t@${NORMAL_CTFCONVERT}", ftype,
toupper(och),
ftp->f_flags & NOWERROR ? "_NOWERROR" : "");
compilewith = cmd;
}
*cp = och;
if (strlen(ftp->f_objprefix))
fprintf(f, "\t%s $S/%s\n\n", compilewith, np);
else
fprintf(f, "\t%s\n\n", compilewith);
}
}
I wonder whether it was NOT allowed to add post-processing to files
with compile-with, license or other issues?
if not a license issue, then I wonder if this fix is OK( I test it on
8-stable with gcc, and 9-stable with both gcc and clang)
diff --git a/usr.sbin/config/mkmakefile.c b/usr.sbin/config/mkmakefile.c
index 2372839..25a85de 100644
--- a/usr.sbin/config/mkmakefile.c
+++ b/usr.sbin/config/mkmakefile.c
@@ -767,6 +767,14 @@ do_rules(FILE *f)
ftp->f_flags & NOWERROR ? "_NOWERROR" : "");
compilewith = cmd;
}
+ //handle CTF issule with NORMAL_C and NORMAL_C_NOERROR
+ else if (!strncmp(compilewith, "${NORMAL_C",sizeof("${NORMAL_C"))) {
+ snprintf(cmd, sizeof(cmd),
+"%s\n\t@${NORMAL_CTFCONVERT}", compilewith);
+ compilewith = cmd;
+ }
___
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 amd64/amd64
TB --- 2011-10-19 01:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 01:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-19 01:10:00 - cleaning the object tree TB --- 2011-10-19 01:10:07 - cvsupping the source tree TB --- 2011-10-19 01:10:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-19 01:10:26 - building world TB --- 2011-10-19 01:10:26 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 01:10:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 01:10:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 01:10:26 - SRCCONF=/dev/null TB --- 2011-10-19 01:10:26 - TARGET=amd64 TB --- 2011-10-19 01:10:26 - TARGET_ARCH=amd64 TB --- 2011-10-19 01:10:26 - TZ=UTC TB --- 2011-10-19 01:10:26 - __MAKE_CONF=/dev/null TB --- 2011-10-19 01:10:26 - cd /src TB --- 2011-10-19 01:10:26 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 19 01:10:26 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-19 01:55:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 01:55:32 - ERROR: failed to build world TB --- 2011-10-19 01:55:32 - 2091.32 user 476.83 system 2732.58 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.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 i386/pc98
TB --- 2011-10-19 01:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 01:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-19 01:10:00 - cleaning the object tree TB --- 2011-10-19 01:10:07 - cvsupping the source tree TB --- 2011-10-19 01:10:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-19 01:10:26 - building world TB --- 2011-10-19 01:10:26 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 01:10:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 01:10:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 01:10:26 - SRCCONF=/dev/null TB --- 2011-10-19 01:10:26 - TARGET=pc98 TB --- 2011-10-19 01:10:26 - TARGET_ARCH=i386 TB --- 2011-10-19 01:10:26 - TZ=UTC TB --- 2011-10-19 01:10:26 - __MAKE_CONF=/dev/null TB --- 2011-10-19 01:10:26 - cd /src TB --- 2011-10-19 01:10:26 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 19 01:10:26 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-19 01:54:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 01:54:56 - ERROR: failed to build world TB --- 2011-10-19 01:54:57 - 2065.98 user 472.90 system 2696.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.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 i386/i386
TB --- 2011-10-19 01:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 01:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-19 01:10:00 - cleaning the object tree TB --- 2011-10-19 01:10:07 - cvsupping the source tree TB --- 2011-10-19 01:10:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-19 01:10:26 - building world TB --- 2011-10-19 01:10:26 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 01:10:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 01:10:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 01:10:26 - SRCCONF=/dev/null TB --- 2011-10-19 01:10:26 - TARGET=i386 TB --- 2011-10-19 01:10:26 - TARGET_ARCH=i386 TB --- 2011-10-19 01:10:26 - TZ=UTC TB --- 2011-10-19 01:10:26 - __MAKE_CONF=/dev/null TB --- 2011-10-19 01:10:26 - cd /src TB --- 2011-10-19 01:10:26 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 19 01:10:26 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-19 01:54:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 01:54:35 - ERROR: failed to build world TB --- 2011-10-19 01:54:35 - 2059.50 user 463.81 system 2675.59 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"
Re: IPv6 accept_rtadv + bfe0
On 19/10/2011 08:16, Bjoern A. Zeeb wrote: On 18. Oct 2011, at 20:00 , Johann Hugo wrote: Hi The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in rc.conf it does nothing. grep bfe /etc/rc.conf ifconfig_bfe0="DHCP accept_rtadv" ifconfig_bfe0="DHCP" ifconfig_bfe0_ipv6="inet6 accept_rtadv" So the _ipv6 bit doesn't take care of passing "inet6" to ifconfig automatically? Does passing two options work, or do I have to pass them separately? E.g.: ifconfig_bfe0_ipv6="inet6 accept_rtadv -ifdisable" or ifconfig_bfe0_ipv6="inet6 accept_rtadv" ifconfig_bfe0_ipv6="inet6 -ifdisable" Mat ___ 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-10-18 22:26:44 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-18 22:26:44 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-18 22:26:44 - cleaning the object tree TB --- 2011-10-18 22:26:58 - cvsupping the source tree TB --- 2011-10-18 22:26:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-18 22:27:11 - building world TB --- 2011-10-18 22:27:11 - CROSS_BUILD_TESTING=YES TB --- 2011-10-18 22:27:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-18 22:27:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-18 22:27:11 - SRCCONF=/dev/null TB --- 2011-10-18 22:27:11 - TARGET=powerpc TB --- 2011-10-18 22:27:11 - TARGET_ARCH=powerpc TB --- 2011-10-18 22:27:11 - TZ=UTC TB --- 2011-10-18 22:27:11 - __MAKE_CONF=/dev/null TB --- 2011-10-18 22:27:11 - cd /src TB --- 2011-10-18 22:27:11 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 18 22:27:11 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-18 23:11:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-18 23:11:43 - ERROR: failed to build world TB --- 2011-10-18 23:11:43 - 2031.27 user 451.99 system 2698.48 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"
Re: [RFC] Enable nxstack by default
In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...) [0] http://pax.grsecurity.net/docs/index.html [1] http://www.netbsd.org/~elad/recent/man/security.8.html [2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff On 10/19/11, Arnaud Lacombe wrote: > Hi, > > 2011/10/18 Kostik Belousov : >> On Tue, Oct 18, 2011 at 01:06:27PM -0400, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter >>> wrote: >>> > On 10/18/11, Arnaud Lacombe wrote: >>> >> Hi, >>> >> >>> >> On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper >>> >> wrote: >>> >>> On Tue, 18 Oct 2011, Arnaud Lacombe wrote: >>> >>> >>> Hi, >>> >>> On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov >>> >>> wrote: >>> > >>> > On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: >>> >> >>> >> Hi all! >>> >> >>> >> I think, it's the time to enable the nxstack feature. Any >>> >> comments, >>> >> pros, cons? >>> > >>> > I dragged the change long enough for it to miss the 9.0. >>> > After the 9.0 is released, I will flip the switch with the >>> > following >>> > change. >>> > >>> > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c >>> > index 8455f48..926fe64 100644 >>> > --- a/sys/kern/imgact_elf.c >>> > +++ b/sys/kern/imgact_elf.c >>> > @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; >>> > SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, >>> > &elf_legacy_coredump, 0, ""); >>> > >>> > -static int __elfN(nxstack) = 0; >>> > +int __elfN(nxstack) = >>> > +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 >>> > bit >>> > */ >>> > >>> Why leaving 32bits x86 CPU supporting the NX feature behind ? >>> >>> >>> >>> Most likely because it was assumed that i386 doesn't fully support >>> >>> it. >>> >>> According to ye great Wikipedia, NX support didn't roll into i386 >>> >>> until >>> >>> Prescott, which was pretty late in the non-64-bit capable family of >>> >>> CPUs, >>> >>> as >>> >>> its successor -- Conroe -- was 64-bit. Intel detuned some of the >>> >>> early >>> >>> Dual >>> >>> Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about >>> >>> AMD. >>> >>> >>> >>> There are probably more details in binutils, gcc, etc, that I'm >>> >>> missing >>> >>> and >>> >>> Kostik can expound on. >>> >>> >>> >> NX support is advertised in the cpuid flags, just add the logic to >>> >> handle this interface. Kostik's patch is just incomplete, but he's got >>> >> a commit bit so he can commit it as-is, as he will. >>> >> >>> >> If nonexec_stack becomes the default, it should be on every CPU >>> >> supporting the feature, not just the low-hanging one. >>> >> >>> >> - Arnaud >>> >> >>> > >>> > the NX detection code already implemented in i386, but this feature >>> > required PAE: >>> > >>> yes, this is the conclusion I reached too. But this does not change >>> the fact that the VM should know about that, and this is missing from >>> Kostik's patch. I guess the first hunk should read: >>> >>> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; >>> SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, >>> &elf_legacy_coredump, 0, ""); >>> >>> -static int __elfN(nxstack) = 0; >>> +int __elfN(nxstack) = >>> +#if defined(PAE) || defined(__amd64__) || defined(__powerpc64__) /* >>> both 64 and 32 bit */ >>> + 1; >>> +#else >>> + 0; >>> +#endif >>> SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO, >>> nxstack, CTLFLAG_RW, &__elfN(nxstack), 0, >>> __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable >>> stack"); >> >> Your patch is not right, it will cause even more user confusion. >> The presence of the PAE kernel does not imply that CPU supports nx. >> >> Below is the updated patch that turns on nxstack by default for the PAE >> kernels on NX-capable CPUs. Note that i386 usermode fully supports the >> PT_GNU_STACK annotations and cares about not enabling nx on stack pages >> unneccessary, but my main target was compat32 on amd64. >> >> The fact that nxstack is not enabled by default does not prevent >> administrator from manually enabling the feature. >> >> Since you worried so much about PAE case, I sincerely expect that you >> will test the change. Thank you in advance. >> > I will. > > Btw, NetBSD has been going down the path of system unit test, > especially of kernel/userland interfaces, and already worked-out the > framework for that. Is that something FreeBSD would be interested in ? > > Thanks, > - Arnaud > >> diff --git a/sys/i386/i386/initcpu.c b/sys/i386/i386/initcpu.c >> index c2daf54..ec77adb 100644 >> --- a/sys/i386/i386/initcpu.c >> +++ b/sys/i386/i386/initcpu.c >> @@ -650,6 +650,8 @@ enable_sse(void) >> #endif >> } >> >> +extern int elf32_nxstack; >> + >> void >
Re: About FreeBSD 9.0 release note
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/18/11 15:07, Hiroki Sato wrote: > Hideki Yamamoto wrote in > : > > hy> Hi, hy> hy> Does someone know where is the draft of FreeBSD > 9.0 release note? hy> I would like to check if there is a > description about new functions hy> about MLDv2 is included or > not. hy> I think the below feature should be included in the > release note as hy> IPv6 network is getting popular. hy> hy> > - hy> MFC r200871: hy> Use > ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave > hy> with SSM MLDv2 by default. hy> This is current practice and > complies with RFC 4604, as well as being hy> required by > production IPv6 networks in Japan. hy> The behaviour may be > disabled by setting the net.inet6.mld.use_allow hy> sysctl/tunable > to 0. hy> - > > I am already working on the relnotes and the above will be > included as an improvement of the IPv6 stack. Can we have it somewhere (in the CVS or wiki) so we can work together on that? This way also makes translation easier... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOnf1GAAoJEATO+BI/yjfB7QYH/iWLx4Gme1uR+KAweDABTj2u tBZIHxrD68O1STbeQHM/69zZ5CmsjBmpI7p3smRCII2yI/UZkwWB4EQH9aTZ0ova KT1sLeZgdeCUbA6kg8ok/bZF6Fdo4ZdeOb7ufuDrz6LMbUOQo1NrYhoAZkrjE8/P Qab8rtbLk9doqDV3/wBikr0mgAO/h+IRiZpFso90msT2xYrMhEVvOso3lL9Nsu9V S+Y1dbzbFsSAa25k/l95WJ0C4eh14Zlh7DykdnVgqyo4oy6N0gyfQaS1NYocc268 9Y5juonQh4y58LMwK8jfP0Xl1k6/ZjkNwN+MzboRTvf0Oj0lQY8jKwY0BpQRFX8= =ivPD -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on amd64/amd64
TB --- 2011-10-18 21:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-18 21:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-18 21:40:00 - cleaning the object tree TB --- 2011-10-18 21:41:04 - cvsupping the source tree TB --- 2011-10-18 21:41:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-18 21:41:17 - building world TB --- 2011-10-18 21:41:17 - CROSS_BUILD_TESTING=YES TB --- 2011-10-18 21:41:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-18 21:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-18 21:41:17 - SRCCONF=/dev/null TB --- 2011-10-18 21:41:17 - TARGET=amd64 TB --- 2011-10-18 21:41:17 - TARGET_ARCH=amd64 TB --- 2011-10-18 21:41:17 - TZ=UTC TB --- 2011-10-18 21:41:17 - __MAKE_CONF=/dev/null TB --- 2011-10-18 21:41:17 - cd /src TB --- 2011-10-18 21:41:17 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 18 21:41:17 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-18 22:26:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-18 22:26:44 - ERROR: failed to build world TB --- 2011-10-18 22:26:44 - 2092.45 user 492.93 system 2804.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.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 i386/i386
TB --- 2011-10-18 21:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-18 21:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-18 21:40:00 - cleaning the object tree TB --- 2011-10-18 21:41:05 - cvsupping the source tree TB --- 2011-10-18 21:41:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-18 21:41:17 - building world TB --- 2011-10-18 21:41:17 - CROSS_BUILD_TESTING=YES TB --- 2011-10-18 21:41:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-18 21:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-18 21:41:17 - SRCCONF=/dev/null TB --- 2011-10-18 21:41:17 - TARGET=i386 TB --- 2011-10-18 21:41:17 - TARGET_ARCH=i386 TB --- 2011-10-18 21:41:17 - TZ=UTC TB --- 2011-10-18 21:41:17 - __MAKE_CONF=/dev/null TB --- 2011-10-18 21:41:17 - cd /src TB --- 2011-10-18 21:41:17 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 18 21:41:18 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-18 22:25:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-18 22:25:50 - ERROR: failed to build world TB --- 2011-10-18 22:25:51 - 2066.52 user 476.09 system 2750.65 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"
Re: [RFC] Enable nxstack by default
Hi,
2011/10/18 Kostik Belousov :
> On Tue, Oct 18, 2011 at 01:06:27PM -0400, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter
>> wrote:
>> > On 10/18/11, Arnaud Lacombe wrote:
>> >> Hi,
>> >>
>> >> On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper
>> >> wrote:
>> >>> On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
>> >>>
>> Hi,
>>
>> On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov
>> wrote:
>> >
>> > On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
>> >>
>> >> Hi all!
>> >>
>> >> I think, it's the time to enable the nxstack feature. Any comments,
>> >> pros, cons?
>> >
>> > I dragged the change long enough for it to miss the 9.0.
>> > After the 9.0 is released, I will flip the switch with the following
>> > change.
>> >
>> > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
>> > index 8455f48..926fe64 100644
>> > --- a/sys/kern/imgact_elf.c
>> > +++ b/sys/kern/imgact_elf.c
>> > @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
>> > SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
>> > &elf_legacy_coredump, 0, "");
>> >
>> > -static int __elfN(nxstack) = 0;
>> > +int __elfN(nxstack) =
>> > +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit
>> > */
>> >
>> Why leaving 32bits x86 CPU supporting the NX feature behind ?
>> >>>
>> >>> Most likely because it was assumed that i386 doesn't fully support it.
>> >>> According to ye great Wikipedia, NX support didn't roll into i386 until
>> >>> Prescott, which was pretty late in the non-64-bit capable family of CPUs,
>> >>> as
>> >>> its successor -- Conroe -- was 64-bit. Intel detuned some of the early
>> >>> Dual
>> >>> Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD.
>> >>>
>> >>> There are probably more details in binutils, gcc, etc, that I'm missing
>> >>> and
>> >>> Kostik can expound on.
>> >>>
>> >> NX support is advertised in the cpuid flags, just add the logic to
>> >> handle this interface. Kostik's patch is just incomplete, but he's got
>> >> a commit bit so he can commit it as-is, as he will.
>> >>
>> >> If nonexec_stack becomes the default, it should be on every CPU
>> >> supporting the feature, not just the low-hanging one.
>> >>
>> >> - Arnaud
>> >>
>> >
>> > the NX detection code already implemented in i386, but this feature
>> > required PAE:
>> >
>> yes, this is the conclusion I reached too. But this does not change
>> the fact that the VM should know about that, and this is missing from
>> Kostik's patch. I guess the first hunk should read:
>>
>> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
>> SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
>> &elf_legacy_coredump, 0, "");
>>
>> -static int __elfN(nxstack) = 0;
>> +int __elfN(nxstack) =
>> +#if defined(PAE) || defined(__amd64__) || defined(__powerpc64__) /*
>> both 64 and 32 bit */
>> + 1;
>> +#else
>> + 0;
>> +#endif
>> SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
>> nxstack, CTLFLAG_RW, &__elfN(nxstack), 0,
>> __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable
>> stack");
>
> Your patch is not right, it will cause even more user confusion.
> The presence of the PAE kernel does not imply that CPU supports nx.
>
> Below is the updated patch that turns on nxstack by default for the PAE
> kernels on NX-capable CPUs. Note that i386 usermode fully supports the
> PT_GNU_STACK annotations and cares about not enabling nx on stack pages
> unneccessary, but my main target was compat32 on amd64.
>
> The fact that nxstack is not enabled by default does not prevent
> administrator from manually enabling the feature.
>
> Since you worried so much about PAE case, I sincerely expect that you
> will test the change. Thank you in advance.
>
I will.
Btw, NetBSD has been going down the path of system unit test,
especially of kernel/userland interfaces, and already worked-out the
framework for that. Is that something FreeBSD would be interested in ?
Thanks,
- Arnaud
> diff --git a/sys/i386/i386/initcpu.c b/sys/i386/i386/initcpu.c
> index c2daf54..ec77adb 100644
> --- a/sys/i386/i386/initcpu.c
> +++ b/sys/i386/i386/initcpu.c
> @@ -650,6 +650,8 @@ enable_sse(void)
> #endif
> }
>
> +extern int elf32_nxstack;
> +
> void
> initializecpu(void)
> {
> @@ -739,6 +741,7 @@ initializecpu(void)
> msr = rdmsr(MSR_EFER) | EFER_NXE;
> wrmsr(MSR_EFER, msr);
> pg_nx = PG_NX;
> + elf32_nxstack = 1;
> }
> #endif
> break;
> diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
> index 8455f48..926fe64 100644
> --- a/sys/kern/imgact_elf.c
> +++ b/sys/kern/imgact_elf.c
> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
> SYSCTL_INT(_debug, OID_AUTO, __elfN(leg
[head tinderbox] failure on i386/pc98
TB --- 2011-10-18 21:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-18 21:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-18 21:40:00 - cleaning the object tree TB --- 2011-10-18 21:40:33 - cvsupping the source tree TB --- 2011-10-18 21:40:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-18 21:40:53 - building world TB --- 2011-10-18 21:40:53 - CROSS_BUILD_TESTING=YES TB --- 2011-10-18 21:40:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-18 21:40:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-18 21:40:53 - SRCCONF=/dev/null TB --- 2011-10-18 21:40:53 - TARGET=pc98 TB --- 2011-10-18 21:40:53 - TARGET_ARCH=i386 TB --- 2011-10-18 21:40:53 - TZ=UTC TB --- 2011-10-18 21:40:53 - __MAKE_CONF=/dev/null TB --- 2011-10-18 21:40:53 - cd /src TB --- 2011-10-18 21:40:53 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 18 21:40:54 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 [...] /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::MipsTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'void::FreeBSDTargetInfo::getOSDefines(const clang::LangOptions&, const llvm::Triple&, clang::MacroBuilder&) const [with Target = ::ARMTargetInfo]': /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:3063: instantiated from here /src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp:245: error: 'Twine' was not declared in this scope *** Error code 1 Stop in /src/lib/clang/libclangbasic. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/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 --- 2011-10-18 22:25:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-18 22:25:35 - ERROR: failed to build world TB --- 2011-10-18 22:25:35 - 2065.66 user 475.65 system 2735.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.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: About FreeBSD 9.0 release note
On Wed, Oct 19, 2011 at 2:07 AM, Hiroki Sato wrote: > Hideki Yamamoto wrote > in : > > hy> Hi, > hy> > hy> Does someone know where is the draft of FreeBSD 9.0 release note? > hy> I would like to check if there is a description about new functions > hy> about MLDv2 is included or not. > hy> I think the below feature should be included in the release note as > hy> IPv6 network is getting popular. > hy> > hy> - > hy> MFC r200871: > hy> Use ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave > hy> with SSM MLDv2 by default. > hy> This is current practice and complies with RFC 4604, as well as being > hy> required by production IPv6 networks in Japan. > hy> The behaviour may be disabled by setting the net.inet6.mld.use_allow > hy> sysctl/tunable to 0. > hy> - > > I am already working on the relnotes and the above will be included > as an improvement of the IPv6 stack. > If you're not complicated. Maybe we should put a draft on the wiki? ___ 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: About FreeBSD 9.0 release note
Hideki Yamamoto wrote in : hy> Hi, hy> hy> Does someone know where is the draft of FreeBSD 9.0 release note? hy> I would like to check if there is a description about new functions hy> about MLDv2 is included or not. hy> I think the below feature should be included in the release note as hy> IPv6 network is getting popular. hy> hy> - hy> MFC r200871: hy> Use ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave hy> with SSM MLDv2 by default. hy> This is current practice and complies with RFC 4604, as well as being hy> required by production IPv6 networks in Japan. hy> The behaviour may be disabled by setting the net.inet6.mld.use_allow hy> sysctl/tunable to 0. hy> - I am already working on the relnotes and the above will be included as an improvement of the IPv6 stack. -- Hiroki pgpooCpg10Xx0.pgp Description: PGP signature
About FreeBSD 9.0 release note
Hi, Does someone know where is the draft of FreeBSD 9.0 release note? I would like to check if there is a description about new functions about MLDv2 is included or not. I think the below feature should be included in the release note as IPv6 network is getting popular. - MFC r200871: Use ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave with SSM MLDv2 by default. This is current practice and complies with RFC 4604, as well as being required by production IPv6 networks in Japan. The behaviour may be disabled by setting the net.inet6.mld.use_allow sysctl/tunable to 0. - Best regards, Hideki Yamamoto ___ 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: IPv6 accept_rtadv + bfe0
On 18. Oct 2011, at 20:00 , Johann Hugo wrote: > Hi > > The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it > with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in > rc.conf it does nothing. > > grep bfe /etc/rc.conf > ifconfig_bfe0="DHCP accept_rtadv" ifconfig_bfe0="DHCP" ifconfig_bfe0_ipv6="inet6 accept_rtadv" -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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"
IPv6 accept_rtadv + bfe0
Hi The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in rc.conf it does nothing. grep bfe /etc/rc.conf ifconfig_bfe0="DHCP accept_rtadv" ifconfig bfe0 bfe0: flags=8843 metric 0 mtu 1500 options=80008 ether 00:1d:09:a7:41:a8 inet6 fe80::21d:9ff:fea7:41a8%bfe0 prefixlen 64 scopeid 0x9 inet 146.64.80.134 netmask 0xff00 broadcast 146.64.80.255 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active ifconfig bfe0 inet6 accept_rtadv ifconfig bfe0 bfe0: flags=8843 metric 0 mtu 1500 options=80008 ether 00:1d:09:a7:41:a8 inet6 fe80::21d:9ff:fea7:41a8%bfe0 prefixlen 64 scopeid 0x9 inet 146.64.80.134 netmask 0xff00 broadcast 146.64.80.255 inet6 2001:4200:7000:100:21d:9ff:fea7:41a8 prefixlen 64 autoconf nd6 options=23 media: Ethernet autoselect (100baseTX ) status: active uname -a FreeBSD pcbsd-615 9.0-BETA3 FreeBSD 9.0-BETA3 grep v6 /etc/rc.conf ipv6_activate_all_interfaces="YES" grep rtadv /etc/sysctl.conf net.inet6.ip6.accept_rtadv=1 Is there anything else that I need to do ? Johann ___ 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: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
Florian Wilkemeyer wrote: > On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb > wrote: > > On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: > > > >> Hello, > >> > >> i recently switched a router in our test-environment to FreeBSD 9.0-Beta= > 3 > >> (and after things didnt worked ... checked out the current RELENG_9 > >> and recompiled kernel & world .. ) > > > > freebsd-pf archives might be a good start and the better list ... > > > > Okay, thanks i'll post it there.. Did you by chance, run out of state entries? I believe the work-around is to load pf as a module until the issue is fixed. Ian -- Ian Freislich ___ 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] Enable nxstack by default
On Tue, Oct 18, 2011 at 01:06:27PM -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter wrote:
> > On 10/18/11, Arnaud Lacombe wrote:
> >> Hi,
> >>
> >> On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper
> >> wrote:
> >>> On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
> >>>
> Hi,
>
> On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov
> wrote:
> >
> > On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
> >>
> >> Hi all!
> >>
> >> I think, it's the time to enable the nxstack feature. Any comments,
> >> pros, cons?
> >
> > I dragged the change long enough for it to miss the 9.0.
> > After the 9.0 is released, I will flip the switch with the following
> > change.
> >
> > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
> > index 8455f48..926fe64 100644
> > --- a/sys/kern/imgact_elf.c
> > +++ b/sys/kern/imgact_elf.c
> > @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
> > SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
> > &elf_legacy_coredump, 0, "");
> >
> > -static int __elfN(nxstack) = 0;
> > +int __elfN(nxstack) =
> > +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit
> > */
> >
> Why leaving 32bits x86 CPU supporting the NX feature behind ?
> >>>
> >>> Most likely because it was assumed that i386 doesn't fully support it.
> >>> According to ye great Wikipedia, NX support didn't roll into i386 until
> >>> Prescott, which was pretty late in the non-64-bit capable family of CPUs,
> >>> as
> >>> its successor -- Conroe -- was 64-bit. Intel detuned some of the early
> >>> Dual
> >>> Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD.
> >>>
> >>> There are probably more details in binutils, gcc, etc, that I'm missing
> >>> and
> >>> Kostik can expound on.
> >>>
> >> NX support is advertised in the cpuid flags, just add the logic to
> >> handle this interface. Kostik's patch is just incomplete, but he's got
> >> a commit bit so he can commit it as-is, as he will.
> >>
> >> If nonexec_stack becomes the default, it should be on every CPU
> >> supporting the feature, not just the low-hanging one.
> >>
> >> - Arnaud
> >>
> >
> > the NX detection code already implemented in i386, but this feature
> > required PAE:
> >
> yes, this is the conclusion I reached too. But this does not change
> the fact that the VM should know about that, and this is missing from
> Kostik's patch. I guess the first hunk should read:
>
> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
> SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
> &elf_legacy_coredump, 0, "");
>
> -static int __elfN(nxstack) = 0;
> +int __elfN(nxstack) =
> +#if defined(PAE) || defined(__amd64__) || defined(__powerpc64__) /*
> both 64 and 32 bit */
> + 1;
> +#else
> + 0;
> +#endif
> SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
> nxstack, CTLFLAG_RW, &__elfN(nxstack), 0,
> __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable
> stack");
Your patch is not right, it will cause even more user confusion.
The presence of the PAE kernel does not imply that CPU supports nx.
Below is the updated patch that turns on nxstack by default for the PAE
kernels on NX-capable CPUs. Note that i386 usermode fully supports the
PT_GNU_STACK annotations and cares about not enabling nx on stack pages
unneccessary, but my main target was compat32 on amd64.
The fact that nxstack is not enabled by default does not prevent
administrator from manually enabling the feature.
Since you worried so much about PAE case, I sincerely expect that you
will test the change. Thank you in advance.
diff --git a/sys/i386/i386/initcpu.c b/sys/i386/i386/initcpu.c
index c2daf54..ec77adb 100644
--- a/sys/i386/i386/initcpu.c
+++ b/sys/i386/i386/initcpu.c
@@ -650,6 +650,8 @@ enable_sse(void)
#endif
}
+extern int elf32_nxstack;
+
void
initializecpu(void)
{
@@ -739,6 +741,7 @@ initializecpu(void)
msr = rdmsr(MSR_EFER) | EFER_NXE;
wrmsr(MSR_EFER, msr);
pg_nx = PG_NX;
+ elf32_nxstack = 1;
}
#endif
break;
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
&elf_legacy_coredump, 0, "");
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, &__elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable stack");
diff
Re: [RFC] Enable nxstack by default
Hi, On Tue, Oct 18, 2011 at 12:53 PM, Oliver Pinter wrote: > On 10/18/11, Arnaud Lacombe wrote: >> Hi, >> >> On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper wrote: >>> On Tue, 18 Oct 2011, Arnaud Lacombe wrote: >>> Hi, On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov wrote: > > On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: >> >> Hi all! >> >> I think, it's the time to enable the nxstack feature. Any comments, >> pros, cons? > > I dragged the change long enough for it to miss the 9.0. > After the 9.0 is released, I will flip the switch with the following > change. > > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c > index 8455f48..926fe64 100644 > --- a/sys/kern/imgact_elf.c > +++ b/sys/kern/imgact_elf.c > @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; > SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, > &elf_legacy_coredump, 0, ""); > > -static int __elfN(nxstack) = 0; > +int __elfN(nxstack) = > +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit > */ > Why leaving 32bits x86 CPU supporting the NX feature behind ? >>> >>> Most likely because it was assumed that i386 doesn't fully support it. >>> According to ye great Wikipedia, NX support didn't roll into i386 until >>> Prescott, which was pretty late in the non-64-bit capable family of CPUs, >>> as >>> its successor -- Conroe -- was 64-bit. Intel detuned some of the early >>> Dual >>> Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD. >>> >>> There are probably more details in binutils, gcc, etc, that I'm missing >>> and >>> Kostik can expound on. >>> >> NX support is advertised in the cpuid flags, just add the logic to >> handle this interface. Kostik's patch is just incomplete, but he's got >> a commit bit so he can commit it as-is, as he will. >> >> If nonexec_stack becomes the default, it should be on every CPU >> supporting the feature, not just the low-hanging one. >> >> - Arnaud >> > > the NX detection code already implemented in i386, but this feature > required PAE: > yes, this is the conclusion I reached too. But this does not change the fact that the VM should know about that, and this is missing from Kostik's patch. I guess the first hunk should read: @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, &elf_legacy_coredump, 0, ""); -static int __elfN(nxstack) = 0; +int __elfN(nxstack) = +#if defined(PAE) || defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ + 1; +#else + 0; +#endif SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO, nxstack, CTLFLAG_RW, &__elfN(nxstack), 0, __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable stack"); - Arnaud ___ 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] Enable nxstack by default
On 10/18/11, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper wrote:
>> On Tue, 18 Oct 2011, Arnaud Lacombe wrote:
>>
>>> Hi,
>>>
>>> On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov
>>> wrote:
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
>
> Hi all!
>
> I think, it's the time to enable the nxstack feature. Any comments,
> pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
&elf_legacy_coredump, 0, "");
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit
*/
>>> Why leaving 32bits x86 CPU supporting the NX feature behind ?
>>
>> Most likely because it was assumed that i386 doesn't fully support it.
>> According to ye great Wikipedia, NX support didn't roll into i386 until
>> Prescott, which was pretty late in the non-64-bit capable family of CPUs,
>> as
>> its successor -- Conroe -- was 64-bit. Intel detuned some of the early
>> Dual
>> Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD.
>>
>> There are probably more details in binutils, gcc, etc, that I'm missing
>> and
>> Kostik can expound on.
>>
> NX support is advertised in the cpuid flags, just add the logic to
> handle this interface. Kostik's patch is just incomplete, but he's got
> a commit bit so he can commit it as-is, as he will.
>
> If nonexec_stack becomes the default, it should be on every CPU
> supporting the feature, not just the low-hanging one.
>
> - Arnaud
>
the NX detection code already implemented in i386, but this feature
required PAE:
@initializecpu(void):
» » }
#ifdef PAE
» » if ((amd_feature & AMDID_NX) != 0) {
» » » uint64_t msr;
» » » msr = rdmsr(MSR_EFER) | EFER_NXE;
» » » wrmsr(MSR_EFER, msr);
» » » pg_nx = PG_NX;
» » }
#endif
» » break
___
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] Enable nxstack by default
On Oct 18, 2011, at 9:26 AM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper wrote: >> On Tue, 18 Oct 2011, Arnaud Lacombe wrote: >> >>> Hi, >>> >>> On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov >>> wrote: On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: > > Hi all! > > I think, it's the time to enable the nxstack feature. Any comments, > pros, cons? I dragged the change long enough for it to miss the 9.0. After the 9.0 is released, I will flip the switch with the following change. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 8455f48..926fe64 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, &elf_legacy_coredump, 0, ""); -static int __elfN(nxstack) = 0; +int __elfN(nxstack) = +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ >>> Why leaving 32bits x86 CPU supporting the NX feature behind ? >> >> Most likely because it was assumed that i386 doesn't fully support it. >> According to ye great Wikipedia, NX support didn't roll into i386 until >> Prescott, which was pretty late in the non-64-bit capable family of CPUs, as >> its successor -- Conroe -- was 64-bit. Intel detuned some of the early Dual >> Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD. >> >> There are probably more details in binutils, gcc, etc, that I'm missing and >> Kostik can expound on. >> > NX support is advertised in the cpuid flags, just add the logic to > handle this interface. Kostik's patch is just incomplete, but he's got > a commit bit so he can commit it as-is, as he will. > > If nonexec_stack becomes the default, it should be on every CPU > supporting the feature, not just the low-hanging one. It gets a bit trickier because now you're putting MD code into MI code, but that should be easy enough to abstract out into amd64, i386, etc. Still wondering if the toolchain is lacking support though, because I remember a few committers (dim?, kib?) making some modifications in order to get NX working about a year ago. -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: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb wrote: > On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: > >> Hello, >> >> i recently switched a router in our test-environment to FreeBSD 9.0-Beta3 >> (and after things didnt worked ... checked out the current RELENG_9 >> and recompiled kernel & world .. ) > > freebsd-pf archives might be a good start and the better list ... > Okay, thanks i'll post it there.. i missed that there's also a pf-related list, sorry > >> Has anything changed from 8.2 to 9.0 that i missed to consider in >> configuration? > > Yes, the implementation was updated ... > > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. > > ___ 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] Enable nxstack by default
Hi, On Tue, Oct 18, 2011 at 11:44 AM, Garrett Cooper wrote: > On Tue, 18 Oct 2011, Arnaud Lacombe wrote: > >> Hi, >> >> On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov >> wrote: >>> >>> On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: Hi all! I think, it's the time to enable the nxstack feature. Any comments, pros, cons? >>> >>> I dragged the change long enough for it to miss the 9.0. >>> After the 9.0 is released, I will flip the switch with the following >>> change. >>> >>> diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c >>> index 8455f48..926fe64 100644 >>> --- a/sys/kern/imgact_elf.c >>> +++ b/sys/kern/imgact_elf.c >>> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; >>> SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, >>> &elf_legacy_coredump, 0, ""); >>> >>> -static int __elfN(nxstack) = 0; >>> +int __elfN(nxstack) = >>> +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit >>> */ >>> >> Why leaving 32bits x86 CPU supporting the NX feature behind ? > > Most likely because it was assumed that i386 doesn't fully support it. > According to ye great Wikipedia, NX support didn't roll into i386 until > Prescott, which was pretty late in the non-64-bit capable family of CPUs, as > its successor -- Conroe -- was 64-bit. Intel detuned some of the early Dual > Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD. > > There are probably more details in binutils, gcc, etc, that I'm missing and > Kostik can expound on. > NX support is advertised in the cpuid flags, just add the logic to handle this interface. Kostik's patch is just incomplete, but he's got a commit bit so he can commit it as-is, as he will. If nonexec_stack becomes the default, it should be on every CPU supporting the feature, not just the low-hanging one. - Arnaud ___ 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"
PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
Hello,
i recently switched a router in our test-environment to FreeBSD 9.0-Beta3
(and after things didnt worked ... checked out the current RELENG_9
and recompiled kernel & world .. )
Problem:
After 5 - 15 minutes NAT stops working (normal routing still works.)
Network Utilization: about 40 MByte/second, which gets routed
only a few kbit/s are getting natted (NTP Syncs and such ... )
When i took a look on the nat rules (via pfctl -vv -s nat)
the rules gets evaluated; but nothing matches anymore...
State Table helds about 9500 Entrys,
Source Tracking Table about 300
Software / Configuration:
pf, carp
pf.conf:
set limit src-nodes 55
set limit frags 32000
set timeout { adaptive.start 53 adaptive.end 54 }
set timeout src.track 600
set timeout frag 30
set skip on lo0
set skip on igb2
set skip on igb3
set skip on bce0
set skip on bce1
set skip on pfsync0
#set skip on internal
#set skip on carp3internal
nat on public from 10.5.0.0/16 to any -> { public }
carp device holding the internal gateway ips (10.5.0.253 .. ),
currently master - no slave
/etc/sysctl.conf:
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.ip.forwarding=1
net.inet.ip.fastforwarding=1
net.inet.icmp.icmplim_output=0
net.inet.icmp.icmplim=0
net.route.netisr_maxqlen=8192
kern.random.sys.harvest.interrupt=0
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.point_to_point=0
net.inet.carp.preempt=1
/boot/loader.conf:
net.isr.maxthreads="2"
net.isr.defaultqlimit="4096"
net.isr.maxqlimit="81920"
net.isr.direct="1"
net.isr.bindthreads="1"
hw.igb.num_queues=2
hw.igb.enable_aim=1
hw.igb.txd=2048
hw.igb.rxd=2048
hw.igb.max_interrupt_rate=8000
hw.intr_storm_threshold=1
kern.ipc.nmbclusters="262144"
kern.hz=1000
# sysctl -a hw.igb
hw.igb.rx_process_limit: 100
hw.igb.num_queues: 2
hw.igb.header_split: 0
hw.igb.max_interrupt_rate: 8000
hw.igb.enable_msix: 1
hw.igb.enable_aim: 1
hw.igb.txd: 2048
hw.igb.rxd: 2048
# sysctl -a dev.igb
dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.5
dev.igb.0.%driver: igb
dev.igb.0.%location: slot=0 function=0
dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10e8 subvendor=0x8086
subdevice=0xa02c class=0x02
dev.igb.0.%parent: pci5
dev.igb.0.nvm: -1
dev.igb.0.enable_aim: 1
dev.igb.0.fc: 65536003
dev.igb.0.rx_processing_limit: 100
dev.igb.0.link_irq: 2
dev.igb.0.dropped: 0
dev.igb.0.tx_dma_fail: 0
dev.igb.0.rx_overruns: 0
dev.igb.0.watchdog_timeouts: 0
dev.igb.0.device_control: 1086325313
dev.igb.0.rx_control: 67141634
dev.igb.0.interrupt_mask: 4
dev.igb.0.extended_int_mask: 2147483655
dev.igb.0.tx_buf_alloc: 0
dev.igb.0.rx_buf_alloc: 0
dev.igb.0.fc_high_water: 58976
dev.igb.0.fc_low_water: 58960
dev.igb.0.queue0.no_desc_avail: 0
dev.igb.0.queue0.tx_packets: 28167655
dev.igb.0.queue0.rx_packets: 942710
dev.igb.0.queue0.rx_bytes: 84905673
dev.igb.0.queue0.lro_queued: 0
dev.igb.0.queue0.lro_flushed: 0
dev.igb.0.queue1.no_desc_avail: 0
dev.igb.0.queue1.tx_packets: 27659961
dev.igb.0.queue1.rx_packets: 219218
dev.igb.0.queue1.rx_bytes: 34229378
dev.igb.0.queue1.lro_queued: 0
dev.igb.0.queue1.lro_flushed: 0
dev.igb.0.mac_stats.excess_coll: 0
dev.igb.0.mac_stats.single_coll: 0
dev.igb.0.mac_stats.multiple_coll: 0
dev.igb.0.mac_stats.late_coll: 0
dev.igb.0.mac_stats.collision_count: 0
dev.igb.0.mac_stats.symbol_errors: 0
dev.igb.0.mac_stats.sequence_errors: 0
dev.igb.0.mac_stats.defer_count: 0
dev.igb.0.mac_stats.missed_packets: 0
dev.igb.0.mac_stats.recv_no_buff: 0
dev.igb.0.mac_stats.recv_undersize: 0
dev.igb.0.mac_stats.recv_fragmented: 0
dev.igb.0.mac_stats.recv_oversize: 0
dev.igb.0.mac_stats.recv_jabber: 0
dev.igb.0.mac_stats.recv_errs: 0
dev.igb.0.mac_stats.crc_errs: 0
dev.igb.0.mac_stats.alignment_errs: 0
dev.igb.0.mac_stats.coll_ext_errs: 0
dev.igb.0.mac_stats.xon_recvd: 0
dev.igb.0.mac_stats.xon_txd: 0
dev.igb.0.mac_stats.xoff_recvd: 0
dev.igb.0.mac_stats.xoff_txd: 0
dev.igb.0.mac_stats.total_pkts_recvd: 1277070
dev.igb.0.mac_stats.good_pkts_recvd: 1161923
dev.igb.0.mac_stats.bcast_pkts_recvd: 101354
dev.igb.0.mac_stats.mcast_pkts_recvd: 714
dev.igb.0.mac_stats.rx_frames_64: 102154
dev.igb.0.mac_stats.rx_frames_65_127: 1015473
dev.igb.0.mac_stats.rx_frames_128_255: 6736
dev.igb.0.mac_stats.rx_frames_256_511: 10919
dev.igb.0.mac_stats.rx_frames_512_1023: 1719
dev.igb.0.mac_stats.rx_frames_1024_1522: 24922
dev.igb.0.mac_stats.good_octets_recvd: 123782443
dev.igb.0.mac_stats.good_octets_txd: 55500343847
dev.igb.0.mac_stats.total_pkts_txd: 55828073
dev.igb.0.mac_stats.good_pkts_txd: 55828073
dev.igb.0.mac_stats.bcast_pkts_txd: 5
dev.igb.0.mac_stats.mcast_pkts_txd: 1
dev.igb.0.mac_stats.tx_frames_64: 10267735
dev.igb.0.mac_stats
Re: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: > Hello, > > i recently switched a router in our test-environment to FreeBSD 9.0-Beta3 > (and after things didnt worked ... checked out the current RELENG_9 > and recompiled kernel & world .. ) freebsd-pf archives might be a good start and the better list ... > Has anything changed from 8.2 to 9.0 that i missed to consider in > configuration? Yes, the implementation was updated ... -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: possible mountroot regression
on 14/10/2011 18:54 Arnaud Lacombe said the following:
> Andry Gapon wrote:
>> Simple: revert to the previous behavior. If a user enters incorrect device
>> name
>> (i.e. root mounting fails), then return back to the prompt instead of
>> panicing.
> That should do the job.
>
> - Arnaud
>
> ---
> sys/kern/vfs_mountroot.c | 45 +++--
> 1 files changed, 23 insertions(+), 22 deletions(-)
>
> diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
> index ccbcb33..ae3ffa7 100644
> --- a/sys/kern/vfs_mountroot.c
> +++ b/sys/kern/vfs_mountroot.c
> @@ -481,28 +481,29 @@ parse_dir_ask(char **conf)
> printf("\n");
> printf(" ? List valid disk boot devices\n");
> printf(" . Yield 1 second (for background tasks)\n");
> - printf(" Abort manual input\n");
> + printf(" x Abort manual input)\n");
> +
> + do {
> + error = EINVAL;
> + printf("\nmountroot> ");
> + gets(name, sizeof(name), GETS_ECHO);
> + if (name[0] == '?') {
> + printf("\nList of GEOM managed disk devices:\n ");
> + g_dev_print();
> + continue;
> + }
> + if (name[0] == '.') {
> + pause("rmask", hz);
> + continue;
> + }
> + if (name[0] == 'x' && name[1] == '\0')
> + break;
> + mnt = name;
> + error = parse_mount(&mnt);
> + if (error < 0)
> + printf("Invalid specification.\n");
> + } while (error != 0);
>
> - again:
> - printf("\nmountroot> ");
> - gets(name, sizeof(name), GETS_ECHO);
> - if (name[0] == '\0')
> - return (0);
> - if (name[0] == '?') {
> - printf("\nList of GEOM managed disk devices:\n ");
> - g_dev_print();
> - goto again;
> - }
> - if (name[0] == '.') {
> - pause("rmask", hz);
> - goto again;
> - }
> - mnt = name;
> - error = parse_mount(&mnt);
> - if (error == -1) {
> - printf("Invalid specification.\n");
> - goto again;
> - }
> return (error);
> }
>
Arnaud,
I like how your change fixes the regression and improves code style.
As you've said, the 'x' change is unrelated. I like it, but it needs to be
discussed and committed separately.
Marcel,
what do you think?
Would you be able to commit a variant of this patch sans the 'x' part?
--
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: [RFC] Enable nxstack by default
On Tue, 18 Oct 2011, Arnaud Lacombe wrote: Hi, On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov wrote: On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote: Hi all! I think, it's the time to enable the nxstack feature. Any comments, pros, cons? I dragged the change long enough for it to miss the 9.0. After the 9.0 is released, I will flip the switch with the following change. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 8455f48..926fe64 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0; SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, &elf_legacy_coredump, 0, ""); -static int __elfN(nxstack) = 0; +int __elfN(nxstack) = +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ Why leaving 32bits x86 CPU supporting the NX feature behind ? Most likely because it was assumed that i386 doesn't fully support it. According to ye great Wikipedia, NX support didn't roll into i386 until Prescott, which was pretty late in the non-64-bit capable family of CPUs, as its successor -- Conroe -- was 64-bit. Intel detuned some of the early Dual Core Pentiums, e.g. the Yonahs to not talk 64-bit. Not sure about AMD. There are probably more details in binutils, gcc, etc, that I'm missing and Kostik can expound on. -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: Panics after AHCI timeouts
Hi.
Alexey Shuvaev wrote:
> On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote:
> Errr... Replying to myself... Ping? Should I file a PR and put it
> in the back burner? :)
Sorry for not replying, I wasn't home to look on it closely.
>> In the view of upcoming RELEASE-9.0 I should have reported it earlier,
>> but it is better later than never... Every time I wanted to report
>> this, the system was ~one month old and I tried to upgrade it
>> to see, if the problem was still there, waiting for the next panic...
>> and when it finally paniced it was one month old again.
>>
> [snip]
>> >From core.txt.5:
>> [snip]
>> Unread portion of the kernel message buffer:
>> Memory modified after free 0xfe000416e200(248) val=79e8800 @
>> 0xfe000416e200
>> panic: Most recently used by cred
>>
>> cpuid = 2
>> Uptime: 20h11m1s
>> Dumping 1308 out of 7914 MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91%
>> [snip]
>> #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
>> 252 if (textdump && textdump_pending) {
>> (kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
>> #1 0x808234aa in kern_reboot (howto=260)
>> at /usr/src/sys/kern/kern_shutdown.c:430
>> #2 0x80822f41 in panic (fmt=Variable "fmt" is not available.
>> )
>> at /usr/src/sys/kern/kern_shutdown.c:595
>> #3 0x80a6f7b4 in mtrash_ctor (mem=Variable "mem" is not available.
>> ) at /usr/src/sys/vm/uma_dbg.c:137
>> #4 0x80a6f01c in uma_zalloc_arg (zone=0xfe021ffe0700,
>> udata=0x0,
>> flags=258) at /usr/src/sys/vm/uma_core.c:2018
>> #5 0x808108be in malloc (size=Variable "size" is not available.
>> ) at uma.h:305
>> #6 0x8081c21f in crget () at /usr/src/sys/kern/kern_prot.c:1809
>> #7 0x8081c269 in crdup (cr=0xfe0143103300)
>> at /usr/src/sys/kern/kern_prot.c:1911
>> #8 0x808c5ca6 in kern_accessat (td=0xfe0007dd7000, fd=-100,
>> path=0x80065c000 ,
>> pathseg=UIO_USERSPACE, flags=Variable "flags" is not available.
>> ) at /usr/src/sys/kern/vfs_syscalls.c:2201
>> #9 0x8086719a in syscallenter (td=0xfe0007dd7000,
>> sa=0xff8223f67bb0) at /usr/src/sys/kern/subr_trap.c:344
>> #10 0x80b0b43c in syscall (frame=0xff8223f67c50)
>> at /usr/src/sys/amd64/amd64/trap.c:910
>> #11 0x80af617d in Xfast_syscall ()
>> at /usr/src/sys/amd64/amd64/exception.S:384
>> #12 0x00080062dbdc in ?? ()
>> Previous frame inner to this frame (corrupt stack?)
>> [snip]
>> [last message in dmesg]
>> ahcich0: Timeout on slot 29 port 0
>> ahcich0: is cs ss rs tfd 40 serr
>> cm
>> d fc17
>> [snip]
Now looking on two you backtraces I don't see anything common between
them. While first crash happened within timer event handler, it was not
AHCI-related event. Second crash happened inside some unrelated syscall.
I may suppose that some memory corruption could cause both, but I have
no idea what it is and how can it be related to AHCI. With the same
effect I could tell that some other hardware problem causes both
problems. Try to collect more statistics.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdtar --gname switch
On Oct 17, 2011, at 3:25 PM, Benjamin Kaduk wrote: > On Mon, 17 Oct 2011, Romain Garbage wrote: >> >> According to bsdtar(1) manpage, tar has a --gname switch that permits >> to set an arbitrary groupname in the tar archive, but: >> $ tar -cf foo.tar --gname root bar >> tar: Option --gname is not supported >> >> I get the same error for --uname and --gid switches. I'm running >> 9.0-BETA3 (r226421). Does this have any chances to be corrected in a >> not to far away future? > > This is, at present, a documentation bug. > FreeBSD svn revision 207786 was "Various manpage updates, including many > long-option synonyms that were previously undocumented", which added the > gname long-format option to bsdtar.1. However, this option is not present in > usr.bin/tar/cmdline.c in FreeBSD head, though it was added in r2349 of > upstream libarchive sources on May 1, 2010. So, it looks like it should have > been in libarchive since 2.8.4; however, pulling tarballs for 2.8.4 and 2.8.5 > it does not seem that gname is listed in cmdline.c for either of them. > > I'm not familiar with the libarchive release process; Tim, can you shed some > insight on what happened here? Looks like the manpage got updated to the latest version from libarchive/trunk. Unfortunately, some of the features described there are not present in libarchive 2.8. It looks like it might be easy to back port some of these features. They don't seem to rely on any of the deeper changes to libarchive internals that have happened since 2.8. Tim ___ 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] Enable nxstack by default
Hi,
On Tue, Oct 18, 2011 at 5:07 AM, Kostik Belousov wrote:
> On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
>> Hi all!
>>
>> I think, it's the time to enable the nxstack feature. Any comments,
>> pros, cons?
>
> I dragged the change long enough for it to miss the 9.0.
> After the 9.0 is released, I will flip the switch with the following
> change.
>
> diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
> index 8455f48..926fe64 100644
> --- a/sys/kern/imgact_elf.c
> +++ b/sys/kern/imgact_elf.c
> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
> SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
> &elf_legacy_coredump, 0, "");
>
> -static int __elfN(nxstack) = 0;
> +int __elfN(nxstack) =
> +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
>
Why leaving 32bits x86 CPU supporting the NX feature behind ?
- Arnaud
> + 1;
> +#else
> + 0;
> +#endif
> SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
> nxstack, CTLFLAG_RW, &__elfN(nxstack), 0,
> __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable
> stack");
> diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
> index 7500462..0e27351 100644
> --- a/sys/powerpc/aim/mmu_oea64.c
> +++ b/sys/powerpc/aim/mmu_oea64.c
> @@ -1445,6 +1445,8 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes,
> u_int8_t *flags, int wait)
> return (void *)va;
> }
>
> +extern int elf32_nxstack;
> +
> void
> moea64_init(mmu_t mmu)
> {
> @@ -1464,6 +1466,8 @@ moea64_init(mmu_t mmu)
> uma_zone_set_allocf(moea64_mpvo_zone,moea64_uma_page_alloc);
> }
>
> + elf32_nxstack = 1;
> +
> moea64_initialized = TRUE;
> }
>
> diff --git a/sys/powerpc/booke/machdep.c b/sys/powerpc/booke/machdep.c
> index c2b5e6f..82a37e1 100644
> --- a/sys/powerpc/booke/machdep.c
> +++ b/sys/powerpc/booke/machdep.c
> @@ -192,6 +192,8 @@ void print_kernel_section_addr(void);
> void print_kenv(void);
> u_int booke_init(uint32_t, uint32_t);
>
> +extern int elf32_nxstack;
> +
> static void
> cpu_e500_startup(void *dummy)
> {
> @@ -227,6 +229,9 @@ cpu_e500_startup(void *dummy)
> /* Set up buffers, so they can be used to read disk labels. */
> bufinit();
> vm_pager_bufferinit();
> +
> + /* Cpu supports execution permissions on the pages. */
> + elf32_nxstack = 1;
> }
>
> static char *
>
>
___
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: zfsloader 9.0 BETA3 r225759 - i/o error - all block copies unavailable
on 18/10/2011 13:35 Henri Hennebert said the following: > I upgrade another system to 9.0-RC1 and encounter the same problem, this time > zfsloader do not run. > > After > > mv /mnt/boot /mnt/Boot > mkdir /mnt/boot > cd /mnt/Boot > find . | cpio -pvdmu /mnt/boot > > FreeBSD boot OK > > > [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 > /dev/ada1p2 > ZFS: SPA version 28 > pool: rpool > config: > > NAME STATE > rpool ONLINE > mirror ONLINE > ada0p2 ONLINE > ada1p2 ONLINE > ZFS: i/o error - all block copies unavailable > can't lookup > > 10 minutes later: > > [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 > /dev/ada1p2|less > ZFS: SPA version 28 > pool: rpool > config: > > NAME STATE > rpool ONLINE > mirror ONLINE > ada0p2 ONLINE > ada1p2 ONLINE > > > it seems ok :-o > > and a other time: > [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 > segmentation fault... > > Strange isn't it. I think that it would be smart to not do any filesystem modifications after the problem is detected / reproduced. Also, currently zfsboottest doesn't do much of a problem self-diagnostics, so using gdb or/and adding some printfs in the code are required to understand a nature of a problem. Like what kind of block gives an I/O error, if it actual reading that fails or checksum verification or etc, and so on. -- 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: Panics after AHCI timeouts
- Original Message - From: "Alexey Shuvaev" To: Sent: Tuesday, October 18, 2011 2:13 PM Subject: Re: Panics after AHCI timeouts On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: On 18 October 2011 03:00, Alexey Shuvaev wrote: > On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote: >> Hello list! >> > Errr... Replying to myself... Ping? Should I file a PR and put it > in the back burner? :) I think filing a PR is a good move. Then just be proactive and poke people about it. It'd be good to get this fixed. :) Done, kern/161768. Question to the list: does anybody see successful recovery from AHCI timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 branch counts also. That is, there are some kernel messages like this: ahcich0: Timeout on slot 29 port 0 ahcich0: is cs ss rs tfd 40 serr cmd fc17 but then AHCI recovers and the system does not panic? Not a recent CURRENT but on 8.2-RELEASE we have seen recovery on secondary ssd drives without a panic, but it does generally drop the disk and need a power off, power on to recover the disk properly; although we believe that's a firmware bug on the ssds Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Panics after AHCI timeouts
On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: > On 18 October 2011 03:00, Alexey Shuvaev > wrote: > > On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote: > >> Hello list! > >> > > Errr... Replying to myself... Ping? Should I file a PR and put it > > in the back burner? :) > > I think filing a PR is a good move. Then just be proactive and poke > people about it. It'd be good to get this fixed. :) > Done, kern/161768. Question to the list: does anybody see successful recovery from AHCI timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 branch counts also. That is, there are some kernel messages like this: ahcich0: Timeout on slot 29 port 0 ahcich0: is cs ss rs tfd 40 serr cmd fc17 but then AHCI recovers and the system does not panic? Poking Alexey. ___ 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: small devfs.conf patch
on 17/10/2011 23:01 Alexander Best said the following: > hi there, > > any thoughts regarding this change? with the ata subsystem dying, linking to > /dev/acd isn't really necessary any more. also a lot of ports nowadays depend > on /dev/dvd. IMO, go for it. -- 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"
mtx_lock() of destroyed mutex on NFS
Hi, as a result of a make buildkernel && make installkernel && reboot all on NFS I got this with a HEAD SVN source at r226465. I cannot dump unfortunately and it seems I just killed the obj tree for this kernel though it should be very close. Oct 18 10:03:22 lion3 reboot: rebooted by test Oct 18 10:03:22 panic: mtx_lock() of destroyed mutex @ /zoo/bz/HEAD.svn/sys/kern/uipc_socket.c:1022 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 _mtx_lock_flags() at _mtx_lock_flags+0x130 sosend_dgram() at sosend_dgram+0xbb sosend() at sosend+0x82 clnt_dg_call() at clnt_dg_call+0xb81 clnt_call_private() at clnt_call_private+0xe8 nlm_get_rpc() at nlm_get_rpc+0x187 nlm_host_get_rpc() at nlm_host_get_rpc+0x130 nlm_clearlock() at nlm_clearlock+0x10a nlm_advlock_internal() at nlm_advlock_internal+0x64f nlm_advlock() at nlm_advlock+0x2a nfs_advlock() at nfs_advlock+0x122 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 vn_closefile() at vn_closefile+0xe8 _fdrop() at _fdrop+0x23 closef() at closef+0x5c fdfree() at fdfree+0x1b4 exit1() at exit1+0x31a sigexit() at sigexit+0x8f cursig() at cursig ast() at ast+0x1a9 doreti_ast() at doreti_ast+0x1f KDB: enter: panic [ thread pid 1652 tid 100106 ] Stopped at kdb_enter+0x3b: movq$0,0x80feb2(%rip) db> show reg cs0x20 ds0x3b es0x3b003b fs0x1b0013 gs0x1b ss0x28 rax 0x12 rcx 0xfe001a001000 rdx 0 rbx 0x80a2bfa8 __func__.3464+0x111 rsp 0xff85cc173780 rbp 0xff85cc1737a0 rsi 0x80 rdi 0xff85cc173600 r8 0x80a2a498 __func__.6043+0x328 r9 0xff85cc1736b0 r10 0xfe001a001000 r110x1 r120x1 r13 0xfe001a001000 r14 0x3fe r15 0x80a39948 __func__.7715+0x2d3 rip 0x80646c2b kdb_enter+0x3b rflags 0x282 kdb_enter+0x3b: movq$0,0x80feb2(%rip) -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: zfsloader 9.0 BETA3 r225759 - i/o error - all block copies unavailable
On 10/06/2011 15:36, Andriy Gapon wrote: on 06/10/2011 15:30 Henri Hennebert said the following: The pool is a mirror: [root@morzine ~]# zpool status rpool pool: rpool state: ONLINE scan: scrub repaired 0 in 1h0m with 0 errors on Wed Aug 24 15:04:36 2011 config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gptid/e915c6a0-fc72-11de-aa21-00e081706b68 ONLINE 0 0 0 gptid/eac8497d-fc72-11de-aa21-00e081706b68 ONLINE 0 0 0 errors: No known data errors and rpool/root is not compressed: [root@morzine ~]# zfs get compression rpool/root NAMEPROPERTY VALUE SOURCE rpool/root compression off inherited from rpool pool is v28 and filesystems are v5 No particular recipes for this environment, just a general suggestion. If you run into a situation like this again, please try to use tools/tools/zfsboottest to diagnose where exactly an error originates. I upgrade another system to 9.0-RC1 and encounter the same problem, this time zfsloader do not run. After mv /mnt/boot /mnt/Boot mkdir /mnt/boot cd /mnt/Boot find . | cpio -pvdmu /mnt/boot FreeBSD boot OK [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 /dev/ada1p2 ZFS: SPA version 28 pool: rpool config: NAME STATE rpool ONLINE mirror ONLINE ada0p2 ONLINE ada1p2 ONLINE ZFS: i/o error - all block copies unavailable can't lookup 10 minutes later: [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 /dev/ada1p2|less ZFS: SPA version 28 pool: rpool config: NAME STATE rpool ONLINE mirror ONLINE ada0p2 ONLINE ada1p2 ONLINE it seems ok :-o and a other time: [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 segmentation fault... Strange isn't it. Henri ___ 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] Enable nxstack by default
Looks good to me.
On 10/18/11, Kostik Belousov wrote:
> On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
>> Hi all!
>>
>> I think, it's the time to enable the nxstack feature. Any comments,
>> pros, cons?
>
> I dragged the change long enough for it to miss the 9.0.
> After the 9.0 is released, I will flip the switch with the following
> change.
>
> diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
> index 8455f48..926fe64 100644
> --- a/sys/kern/imgact_elf.c
> +++ b/sys/kern/imgact_elf.c
> @@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
> SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
> &elf_legacy_coredump, 0, "");
>
> -static int __elfN(nxstack) = 0;
> +int __elfN(nxstack) =
> +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
> + 1;
> +#else
> + 0;
> +#endif
> SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
> nxstack, CTLFLAG_RW, &__elfN(nxstack), 0,
> __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable
> stack");
> diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
> index 7500462..0e27351 100644
> --- a/sys/powerpc/aim/mmu_oea64.c
> +++ b/sys/powerpc/aim/mmu_oea64.c
> @@ -1445,6 +1445,8 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes,
> u_int8_t *flags, int wait)
> return (void *)va;
> }
>
> +extern int elf32_nxstack;
> +
> void
> moea64_init(mmu_t mmu)
> {
> @@ -1464,6 +1466,8 @@ moea64_init(mmu_t mmu)
> uma_zone_set_allocf(moea64_mpvo_zone,moea64_uma_page_alloc);
> }
>
> + elf32_nxstack = 1;
> +
> moea64_initialized = TRUE;
> }
>
> diff --git a/sys/powerpc/booke/machdep.c b/sys/powerpc/booke/machdep.c
> index c2b5e6f..82a37e1 100644
> --- a/sys/powerpc/booke/machdep.c
> +++ b/sys/powerpc/booke/machdep.c
> @@ -192,6 +192,8 @@ void print_kernel_section_addr(void);
> void print_kenv(void);
> u_int booke_init(uint32_t, uint32_t);
>
> +extern int elf32_nxstack;
> +
> static void
> cpu_e500_startup(void *dummy)
> {
> @@ -227,6 +229,9 @@ cpu_e500_startup(void *dummy)
> /* Set up buffers, so they can be used to read disk labels. */
> bufinit();
> vm_pager_bufferinit();
> +
> + /* Cpu supports execution permissions on the pages. */
> + elf32_nxstack = 1;
> }
>
> static char *
>
>
___
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: SPI rework
On Tue, 18 Oct 2011 06:17:46 +0800 Adrian Chadd wrote: >> Hi, >> >> That sounds logical to me. Maybe getting it done before 9.0-RELEASE >> is a bit rushed? >> >> I can help you test out the flash side of things on my atheros SoC >> boards. >> >> >> Adrian More thinking give me a better way to fix that. We leave same structure, but remove KASSERT(cmd->tx_cmd_sz == cmd->rx_cmd_sz,""); and fix SPI controllers drivers to care about possible different sizes. And of course will fix consumers to set exact what they need. (dev/flash: cmd_tx_sz=1, data_rx_sz=3 for "device ID" call) That way better because we will have ability to duplex SPI transfers on controllers that able to do that, RT305x SPI will return error in case when sizes specified for both directions. Comments? WBW -- Alexandr Rybalko aka Alex RAY ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-9.0 smartmontools and ada devices
On Tue, Oct 18, 2011 at 11:02:42AM +0200, John Hay wrote: > On Tue, Oct 18, 2011 at 09:39:24AM +0200, John Hay wrote: > > Hi Guys, > > > > I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using > > a GENERIC kernel. I have installed the smartmontools-5.41_3 package from > > a mirror and found that smartmontools does not like the ada devices anymore. > > Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. > > There an older smartmontools (5.40) worked without a problem on the ada > > devices. > > > > The output of smartctl looks like this: > > > > # > > dolphin# smartctl -a /dev/ada0 > > smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) > > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > > > error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device > > Unable to get CAM device list > > /dev/ada0: Unable to detect device type > > Smartctl: please specify device type with the -d option. > > > > Use smartctl -h to get a usage summary > > > > # > > Just to follow up on myself. :-( I have build smartmontools from ports and > even though it is the same version, it works. So for me the package > amd64/packages-9-current/All/smartmontools-5.41_3.tbz did not work, but the > port does. CAM ABI was changed right before RC1. The issue was mentioned in the Ken' announcement. The packages were obviously built with the old headers. pgpCP3eHnNxYY.pgp Description: PGP signature
Re: freebsd-9.0 smartmontools and ada devices
Op di 18 okt 2011 09:39:24 schreef John Hay: > Hi Guys, > > I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using > a GENERIC kernel. I have installed the smartmontools-5.41_3 package from > a mirror and found that smartmontools does not like the ada devices anymore. > Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. > There an older smartmontools (5.40) worked without a problem on the ada > devices. > > The output of smartctl looks like this: > > # > dolphin# smartctl -a /dev/ada0 > smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device > Unable to get CAM device list > /dev/ada0: Unable to detect device type > Smartctl: please specify device type with the -d option. > > Use smartctl -h to get a usage summary > > # > > Has anybody seen it? > Yes, but rebuilding smartmontools fixed it for me. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Enable nxstack by default
On Mon, Oct 17, 2011 at 09:30:56PM +0200, Oliver Pinter wrote:
> Hi all!
>
> I think, it's the time to enable the nxstack feature. Any comments,
> pros, cons?
I dragged the change long enough for it to miss the 9.0.
After the 9.0 is released, I will flip the switch with the following
change.
diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c
index 8455f48..926fe64 100644
--- a/sys/kern/imgact_elf.c
+++ b/sys/kern/imgact_elf.c
@@ -118,7 +118,12 @@ static int elf_legacy_coredump = 0;
SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW,
&elf_legacy_coredump, 0, "");
-static int __elfN(nxstack) = 0;
+int __elfN(nxstack) =
+#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */
+ 1;
+#else
+ 0;
+#endif
SYSCTL_INT(__CONCAT(_kern_elf, __ELF_WORD_SIZE), OID_AUTO,
nxstack, CTLFLAG_RW, &__elfN(nxstack), 0,
__XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) ": enable non-executable stack");
diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
index 7500462..0e27351 100644
--- a/sys/powerpc/aim/mmu_oea64.c
+++ b/sys/powerpc/aim/mmu_oea64.c
@@ -1445,6 +1445,8 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes,
u_int8_t *flags, int wait)
return (void *)va;
}
+extern int elf32_nxstack;
+
void
moea64_init(mmu_t mmu)
{
@@ -1464,6 +1466,8 @@ moea64_init(mmu_t mmu)
uma_zone_set_allocf(moea64_mpvo_zone,moea64_uma_page_alloc);
}
+ elf32_nxstack = 1;
+
moea64_initialized = TRUE;
}
diff --git a/sys/powerpc/booke/machdep.c b/sys/powerpc/booke/machdep.c
index c2b5e6f..82a37e1 100644
--- a/sys/powerpc/booke/machdep.c
+++ b/sys/powerpc/booke/machdep.c
@@ -192,6 +192,8 @@ void print_kernel_section_addr(void);
void print_kenv(void);
u_int booke_init(uint32_t, uint32_t);
+extern int elf32_nxstack;
+
static void
cpu_e500_startup(void *dummy)
{
@@ -227,6 +229,9 @@ cpu_e500_startup(void *dummy)
/* Set up buffers, so they can be used to read disk labels. */
bufinit();
vm_pager_bufferinit();
+
+ /* Cpu supports execution permissions on the pages. */
+ elf32_nxstack = 1;
}
static char *
pgpYBjVPeBl7n.pgp
Description: PGP signature
Re: freebsd-9.0 smartmontools and ada devices
On Tue, Oct 18, 2011 at 09:39:24AM +0200, John Hay wrote: > Hi Guys, > > I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using > a GENERIC kernel. I have installed the smartmontools-5.41_3 package from > a mirror and found that smartmontools does not like the ada devices anymore. > Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. > There an older smartmontools (5.40) worked without a problem on the ada > devices. > > The output of smartctl looks like this: > > # > dolphin# smartctl -a /dev/ada0 > smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device > Unable to get CAM device list > /dev/ada0: Unable to detect device type > Smartctl: please specify device type with the -d option. > > Use smartctl -h to get a usage summary > > # Just to follow up on myself. :-( I have build smartmontools from ports and even though it is the same version, it works. So for me the package amd64/packages-9-current/All/smartmontools-5.41_3.tbz did not work, but the port does. John ___ 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: r225932 libsasl undefined references - buildworld failure
On Tue, Oct 18, 2011 at 01:29:38AM +0900, Hajimu UMEMOTO wrote: > Hi, > > > On Mon, 17 Oct 2011 16:54:36 +0100 > > Anton Shterenlikht said: > > mexas> On r225932 with > > mexas> SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 > mexas> SENDMAIL_LDFLAGS+= -L/usr/local/lib > mexas> SENDMAIL_LDADD+=-lsasl2 > > mexas> in /etc/make.conf and with cyrus-sasl-2.1.25_1 installed, > mexas> I get these errors on make buildworld: > > mexas> cc -O2 -pipe -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src > -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS > -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 > -I/usr/local/include -DSASL=2 -std=gnu99 -Wsystem-headers -Werror > -Wno-pointer-sign -L/usr/local/lib -o sendmail alias.o arpadate.o bf.o > collect.o conf.o control.o convtime.o daemon.o deliver.o domain.o envelope.o > err.o headers.o macro.o main.o map.o mci.o milter.o mime.o parseaddr.o > queue.o ratectrl.o readcf.o recipient.o savemail.o sasl.o sfsasl.o > shmticklib.o sm_resolve.o srvrsmtp.o stab.o stats.o sysexits.o timers.o tls.o > trace.o udb.o usersmtp.o util.o version.o -lutil -lwrap > /usr/obj/usr/src/usr.sbin/sendmail/../../lib/libsmutil/libsmutil.a > /usr/obj/usr/src/usr.sbin/sendmail/../../lib/libsm/libsm.a -lssl -lcrypto > -lsasl2 > mexas> /usr/local/lib/libsasl2.a(otp.o): In function > `opie_server_mech_dispose': > mexas> otp.c:(.text+0x2e52): undefined reference to `opieverify' > mexas> /usr/local/lib/libsasl2.a(otp.o): In function `opie_server_mech_step': > mexas> otp.c:(.text+0x3052): undefined reference to `opieverify' > mexas> otp.c:(.text+0x3542): undefined reference to `opiechallenge' > mexas> /usr/local/lib/libsasl2.a(gssapi.o): In function > `sasl_gss_free_context_contents': > mexas> gssapi.c:(.text+0x172): undefined reference to `gss_delete_sec_context' > mexas> gssapi.c:(.text+0x1b2): undefined reference to `gss_release_name' > mexas> gssapi.c:(.text+0x1f2): undefined reference to `gss_release_name' > mexas> gssapi.c:(.text+0x232): undefined reference to `gss_release_cred' > mexas> gssapi.c:(.text+0x272): undefined reference to `gss_release_cred' > mexas> /usr/local/lib/libsasl2.a(gssapi.o): In function `sasl_gss_seterror_': > mexas> gssapi.c:(.text+0x7a2): undefined reference to `gss_display_status' > mexas> gssapi.c:(.text+0x842): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x932): undefined reference to `gss_display_status' > mexas> gssapi.c:(.text+0x9d2): undefined reference to `gss_release_buffer' > mexas> /usr/local/lib/libsasl2.a(gssapi.o): In function > `gssapi_client_mech_step': > mexas> gssapi.c:(.text+0xfa2): undefined reference to `gss_delete_sec_context' > mexas> gssapi.c:(.text+0x10a2): undefined reference to `gss_init_sec_context' > mexas> gssapi.c:(.text+0x12a2): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x1322): undefined reference to `gss_inquire_context' > mexas> gssapi.c:(.text+0x1372): undefined reference to `gss_display_name' > mexas> gssapi.c:(.text+0x1452): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x14f2): undefined reference to `gss_unwrap' > mexas> gssapi.c:(.text+0x15c2): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x1942): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x1b32): undefined reference to `gss_wrap' > mexas> gssapi.c:(.text+0x1c72): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x1d52): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x2022): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x2152): undefined reference to > `GSS_C_NT_HOSTBASED_SERVICE' > mexas> gssapi.c:(.text+0x2160): undefined reference to > `GSS_C_NT_HOSTBASED_SERVICE' > mexas> gssapi.c:(.text+0x2172): undefined reference to `gss_import_name' > mexas> gssapi.c:(.text+0x22b2): undefined reference to `gss_wrap_size_limit' > mexas> gssapi.c:(.text+0x24d2): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x2582): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x2612): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x26d2): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x2a52): undefined reference to `gss_release_buffer' > mexas> /usr/local/lib/libsasl2.a(gssapi.o): In function > `gssapi_decode_packet': > mexas> gssapi.c:(.text+0x2be2): undefined reference to `gss_unwrap' > mexas> gssapi.c:(.text+0x2cd2): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x2d62): undefined reference to `gss_release_buffer' > mexas> gssapi.c:(.text+0x2e72): undefined reference to `gss_release_buffer' > mexas> /usr/local/lib/libsasl2.a(gssapi.o): In function `sasl_gss_encode': > mexas> gssapi.c:(.text+0x2ff2): undefined reference to `gss_wrap' > mexas> gssapi.c:(.text+0x30c2): undefined reference to `gss_release_buffer
freebsd-9.0 smartmontools and ada devices
Hi Guys, I have upgraded my desktop from 8.2-stable to 9.0-RC1 (from source), using a GENERIC kernel. I have installed the smartmontools-5.41_3 package from a mirror and found that smartmontools does not like the ada devices anymore. Previously (8.2) I had a GENERIC kernel, with ahci loaded in loader.conf. There an older smartmontools (5.40) worked without a problem on the ada devices. The output of smartctl looks like this: # dolphin# smartctl -a /dev/ada0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ada0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary # Has anybody seen it? John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
