Re: Zpool surgery

2013-01-30 Thread Ulrich Spörlein
On Tue, 2013-01-29 at 15:52:50 +0100, Fabian Keil wrote:
 Dan Nelson dnel...@allantgroup.com wrote:
 
  In the last episode (Jan 28), Fabian Keil said:
   Ulrich Spörlein u...@freebsd.org wrote:
On Mon, 2013-01-28 at 07:11:40 +1100, Peter Jeremy wrote:
 On 2013-Jan-27 14:31:56 -, Steven Hartland 
 kill...@multiplay.co.uk wrote:
 - Original Message - 
 From: Ulrich Spörlein u...@freebsd.org
  I want to transplant my old zpool tank from a 1TB drive to a new
  2TB drive, but *not* use dd(1) or any other cloning mechanism, as
  the pool was very full very often and is surely severely
  fragmented.
 
 Cant you just drop the disk in the original machine, set it as a
 mirror then once the mirror process has completed break the mirror
 and remove the 1TB disk.
 
 That will replicate any fragmentation as well.  zfs send | zfs recv
 is the only (current) way to defragment a ZFS pool.
   
   It's not obvious to me why zpool replace (or doing it manually)
   would replicate the fragmentation.
  
  zpool replace essentially adds your new disk as a mirror to the parent
  vdev, then deletes the original disk when the resilver is done.  Since
  mirrors are block-identical copies of each other, the new disk will contain
  an exact copy of the original disk, followed by 1TB of freespace.
 
 Thanks for the explanation.
 
 I was under the impression that zfs mirrors worked at a higher
 level than traditional mirrors like gmirror but there seems to
 be indeed less magic than I expected.
 
 Fabian

To wrap this up, while the zpool replace worked for the disk, I played
around with it some more, and using snapshots instead *did* work the
second time. I'm not sure what I did wrong the first time ...

So basically this:
# zfs send -R oldtank@2013-01-22 | zfs recv -F -d newtank
(takes ages, then do a final snapshot before unmounting and send the
incremental)
# zfs send -R -i 2013-01-22 oldtank@2013-01-29 | zfs recv -F -d newtank

Allows me to send snapshots up to 2013-01-29 to the archive pool from
either oldtank or newtank. Yay!

Cheers,
Uli
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

stable/8 to HEAD

2013-01-30 Thread Sergey V. Dyatko
Hi,

Possible stupid question, but.. Can I update my stable/8 r228757 to
HEAD? 

sandbox# svnversion
246112
sandbox# cat /etc/src.conf
WITHOUT_PROFILE=YES
WITHOUT_GAMES=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_FREEBSD_UPDATE=YES
WITHOUT_LPR=YES
WITHOUT_NDIS=YES
WITHOUT_WPA_SUPPLICANT_EAPOL=YES
WITHOUT_WIRELESS_SUPPORT=YES
WITHOUT_WIRELESS=YES

sandbox# cat /etc/make.conf
# added by use.perl 2011-01-12 09:43:24
PERL_VERSION=5.10.1

sandbox# make buildworld

