Re: kern/155160: [aesni] AES-NI breaks OpenSSL client calls

2011-03-03 Thread Hans Duedal
The following reply was made to PR kern/155160; it has been noted by GNATS.

From: Hans Duedal 
To: bug-follo...@freebsd.org, h...@onlinecity.dk
Cc:  
Subject: Re: kern/155160: [aesni] AES-NI breaks OpenSSL client calls
Date: Thu, 3 Mar 2011 11:13:17 +0100

 The patch from http://svn.freebsd.org/viewvc/base?view=revision&revision=219178
 / http://www.freebsd.org/cgi/query-pr.cgi?pr=155118 fixes the problem.
 Thank you!
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


misc/155228: security/nss unbuildable on powerpc64

2011-03-03 Thread Nathan Whitehorn

>Number: 155228
>Category:   misc
>Synopsis:   security/nss unbuildable on powerpc64
>Confidential:   no
>Severity:   non-critical
>Priority:   medium
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 03 14:50:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Nathan Whitehorn
>Release:9.0-CURRENT
>Organization:
>Environment:
FreeBSD anacreon.physics.wisc.edu 9.0-CURRENT FreeBSD 9.0-CURRENT #24 r218824: 
Fri Feb 18 18:20:52 CST 2011 
r...@anacreon.physics.wisc.edu:/usr/obj/usr/src/sys/ANACREON  powerpc
>Description:
In mozilla/security/coreconf/arch.mk, line 69, it assumes that uname -m returns 
the architecture value instead of MACHINE, making it unbuildable on platforms 
where these differ (pc98, powerpc64, sun4v).
>How-To-Repeat:

>Fix:
Changing uname -m to uname -p fixes the build.

>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


kern/155227: netflow.c does not compile with disabled INET6

2011-03-03 Thread Dmitry Afanasiev

>Number: 155227
>Category:   kern
>Synopsis:   netflow.c does not compile with disabled INET6
>Confidential:   no
>Severity:   serious
>Priority:   medium
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 03 14:50:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Dmitry Afanasiev
>Release:9.0-CURRENT
>Organization:
>Environment:
FreeBSD orion 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Wed Mar  2 12:54:04 MSK 2011  
   root@orion:/usr/obj/usr/src/sys/orion  amd64

>Description:
sys/netgraph/netflow/netflow.c does not compile with disabled INET6:
mno-sse -mno-sse2 -mno-sse3  -msoft-float -fno-asynchronous-unwind-tables 
-ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -c 
/usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c
/usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c: In 
function 'expire_flow':
/usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c:286: 
error: 'struct netflow' has no member named 'zone6'
/usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c:301: 
error: 'struct netflow' has no member named 'zone6'
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error

>How-To-Repeat:
1. Update to r219182
2. Disable INET6
3. Build kernel
>Fix:


Patch attached with submission follows:

--- netflow.c.orig  2011-03-03 16:36:00.895086339 +0300
+++ netflow.c   2011-03-03 16:37:32.335079030 +0300
@@ -282,8 +282,10 @@
atomic_add_32(&priv->info.nfinfo_export9_failed, 1);
if (version == IPVERSION)
uma_zfree_arg(priv->zone, fle, priv);
+#ifdef INET6
else if (version == IP6VERSION)
uma_zfree_arg(priv->zone6, fle, priv);
+#endif
else
panic("ng_netflow: Unknown IP proto: %d", 
version);
return;
@@ -297,8 +299,10 @@
 
if (version == IPVERSION)
uma_zfree_arg(priv->zone, fle, priv);
+#ifdef INET6
else if (version == IP6VERSION)
uma_zfree_arg(priv->zone6, fle, priv);
+#endif
 }
 
 /* Get a snapshot of node statistics */


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


Re: kern/155227: netflow.c does not compile with disabled INET6

2011-03-03 Thread bz
Synopsis: netflow.c does not compile with disabled INET6

Responsible-Changed-From-To: freebsd-bugs->bz
Responsible-Changed-By: bz
Responsible-Changed-When: Thu Mar 3 15:02:13 UTC 2011
Responsible-Changed-Why: 
I noticed last night and am waiting for compiles to finish to commit
the fix.

http://www.freebsd.org/cgi/query-pr.cgi?pr=155227
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


Re: ports/155228: [patch] security/nss unbuildable on powerpc64

2011-03-03 Thread linimon
Old Synopsis: security/nss unbuildable on powerpc64
New Synopsis: [patch] security/nss unbuildable on powerpc64

Responsible-Changed-From-To: freebsd-bugs->gnome
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Mar 3 16:50:57 UTC 2011
Responsible-Changed-Why: 
Make this a ports PR and assign.

http://www.freebsd.org/cgi/query-pr.cgi?pr=155228
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


Re: kern/133246: commit references a PR

