[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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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
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
Re: IPv6 accept_rtadv + bfe0
Johann Hugo jh...@meraka.csir.co.za wrote in 201110190845.17950.jh...@meraka.csir.co.za: jh On Tuesday, October 18, 2011 11:16:57 pm Bjoern A. Zeeb wrote: jh On 18. Oct 2011, at 20:00 , Johann Hugo wrote: jh Hi jh jh The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do jh it with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to jh ifconfig_bge0 in rc.conf it does nothing. jh jh grep bfe /etc/rc.conf jh ifconfig_bfe0=DHCP accept_rtadv jh jh ifconfig_bfe0=DHCP jh ifconfig_bfe0_ipv6=inet6 accept_rtadv jh jh That works, but what is the function of ipv6_activate_all_interfaces=YES in jh rc.conf $ipv6_activate_all_interfaces has nothing to do with accept_rtadv and is not needed in most cases. Please read rc.conf(5) for more details of the function. -- Hiroki pgpZwsbtIzyZH.pgp Description: PGP signature
Re: About FreeBSD 9.0 release note
Xin LI delp...@delphij.net wrote in 4e9dfd46.1040...@delphij.net: de -BEGIN PGP SIGNED MESSAGE- de Hash: SHA256 de de On 10/18/11 15:07, Hiroki Sato wrote: de Hideki Yamamoto hyam...@gmail.com wrote in de CAOEiK=_nEJ=9prg1y5fmdbbwyqxypd-3+nyomqa9asekkgh...@mail.gmail.com: de de hy Hi, hy hy Does someone know where is the draft of FreeBSD de 9.0 release note? hy I would like to check if there is a de description about new functions hy about MLDv2 is included or de not. hy I think the below feature should be included in the de release note as hy IPv6 network is getting popular. hy hy de - hy MFC r200871: hy Use de ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES to signal a join or leave de hy with SSM MLDv2 by default. hy This is current practice and de complies with RFC 4604, as well as being hy required by de production IPv6 networks in Japan. hy The behaviour may be de disabled by setting the net.inet6.mld.use_allow hy sysctl/tunable de to 0. hy - de de I am already working on the relnotes and the above will be de included as an improvement of the IPv6 stack. de de Can we have it somewhere (in the CVS or wiki) so we can work together de on that? This way also makes translation easier... Yes, I will put it to some shared workspace as soon as possible. I know I should have taken an action more quickly, but I couldn't make it. Sorry. -- Hiroki pgpD7KsyBgoyG.pgp Description: PGP signature
Re: IPv6 accept_rtadv + bfe0
Mattia Rossi mro...@swin.edu.au wrote in 4e9dfe11.2070...@swin.edu.au: mr So the _ipv6 bit doesn't take care of passing inet6 to ifconfig mr automatically? No. You always need to add the inet6 keyword wherever needed. mr Does passing two options work, or do I have to pass them separately? mr E.g.: mr mr ifconfig_bfe0_ipv6=inet6 accept_rtadv -ifdisable This should work. -- Hiroki pgpc4XjXAHbfz.pgp Description: PGP signature
Re: IPv6 accept_rtadv + bfe0
On 18. Oct 2011, at 22:30 , Mattia Rossi wrote: 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 yes or ifconfig_bfe0_ipv6=inet6 accept_rtadv ifconfig_bfe0_ipv6=inet6 -ifdisable Just to also answer this: rc.conf is shell; the 2nd variable assignment would just overwrite any former one. -- 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
[head tinderbox] failure on i386/i386
TB --- 2011-10-19 08:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 08:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-19 08:10:00 - cleaning the object tree TB --- 2011-10-19 08:10:08 - cvsupping the source tree TB --- 2011-10-19 08:10:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-19 08:10:52 - building world TB --- 2011-10-19 08:10:52 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 08:10:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 08:10:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 08:10:52 - SRCCONF=/dev/null TB --- 2011-10-19 08:10:52 - TARGET=i386 TB --- 2011-10-19 08:10:52 - TARGET_ARCH=i386 TB --- 2011-10-19 08:10:52 - TZ=UTC TB --- 2011-10-19 08:10:52 - __MAKE_CONF=/dev/null TB --- 2011-10-19 08:10:52 - cd /src TB --- 2011-10-19 08:10:52 - /usr/bin/make -B buildworld World build started on Wed Oct 19 08:10:52 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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 08:55:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 08:55:39 - ERROR: failed to build world TB --- 2011-10-19 08:55:39 - 2087.30 user 466.00 system 2739.03 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 i386/pc98
TB --- 2011-10-19 08:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 08:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-19 08:10:00 - cleaning the object tree TB --- 2011-10-19 08:10:08 - cvsupping the source tree TB --- 2011-10-19 08:10:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-19 08:10:52 - building world TB --- 2011-10-19 08:10:52 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 08:10:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 08:10:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 08:10:52 - SRCCONF=/dev/null TB --- 2011-10-19 08:10:52 - TARGET=pc98 TB --- 2011-10-19 08:10:52 - TARGET_ARCH=i386 TB --- 2011-10-19 08:10:52 - TZ=UTC TB --- 2011-10-19 08:10:52 - __MAKE_CONF=/dev/null TB --- 2011-10-19 08:10:52 - cd /src TB --- 2011-10-19 08:10:52 - /usr/bin/make -B buildworld World build started on Wed Oct 19 08:10:52 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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 08:56:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 08:56:03 - ERROR: failed to build world TB --- 2011-10-19 08:56:03 - 2089.39 user 478.59 system 2763.28 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 amd64/amd64
TB --- 2011-10-19 08:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 08:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-19 08:10:00 - cleaning the object tree TB --- 2011-10-19 08:10:08 - cvsupping the source tree TB --- 2011-10-19 08:10:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-19 08:10:52 - building world TB --- 2011-10-19 08:10:52 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 08:10:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 08:10:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 08:10:52 - SRCCONF=/dev/null TB --- 2011-10-19 08:10:52 - TARGET=amd64 TB --- 2011-10-19 08:10:52 - TARGET_ARCH=amd64 TB --- 2011-10-19 08:10:52 - TZ=UTC TB --- 2011-10-19 08:10:52 - __MAKE_CONF=/dev/null TB --- 2011-10-19 08:10:52 - cd /src TB --- 2011-10-19 08:10:52 - /usr/bin/make -B buildworld World build started on Wed Oct 19 08:10:52 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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 08:56:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 08:56:44 - ERROR: failed to build world TB --- 2011-10-19 08:56:44 - 2118.43 user 480.86 system 2803.88 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 powerpc/powerpc
TB --- 2011-10-19 08:56:44 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 08:56:44 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-10-19 08:56:44 - cleaning the object tree TB --- 2011-10-19 08:56:49 - cvsupping the source tree TB --- 2011-10-19 08:56:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-10-19 08:57:01 - building world TB --- 2011-10-19 08:57:01 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 08:57:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 08:57:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 08:57:01 - SRCCONF=/dev/null TB --- 2011-10-19 08:57:01 - TARGET=powerpc TB --- 2011-10-19 08:57:01 - TARGET_ARCH=powerpc TB --- 2011-10-19 08:57:01 - TZ=UTC TB --- 2011-10-19 08:57:01 - __MAKE_CONF=/dev/null TB --- 2011-10-19 08:57:01 - cd /src TB --- 2011-10-19 08:57:01 - /usr/bin/make -B buildworld World build started on Wed Oct 19 08:57:02 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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 09:41:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 09:41:31 - ERROR: failed to build world TB --- 2011-10-19 09:41:31 - 2020.82 user 456.88 system 2687.41 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: VM images for FreeBSD
2011/10/17 Warren Block wbl...@wonkity.com On Mon, 17 Oct 2011, Alexander Yerenkow wrote: Hello all. I'm currently made set of scripts, which builds FreeBSD from svn sources, and packing it in VirtualBox (*.vdi) compatible images. It's working now, and producing something like FreeBSD-9-i386-r226409-2011-10-16.vdi.xz (also .vdi, .vdi.zip and plain .img which can be dd to USB flash). I'm developing this here: https://github.com/yerenkow/freebsd-vm-image I have more goals to do (like producing more images, with a installed sets of packages, like KDE-from-ports, KDE-from-area51, with experimental GEM drivers etc.) Excellent! If live CD/memdisk features are added, this could also be useful for testing large xorg port updates before commit. PS: why bash for cron-auto-action.sh? Hello all! I'm working currently on creating images with a set pre-installed packages. I looked at project pkgng (candidate for replacing current pkg_* subsystem), and also I have some thought about current packages/ports system. 1. pkg_add can be launched with parameter -p $PREFIX. So, my first thought was: I create empty directory structure with mtree, and I'll install there all required packages; after that I need only update this installation tree (manually by pkg_delete $old pkg_add $new, or with some tool). But I cannot specify to pkg_add relative root, instead of real one. Let me show example: PKG_DBDIR=/zpool0/testroot/var/db/pkg pkg_add -p /zpool0/testroot/usr/local ubench-0.32.tbz installs package, and in /zpool0/testroot/var/db/pkg/ubench-0.32/+CONTENTS there will be such record: @cwd /zpool0/testroot/usr/local I can't specify to pkg_add that it should treat /zpool0/testroot as root, as I need (so record really should be @cwd /usr/local) Instead, pkg_add allows me to make chroot, which as you understand is not good (In specified chroot all required by pkg* binaries/libraries must exists, unfortunately I can't specify some empty dir and install there). Why is that? Because there is +INSTALL script in packages, in which package/port system allows execute any code/script written by porter. 2. In ports enhancements task list (somewhere i read it) there was one item: Make packages non-executable (or something similar). To do this properly, we must get rid of of free-form post-install post-deinstall scripts. To do this, we need some deep analysis of what types of actions there happening, formalize them and provide some way to porters specify all needed actions in Makefile. I downloaded all packages for 9-current i386, found all +INSTALL scripts, and kinda categorized them, you can get all of them here: http://www.box.net/shared/ieovjj7l8omkrm3l21xb To summarize my efforts: I checked 21195 packages; I found 880 install scripts; 3 scripts contains plain exit 0 8 install scripts contains some perl code; 17 scripts contains some additional install commands; 70 scripts contains some chgroup/chown actions (which probably could be done by specifying mtree file?...) 75 contains uncategorized actions (print of license, some interactive questions, ghostscript actions, tex, fonts etc.) 161 scripts contains some file commands, like (ld / cp / mv, creating backups, creating configs if they aren't exists etc. ) 166 scripts contains useradd/groupadd commands (many similar constructions, not too hard to move this to .mk, in pkgng group/users can be specified in yaml config) 380 contains pear component registration (md5 -q * | uniq - produces exactly one result, so these all scripts are really one, could be moved to some pear.mk) Why I'm interested in non-executable install of package (e.g. simple unpack + execute some typical actions based on package description): - Unpacking of hundreds Mb packages takes several minutes (to mdconfig-ed filesystem) - Installation of these packages via pkg_add (they downloads from local ftp) took hours in my case (to mdconfig-ed filesystem) As you understand, to make efficient image building system, I need to deal with package installation without spending too many cpu/disk resources. Ideally I consider all required packages are extracted to some their own directory, like for ubench: $X/packages/ubench/ (and here goes all directory structure which should be copied to new root) plus separated info of new users/groups (maybe there need some additional data to make package installed in such way fully working). So, maybe someone working in this direction, or have any comments? 3. Other ports ideas/thoughts. I proposed small enahcement to pkgng, but instead in pkgng this should be implemented in ports subsystem, it's about specifying abstract dependencies, and correct resolving of them: https://github.com/pkgng/pkgng/issues/100 Who can comment/elaborate about this? It shouldn't be very complicated, since currently almost same functionality provided in .mk. files ( like USE_PERL etc) 4. Where's the right place to discuss ports system? :) Thanks. -- Regards, Alexander
Re: SPI rework
.. what's wrong with your first suggestion? I liked it. :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x.0 RELASE isn't for production.
2011/10/14 David Wolfskill da...@catwhisker.org On Fri, Oct 14, 2011 at 11:55:28AM +0400, Pavel Timofeev wrote: That's what most people think. Could be. But to the extent that it's true, I have no reason to believe that it's a perspective that is held uniquely (or even principally) about FreeBSD. Hi! I would like to say that most freebsd users don't try CURRENT, but try BETAs-x, RCs-x. Errr... I'll suggest that most folks who posit what most folks do don't actually determine this empirically. Some of them probably engage in something called projection (in lieu of performing appropriate polling, for example). Ok, for example, more emails and bug reports appears in mailing lists after CURRENT stabilization. Why? Because most users don't like compile new kernel and world. It's tediously. Errr... So what? Doing it doesn't prevent one from doing other things (within reason), and the process gets done when it's done. And it's the computer doing the tedious stuff -- which is something at which they excel. I'm in the habit of tracking stable/8, stable/9, and head on a daily basis on a personal build machine and on my laptop. I also update all of the installed ports on each machine daily. It's only you. Good habbit. But this isn't often, for example, my colleagues and friends don't track it. They are just users (consumers). I don't expect most folks to do that; actually, I don't expect anyone else to do (precisely) that. Right. You need to download a CURRENT snapshot iso, to install, csup, and then to build kernel and world. Really? I don't think I've ever used a snapshot. I do maintain a private mirror of the FreeBSD CVS SVN repositories (and mirror those to my laptop). I find the tracking process fairly straightforward, and only rarely surprising (though usually, if it is surprising, it's not in an especially good way -- but then I'm occasionally able to help at least provide some encouragement to fix the cause of the surprise). It's funny =). Not everyone maintains its mirrors. For example, I didn't use my CURRENT (previously installed to VM) about 4 months. And now I want to try new CURRENT. What I need to do? Csup and build? No, downloading and installing fresh snapshot would be more quickly. There is changes in bsdinstall while BETA-3 and if I want to test it what i need to do? FreeBSD project builds CURRENT snapshot every month, but not always. And this volatility is bad. Month is a big period. Very big, imo. For example, 10 day period would be great! If you want finer-grained updates, one way is to use the source. The project still maintains the SVN-to-CVS exporting process, and a network of public CVS mirrors around the planet. The cvs program is in the FreeBSD base system. You have the resources necessary to do this, if you want to do so. See above And when BETA/RC time comes users rush like mad to test it. And they find errors and bugs. Writing PR, emails and even !patches! There are certainly some folks whose first exposure to a new release is in the later stages of the release process. Changing parameters (such as the duration of the process) may affect the population distribution some, but it won't change the fact that there are some folks who will not test early enough to raise some valid objections or concerns in sufficient time to have them addressed in a completely satisfactory manner prior to the release. This is something that appears to involve rather deep-sewated aspects of human nature, and it is not in the power of any organization to prevent it. The best anyone (or any group) can do is find ways to mitigate it, and learn to move on. It's also correctly. But the lion's share of these patches doesn't get into the coming BETA or RC. Maintainers say I don't have time [to test it] or It's too late. Given that the process is intended to produce a release, there comes a time when it is necessary to draw the line and cut the release. Software is rarely perfect. I'd venture that software of sufficient complexity is never perfect. I'll also ventire that FreeBSD -- much as I enjoy using and working with it -- is sufficiently complex as to be imperfect. In fact, it is a work in progress. This ought not be either surprising or unfamiliar to anyone who has been on the planet long enough to recognize the parallels with humans -- remarkably few humans are perfect, either, after all. :-} [And yes, I include myself as imperfect -- certainly as long as I'm still breathing.] Yes, you're right. Why is it late? I'm talking about only BUGS (PRs with patches), not new features. Let's users test it! In coming BETA/RC. Where are we in a hurry? The BETAs and RCs exists for finding BUGS in coming RELEASE! It's the only purpose of it. Of cause pathes would be commited after x.0 RELEASE to x.1 STABLE. Because of this situation most people says x.0 RELASE isn't
Re: x.0 RELASE isn't for production.
2011/10/15 George Kontostanos gkontos.m...@gmail.com On Fri, Oct 14, 2011 at 10:55 AM, Pavel Timofeev tim...@gmail.com wrote: That's what most people think. I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be longer. Six months, for example. New STABLE branch is very important! IMHO different OS releases (Unix or not) are usually at the state of FreeBSD current regarding stability. FreeBSD late BETA and early RC are usually very stable. Therefore the approximate one month period between the first beta and the release is adequate time. Many users are reluctant to follow stable because they have to go through the wolrd kernel procedure. Since freebsd-update exists as a means of binary upgrading a system through releases, I don't think that it would be a bad idea to be able to use is for stable as well. Let's assume that we would have monthly minor releases something like 9.0.1, 9.0.2 etc. That could ease the fear of .0 release. It's not bad idea. This is coming from someone who is using current all the time for workstations and stable for production servers and never uses freebsd-update! Best Regards -- George Kontostanos aisecure.net ___ 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: x.0 RELASE isn't for production.
2011/10/15 Martin Sugioarto mar...@sugioarto.com Am Fri, 14 Oct 2011 11:55:28 +0400 schrieb Pavel Timofeev tim...@gmail.com: That's what most people think. Hi! I'm not thinking this. This is made up by users who only adapt slowly to changes and features. Look at the whole crowd which got furious about the new Microsoft Office. I tell you, in one year, no one will cry about it anymore. Sometimes, I feel like I am the only who is happy about good ideas, even when they change something drastically. The most people think Whoa... I have to learn again!... and then silently accept it when it is very late, because everyone else already migrated. No, i don't care about new features or big changes. I love it! I care about bugs, that people finds while BETA/RC. This has nothing to do with release quality, because the efforts to make a production release of x.0 are much higher, in my opinion. So the quality is generally better, if you have enough time to make this release. For me the worst FreeBSD release ever was 5.3. Even 5.0 BETAs worked better on my hardware. I also stopped using FreeBSD at that time until 7.0 BETAs arrived. And when BETA/RC time comes users rush like mad to test it. And they find errors and bugs. Writing PR, emails and even !pathes! But the lion's share of these pathes doesn't get into the coming BETA or RC. Yes. I'm waiting for my /sbin/dump fix to get verified and committed. It's really disappointing to see the next release without a functioning backup possibility (for my configuration here). kern/160678? A good example. I give 5$ that this fix won't be in 9.0 RELEASE =) I know a few other important PRs that won't be in 9.0 RELEASE. Thats why I wrote initial email. Fortunately, I don't see a fixed release date, yet. I hope the developers fix as much as possible even when we see 9.0R in late 2012. -- Martin ___ 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: x.0 RELASE isn't for production.
2011/10/15 Thomas Mueller mueller6...@bellsouth.net MHO different OS releases (Unix or not) are usually at the state of FreeBSD current regarding stability. FreeBSD late BETA and early RC are usually very stable. Therefore the approximate one month period between the first beta and the release is adequate time. I see your point, especially after installing NetBSD on my new computer and having big problems, like not being able to startx or not neing able to boot at all. On the old computer, I also had big problems with NetBSD, including release, stable and current versions. Building FreeBSD or NetBSD from source might be not feasible on older computers short on RAM and/or disk space. Bingo! I have atom-based computers and building world is torture. There are more frequent current FreeBSD snapshots available on http://pub.allbsd.org/pub/FreeBSD-snapshots/ This site also has snapshots for other BSDs. Great! But it's not official. If this link was in freebsd.org it would be cool. Tom ___ 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: x.0 RELASE isn't for production.
On 19 October 2011 15:42, Pavel Timofeev tim...@gmail.com wrote: =) Thats why we don't have much people in FreeBSD. FreeBSD for users? or developers? The big problem is that these conversations are not wanted everyone. Nobody cares. For example, Vadim Goncharov wrote big mail with description of various problems in FreeBSD (organozation|system|ports|etc). Big consersation and all forgotten. Nothing has changed and will not change. Oh the conversations are wanted. People to build solutions to problems are more wanted. Some of what Vadim mentioned is being addressed (ports/package infrastructure.) The other stuff is likely up for discussion post 9.0-RELEASE. Remember - best way to help is to grab a problem and hack on it until it's fixed. There's only so much that discussion, planning and more discussion can do. (Unless you're an AI researcher and can write systems to take discussion/planning and output code. Then we'd all love to hear from you.) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x.0 RELASE isn't for production.
On 19 October 2011 16:04, Pavel Timofeev tim...@gmail.com wrote: kern/160678? A good example. I give 5$ that this fix won't be in 9.0 RELEASE =) I know a few other important PRs that won't be in 9.0 RELEASE. Thats why I wrote initial email. Kirk fixed it in -HEAD. I hope he'll get it tested and backported to stable/9 before release. If you'd like to help then please re-create the issue on a stable/9 system, apply the fix, verify it works and let him know! Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x.0 RELASE isn't for production.
On 19 October 2011 19:38, Pavel Timofeev tim...@gmail.com wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=160943 (there is hope) or http://www.freebsd.org/cgi/query-pr.cgi?pr=161123 (little hope. it's not me, but there I was noisy.) Just send the committer a polite, nicely worded email and see if they'll submit it for backporting to stable/9. There's a bunch of fixes that I've not backported from -head to stable/9 because I've not received anywhere near enough feedback from people to be sure it hasn't broken things this late in the release cycle. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x.0 RELASE isn't for production.
Pavel Timofeev schreef: I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be longer. Six months, for example. New STABLE branch is very important! So is opening head up to allow developers to work on and commit new code. As with many things in engineering, there's a cost/benefit trade-off. RE is doing a remarkable job, IMO. Sorry, don't misunderstand me. I'm talking about new STABLE branch. Maybe we need to change things like BETA-1(2) is still CURRENT. For example, let's introduce a new concept ALPHA (which will be CURRENT). And BETAs will be STABLE. If you want a really stable OS ,then there is never going to be a release. In CURRENT, there are a lot of changes already that do not go into 9.0 You _must_ take a point in time to release the release, even with known and pending patches. If you are going to wait, then there will never be a release. The 9.0.1, 9.0.2 branch idea is very apealling i must say. But here the same problem do we wait for that one patch that is waiting MFC? So the same problem when do you release the 9.0.x version! Releasing the release is a trade-off. I do like the current approach that FreeBSD uses. The only thing i think could be better is to slow down the release cycle. I would like to see a release like 9.8, which then have an enormous real world exposure and where all possible bugs are ironed out. A release that you could use without hesitating for your daily tasks. But then there is a trade-off again, all new features that are pending in CURRENT do not get as much exposure as we would like, and then when the new CURRENT become the next production release, we could have a much more buggier release then normal. So i am glad i do not have to make these dicisions. :D regards Johan Hendriks ___ 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: x.0 RELASE isn't for production.
2011/10/19 Adrian Chadd adr...@freebsd.org On 19 October 2011 16:04, Pavel Timofeev tim...@gmail.com wrote: kern/160678? A good example. I give 5$ that this fix won't be in 9.0 RELEASE =) I know a few other important PRs that won't be in 9.0 RELEASE. Thats why I wrote initial email. Kirk fixed it in -HEAD. I hope he'll get it tested and backported to stable/9 before release. If you'd like to help then please re-create the issue on a stable/9 system, apply the fix, verify it works and let him know! Yes, I helps. I test everything that comes across to me when I have free time. And I already did tests in such situation. For example: http://www.freebsd.org/cgi/query-pr.cgi?pr=160943 (there is hope) or http://www.freebsd.org/cgi/query-pr.cgi?pr=161123 (little hope. it's not me, but there I was noisy.) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x.0 RELASE isn't for production.
2011/10/19 Adrian Chadd adr...@freebsd.org On 19 October 2011 15:42, Pavel Timofeev tim...@gmail.com wrote: =) Thats why we don't have much people in FreeBSD. FreeBSD for users? or developers? The big problem is that these conversations are not wanted everyone. Nobody cares. For example, Vadim Goncharov wrote big mail with description of various problems in FreeBSD (organozation|system|ports|etc). Big consersation and all forgotten. Nothing has changed and will not change. Oh the conversations are wanted. People to build solutions to problems are more wanted. I'd love to, but I often lack the knowledge and skills. I'm tring to change that. Some of what Vadim mentioned is being addressed (ports/package infrastructure.) The other stuff is likely up for discussion post 9.0-RELEASE. Excelent. But I got carried away. Remember - best way to help is to grab a problem and hack on it until it's fixed. Yes, I know. Usually that's what i'm doing or want to do. There's only so much that discussion, planning and more discussion can do. (Unless you're an AI researcher and can write systems to take discussion/planning and output code. Then we'd all love to hear from you.) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2011-10-19 11:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 11:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-10-19 11:40:00 - cleaning the object tree TB --- 2011-10-19 11:40:08 - cvsupping the source tree TB --- 2011-10-19 11:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-10-19 11:40:27 - building world TB --- 2011-10-19 11:40:27 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 11:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 11:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 11:40:27 - SRCCONF=/dev/null TB --- 2011-10-19 11:40:27 - TARGET=i386 TB --- 2011-10-19 11:40:27 - TARGET_ARCH=i386 TB --- 2011-10-19 11:40:27 - TZ=UTC TB --- 2011-10-19 11:40:27 - __MAKE_CONF=/dev/null TB --- 2011-10-19 11:40:27 - cd /src TB --- 2011-10-19 11:40:27 - /usr/bin/make -B buildworld World build started on Wed Oct 19 11:40:27 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 12:25:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 12:25:21 - ERROR: failed to build world TB --- 2011-10-19 12:25:21 - 2087.97 user 467.23 system 2720.64 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 i386/pc98
TB --- 2011-10-19 11:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 11:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-10-19 11:40:00 - cleaning the object tree TB --- 2011-10-19 11:40:08 - cvsupping the source tree TB --- 2011-10-19 11:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-10-19 11:40:27 - building world TB --- 2011-10-19 11:40:27 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 11:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 11:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 11:40:27 - SRCCONF=/dev/null TB --- 2011-10-19 11:40:27 - TARGET=pc98 TB --- 2011-10-19 11:40:27 - TARGET_ARCH=i386 TB --- 2011-10-19 11:40:27 - TZ=UTC TB --- 2011-10-19 11:40:27 - __MAKE_CONF=/dev/null TB --- 2011-10-19 11:40:27 - cd /src TB --- 2011-10-19 11:40:27 - /usr/bin/make -B buildworld World build started on Wed Oct 19 11:40:27 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 12:25:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 12:25:39 - ERROR: failed to build world TB --- 2011-10-19 12:25:39 - 2089.25 user 479.40 system 2738.11 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 amd64/amd64
TB --- 2011-10-19 11:40:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-10-19 11:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-10-19 11:40:00 - cleaning the object tree TB --- 2011-10-19 11:40:08 - cvsupping the source tree TB --- 2011-10-19 11:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-10-19 11:40:27 - building world TB --- 2011-10-19 11:40:27 - CROSS_BUILD_TESTING=YES TB --- 2011-10-19 11:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-10-19 11:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-10-19 11:40:27 - SRCCONF=/dev/null TB --- 2011-10-19 11:40:27 - TARGET=amd64 TB --- 2011-10-19 11:40:27 - TARGET_ARCH=amd64 TB --- 2011-10-19 11:40:27 - TZ=UTC TB --- 2011-10-19 11:40:27 - __MAKE_CONF=/dev/null TB --- 2011-10-19 11:40:27 - cd /src TB --- 2011-10-19 11:40:27 - /usr/bin/make -B buildworld World build started on Wed Oct 19 11:40:27 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] /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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 'voidunnamed::FreeBSDTargetInfoTarget::getOSDefines(const clang::LangOptions, const llvm::Triple, clang::MacroBuilder) const [with Target = unnamed::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 12:26:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-10-19 12:26:21 - ERROR: failed to build world TB --- 2011-10-19 12:26:21 - 2119.62 user 481.88 system 2780.11 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
Re: BTX halted when booting 9.0-BETA3 (Root On ZFS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I wanted to let you know that FreeBSD is booting again. I don't know exatly what was the solution but here's what I did: 1. clean up the pool, now 90% of free space 2. buildworld with r226519 and Andriy's patch: http://people.freebsd.org/~avg/zfs-boot-gang.diff 3. reinstall the boot blocks (following RootOnZFS guide) I can't be sure if it was a hardware failure or a FreeBSD issue only, because I have problems with the battery and CPU cooling (reported temperature below 0°C... under Windows 7 too). I don't know if Andriy's patch fixes something in my case. Andriy, do you want me to make further tests (without your patch and maybe with the SVN revision I was using before)? Again, thanks for all your suggestions! - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6e1G8ACgkQa+xGJsFYOlPt+wCdECfBUcLVqsvYKqiossWi2Gkv 7PQAni79fZgPO+uXCDHJcj9Wa4HpFXSx =NSlP -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
'/bin/ls' broken by SVN r226509
When running 'configure' for, say, the latest clamav update, '/bin/ls' dumps core with a floating point exception. Reversing out SVN r226509 restores normal operation, imb ___ 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: x.0 RELASE isn't for production.
2011/10/19 Johan Hendriks joh.hendr...@gmail.com Pavel Timofeev schreef: I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be longer. Six months, for example. New STABLE branch is very important! So is opening head up to allow developers to work on and commit new code. As with many things in engineering, there's a cost/benefit trade-off. RE is doing a remarkable job, IMO. Sorry, don't misunderstand me. I'm talking about new STABLE branch. Maybe we need to change things like BETA-1(2) is still CURRENT. For example, let's introduce a new concept ALPHA (which will be CURRENT). And BETAs will be STABLE. If you want a really stable OS ,then there is never going to be a release. In CURRENT, there are a lot of changes already that do not go into 9.0 You _must_ take a point in time to release the release, even with known and pending patches. If you are going to wait, then there will never be a release. Yes, I agree, but there must be a golden mean. The 9.0.1, 9.0.2 branch idea is very apealling i must say. But here the same problem do we wait for that one patch that is waiting MFC? So the same problem when do you release the 9.0.x version! Releasing the release is a trade-off. Ok, I understood. I do like the current approach that FreeBSD uses. The only thing i think could be better is to slow down the release cycle. Yes, me too I would like to see a release like 9.8, which then have an enormous real world exposure and where all possible bugs are ironed out. Well, it's a large number. x.3(4) - yes. However, progress is developing faster and faster and we need to keep up with him, so you're right below. A release that you could use without hesitating for your daily tasks. But then there is a trade-off again, all new features that are pending in CURRENT do not get as much exposure as we would like, and then when the new CURRENT become the next production release, we could have a much more buggier release then normal. So i am glad i do not have to make these decisions.** :D regards Johan Hendriks ___ 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: x.0 RELASE isn't for production.
2011/10/19 Adrian Chadd adr...@freebsd.org On 19 October 2011 19:38, Pavel Timofeev tim...@gmail.com wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=160943 (there is hope) or http://www.freebsd.org/cgi/query-pr.cgi?pr=161123 (little hope. it's not me, but there I was noisy.) Just send the committer a polite, nicely worded email and see if they'll submit it for backporting to stable/9. Big sorry, if I was impolite. My english is very poor and I don't know how to write civilly. There's a bunch of fixes that I've not backported from -head to stable/9 because I've not received anywhere near enough feedback from people to be sure it hasn't broken things this late in the release cycle. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) does not add post-processing for source file with compile-with command in sys/conf/files
I have run into the same issue recently. I have been testing the
following patch(on 8.2-RELEASE) and it seems to have worked for me:
--- mkmakefile.c 11:09:30.0 -0400
+++ mkmakefile.c2011-10-06 11:13:31.0 -0400
@@ -742,15 +742,16 @@
break;
}
snprintf(cmd, sizeof(cmd),
- ${%s_%c%s}\n.if defined(NORMAL_CTFCONVERT)
- !empty(NORMAL_CTFCONVERT)\n
- \t${NORMAL_CTFCONVERT}\n.endif, ftype,
+ ${%s_%c%s}\n, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
- fprintf(f, \t%s\n\n, compilewith);
+ fprintf(f, \t%s\n, compilewith);
+ fprintf(f, .if defined(NORMAL_CTFCONVERT)
+!empty(NORMAL_CTFCONVERT)\n
+\t${NORMAL_CTFCONVERT}\n.endif\n\n);
}
}
___
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
9.0-RC1 - installer observations and shell in new system gamble...
. During install, in the 'Add Users' part, why is it able to add the new user 'peter' to a new group 'peter' [the default option], but when I try to put user 'peter' into a more generic new group 'admin' it says group does not exist - I figure group 'peter' also does not exist at this time. Invite peter into other groups? [] - Sounds like the user gets an invitation and that I should answer 'yes'/'no' here, not with an actual group name, how about List other groups peter should be added to: Also, after I'm done with that and Open a shell in the new system, /etc/passwd is populated with user 'peter', but /etc/rc.conf and /etc/fstab files do not exist. I wanted to change fstab to use the gpt labels, not partition numbers but that file does not exist and gets overwritten by installer on reboot. rc.conf - I created a one line comment #pk test' - after reboot this is what I have in /etc/rc.conf $ cat /etc/rc.conf hostname=pkbsd # pk test ifconfig_em0=DHCP sshd_enable=YES So my comment stayed but was moved when installer configs were written on reboot. Added same comment to /etc/fstab, but it did not stay and was overwritten: $ cat /etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/ada0p2 / ufs rw 1 1 /dev/ada0p3 noneswapsw 0 0 So even if I did add the gpt labeled 'Devices' in there, it would be overwritten when the installer reboots and makes the live shell a gamble of what will stay what won't on reboot ]Peter[ ___ 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: '/bin/ls' broken by SVN r226509
Michael Butler i...@protected-networks.net writes: When running 'configure' for, say, the latest clamav update, '/bin/ls' dumps core with a floating point exception. Thanks for the report. Try r226546. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: '/bin/ls' broken by SVN r226509
On 10/19/11 11:39, Dag-Erling Smørgrav wrote: Michael Butleri...@protected-networks.net writes: When running 'configure' for, say, the latest clamav update, '/bin/ls' dumps core with a floating point exception. Thanks for the report. Try r226546. Fixed - Thanks! :-) imb ___ 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: mtx_lock() of destroyed mutex on NFS
Bjoern A. Zeeb wrote:
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
cs 0x20
ds 0x3b
es 0x3b003b
fs 0x1b0013
gs 0x1b
ss 0x28
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
r11 0x1
r12 0x1
r13 0xfe001a001000
r14 0x3fe
r15 0x80a39948 __func__.7715+0x2d3
rip 0x80646c2b kdb_enter+0x3b
rflags 0x282
kdb_enter+0x3b: movq $0,0x80feb2(%rip)
This seems to have been caused by a premature soclose(), which in
turn implies a premature call to it from clnt_dg_destroy(). The only
race I can see is that the socket buffer lock is used to protect
checking for so_upcall being set (which it then uses to decide if
a new cs_XXX structure is needed), but this lock isn't held when
it decides to throw it away and close the socket.
You could try the attached patch, which I've tested minimally.
(I think it fixes this race.)
rick
--
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
--- rpc/clnt_dg.c.sav 2011-10-18 22:31:10.0 -0400
+++ rpc/clnt_dg.c 2011-10-18 22:44:15.0 -0400
@@ -1001,12 +1001,12 @@ clnt_dg_destroy(CLIENT *cl)
cs = cu-cu_socket-so_rcv.sb_upcallarg;
clnt_dg_close(cl);
+ SOCKBUF_LOCK(cu-cu_socket-so_rcv);
mtx_lock(cs-cs_lock);
cs-cs_refs--;
if (cs-cs_refs == 0) {
mtx_unlock(cs-cs_lock);
- SOCKBUF_LOCK(cu-cu_socket-so_rcv);
soupcall_clear(cu-cu_socket, SO_RCV);
clnt_dg_upcallsdone(cu-cu_socket, cs);
SOCKBUF_UNLOCK(cu-cu_socket-so_rcv);
@@ -1015,6 +1015,7 @@ clnt_dg_destroy(CLIENT *cl)
lastsocketref = TRUE;
} else {
mtx_unlock(cs-cs_lock);
+ SOCKBUF_UNLOCK(cu-cu_socket-so_rcv);
lastsocketref = FALSE;
}
___
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: mtx_lock() of destroyed mutex on NFS
On 19. Oct 2011, at 16:00 , Rick Macklem wrote: Bjoern A. Zeeb wrote: 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 ... This seems to have been caused by a premature soclose(), which in turn implies a premature call to it from clnt_dg_destroy(). The only race I can see is that the socket buffer lock is used to protect checking for so_upcall being set (which it then uses to decide if a new cs_XXX structure is needed), but this lock isn't held when it decides to throw it away and close the socket. You could try the attached patch, which I've tested minimally. (I think it fixes this race.) Great, will do. I couldn't reproduce it every time but I have hit it again the last 24 hours. Thanks a lot! /bz -- 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: '/bin/ls' broken by SVN r226509
On Wed, Oct 19, 2011 at 12:00:12PM -0400, Michael Butler wrote: On 10/19/11 11:39, Dag-Erling Sm??rgrav wrote: Michael Butleri...@protected-networks.net writes: When running 'configure' for, say, the latest clamav update, '/bin/ls' dumps core with a floating point exception. Thanks for the report. Try r226546. I removed subversion to help the move from 1.6 to 1.7. Now I can't build it. If possible, can you provide a patch that can be applied directly to fix this. Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: '/bin/ls' broken by SVN r226509
On Wed, Oct 19, 2011 at 10:19 AM, Anton Shterenlikht me...@bristol.ac.uk wrote: On Wed, Oct 19, 2011 at 12:00:12PM -0400, Michael Butler wrote: On 10/19/11 11:39, Dag-Erling Sm??rgrav wrote: Michael Butleri...@protected-networks.net writes: When running 'configure' for, say, the latest clamav update, '/bin/ls' dumps core with a floating point exception. Thanks for the report. Try r226546. I removed subversion to help the move from 1.6 to 1.7. Now I can't build it. If possible, can you provide a patch that can be applied directly to fix this. svnweb is your friend: http://svnweb.freebsd.org/base/head/bin/ls/ls.c?r1=226546r2=226545pathrev=226546 -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: possible mountroot regression
On Oct 18, 2011, at 9:04 AM, Andriy Gapon wrote:
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( empty lineAbort 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?
I like it.
Would you be able to commit a variant of this patch sans the 'x' part?
Yes, soonish. If people like the 'x' change I can do that in a followup
commit as well. I just need to know if people like it or not...
--
Marcel Moolenaar
mar...@xcllnt.net
___
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
Hello, 2011/10/19 Marcel Moolenaar mar...@xcllnt.net: On Oct 18, 2011, at 9:04 AM, Andriy Gapon wrote: Would you be able to commit a variant of this patch sans the 'x' part? Yes, soonish. If people like the 'x' change I can do that in a followup commit as well. I just need to know if people like it or not... Yes, it's useful. But why not q for quit ? Just a bikeshed color idea... Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: '/bin/ls' broken by SVN r226509
On Wed, Oct 19, 2011 at 10:38:30AM -0700, Garrett Cooper wrote: On Wed, Oct 19, 2011 at 10:19 AM, Anton Shterenlikht me...@bristol.ac.uk wrote: On Wed, Oct 19, 2011 at 12:00:12PM -0400, Michael Butler wrote: On 10/19/11 11:39, Dag-Erling Sm??rgrav wrote: Michael Butleri...@protected-networks.net ?writes: When running 'configure' for, say, the latest clamav update, '/bin/ls' dumps core with a floating point exception. Thanks for the report. ?Try r226546. I removed subversion to help the move from 1.6 to 1.7. Now I can't build it. If possible, can you provide a patch that can be applied directly to fix this. svnweb is your friend: http://svnweb.freebsd.org/base/head/bin/ls/ls.c?r1=226546r2=226545pathrev=226546 Thanks. Can you also please remind how to reinstall just /bin/ls, without the make buildworld? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: '/bin/ls' broken by SVN r226509
On Oct 19, 2011, at 11:47 AM, Anton Shterenlikht me...@bristol.ac.uk wrote: On Wed, Oct 19, 2011 at 10:38:30AM -0700, Garrett Cooper wrote: On Wed, Oct 19, 2011 at 10:19 AM, Anton Shterenlikht me...@bristol.ac.uk wrote: On Wed, Oct 19, 2011 at 12:00:12PM -0400, Michael Butler wrote: On 10/19/11 11:39, Dag-Erling Sm??rgrav wrote: Michael Butleri...@protected-networks.net ?writes: When running 'configure' for, say, the latest clamav update, '/bin/ls' dumps core with a floating point exception. Thanks for the report. ?Try r226546. I removed subversion to help the move from 1.6 to 1.7. Now I can't build it. If possible, can you provide a patch that can be applied directly to fix this. svnweb is your friend: http://svnweb.freebsd.org/base/head/bin/ls/ls.c?r1=226546r2=226545pathrev=226546 Thanks. Can you also please remind how to reinstall just /bin/ls, without the make buildworld? make -C bin/ls cleandir all install ? -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: small devfs.conf patch
On Tue Oct 18 11, Andriy Gapon wrote: 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. unfortunately i don't own a commit bit. -- 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: possible mountroot regression
On 10/19/11, Olivier Smedts oliv...@gid0.org wrote: Hello, 2011/10/19 Marcel Moolenaar mar...@xcllnt.net: On Oct 18, 2011, at 9:04 AM, Andriy Gapon wrote: Would you be able to commit a variant of this patch sans the 'x' part? Yes, soonish. If people like the 'x' change I can do that in a followup commit as well. I just need to know if people like it or not... Yes, it's useful. But why not q for quit ? Just a bikeshed color idea... Cheers eXit :) -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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 Wed, 19 Oct 2011, Oliver Pinter wrote: On 10/19/11, Olivier Smedts oliv...@gid0.org wrote: 2011/10/19 Marcel Moolenaar mar...@xcllnt.net: On Oct 18, 2011, at 9:04 AM, Andriy Gapon wrote: Would you be able to commit a variant of this patch sans the 'x' part? Yes, soonish. If people like the 'x' change I can do that in a followup commit as well. I just need to know if people like it or not... Yes, it's useful. But why not q for quit ? Just a bikeshed color idea... eXit :) In some languages... More important to me is the the Abort manual input which tells what it does but not why the user would want to do that. Abort manual input... and then what? Hang? Retry? Panic? Reboot? Resume attempting to mount the root device that was expected? ___ 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 Wed, Oct 19, 2011 at 12:12 PM, Warren Block wbl...@wonkity.com wrote: On Wed, 19 Oct 2011, Oliver Pinter wrote: On 10/19/11, Olivier Smedts oliv...@gid0.org wrote: 2011/10/19 Marcel Moolenaar mar...@xcllnt.net: On Oct 18, 2011, at 9:04 AM, Andriy Gapon wrote: Would you be able to commit a variant of this patch sans the 'x' part? Yes, soonish. If people like the 'x' change I can do that in a followup commit as well. I just need to know if people like it or not... Yes, it's useful. But why not q for quit ? Just a bikeshed color idea... eXit :) In some languages... More important to me is the the Abort manual input which tells what it does but not why the user would want to do that. Abort manual input... and then what? Hang? Retry? Panic? Reboot? Resume attempting to mount the root device that was expected? Or just go back to status quo for previous releases and we can worry about usability later? -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: SPI rework
On Wed, 19 Oct 2011 19:14:07 +0800 Adrian Chadd adr...@freebsd.org wrote: .. what's wrong with your first suggestion? I liked it. :) Adrian Because we can't do duplex operations in that way. But if we use old struct, we will be able send and receive in the same time. I don't know if such device exists. But if we implement SPI device then we will be able to communicate between two FreeBSD boxes in a duplex manner! :) -- Aleksandr Rybalko r...@ddteam.net ___ 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: Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4
Fabian Keil freebsd-lis...@fabiankeil.de wrote: I pretty reproducible get the following (handtranscribed) panic when sending an zfs snapshot to geli provider based on an USB stick that disappears (due to a bug, or because it's unplugged): Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address = 0x288 fault code = supervisor write data, page not present instruction pointer = 0x20:0x808e2984 stack pointer = 0x28:0xff800023fba0 frame pointer = 0x28:0xff800023fbb0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_up) [ thread pid 13 tid 100010 ] Stopped atatomic_subtract_int+0x4: lock subl %esi,(%rdi) db where Tracing pid 13 tid 100010 td 0xfe00027998c0 atomic_subtract_int() at atomic_subtract_int+0x4 g_io_schdule_up() at g_io_schedule_up+0xa6 g_up_procbody() at g_up_procbody+0x5c fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff800023fd00, rbp 0 --- It seems to be important that ZFS is actually writing to the stick. If the stick is unplugged while the operation is stalled for other reasons, this particular panic doesn't seem to occur. While I end up in the debugger, dumping core doesn't work and produces a double fault and a bunch of duplicated messages (again handtranscribed): The duplicated messages have been recently fixed. db dump Dumping 443 out of 1974 MB: Dumping 443 out of 1974 MB Fatal double fault Fatal double fault rip = 0x8066a9e0 rip = 0x8066a9e0 rsp = 0xff800023c000 rsp = 0xff800023c000 rbp = 0xff800023c040 rbp = 0xff800023c040 cpuid = 0; cpuid = 0; apic id = 00 apic id = 00 panic: double fault panic: double fault cpuid = 0 cpuid = 0 KDB: stack backtrace: KDB: stack backtrace: db_trac_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 dblfault_handler() at dblfault_handler+0xa4 Xdblfault() at Xdblfault+0xa8 --- trap 0x17, rip = 0x8066a9e8, rsp = 0x80e56158, rbp = 0xff800023c040 --- mi_switch() at mi_switch+0x270 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 mi_switch() at mi_switch+0x275 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 [several pages of the previous three lines skipped] mi_switch() at mi_switch+0x275 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 intr_even_schedule_thread() at intr_event_schedule_thread+0xbb ahci_end_transaction() at ahci_end_transaction+0x398 ahci_ch_intr() at ahci_ch_intr+0x2b5 ahcipoll() at ahcipoll+0x15 xpt_polled_action() at xpt_polled_action+0xf7 I first noticed the problem with CURRENT from a week ago, but given that USB sticks don't usually disappear for me while sending snapshots to them, the problem might not be new. I'm using amd64, the panic above is from a custom kernel without WITNESS and INVARIANTS, but enabling them doesn't seem to affect the trace before the double fault. I wasn't able to reproduce the panic by unplugging the stick while writing to the pool using dd (but only tried once). Here's another one, again with recent HEAD. This time the USB stick disappeared while the pool was being scrubbed and dumping actually worked. The stick seems to reproducibly disappear after scrubbing it for a while and the panic seems to be reproducible as well. The stack trace looks a bit different, but I'm not sure if this is because it's a slightly different situation or because of changes in HEAD. fk@r500 /usr/crash $kgdb kernel.3/kernel vmcore.3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: ugen7.2: Generic at usbus7 (disconnected) umass0: at uhub7, port 2, addr 2 (disconnected) (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying command (da0:umass-sim0:0:0:0): Selection timeout (da0:umass-sim0:0:0:0): Retrying command (da0:umass-sim0:0:0:0): Selection timeout (da0:umass-sim0:0:0:0): Retrying command (da0:umass-sim0:0:0:0): Selection timeout (da0:umass-sim0:0:0:0): Retrying command (pass2:umass-sim0:0:0:0): lost device (pass2:umass-sim0:0:0:0): removing device entry (da0:umass-sim0:0:0:0): lost device - 1 outstanding (da0:umass-sim0:0:0:0): Error 6, Retries exhausted (da0:umass-sim0:0:0:0): oustanding 0 GEOM_ELI: Crypto WRITE request
Re: x11/nvidia-driver / Compilation has failed
Hi there After my upgrade from 285.03 to 285.05.09 I experience daily to bidaily freezes on 10-current, with nvidia 8600gts. I'm guessing they come from the nvidia-driver. I'm back to 285.03 (which ran without fault) now to test if they persist. mfg tobias On Wed, 12 Oct 2011 04:20:07 +0200, Alexey Dokuchaev da...@freebsd.org wrote: On Thu, Oct 06, 2011 at 01:35:14AM +, Nali Toja wrote: Ali Mashtizadeh mashtiza...@gmail.com writes: 2011/8/31 Alexey Dokuchaev da...@freebsd.org: On Mon, Aug 29, 2011 at 02:59:48PM +0200, Olivier Smedts wrote: 2011/8/29 ken k...@tydfam.jp: Could I test your patch for nvidia-driver, too? I cannot find your patch in this mail. I took the patch in : http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html And it worked for me. Should be fixed in the port itself now (also updated to 280.13). Is there any reason I should still be hitting this bug when building on 9-STABLE? With Linux compatibility disabled I can build the driver, but the kernel refuses to load it saying it's incompatible with my kernel version. Only if you're using 285.05.09 with the port. And it'd affect both /stable/9 and /head users. // from src/nv-freebsd.h: #if __FreeBSD_version = 900041 #include sys/capability.h #else #define fget(td, fd, cap, fp) fget(td, fd, fp) #endif Can you commit below tiny change? It should make testing the new version a bit easier for people who are impatient to wait for the next port update. That version also includes tunable support similar to ports/156386. Port was updated to serve the most recent release from NVidia, 285.05.09. Please test and report of any issues. Thanks, ./danfe ___ 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 -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ 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
