date:20140304

misc/187258: BCM57810 bxe(4) unstable/fails to initialize

2014-03-04 Thread Ray Abadie


>Number: 187258
>Category:   misc
>Synopsis:   BCM57810 bxe(4) unstable/fails to initialize
>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:   Tue Mar 04 17:00:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Ray Abadie
>Release:10.0-RELEASE
>Organization:
TAG, Inc.
>Environment:
FreeBSD xx 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 
22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
Broadcom BCM957810A1008G dual-NIC card (BCM54810 chipset) fails to initialize 
consistently. On reboot both, either or none of the ports becomes active. The 
inactive ports show "no carrier" despite being connected to operational switch 
ports. Hardware is Dell R710. Have disabled TSO, RXCSUM and TXCSUM as per 
recommendations on other bxe(4) related bug reports to no avail. When ports do 
initialize they often fail and go to "no carrier" state inside of 1 hour. 
Traffic on link is minimal. Same card running fine in VMWare ESXi 4.1.

bxe1: flags=8843 metric 0 mtu 1500
options=504b8
ether 00:10:18:e9:bd:82
inet 10.1.225.1 netmask 0xff00 broadcast 10.1.225.255
inet6 fe80::210:18ff:fee9:bd82%bxe1 prefixlen 64 scopeid 0x6
nd6 options=29
media: Ethernet autoselect (none)
status: no carrier