[skipped]
=== usr.bin/lex/lib (all)
cc  -O2 -pipe -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include
-c /usr/src/usr.bin/lex/lib/libmain.c -o libmain.o cc  -O2 -pipe
-std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include
-c /usr/src/usr.bin/lex/lib/libyywrap.c -o libyywrap.o building static
ln library ranlib libln.a sh /usr/src/tools/install.sh -s -o root -g
wheel -m 555   lex /usr/obj/usr/src/tmp/legacy/usr/bin
sh /usr/src/tools/install.sh -C -o root -g wheel -m
444  /usr/src/usr.bin/lex/FlexLexer.h /usr/obj/usr/src/tmp/legacy/usr/include
=== usr.bin/lex/lib (install) sh /usr/src/tools/install.sh -C -o root
-g wheel -m 444
libln.a /usr/obj/usr/src/tmp/legacy/usr/lib 
/usr/obj/usr/src/tmp/legacy/usr/lib/libl.a
- /usr/obj/usr/src/tmp/legacy/usr/lib/libln.a 
/usr/obj/usr/src/tmp/legacy/usr/lib/libfl.a
- /usr/obj/usr/src/tmp/legacy/usr/lib/libln.a 
/usr/obj/usr/src/tmp/legacy/usr/bin/lex++
- /usr/obj/usr/src/tmp/legacy/usr/bin/lex 
/usr/obj/usr/src/tmp/legacy/usr/bin/flex
- /usr/obj/usr/src/tmp/legacy/usr/bin/lex 
/usr/obj/usr/src/tmp/legacy/usr/bin/flex++
- /usr/obj/usr/src/tmp/legacy/usr/bin/lex === usr.bin/xinstall
(obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/xinstall
created for /usr/src/usr.bin/xinstall rm -f .depend mkdep -f .depend
-a-I/usr/src/usr.bin/xinstall/../../contrib/mtree
-I/usr/src/usr.bin/xinstall/../../lib/libnetbsd
-I/usr/obj/usr/src/tmp/legacy/usr/include
-std=gnu99   /usr/src/usr.bin/xinstall/xinstall.c 
/usr/src/usr.bin/xinstall/../../contrib/mtree/getid.c 
/usr/src/usr.bin/xinstall/xinstall.c:64:20:
error: sha512.h: No such file or directory mkdep: compile failed ***
[.depend] Error code 1

Stop in /usr/src/usr.bin/xinstall.
*** [bootstrap-tools] Error code 1

Stop in /usr/src.
*** [_bootstrap-tools] Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

-- 
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: mounting root from NFS via ROOTDEVNAME

2013-01-30 Thread Eggert, Lars
Hi,

On Jan 30, 2013, at 10:32, Eggert, Lars l...@netapp.com wrote:
 On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote:
 In src/sys/boot/common/boot.c which is part of the loader (not the kernel),
 if you look in the getrootmount() function,
 you will see that the loader will try to figure out where the root file
 system
 is by parsing /etc/fstab, and looking for the / mount.
 
 So, if your kernel is located in:
 
  /usr/home/elars/dst/boot/kernel/kernel
 
 Then create a file /usr/home/elars/dst/etc/fstab file with something like:
 
 # Device MountpointFSType
 Options  Dump Pass
 10.11.12.13:/usr/home/elars/dst/   / nfs  ro00
 
 Thanks, will try that!

doesn't work.

The kernel never leaves the DHCP/BOOTP timeout for server-loop unless I hand 
out a root-path option via DHCP.

I tried your tip above, I tried setting ROOTDEVNAME in the kernel, I created a 
/boot.config with -r in it on the NFS root - all to no avail. 

 Alternatively, if you don't want to create an /etc/fstab file, then
 you could put something like this in your loader.conf file:
 
 vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst
 
 Will try that too, but not sure if this works with our custom loader.

Doesn't seem to work either.

Lars
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: stable/8 to HEAD

2013-01-30 Thread Konstantin Belousov
On Wed, Jan 30, 2013 at 01:11:30PM +0300, Sergey V. Dyatko wrote:
 Hi,
 
 Possible stupid question, but.. Can I update my stable/8 r228757 to
 HEAD? 
You need at least r231588.

Generally, only updates from the latest last stable branches are supported,
i.e. latest stable/9.

From the hand-on experience, it does work to update from even a year-old
stable/8, assuming you do make all install in the _latest_ checkout of
stable/8/lib/libmd and add auditdistd user.

 
 sandbox# svnversion
 246112
 sandbox# cat /etc/src.conf
 WITHOUT_PROFILE=YES
 WITHOUT_GAMES=YES
 WITHOUT_BLUETOOTH=YES
 WITHOUT_FREEBSD_UPDATE=YES
 WITHOUT_LPR=YES
 WITHOUT_NDIS=YES
 WITHOUT_WPA_SUPPLICANT_EAPOL=YES
 WITHOUT_WIRELESS_SUPPORT=YES
 WITHOUT_WIRELESS=YES
 
 sandbox# cat /etc/make.conf
 # added by use.perl 2011-01-12 09:43:24
 PERL_VERSION=5.10.1
 
 sandbox# make buildworld
 
 [skipped]
 === usr.bin/lex/lib (all)
 cc  -O2 -pipe -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include
 -c /usr/src/usr.bin/lex/lib/libmain.c -o libmain.o cc  -O2 -pipe
 -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include
 -c /usr/src/usr.bin/lex/lib/libyywrap.c -o libyywrap.o building static
 ln library ranlib libln.a sh /usr/src/tools/install.sh -s -o root -g
 wheel -m 555   lex /usr/obj/usr/src/tmp/legacy/usr/bin
 sh /usr/src/tools/install.sh -C -o root -g wheel -m
 444  /usr/src/usr.bin/lex/FlexLexer.h /usr/obj/usr/src/tmp/legacy/usr/include
 === usr.bin/lex/lib (install) sh /usr/src/tools/install.sh -C -o root
 -g wheel -m 444
 libln.a /usr/obj/usr/src/tmp/legacy/usr/lib 
 /usr/obj/usr/src/tmp/legacy/usr/lib/libl.a
 - /usr/obj/usr/src/tmp/legacy/usr/lib/libln.a 
 /usr/obj/usr/src/tmp/legacy/usr/lib/libfl.a
 - /usr/obj/usr/src/tmp/legacy/usr/lib/libln.a 
 /usr/obj/usr/src/tmp/legacy/usr/bin/lex++
 - /usr/obj/usr/src/tmp/legacy/usr/bin/lex 
 /usr/obj/usr/src/tmp/legacy/usr/bin/flex
 - /usr/obj/usr/src/tmp/legacy/usr/bin/lex 
 /usr/obj/usr/src/tmp/legacy/usr/bin/flex++
 - /usr/obj/usr/src/tmp/legacy/usr/bin/lex === usr.bin/xinstall
 (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/xinstall
 created for /usr/src/usr.bin/xinstall rm -f .depend mkdep -f .depend
 -a-I/usr/src/usr.bin/xinstall/../../contrib/mtree
 -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd
 -I/usr/obj/usr/src/tmp/legacy/usr/include
 -std=gnu99   /usr/src/usr.bin/xinstall/xinstall.c 
 /usr/src/usr.bin/xinstall/../../contrib/mtree/getid.c 
 /usr/src/usr.bin/xinstall/xinstall.c:64:20:
 error: sha512.h: No such file or directory mkdep: compile failed ***
 [.depend] Error code 1
 
 Stop in /usr/src/usr.bin/xinstall.
 *** [bootstrap-tools] Error code 1
 
 Stop in /usr/src.
 *** [_bootstrap-tools] Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 
 -- 
 wbr, tiger
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


pgpal7Xu8E3tT.pgp
Description: PGP signature


buildworld errors

2013-01-30 Thread Jesse
I updated /usr/src and buildworld just now.
The building process stopped at here. It's FreeBSD 10.0

=== lib/clang/libllvmlinker (all)
=== lib/clang/libllvmmc (all)
=== lib/clang/libllvmmcparser (all)
=== lib/clang/libllvmobject (all)
=== lib/clang/libllvmscalaropts (all)
=== lib/clang/libllvmselectiondag (all)
=== lib/clang/libllvmsupport (all)
=== lib/clang/libllvmtablegen (all)
=== lib/clang/libllvmtarget (all)
=== lib/clang/libllvmtransformutils (all)
=== lib/clang/libllvmvectorize (all)
=== lib/clang/libllvmarmasmparser (all)
=== lib/clang/libllvmarmcodegen (all)
=== lib/clang/libllvmarmdesc (all)
=== lib/clang/libllvmarmdisassembler (all)
=== lib/clang/libllvmarminfo (all)
=== lib/clang/libllvmarminstprinter (all)
=== lib/clang/libllvmmipsasmparser (all)
=== lib/clang/libllvmmipscodegen (all)
=== lib/clang/libllvmmipsdesc (all)
=== lib/clang/libllvmmipsdisassembler (all)
=== lib/clang/libllvmmipsinfo (all)
=== lib/clang/libllvmmipsinstprinter (all)
=== lib/clang/libllvmpowerpccodegen (all)
=== lib/clang/libllvmpowerpcdesc (all)
=== lib/clang/libllvmpowerpcinfo (all)
=== lib/clang/libllvmpowerpcinstprinter (all)
=== lib/clang/libllvmx86asmparser (all)
=== lib/clang/libllvmx86codegen (all)
=== lib/clang/libllvmx86desc (all)
=== lib/clang/libllvmx86disassembler (all)
=== lib/clang/libllvmx86info (all)
=== lib/clang/libllvmx86instprinter (all)
=== lib/clang/libllvmx86utils (all)
=== lib/clang/libllvmdebuginfo (all)
=== lib/clang/libllvmexecutionengine (all)
=== lib/clang/libllvminterpreter (all)
=== lib/clang/libllvmjit (all)
=== lib/clang/libllvmmcdisassembler (all)
=== lib/clang/libllvmmcjit (all)
=== lib/clang/libllvmruntimedyld (all)
=== lib/clang/include (all)
1 error
*** [everything] Error code 2
1 error
*** [buildworld] Error code 2
1 error
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: buildworld error

2013-01-30 Thread Dimitry Andric

On 2013-01-30 10:37, Jesse wrote:

I just update /usr/src and make buildworld. The building proccess stop as
errors:

=== lib/clang/libllvmx86asmparser (all)
=== lib/clang/libllvmx86codegen (all)
=== lib/clang/libllvmx86desc (all)
=== lib/clang/libllvmx86disassembler (all)
=== lib/clang/libllvmx86info (all)
=== lib/clang/libllvmx86instprinter (all)
=== lib/clang/libllvmx86utils (all)
=== lib/clang/libllvmdebuginfo (all)
=== lib/clang/libllvmexecutionengine (all)
=== lib/clang/libllvminterpreter (all)
=== lib/clang/libllvmjit (all)
=== lib/clang/libllvmmcdisassembler (all)
=== lib/clang/libllvmmcjit (all)
=== lib/clang/libllvmruntimedyld (all)
=== lib/clang/include (all)
1 error
*** [everything] Error code 2
1 error
*** [buildworld] Error code 2
1 error


Because you are making buildworld with -j, the actual error message is
not visible.  Try searching back in the log to find the actual error,
and post that.  Alternatively, make buildworld without -j.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: mounting root from NFS via ROOTDEVNAME

2013-01-30 Thread Ian Lepore
On Wed, 2013-01-30 at 09:32 +, Eggert, Lars wrote:
 Hi,
 
 On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote:
  What kind of architecture are you trying to do this on?  Is this
  i386/amd64 or something else?
 
 amd64
 
   I am not familiar with netboot compared to
  PXE.  Is TFTP involved at all with netboot?
 
 TFTP is not involved. The kernel gets booted by our custom loader (over HTTP) 
 and the root FS is supposed to be mounted over NFS.
 
  What does your dhcpd configuration file look like?
 
 Completely standard, with the addition of a root-path option. (Which I 
 would like to get rid of by setting ROOTDEVNAME in the kernel.)
 
  Also, are you using the FreeBSD loader, or something else?  What kinds of
  customizations have you done on the loader?
 
 Custom loader. 
 
  If through your setup you have already managed to load the kernel over
  the network, then a lot of the hard work has been done.  Telling the kernel
  where the root file system is located becomes the next tricky part.
 
 Right, that's the step I am struggeling with. 
 
  In src/sys/boot/common/boot.c which is part of the loader (not the kernel),
  if you look in the getrootmount() function,
  you will see that the loader will try to figure out where the root file
  system
  is by parsing /etc/fstab, and looking for the / mount.
  
  So, if your kernel is located in:
  
/usr/home/elars/dst/boot/kernel/kernel
  
  Then create a file /usr/home/elars/dst/etc/fstab file with something like:
  
  # Device MountpointFSType
  Options  Dump Pass
  10.11.12.13:/usr/home/elars/dst/   / nfs  ro00
 
 Thanks, will try that!
 
  Alternatively, if you don't want to create an /etc/fstab file, then
  you could put something like this in your loader.conf file:
  
  vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst
 
 Will try that too, but not sure if this works with our custom loader.
 
 Lars
 
  
  If you can get this to work without introducing new kernel options,
  that would be ideal, because the kernel options you are
  enabling are triggering behaviors.
  

Just FYI, I believe the current behavior of BOOTP and BOOTP_NFSROOT is a
bug, and I've entered a PR for it 

  http://www.freebsd.org/cgi/query-pr.cgi?pr=175671

I also put a little effort into changing the behavior so that BOOTP
without BOOTP_NFSROOT gets you an address and then moves on to use the
ROOTDEVNAME you have configured, but I didn't have any success yet (it
stays stuck in the state of waiting for the root path).  I intend to get
back to it after wrapping up some other work, if someone else doesn't
get to it first.

-- Ian


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


x11/nvidia-driver build fails in head @r246115

2013-01-30 Thread David Wolfskill
I include

PORTS_MODULES=x11/nvidia-driver

in /etc/src.conf in order to keep nvidia-driver in sync with my kernel.

It last built OK yesterday, @r246057; @r246115, I see:

===   nvidia-driver-304.64 depends on file: 
/usr/local/libdata/pkgconfig/xorg-server.pc - found
===   nvidia-driver-304.64 depends on shared library: GL.1 - found
===  Configuring for nvidia-driver-304.64
===  Building for nvidia-driver-304.64
=== src (all)
@ - /usr/src/sys
machine - /usr/src/sys/i386/include
x86 - /usr/src/sys/x86/include
awk -f @/tools/makeobjops.awk @/kern/device_if.m -h
awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h
awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\304.64\ 
-D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG 
-DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I. -I@ -I@/contrib/altq 
-fno-common   -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding 
-fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -c nvidia_ctl.c
clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\304.64\ 
-D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG 
-DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I. -I@ -I@/contrib/altq 
-fno-common   -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding 
-fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -c nvidia_dev.c
clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\304.64\ 
-D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG 
-DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I. -I@ -I@/contrib/altq 
-fno-common   -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding 
-fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -c nvidia_i2c.c
clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\304.64\ 
-D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG 
-DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I. -I@ -I@/contrib/altq 
-fno-common   -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding 
-fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -c nvidia_linux.c
nvidia_linux.c:51:28: error: variable has incomplete type 'struct 
linux_ioctl_handler'
struct linux_ioctl_handler nvidia_handler = {
   ^
nvidia_linux.c:51:8: note: forward declaration of 'struct linux_ioctl_handler'
struct linux_ioctl_handler nvidia_handler = {
   ^
nvidia_linux.c:62:5: error: implicit declaration of function 
'linux_ioctl_register_handler' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
linux_ioctl_register_handler(nvidia_handler);
^
nvidia_linux.c:69:5: error: implicit declaration of function 
'linux_ioctl_unregister_handler' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
linux_ioctl_unregister_handler(nvidia_handler);
^
nvidia_linux.c:69:5: note: did you mean 'linux_ioctl_register_handler'?
linux_ioctl_unregister_handler(nvidia_handler);
^~
linux_ioctl_register_handler
nvidia_linux.c:62:5: note: 'linux_ioctl_register_handler' declared here
linux_ioctl_register_handler(nvidia_handler);
^
3 errors generated.
*** [nvidia_linux.o] Error code 1

Stop in 
/common/S4/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-304.64/src.
*** [all] Error code 1

Stop in 
/common/S4/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-304.64.
*** [do-build] Error 

Re: mounting root from NFS via ROOTDEVNAME

2013-01-30 Thread Rick Macklem
Lars Eggert wrote:
 Hi,
 
 On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org
 wrote:
  What kind of architecture are you trying to do this on? Is this
  i386/amd64 or something else?
 
 amd64
 
   I am not familiar with netboot compared to
  PXE. Is TFTP involved at all with netboot?
 
 TFTP is not involved. The kernel gets booted by our custom loader
 (over HTTP) and the root FS is supposed to be mounted over NFS.
 
  What does your dhcpd configuration file look like?
 
 Completely standard, with the addition of a root-path option. (Which
 I would like to get rid of by setting ROOTDEVNAME in the kernel.)
 
  Also, are you using the FreeBSD loader, or something else? What
  kinds of
  customizations have you done on the loader?
 
 Custom loader.
 
  If through your setup you have already managed to load the kernel
  over
  the network, then a lot of the hard work has been done. Telling the
  kernel
  where the root file system is located becomes the next tricky part.
 
 Right, that's the step I am struggeling with.
 
If you have options BOOTP and options BOOTP_NFSROOT, the 
VFS_MOUNT()/nfs_mount()
call early in vfs_mountroot() calls bootpc_init(). This function and
related code is in sys/nfs/bootp_subr.c.

At a glance, the code in sys/nfs/bootp_subr.c tries very hard to get
root-path in several places, so it will take some fiddling to get it
to work without the dhcpd returning a root-path option. (I think Ian Lepore
has started to work on this.) I don't have any way of testing this until
at least April, so I can't really help.

It should be possible to modify bootp_subr.c, so that it uses ROOTDEVNAME
instead of trying to get root-path from the dhcp server when it is specified,
but the change will take some work.

If you want bootpc_init() to be called when options BOOTP_NFSROOT isn't
specified, that is a one line change in sys/fs/nfsclient/nfs_clvfsops.c.
(Just look for the bootpc_init() call, but I don't see that as being useful?

I think changing bootpc_init() and friends to avoid getting root-path when it
has already been specified (by ROOTDEVNAME and/or vfs.root.mountfrom) is the
best approach, but will require a significant patch to bootp_subr.c.

I can see two other approaches to doing this:
1 - Supply a root-path via the dhcpd, but override what it says later in
the kernel boot, to use what is specified by ROOTDEVNAME or
vfs.root.mountfrom. I haven't looked at what this would take, but
I didn't see how it could be done with the current code,
because the NFS client code expects a structure called nfsv3_diskless
to be filled in by bootpc_init()
OR
2 - nfs_diskless(). The call to nfs_diskless() is done when options NFS_ROOT
is specified, but options BOOTP + options BOOTP_NFSROOT is not.
(Just look at the calls in sys/fs/nfs/nfs_clvfsops.c or 
sys/nfsclient/nfs_vfsops.c.)
It fills the structure in from a bunch of environment variables. These
are normally filled in by pxeboot, but you could modify your custom loader
to fill them in, which would be this approach.

Once eithe nfs_diskless() or bootpc_init() has filled in nfsv3_diskless and
set nfs_diskless_valid, then the rest of the code uses what is in that 
structure,
so one of these 2 functions needs to be called, unless you do a major re-write 
of
the diskless NFS booting stuff.

Good luck with it, rick

  In src/sys/boot/common/boot.c which is part of the loader (not the
  kernel),
  if you look in the getrootmount() function,
  you will see that the loader will try to figure out where the root
  file
  system
  is by parsing /etc/fstab, and looking for the / mount.
 
  So, if your kernel is located in:
 
/usr/home/elars/dst/boot/kernel/kernel
 
  Then create a file /usr/home/elars/dst/etc/fstab file with something
  like:
 
  # Device Mountpoint FSType
  Options Dump Pass
  10.11.12.13:/usr/home/elars/dst/ / nfs ro 0 0
 
 Thanks, will try that!
 
  Alternatively, if you don't want to create an /etc/fstab file, then
  you could put something like this in your loader.conf file:
 
  vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst
 
 Will try that too, but not sure if this works with our custom loader.
 
 Lars
 
 
  If you can get this to work without introducing new kernel options,
  that would be ideal, because the kernel options you are
  enabling are triggering behaviors.
 
  --
  Craig Rodrigues
  rodr...@crodrigues.org
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: x11/nvidia-driver build fails in head @r246115

2013-01-30 Thread John Baldwin
On Wednesday, January 30, 2013 9:51:35 am David Wolfskill wrote:
 I include
 
 PORTS_MODULES=x11/nvidia-driver
 
 in /etc/src.conf in order to keep nvidia-driver in sync with my kernel.
 
 It last built OK yesterday, @r246057; @r246115, I see:

Oof, it needs to use compat/linux/linux_ioctl.h instead of one of the 
foo/linux.h headers on HEAD.  (and this is my fault)

Alexey, can you patch the port for that?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[no subject]

2013-01-30 Thread AN
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #33 r246130: Wed Jan 30 
15:00:08 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


I just rebuilt the world and kernel.  Then I rebuilt 
/usr/ports/emulators/virtualbox-ose-kmod.


# kldstat
Id Refs AddressSize Name
 1   24 0x8020 116fac0  kernel
 21 0x8137 ee74c8   nvidia.ko
 33 0x82258000 1393f8   linux.ko
 41 0x82412000 997d linprocfs.ko
 51 0x8241c000 344b ums.ko
 61 0x8242 29c3 uhid.ko
 71 0x82423000 2e7b0vboxdrv.ko


# pkg info |grep box
virtualbox-ose-4.2.6   A general-purpose full virtualizer for x86 
hardware

virtualbox-ose-kmod-4.2.6_1VirtualBox kernel module for FreeBSD

Virtualbox suddenly broke for me, possibly related 
to this:

http://svnweb.FreeBSD.org/base?view=revisionrevision=246028

Fix some symbol version mismatches between libstdc++ and 
libsupc++/libcxxrt that were causing the runtime and STL libraries to see 
different versions of various classes and functions when libstdc++ is used as a filter.


When I try to start Vbox it fails with:
# VirtualBox
VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: 
/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by 
/usr/local/lib/virtualbox/VBoxRT.so not found



With all due respect to developers, are these changes tested at all before 
they are added to the codebase?


I understand this is a development branch.  I am not a developer, but it 
seems to me more thought and testing should be done before changes like 
this are committed.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: mounting root from NFS via ROOTDEVNAME

2013-01-30 Thread Craig Rodrigues
On Wed, Jan 30, 2013 at 1:32 AM, Eggert, Lars l...@netapp.com wrote:

 Hi,

 On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote:


 TFTP is not involved. The kernel gets booted by our custom loader (over
 HTTP) and the root FS is supposed to be mounted over NFS.
  If through your setup you have already managed to load the kernel over
  the network, then a lot of the hard work has been done.  Telling the
 kernel
  where the root file system is located becomes the next tricky part.

 Right, that's the step I am struggeling with.

  In src/sys/boot/common/boot.c which is part of the loader (not the
 kernel),
  if you look in the getrootmount() function,
  you will see that the loader will try to figure out where the root file
  system
  is by parsing /etc/fstab, and looking for the / mount.
 
  So, if your kernel is located in:
 
/usr/home/elars/dst/boot/kernel/kernel
 
  Then create a file /usr/home/elars/dst/etc/fstab file with something
 like:
 
  # Device MountpointFSType
  Options  Dump Pass
  10.11.12.13:/usr/home/elars/dst/   / nfs  ro0
  0

 Thanks, will try that!

  Alternatively, if you don't want to create an /etc/fstab file, then
  you could put something like this in your loader.conf file:
 
  vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst

 Will try that too, but not sure if this works with our custom loader.




Hi,

Thanks for the clarification.  I have a better idea of what you are trying
to do.
As you can imagine, not too many people have been playing with this type
of stuff.  A lot of this root mounting/NFS code was written about 14-15
years ago,
and not a lot of folks have been using it, but it is highly useful once you
get it to work.
Rick Macklem has been dusting off a lot of the cobwebs in the NFS code
thankfully.

Since your custom loader can load the kernel without using TFTP, I think
that this is a very good point.

Does your custom loader use any of the FreeBSD bootstrap or loader code?

What you need to do is, before the FreeBSD kernel boots, your
loader needs to export some environment variables.  This will trigger
the various behaviors in the FreeBSD mount code.

So as I suggested before, you should continue with:

(1)  Have /usr/home/elars/dst/etc/fstab with:
#  Options  Dump Pass
 10.11.12.13:/usr/home/elars/dst/   / nfs  ro00


(2)  From your loader, you need to export this environment variable, so
that the kernel can get it with getenv().  You need at least:

vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst



Now, there are some other environment variables you need to export from the
loader.  If you look in
src/sys/boot/i386/libi386/pxe.c, you will see that several environment
variables are set by
the FreeBSD loader (which is /boot/pxeboot on a FreeBSD system):

boot.netif.ip
boot.netif.netmask
boot.netif.gateway
boot.nfsroot.server
boot.nfsroot.path
dchp.host-name

These variables are then read by the FreeBSD kernel's NFS client root mount
code in src/sys/nfsclient/nfs_diskless.c.

If you can get those variables set properly in your loader, so that the
FreeBSD kernel can read them,
then I think this might work. :)
Basically, you need to give the kernel enough basic info about the IP
address, gateway, and netmask so it
can NFS mount the root file system.

Also, unless you really need them, I would recommend removing the BOOTP
options from your kernel config (unless you really feel you need them).
As others have pointed out, some of these options have not been tested for
a long time and might be buggy.  That is always
the risk when kernel options are not part of the GENERIC config.

Good luck!

-- 
Craig Rodrigues
rodr...@crodrigues.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re[2]: Re[2]: AHCI timeout when using ZFS + AIO + NCQ

2013-01-30 Thread Vladislav Prodan



 I once ran into a very severe AHCI timeout problem. After months of trying to
 figure it out and insane Hardware_ECC_Recovered error values, I found that
 the error was with the power connector plug / sata HDD interface. All errors
 disappeared after replacing that cable. Since you have error on more than 1
 HDD, I suggest:
 1. Check smartctl output for each AND all HDD
 2. Check whether your power supply unit is still healthy or if it is
 supplying inconsistent power.
 3. Check the main power supply line and whether it shows any voltage
 fluctuations or if there is a new heavy consumer of amps on the same power
 line as the server is plugged to.
 
 

I've deliberately chose a different server that has a different chipset, and 
that there were no problems with the HDD.

Added kernel support:
device ahci # AHCI-compatible SATA controllers

And now, after 2.5 days fell off one HDD.

[3:14]beastie:root-/root# zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has been removed by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
  scan: none requested
config:

NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
  mirror-0   ONLINE   0 0 0
gpt/disk0ONLINE   0 0 0
gpt/disk2ONLINE   0 0 0
  mirror-1   DEGRADED 0 0 0
gpt/disk1ONLINE   0 0 0
4931885954389536913  REMOVED  0 0 0  was /dev/gpt/disk3

errors: No known data errors


Jan 30 09:49:28 beastie kernel: ahcich3: Timeout on slot 29 port 0
Jan 30 09:49:28 beastie kernel: ahcich3: is  cs 2000 ss  rs 
2000 tfd c0 serr  cmd 0004dd17
Jan 30 09:49:28 beastie kernel: (ada3:ahcich3:0:0:0): FLUSHCACHE48. ACB: ea 00 
00 00 00 40 00 00 00 00 00 00
Jan 30 09:49:28 beastie kernel: (ada3:ahcich3:0:0:0): CAM status: Command 
timeout
Jan 30 09:49:28 beastie kernel: (ada3:ahcich3:0:0:0): Retrying command
Jan 30 09:51:31 beastie kernel: ahcich3: AHCI reset: device not ready after 
31000ms (tfd = 0080)
Jan 30 09:51:31 beastie kernel: ahcich3: Timeout on slot 29 port 0
Jan 30 09:51:31 beastie kernel: ahcich3: is  cs 2000 ss  rs 
2000 tfd 80 serr  cmd 0004dd17
Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): ATA_IDENTIFY. ACB: ec 
00 00 00 00 40 00 00 00 00 00 00
Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): CAM status: Command 
timeout
Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): Error 5, Retry was 
blocked
Jan 30 09:51:31 beastie kernel: ahcich3: AHCI reset: device not ready after 
31000ms (tfd = 0080)
Jan 30 09:51:31 beastie kernel: ahcich3: Timeout on slot 29 port 0
Jan 30 09:51:31 beastie kernel: ahcich3: is  cs  ss  rs 
2000 tfd 58 serr  cmd 0004dd17
Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): ATA_IDENTIFY. ACB: ec 
00 00 00 00 40 00 00 00 00 00 00
Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): CAM status: Command 
timeout
Jan 30 09:51:31 beastie kernel: (aprobe0:ahcich3:0:0:0): Error 5, Retry was 
blocked
Jan 30 09:51:31 beastie kernel: (ada3:ahcich3:0:0:0): lost device
Jan 30 09:51:31 beastie kernel: (pass3:ahcich3:0:0:0): passdevgonecb: devfs 
entry is gone


