Re: [PATCH v7 04/19] amd64: introduce hook for custom preload metadata parsers
On Thu, Dec 19, 2013 at 07:54:41PM +0100, Roger Pau Monne wrote: --- sys/amd64/amd64/machdep.c | 45 + sys/amd64/include/sysarch.h | 12 + sys/conf/files.amd64|1 + This looks fine for me. pgpKHSZIJtBoR.pgp Description: PGP signature
Re: 10-RC2 current wireless link aggregation not working correctly
Guys, Id like to work a bit on this issue in my free time, I have 2 weeks holiday after Xmass. First an update on lagg for the case you boot with wired coupled: 1. I previously said lagg0 switches correctly when I unplug the wired interface, but it is not so. It appeared so because I used ifconfig and listed all interfaces. If I do a ifconfig lagg0 specifically the network activity DOES NOT resume, and the output shows that the interface was not switched. 2. network activity resumes when you specifically do ifconfig bge0 ( master wired). Second: 1. Please tell me if one of the developers made on their personal pages a intro how to set up a solid kernel development intro. It would save me a lot of time considering I never set up such an environment for any Unix like OS. I only worked in kernel development for NT and later derived kernels. I can allocate two core 2 machines for this task , with fire-wire, USN and Ethernet connectivity 2. Any other resources which you can come up from your head which I can print and read are also appreciated. Dan On Tue, 17 Dec 2013 12:11:49 -0800, Adrian Chadd adrian.ch...@gmail.com wrote: Ive no idea sorry. Its likely an ifnet change and not anything WiFi specific. :( On Dec 17, 2013 12:04 PM, dan_partelly wrote: Yes, this is correct. A simple list of the interfaces with ifconfig makes the system recover and restart activity on the secondary port. Its a good starting point to hunt down the problem. One of the ioctls sent has this side effect. Dan If I am am understanding correctly, Dan and Nikolai say that just running ifconfig brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldnt be changing anything. ___ freebsd-current@freebsd.org [2] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current [3] To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org [4] Links: -- [1] mailto:dan_parte...@rdsor.ro [2] mailto:freebsd-current@freebsd.org [3] http://lists.freebsd.org/mailman/listinfo/freebsd-current [4] mailto: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
ZFS/zpool command blocks ... locking up all terminals
I have a faulty pool with an ambiguous label and I tried to resolve that problem. ZFS is at the moment highly active copying data from several volumes to another. Operating system: 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue Dec 17 19:02:10 CET 2013 amd64 In one terminal I exported the pool in question and tried to list it via zpool import. But the this command sequence locks up the terminal for an hour up! In another terminal I tried to issue to command zpool status to watch the status of the pools (I have several). But this terminal ist alos locked up right now! What is wrong here? I had such an issue in 10.0-CURRENT as well. It seems ZFS is locking everything up and can only be brought back by a hard reset! What is going on? Why is zpool locking up in trying to display a label-scrambled pool while the zpool status is then also locked up, but latter is supposed to show the status of the other, healthy pools? This reminds me of single-threaded tools which looks up every operation consecutively issued after the blocking command. How is this to be solved? Oliver signature.asc Description: PGP signature
Re: ZFS/zpool command blocks ... locking up all terminals
On 2013-12-20 05:55, O. Hartmann wrote: I have a faulty pool with an ambiguous label and I tried to resolve that problem. ZFS is at the moment highly active copying data from several volumes to another. Operating system: 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue Dec 17 19:02:10 CET 2013 amd64 In one terminal I exported the pool in question and tried to list it via zpool import. But the this command sequence locks up the terminal for an hour up! In another terminal I tried to issue to command zpool status to watch the status of the pools (I have several). But this terminal ist alos locked up right now! What is wrong here? I had such an issue in 10.0-CURRENT as well. It seems ZFS is locking everything up and can only be brought back by a hard reset! What is going on? Why is zpool locking up in trying to display a label-scrambled pool while the zpool status is then also locked up, but latter is supposed to show the status of the other, healthy pools? This reminds me of single-threaded tools which looks up every operation consecutively issued after the blocking command. How is this to be solved? Oliver Can you input 'control + t' or otherwise send siginfo to see what run 'state' zpool is in? This usually consists of the ZFS function name and is often very revealing and gives a starting point for investigation -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: [Xen-devel] [PATCH v7 01/19] xen: add PV/PVH kernel entry point
On 12/19/2013 06:54 PM, Roger Pau Monne wrote:
Add the PV/PVH entry point and the low level functions for PVH
initialization.
---
sys/amd64/amd64/locore.S | 53 +++
sys/amd64/amd64/machdep.c| 72 ++
sys/amd64/include/asmacros.h | 26 +++
sys/i386/xen/xen_machdep.c |2 +
sys/x86/xen/hvm.c|1 +
sys/xen/xen-os.h |4 ++
6 files changed, 158 insertions(+), 0 deletions(-)
[..]
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index eae657b..a73e33e 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -146,10 +146,17 @@ __FBSDID($FreeBSD$);
#include isa/isareg.h
#include isa/rtc.h
+#ifdef XENHVM
+#include xen/xen-os.h
+#endif
+
/* Sanity check for __curthread() */
CTASSERT(offsetof(struct pcpu, pc_curthread) == 0);
extern u_int64_t hammer_time(u_int64_t, u_int64_t);
+#ifdef XENHVM
+extern u_int64_t hammer_time_xen(start_info_t *, u_int64_t);
+#endif
extern void printcpuinfo(void); /* XXX header file */
extern void identify_cpu(void);
@@ -1683,6 +1690,71 @@ do_next:
msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);
}
+#ifdef XENHVM
+/*
+ * First function called by the Xen PVH boot sequence.
+ *
+ * Set some Xen global variables and prepare the environment so it is
+ * as similar as possible to what native FreeBSD init function expects.
+ */
+u_int64_t
+hammer_time_xen(start_info_t *si, u_int64_t xenstack)
+{
+ u_int64_t physfree;
+ u_int64_t *PT4 = (u_int64_t *)xenstack;
+ u_int64_t *PT3 = (u_int64_t *)(xenstack + PAGE_SIZE);
+ u_int64_t *PT2 = (u_int64_t *)(xenstack + 2 * PAGE_SIZE);
+ int i;
+
+ KASSERT((si != NULL xenstack != 0),
+ (invalid start_info or xenstack));
If I'm not mistaken, the user won't see the error if the assert failed
(the console is not yet initialized). Perhaps xc_printf is more suitable
here.
--
Julien Grall
___
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: 10-RC2 current wireless link aggregation not working correctly
Hi! On 20 December 2013 01:52, dan_partelly dan_parte...@rdsor.ro wrote: Guys, Id like to work a bit on this issue in my free time, I have 2 weeks holiday after Xmass. First an update on lagg for the case you boot with wired coupled: 1. I previously said lagg0 switches correctly when I unplug the wired interface, but it is not so. It appeared so because I used ifconfig and listed all interfaces. If I do a ifconfig lagg0 specifically the network activity DOES NOT resume, and the output shows that the interface was not switched. 2. network activity resumes when you specifically do ifconfig bge0 ( master wired). Hm. Well, doing an ifconfig bge0 will likely do a bunch of queries to the NIC to figure out what the current link status is. I bet what's happening is that the link status isn't being updated correctly, so lagg doesn't flip over. Second: 1. Please tell me if one of the developers made on their personal pages a intro how to set up a solid kernel development intro. It would save me a lot of time considering I never set up such an environment for any Unix like OS. I only worked in kernel development for NT and later derived kernels. I can allocate two core 2 machines for this task , with fire-wire, USN and Ethernet connectivity 2. Any other resources which you can come up from your head which I can print and read are also appreciated. Have a read of the FreeBSD handbook: https://www.freebsd.org/doc/handbook/ And if you have questions about the networking side of things, please don't hesitate to email the list(s). We can turn whatever question/answers you have into a chapter or two in the handbook. -a Dan On Tue, 17 Dec 2013 12:11:49 -0800, Adrian Chadd adrian.ch...@gmail.com wrote: Ive no idea sorry. Its likely an ifnet change and not anything WiFi specific. :( On Dec 17, 2013 12:04 PM, dan_partelly wrote: Yes, this is correct. A simple list of the interfaces with ifconfig makes the system recover and restart activity on the secondary port. Its a good starting point to hunt down the problem. One of the ioctls sent has this side effect. Dan If I am am understanding correctly, Dan and Nikolai say that just running ifconfig brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldnt be changing anything. ___ freebsd-current@freebsd.org [2] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current [3] To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org [4] Links: -- [1] mailto:dan_parte...@rdsor.ro [2] mailto:freebsd-current@freebsd.org [3] http://lists.freebsd.org/mailman/listinfo/freebsd-current [4] mailto: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: md2 on current and 10.
On 2013-12-20 01:44, Mikhail T. wrote: It would appear, neither md2.h nor openssl/md2.h are any longer available on FreeBSD current and 10.x This breaks the devel/tcl-trf port, which I maintain... Could someone, please, comment? Should I patch-up the port to disable the functionality? Or?.. Thank you! -mi Hm the config script tests for md2 and sha1 ... What happens if md2 support is removed from the code? Btw. This issue already exists for a longer time if openssl from ports is in use. http://svnweb.freebsd.org/ports?view=revisionrevision=252255 -- Regards, olli ___ 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: ZFS/zpool command blocks ... locking up all terminals
On Fri, Dec 20, 2013 at 3:55 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I have a faulty pool with an ambiguous label and I tried to resolve that problem. ZFS is at the moment highly active copying data from several volumes to another. Operating system: 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue Dec 17 19:02:10 CET 2013 amd64 In one terminal I exported the pool in question and tried to list it via zpool import. But the this command sequence locks up the terminal for an hour up! In another terminal I tried to issue to command zpool status to watch the status of the pools (I have several). But this terminal ist alos locked up right now! What is wrong here? I had such an issue in 10.0-CURRENT as well. It seems ZFS is locking everything up and can only be brought back by a hard reset! What is going on? Why is zpool locking up in trying to display a label-scrambled pool while the zpool status is then also locked up, but latter is supposed to show the status of the other, healthy pools? This reminds me of single-threaded tools which looks up every operation consecutively issued after the blocking command. How is this to be solved? Sounds like a deadlock. Did the zpool export complete successfully? Did the pool become suspended at any point? Can you get to the kernel debugger? Most importantly, can you reproduce it? If you can, you'll probably need a WITNESS enabled kernel to get any useful info. When I find a deadlock, I usually go into the kernel debugger and issue the following commands. It results in about a megabyte of output, so use screen or tmux or something to capture the output x/s version show msginfo ps alltrace show alllocks # You need witness for this one -Alan Oliver ___ 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: md2 on current and 10.
On 2013-12-20 19:04, Mikhail T. wrote: On 20.12.2013 12:52, olli hauer wrote: Hm the config script tests for md2 and sha1 ... What happens if md2 support is removed from the code? Yes, the md2 can be removed from the set of digests made available by the port -- that's not a problem. What I wanted to know, was why? Maybe, the header files should've been replaced with ones containing an #error (like malloc.h was)... Oh well... -mi md2 was deprecated in 2009 by the openssl project http://cvs.openssl.org/chngview?cn=18381 CVE-2009-2409 As fas as I know some Linux based projects have removed md2 from openssl-0.9.x in 2009. I have no answer why FreeBSD 8/9 has the old openssl-0.9.8y and md2 support was not removed. -- olli ___ 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: md2 on current and 10.
On 20.12.2013 12:52, olli hauer wrote: Hm the config script tests for md2 and sha1 ... What happens if md2 support is removed from the code? Yes, the md2 can be removed from the set of digests made available by the port -- that's not a problem. What I wanted to know, was why? Maybe, the header files should've been replaced with ones containing an #error (like malloc.h was)... Oh well... -mi ___ 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: buildworld error (tcpdump and Capsicum)
ping ! ___ 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: ZFS/zpool command blocks ... locking up all terminals
On Fri, 20 Dec 2013 11:23:25 -0700 Alan Somers asom...@freebsd.org wrote: On Fri, Dec 20, 2013 at 3:55 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I have a faulty pool with an ambiguous label and I tried to resolve that problem. ZFS is at the moment highly active copying data from several volumes to another. Operating system: 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue Dec 17 19:02:10 CET 2013 amd64 In one terminal I exported the pool in question and tried to list it via zpool import. But the this command sequence locks up the terminal for an hour up! In another terminal I tried to issue to command zpool status to watch the status of the pools (I have several). But this terminal ist alos locked up right now! What is wrong here? I had such an issue in 10.0-CURRENT as well. It seems ZFS is locking everything up and can only be brought back by a hard reset! What is going on? Why is zpool locking up in trying to display a label-scrambled pool while the zpool status is then also locked up, but latter is supposed to show the status of the other, healthy pools? This reminds me of single-threaded tools which looks up every operation consecutively issued after the blocking command. How is this to be solved? Sounds like a deadlock. Did the zpool export complete successfully? No, it didn't, it is now stuck for ~ 8 hours. As well as zpool status. Did the pool become suspended at any point? Can you get to the The pools not exported are under heavy load at the moment (two further pools). The pool exported isn't to be checked - I can't check the status since the command is blocking. kernel debugger? Most importantly, can you reproduce it? If you can, you'll probably need a WITNESS enabled kernel to get any useful info. I regret, I have no debugging kernel on this machine. The question regarding the fact whether the problem is reproducable is unanswered since I have no chance at this moment to try the procedure under the very same conditions. I once realised the same behaviour in 10.0-CURRENT three months ago. I do not recall the exact conditions. What I do recall is, that after all operations on any pool has finished, the deadlock released. At this moment, I try to copy ~ 4TB data from a pool (RAIDZ-0) to an external drive (via USB 3.0, also a ZFS pool). That takes hours and I suspect the deadlock will last that long until the copying is finished. But it is scaring, that a single faulty command can block all further operations of ZFS/zpool even on different pools. When I find a deadlock, I usually go into the kernel debugger and issue the following commands. It results in about a megabyte of output, so use screen or tmux or something to capture the output x/s version show msginfo ps alltrace show alllocks # You need witness for this one I try this later after the backup is gone through. Thank you very much. Oliver -Alan Oliver ___ 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 signature.asc Description: PGP signature
nanobsd build failure 'WITHOUT_CASPER=YES' r259661 and earlier
When using 'WITHOUT_CAPSICUM=YES', 'WITHOUT_CASPER=YES' my nanobsd builds in a Virtualbox VM (i386, march=geode, GENERIC without debug+Witness et. al.) fail buildworld for any revision from at least r259518-r259661; like so (this example is r259661): ... === lib/clang/libllvmsupport (obj,depend,all,install) /usr/obj/nanobsd.sstream//usr/src/tmp/usr/src/lib/clang/libllvmsupport created for /usr/src/lib/clang/libllvmsupport rm -f .depend mkdep -f .depend -a -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/includ e -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/in clude -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\i386-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -DNDEBUG -I/usr/obj/nanobsd.sstream//usr/src/tmp/legacy/usr/include -std=gnu99 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConvertU TF.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regcomp. c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regerror .c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regexec. c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regfree. c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regstrlc py.c mkdep -f .depend -a -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/includ e -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/in clude -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\i386-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -DNDEBUG -I/usr/obj/nanobsd.sstream//usr/src/tmp/legacy/usr/include /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat. cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSInt.c pp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Allocato r.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Atomic.c pp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/BlockFre quency.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/BranchPr obability.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CommandL ine.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Constant Range.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConvertU TFWrapper.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CrashRec overyContext.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DAGDelta Algorithm.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debug.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DeltaAlg orithm.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwarf.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DynamicL ibrary.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Errno.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ErrorHan dling.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FileOutp utBuffer.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FoldingS et.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Formatte dStream.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/GraphWri ter.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Hashing. cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Host.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IncludeF ile.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IntEqCla sses.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Interval Map.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Intrusiv eRefCntPtr.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IsInf.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IsNAN.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Locale.c pp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/LockFile Manager.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ManagedS tatic.cpp
Re: buildworld error (tcpdump and Capsicum)
Index: addrtoname.c === --- addrtoname.c (revision 259658) +++ addrtoname.c (working copy) @@ -33,9 +33,11 @@ #endif #ifdef __FreeBSD__ +#ifdef HAVE_LIBCAPSICUM #include libcapsicum.h #include libcapsicum_dns.h #endif +#endif #include tcpdump-stdinc.h #ifdef USE_ETHER_NTOHOST ___ 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: nanobsd build failure 'WITHOUT_CASPER=YES' r259661 and earlier
Hi, Please file a PR and then ask the developer (pjd@) very nicely to take a look at it. Thanks, -adrian On 20 December 2013 12:45, Stefan Hegnauer stefan.hegna...@gmx.ch wrote: When using 'WITHOUT_CAPSICUM=YES', 'WITHOUT_CASPER=YES' my nanobsd builds in a Virtualbox VM (i386, march=geode, GENERIC without debug+Witness et. al.) fail buildworld for any revision from at least r259518-r259661; like so (this example is r259661): ... === lib/clang/libllvmsupport (obj,depend,all,install) /usr/obj/nanobsd.sstream//usr/src/tmp/usr/src/lib/clang/libllvmsupport created for /usr/src/lib/clang/libllvmsupport rm -f .depend mkdep -f .depend -a -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/includ e -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/in clude -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\i386-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -DNDEBUG -I/usr/obj/nanobsd.sstream//usr/src/tmp/legacy/usr/include -std=gnu99 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConvertU TF.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regcomp. c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regerror .c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regexec. c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regfree. c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regstrlc py.c mkdep -f .depend -a -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/includ e -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/in clude -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\i386-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -DNDEBUG -I/usr/obj/nanobsd.sstream//usr/src/tmp/legacy/usr/include /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat. cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSInt.c pp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Allocato r.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Atomic.c pp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/BlockFre quency.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/BranchPr obability.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CommandL ine.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Constant Range.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConvertU TFWrapper.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CrashRec overyContext.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DAGDelta Algorithm.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debug.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DeltaAlg orithm.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwarf.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DynamicL ibrary.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Errno.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ErrorHan dling.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FileOutp utBuffer.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FoldingS et.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Formatte dStream.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/GraphWri ter.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Hashing. cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Host.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IncludeF ile.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IntEqCla sses.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Interval Map.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Intrusiv eRefCntPtr.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IsInf.cp p /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IsNAN.cp p
Re: md2 on current and 10.
Thinking more about the MD2, I'd say, FreeBSD should not have removed the algorithm. Although no longer deemed sufficiently secure, it is still in use and people using it on FreeBSD-8.x and 9.x today may wish to continue doing so after upgrading to 10.x In the old Mechanism vs. Policy debate http://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy we erred on the side of policy and it does not seem right... Whether or not to use MD2 is (or should be) left up to the users of FreeBSD. Even if OpenSSL no longer provides it, libmd should continue to. In other words, /if you like your digest algorithm, you can keep it/. Yours, -mi ___ 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
PR bin/185052 filed (was: RE: nanobsd build failure 'WITHOUT_CASPER=YES' r259661 and earlier)
Hi there, thanks for your support. PR 185052 is filed and should be visible soon - please let me know if I can help in any way (more info, testing, whatever). Thanks again Stefan From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Friday, December 20, 2013 9:52 PM To: Stefan Hegnauer Cc: freebsd-current Subject: Re: nanobsd build failure 'WITHOUT_CASPER=YES' r259661 and earlier Hi, Please file a PR and then ask the developer (pjd@) very nicely to take a look at it. Thanks, -adrian On 20 December 2013 12:45, Stefan Hegnauer stefan.hegna...@gmx.ch wrote: When using 'WITHOUT_CAPSICUM=YES', 'WITHOUT_CASPER=YES' my nanobsd builds in a Virtualbox VM (i386, march=geode, GENERIC without debug+Witness et. al.) fail buildworld for any revision from at least r259518-r259661; like so (this example is r259661): ... === lib/clang/libllvmsupport (obj,depend,all,install) /usr/obj/nanobsd.sstream//usr/src/tmp/usr/src/lib/clang/libllvmsupport created for /usr/src/lib/clang/libllvmsupport snip - see PR for details ... make: stopped in /usr/src Note that this is with PMAKE=-j1, i.e. single threaded build (same happens with standard PMAKE=-j3 but slightly less intuitive to see where it fails) Removing WITHOUT_CASPER=YES in the build instructions cures the problem (!), however I fail to see why I should include it for an embedded device (pcengines.ch Alix boards, several different versions). Also, with the error reported above I have the impression it is not exactly intuitive that you have to include CASPER (and not CAPSICUM) to eliminate the failure? Any pointers/hints/solutions? Sorry for the rant thanks Stefan ___ 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