2011-03-03 Thread dfilter service
The following reply was made to PR kern/133246; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/133246: commit references a PR
Date: Thu,  3 Mar 2011 17:12:43 + (UTC)

 Author: jh
 Date: Thu Mar  3 17:12:24 2011
 New Revision: 219237
 URL: http://svn.freebsd.org/changeset/base/219237
 
 Log:
   MFC r216489:
   
   If dlclose() is called recursively from a _fini() function, the inner
   dlclose() call may unload the object of the outer call prematurely
   because objects are unreferenced before _fini() calls.
   
   Fix this by unreferencing objects after calling objlist_call_fini() in
   dlclose(). Therefore objlist_call_fini() now calls the fini function if
   the reference count of an object is 1. In addition we must restart the
   list_fini traversal after every _fini() call because another dlclose()
   call might have modified the reference counts.
   
   Add an XXX comment to objlist_call_fini() about possible race with
   dlopen().
   
   PR:  133246, 149464
 
 Modified:
   stable/8/libexec/rtld-elf/rtld.c
 Directory Properties:
   stable/8/libexec/rtld-elf/   (props changed)
 
 Modified: stable/8/libexec/rtld-elf/rtld.c
 ==
 --- stable/8/libexec/rtld-elf/rtld.c   Thu Mar  3 17:11:11 2011
(r219236)
 +++ stable/8/libexec/rtld-elf/rtld.c   Thu Mar  3 17:12:24 2011
