Re: [PATCH v7 04/19] amd64: introduce hook for custom preload metadata parsers

[Konstantin Belousov]

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

[dan_partelly]

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 
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

[O. Hartmann]

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

[Allan Jude]

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

[Julien Grall]

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 
  #include 

+#ifdef XENHVM
+#include 
+#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

[Adrian Chadd]

Hi!

On 20 December 2013 01:52, dan_partelly  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 
> 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.

[olli hauer]

On 2013-12-20 01:44, Mikhail T. wrote:
> It would appear, neither  nor  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=revision&revision=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

[Alan Somers]

On Fri, Dec 20, 2013 at 3:55 AM, 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?

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.

[olli hauer]

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.

[Mikhail T.]

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)

[dt71]

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

[O. Hartmann]

On Fri, 20 Dec 2013 11:23:25 -0700
Alan Somers  wrote:

> On Fri, Dec 20, 2013 at 3:55 AM, 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?
> 
> 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

[Stefan Hegnauer]

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
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib

Re: buildworld error (tcpdump and Capsicum)

[dt71]

Index: addrtoname.c
===
--- addrtoname.c	(revision 259658)
+++ addrtoname.c	(working copy)
@@ -33,9 +33,11 @@
 #endif
 
 #ifdef __FreeBSD__
+#ifdef HAVE_LIBCAPSICUM
 #include 
 #include 
 #endif
+#endif
 #include 
 
 #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

[Adrian Chadd]

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  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/libllv

Re: md2 on current and 10.

[Mikhail T.]

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
 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)

[Stefan Hegnauer]

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 
> 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"