nginx报错 &readv() failed (104: Connection reset by peer)& 解决方法 - 为程序员服务
为程序员服务
nginx报错 &readv() failed (104: Connection reset by peer)& 解决方法
nginx错误日志中出现"Connection reset by peer" ：
[error] readv() failed (104: Connection reset by peer) while reading upstream, client: x.x.x.x, server: host.tld, request: &POST /script.php, ...
出现这种情况可能是因为php的配置参数导致php进程意外终止了：
max_input_time = ...
max_execution_time = ...
建议增大这两个参数的值。另外PHP-FPM有一个request_terminate_timeout的参数，这个参数可以设定当php进程终止时请求的等待时长。你可以在php-fpm.conf中将这个参数的值设定为600:
request_terminate_timeout = 600
您可能的代码
相关聚客文章
相关专栏文章From linimon at FreeBSD.org
1 04:41:49 2011
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Tue Mar
1 04:41:55 2011
Subject: kern/127441: [dtrace] Dtrace timestamp variable is wrapping as
if define as uint32_t
Message-ID:
Synopsis: [dtrace] Dtrace timestamp variable is wrapping as if define as uint32_t
State-Changed-From-To: open->closed
State-Changed-By: linimon
State-Changed-When: Tue Mar 1 04:40:12 UTC 2011
State-Changed-Why:
Has been MFCed to 7, and 6 is now EOL.
http://www.freebsd.org/cgi/query-pr.cgi?pr=127441
From jcw at speakeasy.net
1 06:07:18 2011
From: jcw at speakeasy.net (Jason C. Wells)
Date: Tue Mar
1 06:07:25 2011
Subject: PR 154709
Applies to 8.2-RELEASE
Message-ID:
PR 154709 also applies to 8.2-RELEASE.
How can I update the PR?
From linimon at lonesome.com
1 06:30:17 2011
From: linimon at lonesome.com (Mark Linimon)
Date: Tue Mar
1 06:30:24 2011
Subject: kern/154709: [heimdal] Kerberos V5 refuses authentication
because Read req failed: ASN.1 encoding ended unexpectedly [regression]
Message-ID:
The following reply was made to PR kern/154709; it has been noted by GNATS.
From: Mark Linimon
To: bug-followup@FreeBSD.org
Subject: Re: kern/154709: [heimdal] Kerberos V5 refuses authentication
because Read req failed: ASN.1 encoding ended unexpectedly [regression]
Date: Tue, 1 Mar :39 -0600
----- Forwarded message from "Jason C. Wells"
Date: Mon, 28 Feb :21 -0800
From: "Jason C. Wells"
To: freebsd-bugs@FreeBSD.org
Subject: PR 154709
Applies to 8.2-RELEASE
PR 154709 also applies to 8.2-RELEASE.
----- End forwarded message -----
From linimon at lonesome.com
1 06:48:42 2011
From: linimon at lonesome.com (Mark Linimon)
Date: Tue Mar
1 06:48:53 2011
Subject: PR 154709
Applies to 8.2-RELEASE
In-Reply-To:
References:
Message-ID:
The canonical way is to send a message to bug-followup@FreeBSD.org (the
address of GNATS) -- not freebsd-bugs@ which is just a mailing list --
with the following Subject:
Subject: Re: kern/154709: (more text)
The "(more text)" part is optional, but GNATS matches exactly on the
string parts before that.
There's also a link at the bottom of the web form for "submit followup".
I'll just go ahead and forward this message to it for you for now.
(Also, you can always email bugmeister@FreeBSD.org if you are having
trouble with the PR database.)
From swell.k at gmail.com
1 11:10:10 2011
From: swell.k at gmail.com (Anonymous)
Date: Tue Mar
1 11:10:17 2011
Subject: conf/155147: [patch] remove /etc/X11 from mtree
Message-ID:
>Category:
>Synopsis:
[patch] remove /etc/X11 from mtree
>Confidential:
>Severity:
non-critical
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
change-request
>Submitter-Id:
current-users
>Arrival-Date:
Tue Mar 01 11:10:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
FreeBSD 9.0-CURRENT amd64
>Organization:
>Environment:
>Description:
- nothing references it in base system, BSD.x11.dist is gone per r196767
- ports should respect their PREFIX even for config files
- Xserver is capable of running without config file or be configured
via xset(1) + HAL et al nowadays
As POLA was already violated in /head by r196767 I think this "linuxism"
can be removed safely.
>How-To-Repeat:
--- a.diff begins here ---
Index: etc/mtree/BSD.root.dist
===================================================================
--- etc/mtree/BSD.root.dist (revision 219090)
+++ etc/mtree/BSD.root.dist (working copy)
@@ -22,8 +22,6 @@
--- a.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
From swell.k at gmail.com
1 11:20:09 2011
From: swell.k at gmail.com (Anonymous)
Date: Tue Mar
1 11:20:16 2011
Subject: conf/155148: [patch] mark /usr/local as nochange in mtree
Message-ID:
>Category:
>Synopsis:
[patch] mark /usr/local as nochange in mtree
>Confidential:
>Severity:
non-critical
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
change-request
>Submitter-Id:
current-users
>Arrival-Date:
Tue Mar 01 11:20:08 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
FreeBSD 9.0-CURRENT amd64
>Organization:
>Environment:
>Description:
After r196767 /usr/local is governed by ports tree,
i.e. Templates/BSD.local.dist, BSD.gnome.dist, etc.
So, don't try to alter permissions on the directory or issue a warning,
e.g. if it is symlink and points to /dev/null.
>How-To-Repeat:
--- a.diff begins here ---
Index: etc/mtree/BSD.usr.dist
===================================================================
--- etc/mtree/BSD.usr.dist (revision 219090)
+++ etc/mtree/BSD.usr.dist (working copy)
@@ -51,7 +51,7 @@
--- a.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
From swell.k at gmail.com
1 11:40:08 2011
From: swell.k at gmail.com (Anonymous)
Date: Tue Mar
1 11:40:14 2011
Subject: conf/155148: [patch] mark /usr/local as nochange in mtree
Message-ID:
The following reply was made to PR conf/155148; it has been noted by GNATS.
From: Anonymous
To: bug-followup@freebsd.org
Subject: Re: conf/155148: [patch] mark /usr/local as nochange in mtree
Date: Tue, 01 Mar :41 +0300
It's mostly useful for people using LOCALBASE != /usr/local and similar
to r36671 reasoning can be applied to it.
From jcw at speakeasy.net
1 15:12:56 2011
From: jcw at speakeasy.net (Jason C. Wells)
Date: Tue Mar
1 15:13:02 2011
Subject: PR 154709
Applies to 8.2-RELEASE
In-Reply-To:
References:
Message-ID:
On 02/28/11 22:28, Mark Linimon wrote:
> There's also a link at the bottom of the web form for "submit followup".
I knew that if I sent a message that the web team would add a "submit
followup" button the very next day.
And it just happens to be right
where I looked for it yesterday.
Great work team! :)
From eadler at FreeBSD.org
1 15:14:31 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:14:46 2011
Subject: bin/89410: [patch] sh(1) missing \u interpolation and bug/fix
Message-ID:
Synopsis: [patch] sh(1) missing \u interpolation and bug/fix in \W
State-Changed-From-To: open->patched
State-Changed-By: eadler
State-Changed-When: Tue Mar 1 10:14:30 EST 2011
State-Changed-Why:
committed in head
http://www.freebsd.org/cgi/query-pr.cgi?pr=89410
From eadler at FreeBSD.org
1 15:14:33 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:14:46 2011
Subject: conf/96015: uncommenting the msgs invocation in /etc/profile
can fail boot
Message-ID:
Synopsis: uncommenting the msgs invocation in /etc/profile can fail boot
State-Changed-From-To: open->patched
State-Changed-By: eadler
State-Changed-When: Tue Mar 1 10:14:33 EST 2011
State-Changed-Why:
committed in head
http://www.freebsd.org/cgi/query-pr.cgi?pr=96015
From eadler at FreeBSD.org
1 15:14:39 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:15:07 2011
Subject: bin/113398: [libc] [patch] initgroups fails rather than
truncates if number of groups > NGROUPS_MAX meaning the user
can no longer login
Message-ID:
Synopsis: [libc] [patch] initgroups fails rather than truncates if number of groups > NGROUPS_MAX meaning the user can no longer login
State-Changed-From-To: open->closed
State-Changed-By: eadler
State-Changed-When: Tue Mar 1 10:14:38 EST 2011
State-Changed-Why:
committed in head (r194498) but will never be MFCed
http://www.freebsd.org/cgi/query-pr.cgi?pr=113398
From eadler at FreeBSD.org
1 15:14:44 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:15:07 2011
Subject: bin/45193: [patch] truss(1) can't truss itself
Message-ID:
Synopsis: [patch] truss(1) can't truss itself
State-Changed-From-To: patched->closed
State-Changed-By: eadler
State-Changed-When: Tue Mar 1 10:14:43 EST 2011
State-Changed-Why:
This PR is fixed in head, 8.x and 7.x, but will not be merged to 6.x now
that that branch is unsupported, sorry
http://www.freebsd.org/cgi/query-pr.cgi?pr=45193
From eadler at FreeBSD.org
1 15:14:46 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:15:08 2011
Subject: bin/58970: truss(1) coredumps for the no significant reason
Message-ID:
Synopsis: truss(1) coredumps for the no significant reason
State-Changed-From-To: patched->closed
State-Changed-By: eadler
State-Changed-When: Tue Mar 1 10:14:46 EST 2011
State-Changed-Why:
This PR is fixed in head, 8.x and 7.x, but will not be merged to 6.x now
that that branch is unsupported, sorry
http://www.freebsd.org/cgi/query-pr.cgi?pr=58970
From eadler at FreeBSD.org
1 15:15:05 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:15:18 2011
Subject: bin/117966: fdread(1) aborts with EPERM
Message-ID:
Synopsis: fdread(1) aborts with EPERM
State-Changed-From-To: patched->closed
State-Changed-By: eadler
State-Changed-When: Tue Mar 1 10:15:04 EST 2011
State-Changed-Why:
This PR is fixed in head, 8.x and 7.x, but will not be merged to 6.x now
that that branch is unsupported, sorry
http://www.freebsd.org/cgi/query-pr.cgi?pr=117966
From eadler at FreeBSD.org
1 15:15:47 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:15:55 2011
Subject: kern/133867: initgroups(3) Invalid argument
Message-ID:
Synopsis: initgroups(3) Invalid argument
State-Changed-From-To: open->patched
State-Changed-By: eadler
State-Changed-When: Tue Mar 1 10:15:45 EST 2011
State-Changed-Why:
committed in head (r194498)
http://www.freebsd.org/cgi/query-pr.cgi?pr=133867
From eadler at FreeBSD.org
1 15:15:54 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:16:10 2011
Subject: kern/134408: [dtrace] [panic] "opensnoop" DTrace script panics
every time (trace trap 10)
Message-ID:
Synopsis: [dtrace] [panic] "opensnoop" DTrace script panics every time (trace trap 10)
State-Changed-From-To: open->patched
State-Changed-By: eadler
State-Changed-When: Tue Mar 1 10:15:53 EST 2011
State-Changed-Why:
committed in head (r194850)
http://www.freebsd.org/cgi/query-pr.cgi?pr=134408
From hd at onlinecity.dk
1 15:20:08 2011
From: hd at onlinecity.dk (Hans Duedal)
Date: Tue Mar
1 15:20:15 2011
Subject: misc/155160: AES-NI breaks OpenSSL client calls
Message-ID:
>Category:
>Synopsis:
AES-NI breaks OpenSSL client calls
>Confidential:
>Severity:
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
>Submitter-Id:
current-users
>Arrival-Date:
Tue Mar 01 15:20:07 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
Hans Duedal
>Organization:
OnlineCity ApS
>Environment:
FreeBSD db3.gw.ocx.dk 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011
root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
>Description:
When cryptodev and aesni(4) are enabled in FreeBSD 8.2, some clients using OpenSSL can't handshake with SSL servers.
Output of "openssl engine -c -t":
(cryptodev) BSD cryptodev engine
[RSA, DSA, DH, AES-128-CBC]
[ available ]
(dynamic) Dynamic engine loading support
[ unavailable ]
>From dmesg:
CPU: Intel(R) Xeon(R) CPU
@ 2.40GHz (2394.01-MHz K8-class CPU)
Origin = "GenuineIntel"
Id = 0x206c2
Family = 6
Model = 2c
Stepping = 2
Features=0xbfebfbff [shortened]
Features2=0x29ee3ff [shortened]
cryptosoft0:
on motherboard
on motherboard
I followed this article to enable aes-ni: http://translate.google.com/translate?js=n&prev=_t&ie=UTF-8&layout=2&eotf=1&sl=ru&tl=en&u=http%3A%2F%2Fsysadminblog.ru%2Ffreebsd%2F%2F15%2Ffreebsd-aesni-openssl-openvpn.html&act=url
AES-NI gave a 2x performance boost for 1024 and 8192 byte blocks btw.
>How-To-Repeat:
1. Enable cryptodev and aes_ni by adding the following lines to /boot/loader.conf:
aesni_load="YES"
cryptodev_load="YES"
3. Connect to an affected ssl host (most hosts excluding google):
curl -v "https://twitter.com/"
4. Error: "error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac"
Disable aes-ni.
>Release-Note:
>Audit-Trail:
>Unformatted:
From eadler at FreeBSD.org
1 15:22:15 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:22:22 2011
Subject: conf/96015: uncommenting the msgs invocation in /etc/profile
can fail boot
Message-ID:
Synopsis: uncommenting the msgs invocation in /etc/profile can fail boot
Responsible-Changed-From-To: freebsd-bugs->jilles
Responsible-Changed-By: eadler
Responsible-Changed-When: Tue Mar 1 10:22:15 EST 2011
Responsible-Changed-Why:
same as above
http://www.freebsd.org/cgi/query-pr.cgi?pr=96015
From eadler at FreeBSD.org
1 15:22:47 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:22:53 2011
Subject: bin/89410: [patch] sh(1) missing \u interpolation and bug/fix
Message-ID:
Synopsis: [patch] sh(1) missing \u interpolation and bug/fix in \W
Responsible-Changed-From-To: freebsd-bugs->jh
Responsible-Changed-By: eadler
Responsible-Changed-When: Tue Mar 1 10:17:41 EST 2011
Responsible-Changed-Why:
http://www.freebsd.org/cgi/query-pr.cgi?pr=89410
From eadler at FreeBSD.org
1 15:23:06 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:23:25 2011
Subject: kern/133867: initgroups(3) Invalid argument
Message-ID:
Synopsis: initgroups(3) Invalid argument
Responsible-Changed-From-To: freebsd-bugs->brooks
Responsible-Changed-By: eadler
Responsible-Changed-When: Tue Mar 1 10:23:05 EST 2011
Responsible-Changed-Why:
same as above
http://www.freebsd.org/cgi/query-pr.cgi?pr=133867
From eadler at FreeBSD.org
1 15:23:13 2011
From: eadler at FreeBSD.org (eadler@FreeBSD.org)
Date: Tue Mar
1 15:23:36 2011
Subject: kern/134408: [dtrace] [panic] "opensnoop" DTrace script panics
every time (trace trap 10)
Message-ID:
Synopsis: [dtrace] [panic] "opensnoop" DTrace script panics every time (trace trap 10)
Responsible-Changed-From-To: freebsd-bugs->avg
Responsible-Changed-By: eadler
Responsible-Changed-When: Tue Mar 1 10:23:12 EST 2011
Responsible-Changed-Why:
same as above
http://www.freebsd.org/cgi/query-pr.cgi?pr=134408
From lattera at gmail.com
1 17:00:18 2011
From: lattera at gmail.com (Shawn Webb)
Date: Tue Mar
1 17:00:25 2011
Subject: misc/155163: Add Recursive Functionality to setfacl
Message-ID:
>Category:
>Synopsis:
Add Recursive Functionality to setfacl
>Confidential:
>Severity:
non-critical
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
change-request
>Submitter-Id:
current-users
>Arrival-Date:
Tue Mar 01 17:00:17 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
Shawn Webb
>Organization:
>Environment:
FreeBSD shawnwork 8.2-RELEASE FreeBSD 8.2-RELEASE #1 rec1cbd-dirty: Tue Feb 22 15:05:26 MST 2011
shawn@shawnwork:/usr/obj/usr/src/sys/GENERIC
>Description:
The setfacl command is missing recursive functionality. The proposed and attached patch implements said functionality.
Included in the patch is also an enhancement to the -k switch. Solaris allows for zero-number ACL entries on objects stored in ZFS datasets via `chmod A= /path/to/file". FreeBSD does not support zero-number ACL entries so I give owner@ full permissions. This enhancement depends upon another bug report I sent that allows use of ACL sets (read_set, write_set, modify_set, full_set) in ZFS NFSv4 ACLs.
>How-To-Repeat:
Patch included.
Patch attached with submission follows:
diff --git a/bin/setfacl/setfacl.c b/bin/setfacl/setfacl.c
index a0f937c..644
--- a/bin/setfacl/setfacl.c
+++ b/bin/setfacl/setfacl.c
@@ -32,6 +32,8 @@ __FBSDID("$FreeBSD$");
@@ -44,6 +46,8 @@ __FBSDID("$FreeBSD$");
static void add_filename(const char *filename);
static void usage(void);
+static void recurse_directory(char *const *paths, int r_flag, int l_flag, int big_h_flag);
+static acl_t remove_invalid_inherit(const char *path, acl_t acl, int l_flag);
static void
add_filename(const char *filename)
@@ -62,34 +66,112 @@ add_filename(const char *filename)
static void
usage(void)
- fprintf(stderr, "usage: setfacl [-bdhkn] [-a position entries] "
+ fprintf(stderr, "usage: setfacl [-bdhkLnR] [-a position entries] "
"[-m entries] [-M file] [-x entries] [-X file] [file ...]\n");
+static void
+recurse_directory(char *const *paths, int r_flag, int l_flag, int big_h_flag)
+ FTSENT *p, *
+ int fts_options = FTS_NOCHDIR;
+ fts_options |= (l_flag == 1) ? FTS_LOGICAL : FTS_PHYSICAL;
+ if (big_h_flag)
fts_options |= FTS_COMFOLLOW;
+ if (r_flag)
ftsp = fts_open(paths, fts_options, NULL);
if (ftsp == NULL)
chp = fts_children(ftsp, 0);
if (chp == NULL)
while ((p = fts_read(ftsp)) != NULL) {
if (l_flag == 0 && p->fts_info & FTS_D)
else if (l_flag == 1 && p->fts_info & FTS_DP)
add_filename(strdup(p->fts_path));
fts_close(ftsp);
for (i = 0; paths[i] != NULL; i++)
add_filename(paths[i]);
+static acl_t
+remove_invalid_inherit(const char *path, acl_t acl, int l_flag)
+ acl_t acl_
+ int acl_
+ acl_entry_
+ int entry_
+ acl_flagset_
+ acl_get_brand_np(acl, &acl_brand);
+ if (acl_brand != ACL_BRAND_NFS4)
+ if (l_flag == 1) {
if (stat(path, &sb) == -1)
if (lstat(path, &sb) == -1)
+ if (S_ISDIR(sb.st_mode) != 0)
+ acl_new = acl_dup(acl);
+ entry_id = ACL_FIRST_ENTRY;
+ while (acl_get_entry(acl_new, entry_id, &entry) == 1) {
entry_id = ACL_NEXT_ENTRY;
acl_get_flagset_np(entry, &flagset);
if (acl_get_flag_np(flagset, ACL_ENTRY_INHERIT_ONLY)) {
acl_delete_entry(acl_new, entry);
acl_delete_flag_np(flagset, ACL_ENTRY_FILE_INHERIT | ACL_ENTRY_DIRECTORY_INHERIT | ACL_ENTRY_NO_PROPAGATE_INHERIT);
+ return acl_
main(int argc, char *argv[])
+ acl_t acl, acl_
acl_type_t acl_
char filename[PATH_MAX];
- int local_error, carried_error, ch, i, entry_number,
+ int local_error, carried_error, ch, entry_number,
+ int h_flag, r_flag, l_flag, big_h_
struct sf_file *
struct sf_entry *
- const char *fn_
+ char *fn_
+ char **files=NULL;
+ unsigned int numfiles=0;
acl_type = ACL_TYPE_ACCESS;
carried_error = local_error = 0;
- h_flag = have_mask = have_stdin = n_flag = need_mask = 0;
+ h_flag = have_mask = have_stdin = n_flag = need_mask = r_flag = l_flag = big_h_flag = 0;
TAILQ_INIT(&entrylist);
TAILQ_INIT(&filelist);
- while ((ch = getopt(argc, argv, "M:X:a:bdhkm:nx:")) != -1)
+ while ((ch = getopt(argc, argv, "HLRM:X:a:bdhkm:nx:")) != -1)
switch(ch) {
entry = zmalloc(sizeof(struct sf_entry));
@@ -167,6 +249,15 @@ main(int argc, char *argv[])
TAILQ_INSERT_TAIL(&entrylist, entry, next);
r_flag = 1;
l_flag = 1;
big_h_flag = 1;
@@ -189,11 +280,18 @@ main(int argc, char *argv[])
fn_dup = strdup(filename);
if (fn_dup == NULL)
err(1, "strdup() failed");
add_filename(fn_dup);
files = realloc(files, ++numfiles * sizeof(char **));
if (files == NULL)
err(1, "realloc() failed");
files[numfiles-1] = (char *)fn_
files = realloc(files, ++numfiles * sizeof(char **));
files[numfiles-1] = NULL;
for (i = 0; i filename, &sb) == -1) {
warn("%s: stat() failed", file->filename);
carried_error++;
if (acl_type == ACL_TYPE_DEFAULT && S_ISDIR(sb.st_mode) == 0) {
warnx("%s: default ACL may only be set on a directory",
file->filename);
carried_error++;
@@ -220,7 +316,6 @@ main(int argc, char *argv[])
if (acl_type == ACL_TYPE_DEFAULT) {
warnx("%s: there are no default entries "
"in NFSv4 ACLs", file->filename);
carried_error++;
acl_type = ACL_TYPE_NFS4;
@@ -243,7 +338,6 @@ main(int argc, char *argv[])
warn("%s: acl_get_file() failed",
file->filename);
carried_error++;
@@ -254,12 +348,24 @@ main(int argc, char *argv[])
switch(entry->op) {
case OP_ADD_ACL:
acl_backup = entry->
entry->acl = remove_invalid_inherit(file->filename, entry->acl, l_flag);
local_error += add_acl(entry->acl,
entry->entry_number, &acl, file->filename);
if (entry->acl != acl_backup) {
acl_free(entry->acl);
entry->acl = acl_
case OP_MERGE_ACL:
acl_backup = entry->
entry->acl = remove_invalid_inherit(file->filename, entry->acl, l_flag);
local_error += merge_acl(entry->acl, &acl,
file->filename);
if (entry->acl != acl_backup) {
acl_free(entry->acl);
entry->acl = acl_
need_mask = 1;
case OP_REMOVE_EXT:
@@ -267,20 +373,20 @@ main(int argc, char *argv[])
need_mask = 0;
case OP_REMOVE_DEF:
if (acl_type == ACL_TYPE_NFS4) {
warnx("%s: there are no default entries in NFSv4 ACLs; "
"cannot remove", file->filename);
local_error++;
if (acl_delete_def_file(file->filename) == -1) {
warn("%s: acl_delete_def_file() failed",
file->filename);
local_error++;
if (acl_type != ACL_TYPE_NFS4) {
if (acl_delete_def_file(file->filename) == -1) {
warn("%s: acl_delete_def_file() failed",
file->filename);
local_error++;
if (acl_type == ACL_TYPE_DEFAULT)
local_error += remove_default(&acl,
file->filename);
/* FreeBSD does not support a zero amount of ACL entries like Solaris, give owner@ full permissions */
acl_free(acl);
acl = acl_from_text("owner@:full_set::allow");
if (acl_type == ACL_TYPE_DEFAULT)
local_error += remove_default(&acl,
file->filename);
need_mask = 0;
case OP_REMOVE_ACL:
>Release-Note:
>Audit-Trail:
>Unformatted:
From bz at FreeBSD.org
1 17:40:16 2011
From: bz at FreeBSD.org (Bjoern A. Zeeb)
Date: Tue Mar
1 17:40:22 2011
Subject: kern/155165: Zabbadoz.NeT
Message-ID:
>Category:
>Synopsis:
Zabbadoz.NeT
>Confidential:
>Severity:
non-critical
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
>Submitter-Id:
current-users
>Arrival-Date:
Tue Mar 01 17:40:13 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
Bjoern A. Zeeb
>Organization:
>Environment:
>Description:
problem with IPv6 over an IPv6 IPSec tunnel and
TCP on top of that probably related to a sepcial payload size
as it can be mitigated by manual adjustments of the mtu of
the route to the destination.
>How-To-Repeat:
Not sure yet.
>Release-Note:
>Audit-Trail:
>Unformatted:
From bz at FreeBSD.org
1 17:46:18 2011
From: bz at FreeBSD.org (bz@FreeBSD.org)
Date: Tue Mar
1 17:46:24 2011
Subject: kern/155165: IPv6 over IPv6 IPsec tunnel MTU(?) issue.
Message-ID:
Old Synopsis: Zabbadoz.NeT
New Synopsis: IPv6 over IPv6 IPsec tunnel MTU(?) issue.
Responsible-Changed-From-To: freebsd-bugs->bz
Responsible-Changed-By: bz
Responsible-Changed-When: Tue Mar 1 17:45:28 UTC 2011
Responsible-Changed-Why:
Take my own report.
http://www.freebsd.org/cgi/query-pr.cgi?pr=155165
From yongari at FreeBSD.org
1 18:19:06 2011
From: yongari at FreeBSD.org (yongari@FreeBSD.org)
Date: Tue Mar
1 18:19:12 2011
Subject: misc/155134: Vlan hwtagging on fxp under 7.4-PRERELEASE doesn't
Message-ID:
Synopsis: Vlan hwtagging on fxp under 7.4-PRERELEASE doesn't work
State-Changed-From-To: open->feedback
State-Changed-By: yongari
State-Changed-When: Tue Mar 1 18:16:26 UTC 2011
State-Changed-Why:
I'm pretty sure TSO and VLAN hardware tagging worked without
problems when I firstly implemented that hardware features. AFAIK
FreeBSD is the only OS that takes advantage of these features and
Intel's public data sheet does not (intentionally) mention VLAN
hardware tag insertion/strip feature of controller. The TSO and
VLAN hardware tagging is supported on i82550 and i82551
controllers.
>From your description of the issue and tcpdump output I don't see
any problems. For instance, I see ping for 192.168.3.1 worked and I
also see VLAN encapsulation(ether type 0x8100) header in the
tcpdump. If VLAN hardware tagging does not work, you wouldn't get
any response from 192.168.30.1. So what is your problem?
Responsible-Changed-From-To: freebsd-bugs->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Tue Mar 1 18:16:26 UTC 2011
Responsible-Changed-Why:
http://www.freebsd.org/cgi/query-pr.cgi?pr=155134
From arundel at FreeBSD.org
1 21:39:06 2011
From: arundel at FreeBSD.org (arundel@FreeBSD.org)
Date: Tue Mar
1 21:39:12 2011
Subject: misc/155126: cvsup10.us having problems
Message-ID:
Synopsis: cvsup10.us having problems
State-Changed-From-To: open->closed
State-Changed-By: arundel
State-Changed-When: Tue Mar 1 21:36:30 UTC 2011
State-Changed-Why:
"The base problem was that ncvsup had run out of disk-space.
I have hacked it for now by decreasing file system reserve,
and going to look into upgrading the server.
36GB disks aren't w-)." - Simon
http://www.freebsd.org/cgi/query-pr.cgi?pr=155126
From arundel at freebsd.org
1 22:00:31 2011
From: arundel at freebsd.org (Alexander Best)
Date: Tue Mar
1 22:00:37 2011
Subject: bin/155129: fetch(1) doesn't interop with tukaani.org
Message-ID:
The following reply was made to PR bin/155129; it has been noted by GNATS.
From: Alexander Best
To: bug-followup@freebsd.org
Subject: Re: bin/155129: fetch(1) doesn't interop with tukaani.org
Date: Tue, 1 Mar :21 +0000
confirmed running 9.0:
otaku% fetch -vvvvvv http://tukaani.org/xz/xz-5.0.1.tar.bz2
password: []
[tukaani.org]
document: [/xz/xz-5.0.1.tar.bz2]
---> tukaani.org:80
looking up tukaani.org
connecting to tukaani.org:80
requesting http://tukaani.org/xz/xz-5.0.1.tar.bz2
>>> GET /xz/xz-5.0.1.tar.bz2 HTTP/1.1
>>> Host: tukaani.org
>>> User-Agent: fetch libfetch/2.0
>>> Connection: close
fetch: transfer timed out
otaku% ftp -v -d http://tukaani.org/xz/xz-5.0.1.tar.bz2
parse_url: user `' pass `' host tukaani.org port http(80) path `/xz/xz-5.0.1.tar.bz2'
savefile `xz-5.0.1.tar.bz2'
Requesting http://tukaani.org/xz/xz-5.0.1.tar.bz2
received `HTTP/1.1 200 OK'
received `Date: Tue, 01 Mar :21 GMT'
received `Server: Apache/2'
received `Last-Modified: Sat, 29 Jan :16 GMT'
received `ETag: "31214bc-f5987-49afdb1215e00"'
received `Accept-Ranges: bytes'
received `Content-Length: 1005959'
parsed len as: 1005959
received `Vary: Accept-Encoding,User-Agent'
received `Connection: close'
received `Content-Type: application/x-bzip2'
100% |********************************************************************************************************************************************************************************************************************|
386.78 KB/s
00:00 ETA1005959 bytes retrieved in 00:02 (386.74 KB/s)
From andrei.manescu at ivorde.ro
1 22:55:26 2011
From: andrei.manescu at ivorde.ro (Andrei Manescu - Ivorde)
Date: Tue Mar
1 22:55:32 2011
Subject: misc/155134: Vlan hwtagging on fxp under 7.4-PRERELEASE doesn't
In-Reply-To:
References:
Message-ID:
Thanks for replying.
When vlanhwtag is enabled on the fxp physical interface, the packets are
not vlan tagged and, sometimes, not replied:
[root@thor ~]# ifconfig fe-0/0
fe-0/0: flags=8843 metric 0 mtu 1500
options=211b
[root@thor ~]# ifconfig vlan10
vlan10: flags=8843 metric 0 mtu 1500
ether 00:02:b3:9f:ef:86
inet 192.168.3.2 netmask 0xffffff00 broadcast 192.168.3.255
media: Ethernet autoselect (100baseTX )
status: active
vlan: 10 parent interface: fe-0/0
Consecutive commands:
[root@thor ~]# ping -c 1 192.168.3.1
--> NO REPLY
PING 192.168.3.1 (192.168.3.1): 56 data bytes
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
[root@thor ~]# ping -c 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
64 bytes from 192.168.3.1: icmp_seq=0 ttl=64 time=0.398 ms
--- 192.168.3.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.398/0.398/0.398/0.000 ms
tcpdump of the above echo requests. Only the reply is tagged:
[root@thor ~]# tcpdump -nni fe-0/0 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fe-0/0, link-type EN10MB (Ethernet), capture size 96 bytes
23:10:28.:02:b3:9f:ef:86 > 00:02:a5:8f:56:69, ethertype IPv4
(0x0800), length 98: 192.168.3.2 > 192.168.3.1: ICMP echo request, id
17620, seq 0, length 64
23:10:44.:02:b3:9f:ef:86 > 00:02:a5:8f:56:69, ethertype IPv4
(0x0800), length 98: 192.168.3.2 > 192.168.3.1: ICMP echo request, id
24788, seq 0, length 64
23:10:44.:02:a5:8f:56:69 > 00:02:b3:9f:ef:86, ethertype 802.1Q
(0x8100), length 102: vlan 10, p 0, ethertype IPv4, 192.168.3.1 >
192.168.3.2: ICMP echo reply, id 24788, seq 0, length 64
The tcpdump clearly shows that for the first two packets (echo
requests), the ethertype is 0x0800 and it doesn't contain the vlan tag.
Now, if I disable the vlanhwtag on the physical interface, all gets back
to normal.
The physical interface is a supported 82550 chip.
[root@thor ~]# grep fe-0/0 /etc/rc.conf
ifconfig_fxp0_name="fe-0/0"
[root@thor ~]# pciconf -lv
fxp0@pci0:1:1:0:
class=0x020000 card=0x chip=0x
rev=0x0c hdr=0x00
= 'Intel Corporation'
= '/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
= ethernet
Am I really off topic ?
P.S.: I also attached a capture with one echo request and an echo reply.
The req leaving the FreeBSD box in question is not encapsulated, but the
reply is coming in (with the vlan tag).
P.S.S.: At the other end, there is a pFsense 2.0-RC1 (FreeBSD 8.1)
firewall with vlans configured on an fxp0 interface also.
On 03/01/ PM, yongari@FreeBSD.org wrote:
> Synopsis: Vlan hwtagging on fxp under 7.4-PRERELEASE doesn't work
> State-Changed-From-To: open->feedback
> State-Changed-By: yongari
> State-Changed-When: Tue Mar 1 18:16:26 UTC 2011
> State-Changed-Why:
> I'm pretty sure TSO and VLAN hardware tagging worked without
> problems when I firstly implemented that hardware features. AFAIK
> FreeBSD is the only OS that takes advantage of these features and
> Intel's public data sheet does not (intentionally) mention VLAN
> hardware tag insertion/strip feature of controller. The TSO and
> VLAN hardware tagging is supported on i82550 and i82551
> controllers.
From your description of the issue and tcpdump output I don't see
> any problems. For instance, I see ping for 192.168.3.1 worked and I
> also see VLAN encapsulation(ether type 0x8100) header in the
> tcpdump. If VLAN hardware tagging does not work, you wouldn't get
> any response from 192.168.30.1. So what is your problem?
> Responsible-Changed-From-To: freebsd-bugs->yongari
> Responsible-Changed-By: yongari
> Responsible-Changed-When: Tue Mar 1 18:16:26 UTC 2011
> Responsible-Changed-Why:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=155134
From pjp at centroid.eu
2 00:00:27 2011
From: pjp at centroid.eu (Peter J. Philipp)
Date: Wed Mar
2 00:00:34 2011
Subject: misc/155175: typo in faithd
Message-ID:
>Category:
>Synopsis:
typo in faithd
>Confidential:
>Severity:
non-critical
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
>Submitter-Id:
current-users
>Arrival-Date:
Wed Mar 02 00:00:25 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
Peter J. Philipp
8.2-RELEASE
>Organization:
>Environment:
janus# uname -a
FreeBSD janus.centroid.eu 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011
root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
>Description:
--- faithd.c.orig
00:51:19. +0100
+++ faithd.c
00:51:29. +0100
@@ -340,7 +340,7 @@
snprintf(logname, sizeof(logname), "faithd %s", service);
snprintf(procname, sizeof(procname), "accepting port %s", service);
openlog(logname, LOG_PID | LOG_NOWAIT, LOG_DAEMON);
syslog(LOG_INFO, "Staring faith daemon for %s port", service);
syslog(LOG_INFO, "Starting faith daemon for %s port", service);
play_service(s_wld);
/* NOTREACHED */
>How-To-Repeat:
>Release-Note:
>Audit-Trail:
>Unformatted:
From pyunyh at gmail.com
2 02:04:44 2011
From: pyunyh at gmail.com (YongHyeon PYUN)
Date: Wed Mar
2 02:04:56 2011
Subject: misc/155134: Vlan hwtagging on fxp under 7.4-PRERELEASE doesn't
In-Reply-To:
References:
Message-ID:
On Tue, Mar 01, 2011 at 11:28:39PM +0100, Andrei Manescu - Ivorde wrote:
> Thanks for replying.
> When vlanhwtag is enabled on the fxp physical interface, the packets are
> not vlan tagged and, sometimes, not replied:
> [root@thor ~]# ifconfig fe-0/0
> fe-0/0: flags=8843 metric 0 mtu 1500
options=211b
> [root@thor ~]# ifconfig vlan10
> vlan10: flags=8843 metric 0 mtu 1500
ether 00:02:b3:9f:ef:86
inet 192.168.3.2 netmask 0xffffff00 broadcast 192.168.3.255
media: Ethernet autoselect (100baseTX )
status: active
vlan: 10 parent interface: fe-0/0
> Consecutive commands:
> [root@thor ~]# ping -c 1 192.168.3.1
--> NO REPLY
> PING 192.168.3.1 (192.168.3.1): 56 data bytes
> --- 192.168.3.1 ping statistics ---
> 1 packets transmitted, 0 packets received, 100.0% packet loss
> [root@thor ~]# ping -c 1 192.168.3.1
> PING 192.168.3.1 (192.168.3.1): 56 data bytes
> 64 bytes from 192.168.3.1: icmp_seq=0 ttl=64 time=0.398 ms
> --- 192.168.3.1 ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.398/0.398/0.398/0.000 ms
> tcpdump of the above echo requests. Only the reply is tagged:
> [root@thor ~]# tcpdump -nni fe-0/0 -e
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on fe-0/0, link-type EN10MB (Ethernet), capture size 96 bytes
> 23:10:28.:02:b3:9f:ef:86 > 00:02:a5:8f:56:69, ethertype IPv4
> (0x0800), length 98: 192.168.3.2 > 192.168.3.1: ICMP echo request, id
> 17620, seq 0, length 64
> 23:10:44.:02:b3:9f:ef:86 > 00:02:a5:8f:56:69, ethertype IPv4
> (0x0800), length 98: 192.168.3.2 > 192.168.3.1: ICMP echo request, id
> 24788, seq 0, length 64
> 23:10:44.:02:a5:8f:56:69 > 00:02:b3:9f:ef:86, ethertype 802.1Q
> (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 192.168.3.1 >
> 192.168.3.2: ICMP echo reply, id 24788, seq 0, length 64
> The tcpdump clearly shows that for the first two packets (echo
> requests), the ethertype is 0x0800 and it doesn't contain the vlan tag.
> Now, if I disable the vlanhwtag on the physical interface, all gets back
> to normal.
> The physical interface is a supported 82550 chip.
> [root@thor ~]# grep fe-0/0 /etc/rc.conf
> ifconfig_fxp0_name="fe-0/0"
> [root@thor ~]# pciconf -lv
> fxp0@pci0:1:1:0:
class=0x020000 card=0x chip=0x
> rev=0x0c hdr=0x00
= 'Intel Corporation'
= '/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
= ethernet
Your controller is i82550 Pro/100 Ethernet and it is known to
support TSO/VLAN hardware tagging as well as IPSec acceleration.
> Am I really off topic ?
No, but looks strange to me. Could you capture both boxes(one for
sender(fxp0) and receiver to see whether the packets really have no
VLAN header.)?
> P.S.: I also attached a capture with one echo request and an echo reply.
> The req leaving the FreeBSD box in question is not encapsulated, but the
> reply is coming in (with the vlan tag).
I think the capture is incomplete since it only has sender side. I
need capture both sender and receiver.
> P.S.S.: At the other end, there is a pFsense 2.0-RC1 (FreeBSD 8.1)
> firewall with vlans configured on an fxp0 interface also.
Don't know about pfSense but you can disable VLAN hardware tagging
on pfSense side to rule out possible VLAN hardware related issues
before capturing VLAN traffic. Make sure to capture parent
interface traffic instead of vlan interface.
From krehan at ktait.com
2 05:10:22 2011
From: krehan at ktait.com (Khalid Rehan)
Date: Wed Mar
2 05:10:30 2011
Subject: Installing FreeBSD on Dell-mini 9"
In-Reply-To:
References:
Message-ID:
Hi Polytropon,
I'm getting this error:
*unable to find device node for /dev/ad0s1b in /dev*
on installing FreeBSD 8.1..
*P.S*: The Dell-mini has an SSD of 32 GB..
Thanks in advance,
On Thu, Feb 24, 2011 at 11:05 PM, Khalid Rehan
> You mean force installing the old version, right?
> OK, I will go through it.
> I'm sorry, I'm not familiar with BSD, so I will try it, and I will be
> confirming you my results.
> Thanks so much,
> Khalid..
> On Thu, Feb 24, 2011 at 9:54 PM, Polytropon
>> On Thu, 24 Feb :07 -0500, Khalid Rehan
>> > Yes, an old OpenSSH version is needed...
>> In that case, use a current release, then get the ports
>> tree of 4.9 (or wherever the OpenSSH version occurs that
>> you require) and build it from source. Or maybe even
>> better: Use the port "portdowngrade" to get an older
>> version of OpenSSH and install it. You can install it
>> as an additional program, or overwrite the system's
>> SSH with it.
>> Polytropon
>> Magdeburg, Germany
>> Happy FreeBSD user since 4.0
>> Andra moi ennepe, Mousa, ...
> Khalid Abd El-Halim Rehan
> System Administration, KTAIT.
> -------------------------------------------------------------------
> http://english.islamway.com/
> http://www.openoffice.org/
> For family safe on-line:
> http://www.opendns.com/
Khalid Abd El-Halim Rehan
RHCT Certified.
System Administration, KTAIT.
-------------------------------------------------------------------
http://english.islamway.com/
http://www.openoffice.org/
For family safe on-line:
http://www.opendns.com/
From eschoedler at gmail.com
2 05:20:11 2011
From: eschoedler at gmail.com (Eduardo Schoedler)
Date: Wed Mar
2 05:20:18 2011
Subject: kern/155177: Panic when inject routes in kernel
Message-ID:
>Category:
>Synopsis:
Panic when inject routes in kernel
>Confidential:
>Severity:
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
>Submitter-Id:
current-users
>Arrival-Date:
Wed Mar 02 05:20:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
Eduardo Schoedler
8.2-STABLE
>Organization:
>Environment:
FreeBSD border01.scr 8.2-STABLE FreeBSD 8.2-STABLE #5: Wed Mar
2 01:34:10 BRT 2011
root@border01.scr:/usr/obj/usr/src/sys/BORDER-RTR
>Description:
I'm using Quagga 0.99.17 peering with bgpsimple tool in another machine.
Bgpsimple injects full-routing table in this bgp session.
When the bgpsimple terminates the injection (or when I cancel by pressing CTRL+C), an kernel panic occurs in the router.
Kernel debugging:
# kgdb kernel.debug /var/crash/vmcore.1
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:
panic: rtfree 2
Uptime: 4m38s
Physical memory: 8170 MB
Dumping 566 MB: 551 535 519 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7
doadump () at pcpu.h:224
__asm("movq %%gs:0,%0" : "=r" (td));
(kgdb) quit
Copyright (c)
The FreeBSD Project.
Copyright (c) , , , ,
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.2-STABLE #5: Wed Mar
2 01:34:10 BRT 2011
root@border01.scr:/usr/obj/usr/src/sys/BORDER-RTR amd64
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU
@ 2.53GHz (2527.00-MHz K8-class CPU)
Origin = "GenuineIntel"
Id = 0x106e5
Family = 6
Model = 1e
Stepping = 5
Features=0xbfebfbff
Features2=0x98e3fd
AMD Features=0x
AMD Features2=0x1
TSC: P-state invariant
real memory
avail memory =
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
cpu0 (BSP): APIC ID:
cpu1 (AP): APIC ID:
cpu2 (AP): APIC ID:
cpu3 (AP): APIC ID:
cpu4 (AP): APIC ID:
cpu5 (AP): APIC ID:
cpu6 (AP): APIC ID:
cpu7 (AP): APIC ID:
irqs 0-23 on motherboard
netisr_init: forcing maxthreads to 1 and bindthreads to 0 for device polling
kbd1 at kbdmux0
ichwd module loaded
at iomem 0xfcac0-0xfcade on motherboard
smbios0: Version: 2.6, BCD Revision: 2.6
cryptosoft0:
on motherboard
on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
unknown: I/O range not supported
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0:
port 0x808-0x80b on acpi0
port 0xcf8-0xcff on acpi0
at device 3.0 on pci0
at device 0.0 on pci1
at device 2.0 on pci2
port 0xfcc0-0xfcdf mem 0xddfc0000-0xddfdffff,0xdexde3fffff,0xddfb8000-0xddfbbfff irq 18 at device 0.0 on pci3
igb0: Using MSIX interrupts with 9 vectors
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: Ethernet address: 00:1b:21:42:87:e0
port 0xfce0-0xfcff mem 0xddfe0000-0xddffffff,0xdexde7fffff,0xddfbc000-0xddfbffff irq 19 at device 0.1 on pci3
igb1: Using MSIX interrupts with 9 vectors
igb1: [ITHREAD]
igb1: [ITHREAD]
igb1: [ITHREAD]
igb1: [ITHREAD]
igb1: [ITHREAD]
igb1: [ITHREAD]
igb1: [ITHREAD]
igb1: [ITHREAD]
igb1: [ITHREAD]
igb1: Ethernet address: 00:1b:21:42:87:e1
at device 4.0 on pci2
port 0xecc0-0xecdf mem 0xdd3c0000-0xdd3dffff,0xddxdd7fffff,0xdd3b8000-0xdd3bbfff irq 16 at device 0.0 on pci4
igb2: Using MSIX interrupts with 9 vectors
igb2: [ITHREAD]
igb2: [ITHREAD]
igb2: [ITHREAD]
igb2: [ITHREAD]
igb2: [ITHREAD]
igb2: [ITHREAD]
igb2: [ITHREAD]
igb2: [ITHREAD]
igb2: [ITHREAD]
igb2: Ethernet address: 00:1b:21:42:87:e4
port 0xece0-0xecff mem 0xdd3e0000-0xdd3fffff,0xddxddbfffff,0xdd3bc000-0xdd3bffff irq 17 at device 0.1 on pci4
igb3: Using MSIX interrupts with 9 vectors
igb3: [ITHREAD]
igb3: [ITHREAD]
igb3: [ITHREAD]
igb3: [ITHREAD]
igb3: [ITHREAD]
igb3: [ITHREAD]
igb3: [ITHREAD]
igb3: [ITHREAD]
igb3: [ITHREAD]
igb3: Ethernet address: 00:1b:21:42:87:e5
at device 8.0 (no driver attached)
at device 8.1 (no driver attached)
at device 8.2 (no driver attached)
at device 8.3 (no driver attached)
at device 16.0 (no driver attached)
at device 16.1 (no driver attached)
mem 0xde8fc000-0xde8fc3ff irq 22 at device 26.0 on pci0
ehci0: [ITHREAD]
usbus0: EHCI version 1.0
at device 28.0 on pci0
mem 0xdxd9ffffff irq 16 at device 0.0 on pci5
PHY 1 on miibus0
10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bce0: Ethernet address: 00:26:b9:7f:d4:26
bce0: [ITHREAD]
mem 0xdaxdbffffff irq 17 at device 0.1 on pci5
PHY 1 on miibus1
10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bce1: Ethernet address: 00:26:b9:7f:d4:27
bce1: [ITHREAD]
mem 0xde8fe000-0xde8fe3ff irq 22 at device 29.0 on pci0
ehci1: [ITHREAD]
usbus1: EHCI version 1.0
at device 30.0 on pci0
mem 0xdxd7ffffff,0xdc7fc000-0xdc7fffff,0xdcxdcffffff irq 19 at device 3.0 on pci6
at device 31.0 on pci0
port 0xdca0-0xdca7,0xdc90-0xdc93,0xdca8-0xdcaf,0xdc94-0xdc97,0xdcc0-0xdccf,0xdcd0-0xdcdf irq 20 at device 31.2 on pci0
atapci0: [ITHREAD]
on atapci0
ata2: [ITHREAD]
on atapci0
ata3: [ITHREAD]
port 0xdcb0-0xdcb7,0xdc98-0xdc9b,0xdcb8-0xdcbf,0xdc9c-0xdc9f,0xdce0-0xdcef,0xdcf0-0xdcff irq 21 at device 31.5 on pci0
atapci1: [ITHREAD]
on atapci1
ata4: [ITHREAD]
on atapci1
ata5: [ITHREAD]
acpi_hpet0:
iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency
Hz quality 900
port 0x70-0x7f irq 8 on acpi0
port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
port 0x2f8-0x2ff irq 3 on acpi0
uart1: [FILTER]
at iomem 0xcfff,0xcfff,0xec000-0xeffff on isa0
atkbd: unable to set the command byte.
at flags 0x100 on isa0
at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
at port 0x60,0x64 on isa0
irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
coretemp0:
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 14
device_attach: est0 attach returned 6
coretemp1:
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 14
device_attach: est1 attach returned 6
coretemp2:
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 14
device_attach: est2 attach returned 6
coretemp3:
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 14
device_attach: est3 attach returned 6
coretemp4:
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 14
device_attach: est4 attach returned 6
coretemp5:
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 14
device_attach: est5 attach returned 6
coretemp6:
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 14
device_attach: est6 attach returned 6
coretemp7:
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 14
device_attach: est7 attach returned 6
Timecounters tick every 1.000 msec
IPsec: Initialized Security Association Processing.
ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based forwarding enabled, default to accept, logging disabled
load_dn_sched dn_sched WF2Q+ loaded
load_dn_sched dn_sched FIFO loaded
load_dn_sched dn_sched PRIO loaded
load_dn_sched dn_sched QFQ loaded
load_dn_sched dn_sched RR loaded
usbus0: 480Mbps High Speed USB v2.0
usbus1: 480Mbps High Speed USB v2.0
ad4: 238418MB
at ata2-master UDMA100 SATA 3Gb/s
ad6: 238418MB
at ata3-master UDMA100 SATA 3Gb/s
acd0: DVDROM
at ata3-slave UDMA100 SATA 1.5Gb/s
SMP: AP CPU #1 Launched!
SMP: AP CPU #4 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #5 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #6 Launched!
SMP: AP CPU #7 Launched!
hwpmc: TSC/1/64/0x20 IAP/4/48/0x3ff IAF/3/48/0x61 UCP/8/48/0x3f8 UCF/1/48/0x60
WARNING: WITNESS option enabled, expect reduced performance.
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 6 ports with 6 removable, self powered
uhub3: 8 ports with 8 removable, self powered
kbd2 at ukbd0
ums0: 3 buttons and [Z] coordinates ID=0
uhub4: 4 ports with 4 removable, self powered
kbd3 at ukbd1
Trying to mount root from ufs:/dev/ad4s1a
WARNING: / was not properly dismounted
WARNING: /usr was not properly dismounted
WARNING: /var was not properly dismounted
bce0: link state changed to UP
# cat /boot/loader.conf
net.inet.tcp.syncache.hashsize=1024
net.inet.tcp.syncache.bucketlimit=512
net.inet.tcp.syncache.cachelimit=65536
net.inet.tcp.hostcache.hashsize="16384"
net.inet.tcp.hostcache.bucketlimit="100"
net.inet.tcp.tcbhashsize=4096
net.isr.direct=1
net.isr.bindthreads=1
net.isr.numthreads=4
net.isr.defaultqlimit=4096
kern.ipc.nmbclusters=65536
net.fibs=2
kern.hz=1000
# cat /etc/sysctl.conf
kern.securelevel=1
kern.ipc.nmbjumbo9=69000
kern.timecounter.hardware=HPET
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
net.inet.carp.log=0
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
net.inet.ip.fastforwarding=1
net.inet.ip.fw.verbose_limit=0
kern.ipc.somaxconn=8192
kern.maxfilesperproc=57636
net.inet.tcp.delayed_ack=0
net.inet.tcp.sendspace=65535
net.inet.udp.recvspace=65535
net.inet.udp.maxdgram=57344
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
kern.ipc.shmmax=
kern.maxfiles=204800
kern.maxfilesperproc=200000
kern.maxvnodes=200000
net.inet.tcp.rfc1323=1
net.inet.ip.portrange.first=1024
net.inet.ip.portrange.last=65535
net.inet.ip.ttl=128
net.inet.tcp.maxtcptw=200000
net.inet.tcp.fast_finwait2_recycle=1
net.inet.tcp.msl=5000
net.inet.ip.dummynet.io_fast=1
net.inet.udp.blackhole=1
net.inet.tcp.blackhole=2
net.inet.icmp.maskrepl=0
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.tcp.drop_synfin=1
net.inet.tcp.log_in_vain=1
net.inet.udp.log_in_vain=1
net.inet.tcp.icmp_may_rst=0
net.inet.icmp.icmplim=50
net.inet.ip.redirect=0
net.inet6.ip6.redirect=0
net.inet.icmp.bmcastecho=0
kern.polling.burst_max=1000
kern.polling.each_burst=1000
kern.polling.reg_frac=100
kern.polling.user_frac=1
kern.polling.idle_poll=0
net.link.ether.inet.max_age=14400
net.inet6.icmp6.rediraccept=0
net.inet6.ip6.accept_rtadv=0
# ifconfig
igb0: flags=8843 metric 0 mtu 1500
options=101bb
ether 00:1b:21:42:87:e0
media: Ethernet 1000baseT
status: active
igb1: flags=8843 metric 0 mtu 1500
options=101bb
ether 00:1b:21:42:87:e1
inet 172.16.x.x netmask 0xffffff00 broadcast 172.16.x.x
media: Ethernet 1000baseT
status: active
igb2: flags=8843 metric 0 mtu 1500
options=101bb
ether 00:1b:21:42:87:e4
media: Ethernet 1000baseT
(autoselect)
status: no carrier
igb3: flags=8843 metric 0 mtu 1500
options=101bb
ether 00:1b:21:42:87:e5
media: Ethernet 1000baseT
(autoselect)
status: no carrier
bce0: flags=8843 metric 0 mtu 1500
options=c01bb
ether 00:26:b9:7f:d4:26
inet 187.x.y.1 netmask 0xfffffffc broadcast 187.x.y.3
media: Ethernet 1000baseT
status: active
bce1: flags=8843 metric 0 mtu 1500
options=c01bb
ether 00:26:b9:7f:d4:27
media: Ethernet 1000baseT
status: no carrier
ipfw0: flags=8801 metric 0 mtu 65536
lo0: flags=8049 metric 0 mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
nd6 options=3
enc0: flags=0 metric 0 mtu 1536
lo10: flags=8049 metric 0 mtu 16384
inet 187.x.x.254 netmask 0xffffffff
lo20: flags=8049 metric 0 mtu 16384
inet 187.x.x.21 netmask 0xffffffff
lo30: flags=8049 metric 0 mtu 16384
inet 187.x.x.1 netmask 0xffffffff
disc10: flags=8049 metric 0 mtu 65532
inet 192.0.2.1 netmask 0xffffffff
inet6 2001:db8:0:dead:beef::1 prefixlen 128
nd6 options=3
igb0.2000: flags=8843 metric 0 mtu 1500
ether 00:1b:21:xx:xx:xx
inet 18x.x.x.x netmask 0xfffffffc broadcast 18x.x.x.x
media: Ethernet 1000baseT
status: active
vlan: 2000 parent interface: igb0
>How-To-Repeat:
Quagga on R1:
router bgp 65501
no synchronization
no bgp fast-external-failover
bgp router-id 187.x.x.254
bgp log-neighbor-changes
no bgp default ipv4-unicast
bgp deterministic-med
bgp graceful-restart
bgp network import-check
network 187.x.y.0 mask 255.255.254.0
neighbor 187.x.z.2 remote-as 65501
neighbor 187.x.z.2 activate
neighbor 187.x.z.2 next-hop-self
no auto-summary
In the another machine:
1) http://code.google.com/p/bgpsimple/wiki/README (using data from rcc00)
2) Execute bgpsimple:
# ./bgp_simple.pl -myas 65501 -myip 187.x.y.2 -peeras 65501 -peerip 187.x.y.1 -p myroutes -n -v
3) When bgpsimple terminates, this is the output:
Full update sent.
Error occured: type [Hold Timer Expired]
Connection reset with peer 187.x.y.1, AS 65501.
Error occured: type [Cease]
Error occured: type [Cease]
>Release-Note:
>Audit-Trail:
>Unformatted:
From trasz at FreeBSD.org
2 07:25:02 2011
From: trasz at FreeBSD.org (trasz@FreeBSD.org)
Date: Wed Mar
2 07:25:09 2011
Subject: kern/154113: [patch] [libc] Missing ZFS NFSv4 ACL read_set,
modify_set, write_set, full_set
Message-ID:
Synopsis: [patch] [libc] Missing ZFS NFSv4 ACL read_set, modify_set, write_set, full_set
Responsible-Changed-From-To: freebsd-bugs->trasz
Responsible-Changed-By: trasz
Responsible-Changed-When: Wed Mar 2 07:25:01 UTC 2011
Responsible-Changed-Why:
I'll take it.
http://www.freebsd.org/cgi/query-pr.cgi?pr=154113
From trasz at FreeBSD.org
2 07:25:29 2011
From: trasz at FreeBSD.org (trasz@FreeBSD.org)
Date: Wed Mar
2 07:25:36 2011
Subject: bin/155163: [patch] Add Recursive Functionality to setfacl
Message-ID:
Synopsis: [patch] Add Recursive Functionality to setfacl
Responsible-Changed-From-To: freebsd-bugs->trasz
Responsible-Changed-By: trasz
Responsible-Changed-When: Wed Mar 2 07:25:28 UTC 2011
Responsible-Changed-Why:
I'll take it.
http://www.freebsd.org/cgi/query-pr.cgi?pr=155163
From linimon at FreeBSD.org
2 07:35:22 2011
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Mar
2 07:35:34 2011
Subject: kern/155177: [route] [panic] Panic when inject routes in kernel
Message-ID:
Old Synopsis: Panic when inject routes in kernel
New Synopsis: [route] [panic] Panic when inject routes in kernel
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Mar 2 07:33:35 UTC 2011
Responsible-Changed-Why:
Attempt to classify and reassign.
http://www.freebsd.org/cgi/query-pr.cgi?pr=155177
From linimon at FreeBSD.org
2 07:36:53 2011
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Mar
2 07:37:00 2011
Subject: kern/155113: [re] 'media auto' does not work
Message-ID:
Old Synopsis: 'media auto' does not work
New Synopsis: [re] 'media auto' does not work
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Mar 2 07:36:30 UTC 2011
Responsible-Changed-Why:
Reclassify and assign.
http://www.freebsd.org/cgi/query-pr.cgi?pr=155113
From linimon at FreeBSD.org
2 07:37:33 2011
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Mar
2 07:37:44 2011
Subject: kern/155118: [geom] geom_eli containers created on systems with
aesni(4) enabled are not working on systems without aesni(4)
and vice versa.
Message-ID:
Old Synopsis: geom_eli containers created on systems with aesni(4) enabled are not working on systems without aesni(4) and vice versa.
New Synopsis: [geom] geom_eli containers created on systems with aesni(4) enabled are not working on systems without aesni(4) and vice versa.
Responsible-Changed-From-To: freebsd-bugs->freebsd-geom
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Mar 2 07:37:13 UTC 2011
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=155118
From jt at xoasis.de
2 08:00:28 2011
From: jt at xoasis.de (Joerg Traeger)
Date: Wed Mar
2 08:00:42 2011
Subject: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and
OXPCIe958 PCI Express chips
Message-ID:
The following reply was made to PR kern/134878; it has been noted by GNATS.
From: Joerg Traeger
To: bug-followup@FreeBSD.org
Cc: david@wood2.org.uk
Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Wed, 2 Mar :04 +0100
I would like to report success using a PCIe card with Oxford 958 and 32 (2 x
16) serial ports. Its name is EXSYS EX-44032. OS is FreeBSD 8.2.
Using the patch mentioned puc recognizes all ports and the card works fine.
Will this patch be commited in the future?
Joerg Traeger
From hd at onlinecity.dk
2 11:20:12 2011
From: hd at onlinecity.dk (Hans Duedal)
Date: Wed Mar
2 11:20:25 2011
Subject: kern/155160: [aesni] AES-NI breaks OpenSSL client calls
Message-ID:
The following reply was made to PR kern/155160; it has been noted by GNATS.
From: Hans Duedal
To: bug-followup@freebsd.org, hd@onlinecity.dk
Subject: Re: kern/155160: [aesni] AES-NI breaks OpenSSL client calls
Date: Wed, 2 Mar :51 +0100
--da7c7c049d7e1365
Content-Type: text/ charset=ISO-8859-1
Does not work:
curl -v --ciphers AES256-SHA "https://twitter.com/"
curl -v --ciphers AES256-SHA "https://encrypted.google.com/"
curl -v --ciphers AES128-SHA "https://twitter.com/"
curl -v --ciphers AES128-SHA "https://encrypted.google.com/"
curl -v --ciphers RC4-SHA "https://twitter.com/"
curl -v --ciphers CAMELLIA128-SHA "https://oc.nimta.com/"
curl -v --ciphers CAMELLIA256-SHA "https://oc.nimta.com/"
The problem only affects the AES256 cipher and it's variants
(DHE-RSA-AES256-SHA & DHE-DSS-AES256-SHA). But openssl s_client still works
openssl s_client -ssl3 -cipher AES256-SHA -state -CAfile
/usr/local/share/certs/ca-root-nss.crt -connect twitter.com:443
--da7c7c049d7e1365
Content-Type: text/ charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Does not work:curl -v --ciphers AES256-SHA &&curl -v --c=
iphers AES256-SHA &&
Works:curl -v --ciphers AES128-SHA &&curl=
-v --ciphers AES128-SHA &&
curl -v --ciphers RC4-SHA &&curl -v --ciphers CAMELLIA128-SHA &quot=
curl -v --ciphers CAMELLIA256-SHA &&The problem only af=
fects the AES256 cipher and it's variants (DHE-RSA-AES256-SHA & DHE=
-DSS-AES256-SHA). But openssl s_client still works with it:
openssl s_client -ssl3 -cipher AES256-SHA -state -CAfile /usr/local/sh=
are/certs/ca-root-nss.crt -connect
--da7c7c049d7e1365--
From hd at onlinecity.dk
2 11:30:11 2011
From: hd at onlinecity.dk (Hans Duedal)
Date: Wed Mar
2 11:30:17 2011
Subject: kern/155160: [aesni] AES-NI breaks OpenSSL client calls
Message-ID:
The following reply was made to PR kern/155160; it has been noted by GNATS.
From: Hans Duedal
To: bug-followup@FreeBSD.org, Hans Duedal
Subject: Re: kern/155160: [aesni] AES-NI breaks OpenSSL client calls
Date: Wed, 2 Mar :32 +0100
--b259bdb93e
Content-Type: text/ charset=ISO-8859-1
I should note that the issue does not affect the openssl s_client test
db3# openssl s_client -quiet -state -CAfile
/usr/local/share/certs/ca-root-nss.crt -connect twitter.com:443
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
verify return:1
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G5
verify return:1
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation
verify return:1
/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private
Organization/serialNumber=4337446/C=US/postalCode=94107/ST=California/L=San
Francisco/street=795 Folsom St, Suite 600/O=Twitter, Inc./OU=Twitter
Operations
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
Status: 500 Internal Server Error
Content-Type: text/html
500 Internal Server ErrorSSL3 alert
read:warning:close notify
SSL3 alert write:warning:close notify
Used the ca-root from security/ca_root_nss package to avoid verify issues.
As you can see from my original report, cURL is affected, and so is puppet
which is ruby based, but I assume that many more clients are affected.
--b259bdb93e
Content-Type: text/ charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I should note that the issue does not affect the openssl s_client test comm=
db3# openssl s_client -quiet -state -CAfile /usr/l=
ocal/share/certs/ca-root-nss.crt -connect SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello ASSL_connect:SSLv3 =
read server hello Adepth=3D3 /C=3DUS/O=3DVeriSign, Inc./OU=3DCla=
ss 3 Public Primary Certification Authorityverify return:1=
depth=3D2 /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Network/OU=3D(c) 2=
006 VeriSign, Inc. - For authorized use only/CN=3DVeriSign Class 3 Public P=
rimary Certification Authority - G5verify return:1dep=
th=3D1 /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Network/OU=3DTerms of=
(c)06/CN=3DVeriSign Class 3 Extended Validation SSL CA
verify return:1depth=3D0 /1.3.6.1.4.1.311.60.2.1.3=3DUS/1.3=
.6.1.4.1.311.60.2.1.2=3DDelaware/businessCategory=3DPrivate Organization/se=
rialNumber=3D4337446/C=3DUS/postalCode=3D94107/ST=3DCalifornia/L=3DSan Fran=
cisco/street=3D795 Folsom St, Suite 600/O=3DTwitter, Inc./OU=3DTwitter =A0O=
verify return:1SSL_connect:SSLv3 read server certificate ASSL_connect:SSLv3 read server done ASSL_connect:SSLv3 =
write client key exchange ASSL_connect:SSLv3 write change cipher=
SSL_connect:SSLv3 write finished ASSL_connect:SSLv3 flush d=
ataSSL_connect:SSLv3 read finished AaaaaSt=
atus: 500 Internal Server ErrorContent-Type: text/html
&html&&body&&h1&500 Internal Server E=
rror&/h1&&/body&&/html&SSL3 alert read:warning:close noti=
fySSL3 alert write:warning:close notify
Used the ca-root from security/ca_root_nss package to avoid veri=
fy issues.As you can see from my original report,=
cURL is affected, and so is puppet which is ruby based, but I assume that =
many more clients are affected.=A0
--b259bdb93e--
From xelah-freebsd-pr at xelah.com
2 11:40:12 2011
From: xelah-freebsd-pr at xelah.com (Alex Hayward)
Date: Wed Mar
2 11:40:18 2011
Subject: misc/155186: False exception throw by NetworkInterface.isUp() (and
probably others)
Message-ID:
>Category:
>Synopsis:
False exception throw by NetworkInterface.isUp() (and probably others)
>Confidential:
>Severity:
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
>Submitter-Id:
current-users
>Arrival-Date:
Wed Mar 02 11:40:11 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
Alex Hayward
8.2-PRERELEASE
>Organization:
Ticketable Ltd
>Environment:
FreeBSD magnus.xelah.com 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #38: Thu Jan 27 12:11:49 GMT 2011
alex@magnus.xelah.com:/usr/obj/usr/src/sys/MAGNUS
>Description:
NetworkInterface.isUp() can throw a SocketException when there was in fact no error. This breaks, for example, JGroups.
getFlags in /usr/ports/java/openjdk7/work/openjdk/jdk/src/solaris/native/java/net/NetworkInterface.c returns if2.ifr_flags where if2 is a struct ifreq. Callers expect a negative (int) result on error, a positive one otherwise. ifr_flags is a short and the top bit can be set of multi-cast capable interfaces. This remains negative when cast to an int and the caller believes an error occurred. An exception is thrown based on whatever errno happens to be.
My JDK port version is openjdk-7.0.122
>How-To-Repeat:
Run this (from JGroups):
import java.net.*;
import java.util.*;
public class test {
public static void main(String[] argv) throws SocketException {
InetAddress address=
Enumeration intfs=NetworkInterface.getNetworkInterfaces();
while(intfs.hasMoreElements()) {
NetworkInterface intf=(NetworkInterface)intfs.nextElement();
if(intf.isUp()) {
//address=getAddress(intf, AddressScope.NON_LOOPBACK) ;
//System.err.println(address);
} catch (SocketException e) {
e.printStackTrace();
Change the last statement of getFlags to 'return ((int) if2.ifr_flags) & 0'
>Release-Note:
>Audit-Trail:
>Unformatted:
From david at wood2.org.uk
2 12:40:13 2011
From: david at wood2.org.uk (David Wood)
Date: Wed Mar
2 12:40:24 2011
Subject: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and
OXPCIe958 PCI Express chips
Message-ID:
The following reply was made to PR kern/134878; it has been noted by GNATS.
From: David Wood
To: jt@xoasis.de
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Wed, 2 Mar :25 +0000
In message , Joerg Traeger
>I would like to report success using a PCIe card with Oxford 958 and 32 (2 x
>16) serial ports. Its name is EXSYS EX-44032. OS is FreeBSD 8.2.
>Using the patch mentioned puc recognizes all ports and the card works fine.
>Will this patch be commited in the future?
I'm glad to hear that the patch works correctly for such a 'mega' serial
I would still like to implement MSI-X interrupt handling. With standard
IRQs, I found that the jitter is too high on my OXPCIe954 based card for
pulse per second to work optimally with NTP, though it is usable.
The most important thing is that this driver works 'as is' for a range
of cards on several FreeBSD versions. I hope it will be committed so
that others can use these excellent PCIe serial chips without patching
their kernels.
I did my best to try to interest some committers, though without
success. The PR is on linimon's list of easy PRs
http://people.freebsd.org/~linimon/studies/prs/easy_prs.html
I keep hoping that someone will commit this and close a PR that has been
open for 21 months. If you want to try some advocacy amongst committers,
be my guest!
With best wishes,
David Wood
david@wood2.org.uk
From brucec at FreeBSD.org
2 12:52:19 2011
From: brucec at FreeBSD.org (brucec@FreeBSD.org)
Date: Wed Mar
2 12:52:31 2011
Subject: ports/155186: java/openjdk7: False exception throw by
NetworkInterface.isUp() (and probably others)
Message-ID:
Old Synopsis: False exception throw by NetworkInterface.isUp() (and probably others)
New Synopsis: java/openjdk7: False exception throw by NetworkInterface.isUp() (and probably others)
Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs
Responsible-Changed-By: brucec
Responsible-Changed-When: Wed Mar 2 12:51:29 UTC 2011
Responsible-Changed-Why:
Ports PR (java).
http://www.freebsd.org/cgi/query-pr.cgi?pr=155186
From dimanenator at gmail.com
2 14:30:13 2011
From: dimanenator at gmail.com (Dmitry Rybin)
Date: Wed Mar
2 14:30:28 2011
Subject: kern/155192: bge1 mtu problem
Message-ID:
>Category:
>Synopsis:
bge1 mtu problem
>Confidential:
>Severity:
non-critical
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
>Submitter-Id:
current-users
>Arrival-Date:
Wed Mar 02 14:30:12 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
Dmitry Rybin
8.2-STABLE
>Organization:
>Environment:
FreeBSD ground.corbina.net 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Mar
2 10:57:25 MSK 2011
root@ground:/usr/obj/usr/src/sys/GENERIC
>Description:
I coudn't set mtu over 1500 on BGE interface, but in
http://svn.freebsd.org/viewvc/base?view=revision&revision=214997
it was commited.
Server HP DL320s, NIC Controller: Embedded NC324i PCIe Dual Port Gigabit Server Adapter
bge0@pci0:3:4:0:
class=0x020000 card=0x7039103c chip=0x rev=0xa3 hdr=0x00
= 'Broadcom Corporation'
= 'NetXtreme BCM5714 Gigabit Ethernet'
= ethernet
bge1@pci0:3:4:1:
class=0x020000 card=0x7039103c chip=0x rev=0xa3 hdr=0x00
= 'Broadcom Corporation'
= 'NetXtreme BCM5714 Gigabit Ethernet'
= ethernet
# ifconfig bge1 mtu 1501
ifconfig: ioctl (set mtu): Invalid argument
>How-To-Repeat:
# ifconfig bge1 mtu 1501
ifconfig: ioctl (set mtu): Invalid argument
$ ifconfig bge1 mtu 9000
ifconfig: ioctl (set mtu): Invalid argument
>Release-Note:
>Audit-Trail:
>Unformatted:
From lars at larseighner.com
2 14:50:12 2011
From: lars at larseighner.com (Lars Eighner)
Date: Wed Mar
2 14:50:28 2011
Subject: kern/155196: Uart cannot identify internal modem or its chip
Message-ID:
>Category:
>Synopsis:
Uart cannot identify internal modem or its chip
>Confidential:
>Severity:
>Priority:
>Responsible:
freebsd-bugs
>Keywords:
>Date-Required:
>Submitter-Id:
current-users
>Arrival-Date:
Wed Mar 02 14:50:11 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:
Lars Eighner
>Organization:
>Environment:
>D