(r219237)
 @@ -107,7 +107,7 @@ static int load_needed_objects(Obj_Entry
  static int load_preload_objects(void);
  static Obj_Entry *load_object(const char *, const Obj_Entry *, int);
  static Obj_Entry *obj_from_addr(const void *);
 -static void objlist_call_fini(Objlist *, bool, int *);
 +static void objlist_call_fini(Objlist *, Obj_Entry *, int *);
  static void objlist_call_init(Objlist *, int *);
  static void objlist_clear(Objlist *);
  static Objlist_Entry *objlist_find(Objlist *, const Obj_Entry *);
 @@ -1616,36 +1616,56 @@ obj_from_addr(const void *addr)
  
  /*
   * Call the finalization functions for each of the objects in "list"
 - * which are unreferenced.  All of the objects are expected to have
 - * non-NULL fini functions.
 + * belonging to the DAG of "root" and referenced once. If NULL "root"
 + * is specified, every finalization function will be called regardless
 + * of the reference count and the list elements won't be freed. All of
 + * the objects are expected to have non-NULL fini functions.
   */
  static void
 -objlist_call_fini(Objlist *list, bool force, int *lockstate)
 +objlist_call_fini(Objlist *list, Obj_Entry *root, int *lockstate)
  {
 -Objlist_Entry *elm, *elm_tmp;
 +Objlist_Entry *elm;
  char *saved_msg;
  
 +assert(root == NULL || root->refcount == 1);
 +
  /*
   * Preserve the current error message since a fini function might
   * call into the dynamic linker and overwrite it.
   */
  saved_msg = errmsg_save();
 -STAILQ_FOREACH_SAFE(elm, list, link, elm_tmp) {
 -  if (elm->obj->refcount == 0 || force) {
 +do {
 +  STAILQ_FOREACH(elm, list, link) {
 +  if (root != NULL && (elm->obj->refcount != 1 ||
 +objlist_find(&root->dagmembers, elm->obj) == NULL))
 +  continue;
dbg("calling fini function for %s at %p", elm->obj->path,
(void *)elm->obj->fini);
LD_UTRACE(UTRACE_FINI_CALL, elm->obj, (void *)elm->obj->fini, 0, 0,
elm->obj->path);
/* Remove object from fini list to prevent recursive invocation. */
STAILQ_REMOVE(list, elm, Struct_Objlist_Entry, link);
 +  /*
 +   * XXX: If a dlopen() call references an object while the
 +   * fini function is in progress, we might end up trying to
 +   * unload the referenced object in dlclose() or the object
 +   * won't be unloaded although its fini function has been
 +   * called.
 +   */
wlock_release(rtld_bind_lock, *lockstate);
call_initfini_pointer(elm->obj, elm->obj->fini);
*lockstate = wlock_acquire(rtld_bind_lock);
/* No need to free anything if process is going down. */
 -  if (!force)
 +  if (root != NULL)
free(elm);
 +  /*
 +   * We must restart the list traversal after every fini call
 +   * because a dlclose() call from the fini function or from
 +   * another thread might have modified the reference counts.
 +   */
 +  break;
}
 -}
 +} while (elm != NULL);
  errmsg_restore(saved_msg);
  }
  
 @@ -1833,7 +1853,7 @@ rtld_exit(void)
  
  lockstate = wlock_acquire(rtld_bind_lock);
  dbg("rtld_exit()");
 -objlist_call_fini(&list_fini, true, &lockstate);
 +objlist_call_fini(&list_fini, NULL, &lockstate);
  /* No need to remove the items from the list, since we are exiting. */
  if (!libmap_disable)

Re: bin/145230: mtree(8) -P is broken because l* functions aren't being used

2011-03-03 Thread jh
Synopsis: mtree(8) -P is broken because l* functions aren't being used

State-Changed-From-To: feedback->closed
State-Changed-By: jh
State-Changed-When: Thu Mar 3 17:22:27 UTC 2011
State-Changed-Why: 
Feedback timeout. Seems to be duplicate of bin/50949.

http://www.freebsd.org/cgi/query-pr.cgi?pr=145230
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


kern/155238: 20 minute time jumps in VirtualBox

2011-03-03 Thread Martin Birgmeier

>Number: 155238
>Category:   kern
>Synopsis:   20 minute time jumps in VirtualBox
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 03 20:30:08 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Martin Birgmeier
>Release:8.2, HEAD
>Organization:
MBi at home
>Environment:
FreeBSD v902.xyzzy 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Sun Feb 20 19:23:23 CET 
2011 
root@v902.xyzzy:/.../hal/z/OBJ/FreeBSD/i386/RELENG_8_2_0_RELEASE/src/sys/XYZZY_SMP
  i386

FreeBSD v903.xyzzy 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Sun Jan 30 13:12:33 CET 
2011 
root@v903.xyzzy:/usr/obj/.../hal/z/SRC/FreeBSD/HEAD/src/sys/XYZZY_SMP_NA  amd64
>Description:
I am running several versions of FreeBSD under VirtualBox, on a 4-core AMD box 
running FreeBSD 8.2 amd64.

Since recently, and I believe since installing 8.2, every few minutes the time 
in the vbox clients jumps by exactly 20 minutes like this (hal is the host, the 
v90x are the vbox clients):

[0]# rdate -p hal ; date
Thu Mar  3 19:36:27 2011
Thu Mar  3 19:36:27 CET 2011
[0]# rdate -p hal ; date
Thu Mar  3 19:44:06 2011
Thu Mar  3 19:44:06 CET 2011
[0]# rdate -p hal ; date
Thu Mar  3 20:09:14 2011
Thu Mar  3 20:29:14 CET 2011 <=== jump by 20 minutes
[0]# date ; rdate hal   
Thu Mar  3 20:29:16 CET 2011 <=== manual reset using rdate
Thu Mar  3 20:09:16 2011
[0]# date ; rdate hal
Thu Mar  3 20:43:58 CET 2011
Thu Mar  3 20:43:59 2011

or this:

[0]# rdate -p hal ; date
Thu Mar  3 20:57:44 2011
Thu Mar  3 20:57:43 CET 2011
[0]# rdate -p hal ; date
Thu Mar  3 20:58:31 2011
Thu Mar  3 21:18:30 CET 2011 <=== jump
[0]# date ; rdate hal
Thu Mar  3 21:18:34 CET 2011 <=== manual reset
Thu Mar  3 20:58:35 2011
[0]# rdate -p hal ; date
Thu Mar  3 21:00:49 2011
Thu Mar  3 21:00:49 CET 2011
[0]# rdate -p hal ; date
Thu Mar  3 21:05:31 2011
Thu Mar  3 21:25:31 CET 2011 <=== jump
[0]# date ; rdate hal   
Thu Mar  3 21:25:37 CET 2011 <=== manual reset
Thu Mar  3 21:05:37 2011
[0]# date ; rdate hal
Thu Mar  3 21:08:12 CET 2011
Thu Mar  3 21:08:13 2011

This does not seem to happen on the 7.4 client which is also running at the 
same time as the two others (HEAD, 8.2).

Previously (and I believe even now), if the host was very busy, the clients 
would simply lag behind the host, and I could use rdate to set them forward 
again. But these exact 20 minute jumps are a completely new experience and 
rather annoying.

Btw., if I remember correctly, they also accumulate: If I do not manually reset 
the time, after a longer while I will have the clock 40 minutes into the 
future, etc.
>How-To-Repeat:
Run HEAD or 8.2 in VirtualBox, observe the time.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


Re: gnu/138983: [binutils] System binutils too old for modern CPUs

2011-03-03 Thread Dimitry Andric

On 2011-02-18 22:23, arun...@freebsd.org wrote:

In r218822 binutils-2.17 got commited to HEAD.


Andrei, I think it's fairly safe to say that binutils 2.17 will probably
not be MFC'd to -STABLE (never say never :), but it is now committed to
HEAD, and it supports quite a lot of newer CPU features, up to SSE 4.2.

So shall we close this PR now?
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


Re: kern/155238: 20 minute time jumps in VirtualBox

2011-03-03 Thread linimon
Synopsis: 20 minute time jumps in VirtualBox

Responsible-Changed-From-To: freebsd-bugs->freebsd-emulation
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Mar 4 02:18:30 UTC 2011
Responsible-Changed-Why: 
Not really sure how to classify this one, so make a random guess.  If
anyone from -emulation has any insight, please submit a followup.  Thanks.

http://www.freebsd.org/cgi/query-pr.cgi?pr=155238
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


Re: kern/155160: [aesni] AES-NI breaks OpenSSL client calls

2011-03-03 Thread linimon
Synopsis: [aesni] AES-NI breaks OpenSSL client calls

State-Changed-From-To: feedback->closed
State-Changed-By: linimon
State-Changed-When: Fri Mar 4 06:04:34 UTC 2011
State-Changed-Why: 
Apparently fixed by the most recent commit to this file.

http://www.freebsd.org/cgi/query-pr.cgi?pr=155160
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"