Enabled "Flying Monkeys" debug in bxe driver (via loader.conf 
hw.bxe.debug=0x and got this:

Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=71)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=71)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4957) Received 
SIOCSIFMEDIA/SIOCGIFMEDI
A ioctl (cmd=56)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4957) Received 
SIOCSIFMEDIA/SIOCGIFMEDI
A ioctl (cmd=56)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=58)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=107)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=150)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4957) Received 
SIOCSIFMEDIA/SIOCGIFMEDI
A ioctl (cmd=56)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=235)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=248)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=123)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=140)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=145)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=143)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=59)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=71)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=71)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4957) Received 
SIOCSIFMEDIA/SIOCGIFMEDI
A ioctl (cmd=56)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4957) Received 
SIOCSIFMEDIA/SIOCGIFMEDI
A ioctl (cmd=56)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=58)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=107)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=150)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4957) Received 
SIOCSIFMEDIA/SIOCGIFMEDI
A ioctl (cmd=56)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/usr/src/sys/modules/bxe/../../dev/bxe/bxe.c:4993) Received Unknown 
Ioctl (cmd=235)
Mar  4 09:21:02 asnas04 kernel: bxe0: 
bxe_ioctl(/us

misc/187261: FUSE kernel panic when using socket / bind

2014-03-04 Thread Kris Moore


>Number: 187261
>Category:   misc
>Synopsis:   FUSE kernel panic when using socket / bind
>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:   Tue Mar 04 18:10:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Kris Moore
>Release:10.0-RELEASE
>Organization:
iXsystems
>Environment:
FreeBSD krisdesktop 10.0-RELEASE FreeBSD 10.0-RELEASE-p4 #0: Tue Jan 14 
20:48:07 UTC 2014 r...@amd64-builder.pcbsd.org:/usr/obj/usr/src/sys/GENERIC 
 amd64
>Description:
I've run across an interesting bug in our fuse implementation. It looks like 
whenever a program running on the FUSE layer tries to create a socket() and 
then use bind(), it will immediately trigger a kernel panic. 

This is very likely the source of a number of fuse related kernel panics.

>How-To-Repeat:
I've attached an example to let you trigger this bug. Extract the archive and 
then compile "fusexmp.c" and socktest.c

% cc -Wall `pkg-config fuse --cflags --libs` fusexmp.c -o fusexmp
% cc socktest.c -o socktest

Now mount the fuse passthrough filesystem, chroot and run the socktest program. 
You should see an immediate kernel panic. 

# ./fusexmp /mnt
# chroot /mnt
# cd 
# ./socktest

>Fix:
The kernel panic messages refer to fuse_vnop_create() being the culprit, 
located in sys/fs/fuse/fuse_vnops.c



Patch attached with submission follows:

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#   .
#   ./fusexmp.c
#   ./socktest.c
#
echo c - .
mkdir -p . > /dev/null 2>&1
echo x - ./fusexmp.c
sed 's/^X//' >./fusexmp.c << 'e2b4462e60c1b7270abe13927239aced'
X/*
X  FUSE: Filesystem in Userspace
X  Copyright (C) 2001-2007  Miklos Szeredi 
X
X  This program can be distributed under the terms of the GNU GPL.
X  See the file COPYING.
X
X  gcc -Wall `pkg-config fuse --cflags --libs` fusexmp.c -o fusexmp
X*/
X
X#define FUSE_USE_VERSION 26
X
X#ifdef HAVE_CONFIG_H
X#include 
X#endif
X
X#ifdef linux
X/* For pread()/pwrite() */
X#define _XOPEN_SOURCE 500
X#endif
X
X#include 
X#include 
X#include 
X#include 
X#include 
X#include 
X#include 
X#include 
X#ifdef HAVE_SETXATTR
X#include 
X#endif
X
Xstatic int xmp_getattr(const char *path, struct stat *stbuf)
X{
X   int res;
X
X   res = lstat(path, stbuf);
X   if (res == -1)
X   return -errno;
X
X   return 0;
X}
X
Xstatic int xmp_access(const char *path, int mask)
X{
X   int res;
X
X   res = access(path, mask);
X   if (res == -1)
X   return -errno;
X
X   return 0;
X}
X
Xstatic int xmp_readlink(const char *path, char *buf, size_t size)
X{
X   int res;
X
X   res = readlink(path, buf, size - 1);
X   if (res == -1)
X   return -errno;
X
X   buf[res] = '\0';
X   return 0;
X}
X
X
Xstatic int xmp_readdir(const char *path, void *buf, fuse_fill_dir_t filler,
X  off_t offset, struct fuse_file_info *fi)
X{
X   DIR *dp;
X   struct dirent *de;
X
X   (void) offset;
X   (void) fi;
X
X   dp = opendir(path);
X   if (dp == NULL)
X   return -errno;
X
X   while ((de = readdir(dp)) != NULL) {
X   struct stat st;
X   memset(&st, 0, sizeof(st));
X   st.st_ino = de->d_ino;
X   st.st_mode = de->d_type << 12;
X   if (filler(buf, de->d_name, &st, 0))
X   break;
X   }
X
X   closedir(dp);
X   return 0;
X}
X
Xstatic int xmp_mknod(const char *path, mode_t mode, dev_t rdev)
X{
X   int res;
X
X   /* On Linux this could just be 'mknod(path, mode, rdev)' but this
X  is more portable */
X   if (S_ISREG(mode)) {
X   res = open(path, O_CREAT | O_EXCL | O_WRONLY, mode);
X   if (res >= 0)
X   res = close(res);
X   } else if (S_ISFIFO(mode))
X   res = mkfifo(path, mode);
X   else
X   res = mknod(path, mode, rdev);
X   if (res == -1)
X   return -errno;
X
X   return 0;
X}
X
Xstatic int xmp_mkdir(const char *path, mode_t mode)
X{
X   int res;
X
X   res = mkdir(path, mode);
X   if (res == -1)
X   return -errno;
X
X   return 0;
X}
X
Xstatic int xmp_unlink(const char *path)
X{
X   int res;
X
X   res = unlink(path);
X   if (res == -1)
X   return -errno;
X
X   return 0;
X}
X
Xstatic int xmp_rmdir(const char *path)
X{
X   int res;
X
X   res = rmdir(path);
X   if (res == -1)
X   return -errno;
X
X   return 0;
X}
X
Xstatic int xmp_symlink(const char *from, const char *to)
X{
X   int res;
X
X

Re: misc/187261: FUSE kernel panic when using socket / bind

2014-03-04 Thread Kris Moore

The following reply was made to PR misc/187261; it has been noted by GNATS.

From: Kris Moore 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: misc/187261: FUSE kernel panic when using socket / bind
Date: Tue, 04 Mar 2014 13:35:37 -0500

 You can download the text-dump from the system below.
 
 http://web.pcbsd.org/~kris/textdump-fusesocket.tar
 
 -- 
 Kris Moore
 PC-BSD Software
 iXsystems
 
___
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"

bin/187264: rm command: rm -r file1 file2 "" does not remove existing files or directories

2014-03-04 Thread John Wolfe


>Number: 187264
>Category:   bin
>Synopsis:   rm command: rm -r file1 file2 "" does not remove existing 
>files or directories
>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:   Tue Mar 04 21:50:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: John Wolfe
>Release:FreeBSD 9.2   (PC-BSD 9.2)
>Organization:
Xinuos, Inc.
>Environment:
FreeBSD sapphire.nj.sco.com 9.2-RELEASE-p12 FreeBSD 9.2-RELEASE-p12 #0: Thu Jan 
16 21:12:30 UTC 2014 
r...@amd64-builder.pcbsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

>Description:
When the gmake/make clean target contains a command of the form

   rm -rf "a.out" "$(DSYM)"  main.o main.d

the  command fails to remove any of the existing files if DSYM is null.
The '-f' option hides the error associated with the zero length file name, but 
gives no indication that, in fact, NO files/directories have been removed.


>How-To-Repeat:
Use the following script to see the problem

rm.bug.sh:
==
#! /bin/sh
set -x

cat  > file_1 << !EOF
12345
How no brown cow
!EOF
cp file_1 file_2
cp file_1 file_3

# The following command should remove file_[123], but does not.
# The '-r' implies the '-d' option - attempt to remove directories 
# as well as other types of files.The "" results in an error 
# when treated as a possible directory.
#
#  $ rm -r ""
#  rm: fts_open: No such file or directory
#
# which is a valid error, but none of the arguments are removed.
# 
# When the following command is run without the '-r', all three 
# files are removed.


rm -r "file_1" "" file_[23]

ls -l

# Yet a "rm -r " with a non-existant file in the list, will remove 
# all existing files.

rm -r "file_1" "xxx" file_2

ls -l

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

bin/187265: Passing -P to daemon(8) doesn't spawn child in an external process

2014-03-04 Thread Kimo R


>Number: 187265
>Category:   bin
>Synopsis:   Passing -P to daemon(8) doesn't spawn child in an external 
>process
>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:   Tue Mar 04 23:10:01 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Kimo R
>Release:10.0-RELEASE
>Organization:
>Environment:
>Description:
The manpage for daemon(8) says that with the -P (write daemon's pid to a file) 
flag, the program is spawned in a child process. However, passing -P doesn't 
cause the program to actually spawn in a child process.
>How-To-Repeat:
daemon -P /tmp/foo.pid some_long_running_process
>Fix:
This patch checks if -P was given in the same place as the check for -p (and -r)

Patch attached with submission follows:

--- ./daemon.c.orig 2014-03-04 22:20:17.0 +
+++ ./daemon.c  2014-03-04 22:23:29.0 +
@@ -139,7 +139,7 @@
 * get SIGCHLD eventually.
 */
pid = -1;
-   if (pidfile != NULL || restart) {
+   if (pidfile != NULL || ppidfile != NULL || restart) {
/*
 * Restore default action for SIGTERM in case the
 * parent process decided to ignore it.


>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: bin/187264: rm command: rm -r file1 file2 "" does not remove existing files or directories

2014-03-04 Thread Jilles Tjoelker

The following reply was made to PR bin/187264; it has been noted by GNATS.

From: Jilles Tjoelker 
To: bug-follo...@freebsd.org, j...@xinuos.com
Cc:  
Subject: Re: bin/187264: rm command: rm -r file1 file2 "" does not
 remove existing files or directories
Date: Wed, 5 Mar 2014 00:23:15 +0100

 In PR bin/187264, you wrote:
 > When the gmake/make clean target contains a command of the form
 
 > rm -rf "a.out" "$(DSYM)" main.o main.d
 
 > the command fails to remove any of the existing files if DSYM is null.
 > The '-f' option hides the error associated with the zero length file
 > name, but gives no indication that, in fact, NO files/directories have
 > been removed.
 
 I can reproduce this, not only with rm, but also with ls, cp and find.
 The underlying fts_open(3) fails if any pathname is empty and causes the
 entire command to fail. If a pathname otherwise does not refer to an
 existing file, this correctly does not prevent processing of other
 pathnames.
 
 The below patch makes fts_open(3) treat an empty pathname like any other
 pathname that cannot be lstatted because of [ENOENT]. It is lightly
 tested.
 
 Index: lib/libc/gen/fts.c
 ===
 --- lib/libc/gen/fts.c (revision 262358)
 +++ lib/libc/gen/fts.c (working copy)
 @@ -161,11 +161,7 @@ fts_open(argv, options, compar)
  
/* Allocate/initialize root(s). */
for (root = NULL, nitems = 0; *argv != NULL; ++argv, ++nitems) {
 -  /* Don't allow zero-length paths. */
 -  if ((len = strlen(*argv)) == 0) {
 -  errno = ENOENT;
 -  goto mem3;
 -  }
 +  len = strlen(*argv);
  
p = fts_alloc(sp, *argv, len);
p->fts_level = FTS_ROOTLEVEL;
 
 -- 
 Jilles Tjoelker
___
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"

bin/187266: clang 3.4 aborts when building math/py-numeric with -march=athlon64 on i386

2014-03-04 Thread Don Lewis


>Number: 187266
>Category:   bin
>Synopsis:   clang 3.4 aborts when building math/py-numeric with 
>-march=athlon64 on i386
>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:   Wed Mar 05 00:00:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Don Lewis
>Release:FreeBSD 11.0-CURRENT i386
>Organization:
FreeBSD Project
>Environment:
System: FreeBSD scratch.catspoiler.org 11.0-CURRENT FreeBSD 11.0-CURRENT #71 
r262666M: Sat Mar 1 16:42:54 PST 2014 
d...@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB

Ports tree revision r346717.

py27-numeric-24.2_3


>Description:

When attempting to build math/py-numeric on a machine with an Athlon 64
CPU running in i386 mode, clang 3.4 aborts while compiling the dlaed3_()
function in the file dlapack_lite.c.

cc -DNDEBUG -O2 -pipe -march=athlon64 -fno-strict-aliasing -fPIC -IInclude 
-IPackages/FFT/Include -IPackages/RNG/Include -I/usr/local/include/python2.7 -c 
Src/dlapack_lite.c -o 
build/temp.freebsd-11.0-CURRENT-i386-2.7/Src/dlapack_lite.o
Instruction does not dominate all uses!
  %arrayidx106 = getelementptr inbounds double* %dlamda, i32 %sub83
  %bound1492 = icmp ule double* %arrayidx106, %scevgep473
Instruction does not dominate all uses!
  %arrayidx106 = getelementptr inbounds double* %dlamda, i32 %sub83
  %bound0491 = icmp ule double* %scevgep471, %arrayidx106
Broken module found, compilation aborted!
Stack dump:
0.  Program arguments: /usr/bin/cc -cc1 -triple i386-unknown-freebsd11.0 
-emit-obj -disable-free -main-file-name dlapack_lite.c -mrelocation-model pic 
-pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose 
-mconstructor-aliases -target-cpu athlon64 -coverage-file 
/usr/ports/math/py-numeric/work/Numeric-24.2/build/temp.freebsd-11.0-CURRENT-i386-2.7/Src/dlapack_lite.o
 -resource-dir /usr/bin/../lib/clang/3.4 -D NDEBUG -I Include -I 
Packages/FFT/Include -I Packages/RNG/Include -I /usr/local/include/python2.7 
-O2 -fdebug-compilation-dir /usr/ports/math/py-numeric/work/Numeric-24.2 
-ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gnustep 
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp 
-o build/temp.freebsd-11.0-CURRENT-i386-2.7/Src/dlapack_lite.o -x c 
Src/dlapack_lite.c 
1.   parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module 'Src/dlapack_lite.c'.
4.  Running pass 'Module Verifier' on function '@dlaed3_'
cc: error: unable to execute command: Abort trap (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see 
invocation)
FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
Target: i386-unknown-freebsd11.0
Thread model: posix
cc: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ 
and include the crash backtrace, preprocessed source, and associated run script.
cc: note: diagnostic msg: 


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/dlapack_lite-26ef53.c
cc: note: diagnostic msg: /tmp/dlapack_lite-26ef53.sh
cc: note: diagnostic msg: 


error: command 'cc' failed with exit status 254
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/math/py-numeric
*** Error code 1

Stop.
make: stopped in /usr/ports/math/py-numeric


The compilation succeeds if -march=athlon64 is *not* specified.

A bug report has been filed upstream:



>How-To-Repeat:

Attempt to compile dlapack_lite.c from math/py-numeric with clang 3.4
on i386 with the -march=athlon64 flag.

>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: kern/187074: Crash cross compilation for MIPS

2014-03-04 Thread glebius

Synopsis: Crash cross compilation for MIPS

State-Changed-From-To: open->closed
State-Changed-By: glebius
State-Changed-When: Wed Mar 5 00:40:37 UTC 2014
State-Changed-Why: 
Fixed.


Responsible-Changed-From-To: freebsd-bugs->glebius
Responsible-Changed-By: glebius
Responsible-Changed-When: Wed Mar 5 00:40:37 UTC 2014
Responsible-Changed-Why: 
Fixed.

http://www.freebsd.org/cgi/query-pr.cgi?pr=187074
___
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/187268: graphics/libopenraw-0.0.8 fails to build/install during configure stage -- can't find Boost unit_test_framework library

2014-03-04 Thread C Hutchinson


>Number: 187268
>Category:   misc
>Synopsis:   graphics/libopenraw-0.0.8 fails to build/install during 
>configure stage -- can't find Boost unit_test_framework library
>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:   Wed Mar 05 01:50:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: C Hutchinson
>Release:8.4-STABLE
>Organization:
>Environment:
FreeBSD ns0 8.4-STABLE FreeBSD 8.4-STABLE #0 r262568: Thu Feb 27 14:27:03 PST 
2014 root@ns0:/usr/obj/usr/src/sys/NS0  amd64
>Description:
Any attempt to build graphics/libopenraw fail during the configure stage:

..
checking for the toolset name used by Boost for c++... gcc42
checking boost/test/unit_test.hpp usability... yes
checking boost/test/unit_test.hpp presence... yes
checking for boost/test/unit_test.hpp... yes
checking for the Boost unit_test_framework library... no
configure: error: Could not find the flags to link with Boost unit_test_framewor
k
===>  Script "configure" failed unexpectedly.
Please report the problem to po...@freebsd.org [maintainer] and attach the
"/usr/ports/graphics/libopenraw/work/libopenraw-0.0.8/config.log" including
the output of the failure of your make command. Also, it might be a good idea
to provide an overview of all packages installed on your system (e.g. a
/usr/sbin/pkg_info -Ea).
*** Error code 1

Stop in /usr/ports/graphics/libopenraw.
*** Error code 1

Stop in /usr/ports/graphics/libopenraw.

OK. That's BS. I have Boost installed, and many other ports which depend on it
build just fine.

Let's see now:

# ls /usr/local/include/boost/test


auto_unit_test.hpp
debug.hpp
debug_config.hpp
detail
exception_safety.hpp
execution_monitor.hpp
floating_point_comparison.hpp
framework.hpp
impl
included
interaction_based.hpp
logged_expectations.hpp
minimal.hpp
mock_object.hpp
output
output_test_stream.hpp
parameterized_test.hpp
predicate_result.hpp
prg_exec_monitor.hpp
progress_monitor.hpp
results_collector.hpp
results_reporter.hpp
test_case_template.hpp
test_exec_monitor.hpp
test_observer.hpp
test_tools.hpp
unit_test.hpp
unit_test_log.hpp
unit_test_log_formatter.hpp
unit_test_monitor.hpp
unit_test_suite.hpp
unit_test_suite_impl.hpp
utils

Yep. All the needed headers are there. But it was complaining about libs.
Let's see...

# ls /usr/local/lib/libboost_unit*

/usr/local/lib/libboost_unit_test_framework.a
/usr/local/lib/libboost_unit_test_framework.so
/usr/local/lib/libboost_unit_test_framework.so.1.55.0
/usr/local/lib/libboost_unit_test_framework.so.5

Yep. The needed libs are there too. So what exactly is the problem?!

Thank you for any time, and consideration, in this matter

--Chris

>How-To-Repeat:
attempt to build graphics/libopenraw

>Fix:
Beats me?


>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: ports/187268: graphics/libopenraw: graphics/libopenraw-0.0.8 fails to build/install during configure stage -- can't find Boost unit_test_framework library

2014-03-04 Thread gjb

Old Synopsis: graphics/libopenraw-0.0.8 fails to build/install during configure 
stage -- can't find Boost unit_test_framework library
New Synopsis: graphics/libopenraw: graphics/libopenraw-0.0.8 fails to 
build/install during configure stage -- can't find Boost unit_test_framework 
library

Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs
Responsible-Changed-By: gjb
Responsible-Changed-When: Wed Mar 5 01:53:06 UTC 2014
Responsible-Changed-Why: 
Ports PR.


http://www.freebsd.org/cgi/query-pr.cgi?pr=187268
___
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/187258: [bxe] BCM57810 bxe(4) unstable/fails to initialize

2014-03-04 Thread linimon

Old Synopsis: BCM57810 bxe(4) unstable/fails to initialize
New Synopsis: [bxe] BCM57810 bxe(4) unstable/fails to initialize

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Mar 5 03:24:00 UTC 2014
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=187258
___
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/187261: [fuse] FUSE kernel panic when using socket / bind

2014-03-04 Thread linimon

Old Synopsis: FUSE kernel panic when using socket / bind
New Synopsis: [fuse] FUSE kernel panic when using socket / bind

Responsible-Changed-From-To: freebsd-bugs->freebsd-fs
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Mar 5 03:25:57 UTC 2014
Responsible-Changed-Why: 
reclassify.

http://www.freebsd.org/cgi/query-pr.cgi?pr=187261
___
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/187269: AF-4Kn SATA drives have mis-interpreted sector sizes

2014-03-04 Thread Ravi Pokala


>Number: 187269
>Category:   misc
>Synopsis:   AF-4Kn SATA drives have mis-interpreted sector sizes
>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:   Wed Mar 05 04:20:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Ravi Pokala
>Release:10-STABLE r262757
>Organization:
Panasas, Inc.
>Environment:
FreeBSD mau-kennedy-1a 10.0-STABLE FreeBSD 10.0-STABLE #0 r262757M: Tue Mar  4 
17:24:53 PST 2014 root@mau-kennedy-1a:/usr/obj/usr/src/sys/GENERIC  amd64

>Description:
AF-4Kn SATA drives (4KB logical sector size, 4KB physical sector size) are 
being identified as having 2KB logical sectors and 512-byte physical sectors. 
This leads to data access timing out, the GPT being unreadable, and general 
uselessness.

The drive that I was using when I discovered this problem is an engineering 
sample under NDA, so I have obscured the model/firmware/serial/WWN; sorry about 
that. The label states that the capacity is 5.0TB and that there are 1220942646 
LBAs.


/var/run/dmesg.boot (comments indented):

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0:  ATA-9 SATA 3.x device
ada0: Serial Number DRIVE-SERIAL-NUMBER
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 4096bytes)
ada0: Command Queueing enabled
ada0: 2384653MB (1220942646 2048 byte sectors: 16H 63S/T 16383C)
Incorrect capacity
Correct number of logical sectors, but incorrect sector size
ada0: Previously was known as ad4
(ada0:ahcich0:0:0:0): READ_DMA48. ACB: 25 00 f7 1a c6 40 48 00 00 00 04 00
(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid
(ada0:ahcich0:0:0:0): Error 22, Unretryable error
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 01 34 1b c6 40 48 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid
(ada0:ahcich0:0:0:0): Error 22, Unretryable error
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 01 34 1b c6 40 48 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid
(ada0:ahcich0:0:0:0): Error 22, Unretryable error
GEOM: ada0: corrupt or invalid GPT detected.
GEOM: ada0: GPT rejected -- may not be recoverable.
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 20 00 00 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 20 00 00 00 00 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 04 00 00 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 04 00 00 00 00 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 00 00 00 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 00 00 00 00 00 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 80 00 00 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 80 00 00 00 00 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 20 00 00 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 20 00 00 00 00 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 04 00 00 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 04 00 00 00 00 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 00 00 00 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 00 00 00 00 00 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 80 00 00 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 80 00 00 00 00 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 04 f7 1a c6 40 48 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: ATA Status Error
(ada0:ahcich0:0:0:0): ATA status: 41 (DRDY ERR), error: 84 (ICRC ABRT )
(ada0:ahcich0:0:0:0): RES: 41 84 f7 1a c6 00 48 00 00 00 00
5 attempts
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 01 34 1b c6 40 48 00

misc/187258: BCM57810 bxe(4) unstable/fails to initialize

misc/187261: FUSE kernel panic when using socket / bind

Re: misc/187261: FUSE kernel panic when using socket / bind

bin/187264: rm command: rm -r file1 file2 "" does not remove existing files or directories

bin/187265: Passing -P to daemon(8) doesn't spawn child in an external process

Re: bin/187264: rm command: rm -r file1 file2 "" does not remove existing files or directories

bin/187266: clang 3.4 aborts when building math/py-numeric with -march=athlon64 on i386

Re: kern/187074: Crash cross compilation for MIPS

misc/187268: graphics/libopenraw-0.0.8 fails to build/install during configure stage -- can't find Boost unit_test_framework library

Re: ports/187268: graphics/libopenraw: graphics/libopenraw-0.0.8 fails to build/install during configure stage -- can't find Boost unit_test_framework library

Re: kern/187258: [bxe] BCM57810 bxe(4) unstable/fails to initialize

Re: kern/187261: [fuse] FUSE kernel panic when using socket / bind

misc/187269: AF-4Kn SATA drives have mis-interpreted sector sizes

13 matches

Site Navigation

Mail list logo

Footer information