-- 
Vladislav V. Prodan
System  Network Administrator 
http://support.od.ua   
+380 67 4584408, +380 99 4060508
VVP88-RIPE

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'

2013-01-30 Thread Jan Beich
O. Hartmann ohart...@zedat.fu-berlin.de writes:

 c++ -O3 -pipe -fno-strict-aliasing -march=native -march=native
 -DHAVE_CONFIG_H -I/usr/src/libexec/atf/atf-check/../../../contrib/atf
 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall
 -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith
 -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int
 -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
 -Wno-unused-function -Wno-conversion -stdlib=libc++ -std=c++11
 -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++
 -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c -o
 atf-check atf-check.o -latf-c++ -latf-c
 /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to
 `std::bad_alloc::~bad_alloc()'
 /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so:
 undefined reference to `std::bad_alloc::bad_alloc()'
 /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so:
 undefined reference to `std::bad_alloc::~bad_alloc()'
 /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to
 `std::bad_alloc::bad_alloc()'
 c++: error: linker command failed with exit code 1 (use -v to see
 invocation)
 *** [atf-check] Error code 1

Try stage binaries built with default CXXFLAGS from allbsd.org snapshot.
With them installed do you see smth like the following?

  $ clang++ -stdlib=libc++ foo.c
  clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated
  /usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'
  /usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()'
  /usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'
  /usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()'
  clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)

It's different from the error when you build libc++ before libcxxrt.

  $ clang++ -stdlib=libc++ foo.c
  clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated
  /usr/lib/libc++.so: undefined reference to 
`std::uncaught_exception()@CXXABI_1.3'
  /usr/lib/libc++.so: undefined reference to 
`std::exception::~exception()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_alloc::~bad_alloc()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to `typeinfo for 
std::exception@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_alloc::~bad_alloc()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_alloc::bad_alloc()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to `typeinfo for 
std::bad_cast@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_cast::~bad_cast()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to `typeinfo for 
std::bad_alloc@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_alloc::bad_alloc()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to `std::terminate()@CXXABI_1.3'
  clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)

--
#! /bin/sh
# fetch/install stage binaries from allbsd.org snapshots

TARGET=amd64
TARGET_ARCH=amd64
BRANCH=10.0-HEAD
#REVISION=r245980 # works fine
REVISION=r246034 # doesn't work
LIBS=lib/libcxxrt/libcxxrt.so.1:/lib \
  lib/libc++/libc++.so.1:/usr/lib \
  gnu/lib/libsupc++/libsupc++.so.1:/usr/lib

for f in $LIBS; do
#chflags 0 $dir/${file##*/}
fetch -o ${f#*:} 
https://pub.allbsd.org/FreeBSD-snapshots/${TARGET}-${TARGET_ARCH}/${BRANCH}-${REVISION}-JPSNAP/stage/usr/obj/usr/src/${f%:*}
done
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: mounting root from NFS via ROOTDEVNAME

2013-01-30 Thread Julian Elischer

On 1/30/13 1:32 AM, Eggert, Lars wrote:

Hi,

On Jan 29, 2013, at 20:22, Craig Rodrigues rodr...@crodrigues.org wrote:


Alternatively, if you don't want to create an /etc/fstab file, then
you could put something like this in your loader.conf file:

vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst

Will try that too, but not sure if this works with our custom loader.


your custom loader should have some way to set kernel environment values.
it's a pretty basic requirement and, surprisingly, not that hard to do.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: buildworld error

2013-01-30 Thread Jesse
i set these  in make.conf:
CXXFLAGS+=-stdlib=libc++
CXXFLAGS+=-std=c++11

i comment them and rebuild world ok
but it works at previous revision.

On 1/30/13, Dimitry Andric d...@freebsd.org wrote:
 On 2013-01-30 10:37, Jesse wrote:
 I just update /usr/src and make buildworld. The building proccess stop as
 errors:

 === lib/clang/libllvmx86asmparser (all)
 === lib/clang/libllvmx86codegen (all)
 === lib/clang/libllvmx86desc (all)
 === lib/clang/libllvmx86disassembler (all)
 === lib/clang/libllvmx86info (all)
 === lib/clang/libllvmx86instprinter (all)
 === lib/clang/libllvmx86utils (all)
 === lib/clang/libllvmdebuginfo (all)
 === lib/clang/libllvmexecutionengine (all)
 === lib/clang/libllvminterpreter (all)
 === lib/clang/libllvmjit (all)
 === lib/clang/libllvmmcdisassembler (all)
 === lib/clang/libllvmmcjit (all)
 === lib/clang/libllvmruntimedyld (all)
 === lib/clang/include (all)
 1 error
 *** [everything] Error code 2
 1 error
 *** [buildworld] Error code 2
 1 error

 Because you are making buildworld with -j, the actual error message is
 not visible.  Try searching back in the log to find the actual error,
 and post that.  Alternatively, make buildworld without -j.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: buildworld error

2013-01-30 Thread Jesse
z

On 1/31/13, Jesse je...@glx.me wrote:
 i set these  in make.conf:
 CXXFLAGS+=-stdlib=libc++
 CXXFLAGS+=-std=c++11

 i comment them and rebuild world ok
 but it works at previous revision.

 On 1/30/13, Dimitry Andric d...@freebsd.org wrote:
 On 2013-01-30 10:37, Jesse wrote:
 I just update /usr/src and make buildworld. The building proccess stop
 as
 errors:

 === lib/clang/libllvmx86asmparser (all)
 === lib/clang/libllvmx86codegen (all)
 === lib/clang/libllvmx86desc (all)
 === lib/clang/libllvmx86disassembler (all)
 === lib/clang/libllvmx86info (all)
 === lib/clang/libllvmx86instprinter (all)
 === lib/clang/libllvmx86utils (all)
 === lib/clang/libllvmdebuginfo (all)
 === lib/clang/libllvmexecutionengine (all)
 === lib/clang/libllvminterpreter (all)
 === lib/clang/libllvmjit (all)
 === lib/clang/libllvmmcdisassembler (all)
 === lib/clang/libllvmmcjit (all)
 === lib/clang/libllvmruntimedyld (all)
 === lib/clang/include (all)
 1 error
 *** [everything] Error code 2
 1 error
 *** [buildworld] Error code 2
 1 error

 Because you are making buildworld with -j, the actual error message is
 not visible.  Try searching back in the log to find the actual error,
 and post that.  Alternatively, make buildworld without -j.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'

2013-01-30 Thread O. Hartmann
Am 01/29/13 17:35, schrieb David Wolfskill:
 On Tue, Jan 29, 2013 at 11:06:02AM +0100, O. Hartmann wrote:
 I receive this error since yesterday building world and it is still
 sticky on most recent sources (r246057) and I was wondering why the
 tinderboxes do not pick this up on the 10.0-CURRENT builds ... just for
 a notice for the development folks ...
 ... 
 === libexec/atf/atf-check (all)
 ...
 c++ -O3 -pipe -fno-strict-aliasing -march=native -march=native
 -DHAVE_CONFIG_H -I/usr/src/libexec/atf/atf-check/../../../contrib/atf
 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall
 -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith
 -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int
 -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
 -Wno-unused-function -Wno-conversion -stdlib=libc++ -std=c++11
 -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++
 -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c -o
 atf-check atf-check.o -latf-c++ -latf-c
 /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to
 `std::bad_alloc::~bad_alloc()'
 /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so:
 undefined reference to `std::bad_alloc::bad_alloc()'
 /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so:
 undefined reference to `std::bad_alloc::~bad_alloc()'
 /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to
 `std::bad_alloc::bad_alloc()'
 c++: error: linker command failed with exit code 1 (use -v to see
 invocation)
 *** [atf-check] Error code 1

 Stop in /usr/src/libexec/atf/atf-check.
 *** [all] Error code 1
 ...
 
 In contrast, I don't see a problem; most recent head build I have is:
 
 FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1057  
 r246057M/246068: Tue Jan 29 07:29:55 PST 2013 
 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC  i386
 
 
 For reference, yesterday's was:
 
 FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1056  
 r246028M/246028: Mon Jan 28 06:49:44 PST 2013 
 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC  i386
 
 
 That said (and this may be relevant), I'm using clang/clang++ to
 build FreeBSD.
 
 Peace,
 david
 

First, I suspected the c++ option -std=c++11 I issued in /etc/src.conf
when building the sources - I did this before without any problems.
Then, leaving the build without -std=c++11 option, I get the following
error below and compilation stops.

Maybe this reveals the real issue.

The revision of the OS I compile on and where it fails is FreeBSD
10.0-CURRENT #2 r245995: Sun Jan 27 19:56:47 CET 2013. This is maybe of
any help.

The sources are at Revision: 246142

Oliver




[...]
/usr/obj/usr/src/tmp/usr/include/c++/v1/memory:3771:14: error: default
template arguments for a function template are a C++11 extension
[-Werror,-Wc++11-extensions]
 class = typename enable_if
 ^   ~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
In file included from
/usr/src/lib/atf/libatf-c++/../../../contrib/atf/atf-c++/detail/application.cpp:42:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/iostream:38:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:434:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:594:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/memory:597:
/usr/obj/usr/src/tmp/usr/include/c++/v1/__functional_base:22:1: error:
inline namespaces are a C++11 feature [-Werror,-Wc++11-extensions]
_LIBCPP_BEGIN_NAMESPACE_STD
^
/usr/obj/usr/src/tmp/usr/include/c++/v1/__config:275:52: note: expanded
from macro '_LIBCPP_BEGIN_NAMESPACE_STD'
#define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {inline namespace
_LIBCPP_NAMESPACE {
   ^
/usr/obj/usr/src/tmp/usr/include/c++/v1/__config:275:52: note: expanded
from macro '_LIBCPP_BEGIN_NAMESPACE_STD'
#define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {inline namespace
_LIBCPP_NAMESPACE {
   ^
In file included from
/usr/src/lib/atf/libatf-c++/../../../contrib/atf/atf-c++/detail/application.cpp:42:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/iostream:38:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:434:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:594:
/usr/obj/usr/src/tmp/usr/include/c++/v1/memory:614:1: error: inline
namespaces are a C++11 feature [-Werror,-Wc++11-extensions]
_LIBCPP_BEGIN_NAMESPACE_STD
^

Re: buildworld error

2013-01-30 Thread O. Hartmann
Am 01/31/13 05:06, schrieb Jesse:
 z
 
 On 1/31/13, Jesse je...@glx.me wrote:
 i set these  in make.conf:
 CXXFLAGS+=-stdlib=libc++
 CXXFLAGS+=-std=c++11

 i comment them and rebuild world ok
 but it works at previous revision.

 On 1/30/13, Dimitry Andric d...@freebsd.org wrote:
 On 2013-01-30 10:37, Jesse wrote:
 I just update /usr/src and make buildworld. The building proccess stop
 as
 errors:

 === lib/clang/libllvmx86asmparser (all)
 === lib/clang/libllvmx86codegen (all)
 === lib/clang/libllvmx86desc (all)
 === lib/clang/libllvmx86disassembler (all)
 === lib/clang/libllvmx86info (all)
 === lib/clang/libllvmx86instprinter (all)
 === lib/clang/libllvmx86utils (all)
 === lib/clang/libllvmdebuginfo (all)
 === lib/clang/libllvmexecutionengine (all)
 === lib/clang/libllvminterpreter (all)
 === lib/clang/libllvmjit (all)
 === lib/clang/libllvmmcdisassembler (all)
 === lib/clang/libllvmmcjit (all)
 === lib/clang/libllvmruntimedyld (all)
 === lib/clang/include (all)
 1 error
 *** [everything] Error code 2
 1 error
 *** [buildworld] Error code 2
 1 error

 Because you are making buildworld with -j, the actual error message is
 not visible.  Try searching back in the log to find the actual error,
 and post that.  Alternatively, make buildworld without -j.


 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 


I see the very same issue and reported this already. Since I'm not a
professional developer, I'm not quite sure what and how to report the
issue in exactly and accurate.

In my case, this issue came out of the blue. I also have set

CXXFLAGS+= -stdlib=libc++  -std=c++11

but in /etc/src.conf. Commenting out -std=c++11 makes the build of
world fail with something like

[...]
fatal error: too many errors emitted, stopping now [-ferror-limit=]
In file included from
/usr/src/lib/atf/libatf-c++/../../../contrib/atf/atf-c++/detail/application.cpp:42:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/iostream:38:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:434:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:594:
In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/memory:597:
/usr/obj/usr/src/tmp/usr/include/c++/v1/__functional_base:22:1: error:
inline namespaces are a C++11 feature [-Werror,-Wc++11-extensions]
[...]

which sounds strange to me, since I completely erase /usr/obj before
building and I do not use a ccache or any other similar facility.

Regards,
Oliver




signature.asc
Description: OpenPGP digital signature


Re: x220 notes

2013-01-30 Thread Thomas Mueller
Excerpt from Andrey Fesenko f0and...@gmail.com:

 And other problems.
 1) wi-fi
 standart rtl8192cu - not work
 change AR5B95 - work n-mode (thanks Adrian Chadd :) need hack BIOS
 dev.acpi_ibm.0.wlan: 1 - read only
 hardware switch work, not send mesage

What did you try to make rtl8192cu work?  Did you try NDIS?

I have Hiro USB wireless adapter with rtl8191s chip, am still trying, on and
off, to get it to work.

OpenBSD has urtwn driver that should work, ported to NetBSD, but why not 
FreeBSD?  ALso, there is a Linux driver.

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org