FreeBSD_HEAD_amd64_gcc4.9 - Build #711 - Failure

2015-10-23 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc4.9 - Build #711 - Failure:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/711/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/711/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/711/console

Change summaries:

289817 by mav:
Disable full bus scan by CAM for FC adapters.

FC port database code already notifies CAM about all devices.  Additional
full scan is just a waste of time, that by definition won't find anything
that is not present in port database.

289816 by avos:
urtwn(4): add DBM_ANTNOISE radiotap field

Reviewed by:kevlo
Approved by:adrian (mentor)
Differential Revision:  https://reviews.freebsd.org/D3839

289812 by mav:
Some polishing and unification in ISR code.

289811 by avos:
- Split one 4-byte R92C_CR register into 2-byte R92C_CR and 1-byte R92C_MSR
registers (they are used for different purposes).
- Wrap R92C_MSR modifications into urtwn_set_mode().

Reviewed by:kevlo
Approved by:adrian (mentor)
Differential Revision:  https://reviews.freebsd.org/D3838

289799 by avos:
urtwn(4): fix the RSSI calculation for RTL8188EU.

This change also reverts r252405 (causes integer underflow).

Reviewed by:kevlo
Approved by:adrian (mentor)
Differential Revision:  https://reviews.freebsd.org/D3820

289797 by dteske:
dpv(1) merged to stable/10 before release/10.2.0

MFC after:  3 days
X-MFC-to:   stable/10

289794 by dteske:
figpar(3) merged to stable/10 before release/10.2.0

MFC after:  3 days
X-MFC-to:   stable/10

289793 by dteske:
Bump date/copyright after correcting HISTORY

MFC after:  3 days
X-MFC-to:   stable/10
X-MFC-with: r289790

289790 by dteske:
dpv(3) merged to stable/10 before release/10.2.0

MFC after:  3 days
X-MFC-to:   stable/10

289783 by glebius:
A miss from r289764.

289782 by adrian:
otus(4) - add missing ieee80211_free_node() call.

289781 by adrian:
otus(4) - demagicify register names.

Obtained from:  Linux carl9170 hw.h

289779 by adrian:
otus(4): begin supporting raw transmit parameters in otus_tx()

* Add a comment about the parameters I should support, stolen shamelessly
  from iwn(4);
* Implement the rate bit for the raw transmit path;
* Print out the host-order versions of each of the transmit bits, so
  I have a hope in heck of debugging why things are going wrong.

This still doesn't fix 5GHz in the office but that's likely due to a lot
of other configuration parameters being 2GHz-specific.  That'll come next.

Tested:

* AR9170 + AR9103 (2/5GHz) 2x2, 5GHz association



The end of the build log:

[...truncated 310560 lines...]
--- all_subdir_vmware ---
--- if_vmx.ko.debug ---
/usr/local/x86_64-freebsd/bin/objcopy --only-keep-debug if_vmx.ko.full 
if_vmx.ko.debug
--- if_vmx.ko ---
/usr/local/x86_64-freebsd/bin/objcopy --strip-debug 
--add-gnu-debuglink=if_vmx.ko.debug  if_vmx.ko.full if_vmx.ko
--- ar5413.o ---
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem 
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include
 
-L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib
 
--sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
 -B/usr/local/x86_64-freebsd/bin/ -c -O2 -frename-registers -pipe 
-fno-strict-aliasing  -g -nostdinc  -I. -I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys 
-I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -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-unk
 nown-pragmas  -Wno-error=inline -Wno-error=enum-compare 
-Wno-error=unused-but-set-variable  -Wno-error=aggressive-loop-optimizations 
-Wno-error=maybe-uninitialized  -Wno-error=array-bounds -Wno-error=address  
-Wno-error=cast-qual -Wno-error=sequence-point -Wno-error=attributes  
-Wno-error=strict-overflow -Wno-error=overflow  -fno-common -fms-extensions 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -std=iso9899:1999   
/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/dev/ath/ath_hal/ar5212/ar5413.c 
-I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/dev/ath 
-I/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/dev/ath/ath_hal
--- modules-all ---
--- all_subdir_vmm ---
ctfconvert -L VERSION -g vmcs.o
--- vmx_msr.o ---
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem 
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include
 
-L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib

kernel-toolchain fails in stable/9 build on head

2015-10-23 Thread Andriy Gapon 

$ make kernel-toolchain
...
===> gnu/usr.bin/cc/cc_tools (depend)
make[4]: "/usr/devel/svn/stable/9/share/mk/bsd.own.mk" line 233: warning:
unsetting WITH_CTF
cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -I.
-DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\"/usr/obj/usr/devel/svn/stable/9/tmp/usr\"
-I/usr/obj/usr/devel/svn/stable/9/tmp/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools
-I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools
-I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc
-I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config
-I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include
-I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include
-I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber
-g -DGENERATOR_FILE -DHAVE_CONFIG_H -g -std=gnu89
-I/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/include  -static
-L/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/lib -o genattrtab genattrtab.o
rtl.o read-rtl.o ggc-none.o vec.o min-insn-modes.o gensupport.o print-rtl.o
errors.o libiberty.a -lm
print-rtl.o: In function `print_rtx':
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:287:
undefined reference to `dump_addr'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:533:
undefined reference to `bitmap_print'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:268:
undefined reference to `print_node_brief'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:540:
undefined reference to `dump_addr'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:415:
undefined reference to `insn_file'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416:
undefined reference to `insn_file'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416:
undefined reference to `insn_line'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:434:
undefined reference to `reg_names'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:588:
undefined reference to `real_to_decimal'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:592:
undefined reference to `real_to_hexadecimal'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:573:
undefined reference to `mode_size'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:575:
undefined reference to `mode_size'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1
-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

dtc(1): reproducible segmentation fault

2015-10-23 Thread George Abdelmalik 

Hi,

With recent amd64 11.0-current system (as of earlier this week) I can 
reproduciblycw

get a SIGSEGV when running a command such as

$ dtc -o zb.dtb /usr/src/sys/boot/fdt/dts/arm/zedboard.dts
Segmentation fault (core dumped)

I've investigated the issue and found that the problem is at line
241 of the /usr/src/usr.bin/dtc/input_buffer.cc where the call to
mmap(2) fails. Snippet below:

233 mmap_input_buffer::mmap_input_buffer(int fd) : input_buffer(0, 0)
234 {
235 struct stat sb;
236 if (fstat(fd, ))
237 {
238 perror("Failed to stat file");
239 }
240 size = sb.st_size;
241 buffer = (const char*)mmap(0, size, PROT_READ,
242 MAP_PREFAULT_READ, fd, 0);
243 if (buffer == 0)
244 {
245 perror("Failed to mmap file");
246 }
247 }

The code incorrectly tests againts 0 instead of MAP_FAILED for failure
which is why the the perror message isn't seen at the terminal, the SIGSEGV
happens later when an attempt to access the buffer array is made.

Also the final parts of truss output are:

..
..
getrusage(0,{ u=0.00,s=0.002578,in=2,out=0 }) = 0 (0x0)
mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 
34384904192 (0x80180)

openat(AT_FDCWD,"xxx.dtb",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3)
getrusage(0,{ u=0.00,s=0.002697,in=2,out=0 }) = 0 (0x0)
openat(AT_FDCWD,"/usr/src/sys/boot/fdt/dts/arm/zedboard.dts",O_RDONLY,00) = 
4 (0x4)

fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) = 0 (0x0)
fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) = 0 (0x0)
mmap(0x0,5360,PROT_READ,MAP_PREFAULT_READ,4,0x0) ERR#22 'Invalid argument'
close(4) = 0 (0x0)
SIGNAL 11 (SIGSEGV)
process killed, signal = 11 (core dumped)

Any help debugging this futher would be much appreciated. I just can't 
understand why

the mmap in question would fail, and what's invalid about its arguments?

Regards,
George.

--
George Abdelmalik
Director
Principal Software Engineer
Uniridge Pty Ltd
http://www.uniridge.com.au/

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

Re: dtc(1): reproducible segmentation fault

2015-10-23 Thread Garrett Cooper 

> On Oct 23, 2015, at 07:10, George Abdelmalik  
> wrote:
> 
> Hi,
> 
> With recent amd64 11.0-current system (as of earlier this week) I can 
> reproduciblycw
> get a SIGSEGV when running a command such as
> 
> $ dtc -o zb.dtb /usr/src/sys/boot/fdt/dts/arm/zedboard.dts
> Segmentation fault (core dumped)
> 
> I've investigated the issue and found that the problem is at line
> 241 of the /usr/src/usr.bin/dtc/input_buffer.cc where the call to
> mmap(2) fails. Snippet below:
> 
> 233 mmap_input_buffer::mmap_input_buffer(int fd) : input_buffer(0, 0)
> 234 {
> 235 struct stat sb;
> 236 if (fstat(fd, ))
> 237 {
> 238 perror("Failed to stat file");
> 239 }
> 240 size = sb.st_size;
> 241 buffer = (const char*)mmap(0, size, PROT_READ,
> 242 MAP_PREFAULT_READ, fd, 0);
> 243 if (buffer == 0)
> 244 {
> 245 perror("Failed to mmap file");
> 246 }
> 247 }
> 
> The code incorrectly tests againts 0 instead of MAP_FAILED for failure
> which is why the the perror message isn't seen at the terminal, the SIGSEGV
> happens later when an attempt to access the buffer array is made.
> 
> Also the final parts of truss output are:
> 
> ..
> ..
> getrusage(0,{ u=0.00,s=0.002578,in=2,out=0 }) = 0 (0x0)
> mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 
> 34384904192 (0x80180)
> openat(AT_FDCWD,"xxx.dtb",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3)
> getrusage(0,{ u=0.00,s=0.002697,in=2,out=0 }) = 0 (0x0)
> openat(AT_FDCWD,"/usr/src/sys/boot/fdt/dts/arm/zedboard.dts",O_RDONLY,00) = 4 
> (0x4)
> fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) = 0 (0x0)
> fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) = 0 (0x0)
> mmap(0x0,5360,PROT_READ,MAP_PREFAULT_READ,4,0x0) ERR#22 'Invalid argument'
> close(4) = 0 (0x0)
> SIGNAL 11 (SIGSEGV)
> process killed, signal = 11 (core dumped)
> 
> Any help debugging this futher would be much appreciated. I just can't 
> understand why
> the mmap in question would fail, and what's invalid about its arguments?

Hi George,
Could you please post the bug report (with your dts file) on 
bugs.freebsd.org and CC Ian Lepore and Warner Losh?
Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_i386 - Build #1489 - Failure

2015-10-23 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #1489 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1489/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1489/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1489/console

Change summaries:

289817 by mav:
Disable full bus scan by CAM for FC adapters.

FC port database code already notifies CAM about all devices.  Additional
full scan is just a waste of time, that by definition won't find anything
that is not present in port database.

289816 by avos:
urtwn(4): add DBM_ANTNOISE radiotap field

Reviewed by:kevlo
Approved by:adrian (mentor)
Differential Revision:  https://reviews.freebsd.org/D3839

289812 by mav:
Some polishing and unification in ISR code.

289811 by avos:
- Split one 4-byte R92C_CR register into 2-byte R92C_CR and 1-byte R92C_MSR
registers (they are used for different purposes).
- Wrap R92C_MSR modifications into urtwn_set_mode().

Reviewed by:kevlo
Approved by:adrian (mentor)
Differential Revision:  https://reviews.freebsd.org/D3838

289799 by avos:
urtwn(4): fix the RSSI calculation for RTL8188EU.

This change also reverts r252405 (causes integer underflow).

Reviewed by:kevlo
Approved by:adrian (mentor)
Differential Revision:  https://reviews.freebsd.org/D3820

289797 by dteske:
dpv(1) merged to stable/10 before release/10.2.0

MFC after:  3 days
X-MFC-to:   stable/10

289794 by dteske:
figpar(3) merged to stable/10 before release/10.2.0

MFC after:  3 days
X-MFC-to:   stable/10

289793 by dteske:
Bump date/copyright after correcting HISTORY

MFC after:  3 days
X-MFC-to:   stable/10
X-MFC-with: r289790

289790 by dteske:
dpv(3) merged to stable/10 before release/10.2.0

MFC after:  3 days
X-MFC-to:   stable/10



The end of the build log:

[...truncated 185822 lines...]
===> virtio/balloon (all)
--- virtio_balloon.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h 
-I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC  -mno-mmx 
-mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -c 
/usr/src/sys/modules/virtio/balloon/../../../dev/virtio/balloon/virtio_balloon.c
 -o virtio_balloon.o
--- all_subdir_usb ---
--- all_subdir_urtw ---
ctfconvert -L VERSION -g if_urtw.o
--- all_subdir_virtio ---
ctfconvert -L VERSION -g virtio_balloon.o
--- virtio_balloon.kld ---
ld -d -warn-common -r -d -o virtio_balloon.kld virtio_balloon.o
ctfmerge -L VERSION -g -o virtio_balloon.kld virtio_balloon.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk virtio_balloon.kld  export_syms | xargs 
-J% objcopy % virtio_balloon.kld
--- virtio_balloon.ko.full ---
ld -Bshareable -d -warn-common -o virtio_balloon.ko.full virtio_balloon.kld
--- virtio_balloon.ko.debug ---
objcopy --only-keep-debug virtio_balloon.ko.full virtio_balloon.ko.debug
--- virtio_balloon.ko ---
objcopy --strip-debug --add-gnu-debuglink=virtio_balloon.ko.debug  
virtio_balloon.ko.full virtio_balloon.ko
===> virtio/scsi (all)
--- all_subdir_usb ---
--- if_urtw.kld ---
ld -d -warn-common -r -d -o if_urtw.kld if_urtw.o
ctfmerge -L VERSION -g -o if_urtw.kld if_urtw.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk if_urtw.kld  export_syms | xargs -J% 
objcopy % if_urtw.kld
--- if_urtw.ko.full ---
ld -Bshareable -d -warn-common -o if_urtw.ko.full if_urtw.kld
--- if_urtw.ko.debug ---
objcopy --only-keep-debug if_urtw.ko.full if_urtw.ko.debug
--- all_subdir_virtio ---
--- virtio_scsi.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h 
-I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC  -mno-mmx 
-mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -c 
/usr/src/sys/modules/virtio/scsi/../../../dev/virtio/scsi/virtio_scsi.c -o 
virtio_scsi.o
--- all_subdir_usb ---
---

Re: kernel-toolchain fails in stable/9 build on head

2015-10-23 Thread Andriy Gapon 

[sorry for top-posting *again*]
Just for the records, doing `make make` and then using the resulting make binary
seems to have solved the problems.

On 23/10/2015 13:27, Andriy Gapon wrote:
> 
> Oh, hrrm:
> 
> --- libbackend.a ---
> building static backend library
> nm: 'print-rtl.o': No such file or directory
> nm: 'rtl.o': No such file or directory
> nm: 'vec.o': No such file or directory
> ar: warning: can't open file: vec.o: No such file or directory
> ar: warning: can't open file: rtl.o: No such file or directory
> ar: warning: can't open file: print-rtl.o: No such file or directory
> ranlib libbackend.a
> 
> That's with -j4 during another attempt to build the same target.
> 
> On 23/10/2015 12:46, Andriy Gapon wrote:
>>
>> $ make kernel-toolchain
>> ...
>> ===> gnu/usr.bin/cc/cc_tools (depend)
>> make[4]: "/usr/devel/svn/stable/9/share/mk/bsd.own.mk" line 233: warning:
>> unsetting WITH_CTF
>> cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -I.
>> -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H
>> -DPREFIX=\"/usr/obj/usr/devel/svn/stable/9/tmp/usr\"
>> -I/usr/obj/usr/devel/svn/stable/9/tmp/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools
>> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools
>> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc
>> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config
>> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include
>> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include
>> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber
>> -g -DGENERATOR_FILE -DHAVE_CONFIG_H -g -std=gnu89
>> -I/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/include  -static
>> -L/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/lib -o genattrtab 
>> genattrtab.o
>> rtl.o read-rtl.o ggc-none.o vec.o min-insn-modes.o gensupport.o print-rtl.o
>> errors.o libiberty.a -lm
>> print-rtl.o: In function `print_rtx':
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:287:
>> undefined reference to `dump_addr'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:533:
>> undefined reference to `bitmap_print'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:268:
>> undefined reference to `print_node_brief'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:540:
>> undefined reference to `dump_addr'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:415:
>> undefined reference to `insn_file'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416:
>> undefined reference to `insn_file'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416:
>> undefined reference to `insn_line'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:434:
>> undefined reference to `reg_names'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:588:
>> undefined reference to `real_to_decimal'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:592:
>> undefined reference to `real_to_hexadecimal'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:573:
>> undefined reference to `mode_size'
>> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:575:
>> undefined reference to `mode_size'
>> cc: error: linker command failed with exit code 1 (use -v to see invocation)
>> *** Error code 1
>>
> 
> 


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

FreeBSD_HEAD_i386 - Build #1490 - Fixed

2015-10-23 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #1490 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1490/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1490/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1490/console

Change summaries:

289821 by hselasky:
Fix kernel build by restoring a temporary variable which was not yet
ripe for removal.

289819 by mav:
Fix LUN disable in CAM broken at r285155.

MFC after:  1 week

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

Re: kernel-toolchain fails in stable/9 build on head

2015-10-23 Thread Andriy Gapon 

Oh, hrrm:

--- libbackend.a ---
building static backend library
nm: 'print-rtl.o': No such file or directory
nm: 'rtl.o': No such file or directory
nm: 'vec.o': No such file or directory
ar: warning: can't open file: vec.o: No such file or directory
ar: warning: can't open file: rtl.o: No such file or directory
ar: warning: can't open file: print-rtl.o: No such file or directory
ranlib libbackend.a

That's with -j4 during another attempt to build the same target.

On 23/10/2015 12:46, Andriy Gapon wrote:
> 
> $ make kernel-toolchain
> ...
> ===> gnu/usr.bin/cc/cc_tools (depend)
> make[4]: "/usr/devel/svn/stable/9/share/mk/bsd.own.mk" line 233: warning:
> unsetting WITH_CTF
> cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -I.
> -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H
> -DPREFIX=\"/usr/obj/usr/devel/svn/stable/9/tmp/usr\"
> -I/usr/obj/usr/devel/svn/stable/9/tmp/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools
> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools
> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc
> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config
> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include
> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include
> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber
> -g -DGENERATOR_FILE -DHAVE_CONFIG_H -g -std=gnu89
> -I/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/include  -static
> -L/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/lib -o genattrtab 
> genattrtab.o
> rtl.o read-rtl.o ggc-none.o vec.o min-insn-modes.o gensupport.o print-rtl.o
> errors.o libiberty.a -lm
> print-rtl.o: In function `print_rtx':
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:287:
> undefined reference to `dump_addr'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:533:
> undefined reference to `bitmap_print'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:268:
> undefined reference to `print_node_brief'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:540:
> undefined reference to `dump_addr'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:415:
> undefined reference to `insn_file'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416:
> undefined reference to `insn_file'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416:
> undefined reference to `insn_line'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:434:
> undefined reference to `reg_names'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:588:
> undefined reference to `real_to_decimal'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:592:
> undefined reference to `real_to_hexadecimal'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:573:
> undefined reference to `mode_size'
> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:575:
> undefined reference to `mode_size'
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error code 1
> 


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

FreeBSD_HEAD_amd64_gcc4.9 - Build #712 - Fixed

2015-10-23 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc4.9 - Build #712 - Fixed:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/712/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/712/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/712/console

Change summaries:

289821 by hselasky:
Fix kernel build by restoring a temporary variable which was not yet
ripe for removal.

289819 by mav:
Fix LUN disable in CAM broken at r285155.

MFC after:  1 week

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

Re: dtc(1): reproducible segmentation fault

2015-10-23 Thread Ian Lepore 
On Fri, 2015-10-23 at 09:14 -0700, Garrett Cooper wrote:
> > On Oct 23, 2015, at 07:10, George Abdelmalik <
> > gabdelma...@uniridge.com.au> wrote:
> > 
> > Hi,
> > 
> > With recent amd64 11.0-current system (as of earlier this week) I
> > can reproduciblycw
> > get a SIGSEGV when running a command such as
> > 
> > $ dtc -o zb.dtb /usr/src/sys/boot/fdt/dts/arm/zedboard.dts
> > Segmentation fault (core dumped)
> > 
> > I've investigated the issue and found that the problem is at line
> > 241 of the /usr/src/usr.bin/dtc/input_buffer.cc where the call to
> > mmap(2) fails. Snippet below:
> > 
> > 233 mmap_input_buffer::mmap_input_buffer(int fd) : input_buffer(0,
> > 0)
> > 234 {
> > 235 struct stat sb;
> > 236 if (fstat(fd, ))
> > 237 {
> > 238 perror("Failed to stat file");
> > 239 }
> > 240 size = sb.st_size;
> > 241 buffer = (const char*)mmap(0, size, PROT_READ,
> > 242 MAP_PREFAULT_READ, fd, 0);
> > 243 if (buffer == 0)
> > 244 {
> > 245 perror("Failed to mmap file");
> > 246 }
> > 247 }
> > 
> > The code incorrectly tests againts 0 instead of MAP_FAILED for
> > failure
> > which is why the the perror message isn't seen at the terminal, the
> > SIGSEGV
> > happens later when an attempt to access the buffer array is made.
> > 
> > Also the final parts of truss output are:
> > 
> > ..
> > ..
> > getrusage(0,{ u=0.00,s=0.002578,in=2,out=0 }) = 0 (0x0)
> > mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
> > = 34384904192 (0x80180)
> > openat(AT_FDCWD,"xxx.dtb",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3)
> > getrusage(0,{ u=0.00,s=0.002697,in=2,out=0 }) = 0 (0x0)
> > openat(AT_FDCWD,"/usr/src/sys/boot/fdt/dts/arm/zedboard.dts",O_RDON
> > LY,00) = 4 (0x4)
> > fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) =
> > 0 (0x0)
> > fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) =
> > 0 (0x0)
> > mmap(0x0,5360,PROT_READ,MAP_PREFAULT_READ,4,0x0) ERR#22 'Invalid
> > argument'
> > close(4) = 0 (0x0)
> > SIGNAL 11 (SIGSEGV)
> > process killed, signal = 11 (core dumped)
> > 
> > Any help debugging this futher would be much appreciated. I just
> > can't understand why
> > the mmap in question would fail, and what's invalid about its
> > arguments?
> 
> Hi George,
> Could you please post the bug report (with your dts file) on
> bugs.freebsd.org and CC Ian Lepore and Warner Losh?
> Thanks!
> -NGie

Don't cc me.  I looked at the in-tree dtc code once and decided it's
too flawed to try to maintain, and it supports only a subset of the
full dts syntax.  That's why we switched back to using the gnu dtc for
buildkernel.  But I just discovered that for some reason gnu is not the
copy of dtc that gets installed, it's just the one that gets used
during a buildkernel.

So basically if you do 'dtc -v' and the result is 0.4.0, that's too
limited to compile modern dts files, and if the result is 1.4.0 that's
the gnu dtc that should work fine, and if it doesn't we probably need
to report the problem upstream.

-- Ian

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

Re: Depreciate and remove gbde

2015-10-23 Thread Poul-Henning Kamp 

In message <20151023192353.ga95...@cons.org>, Martin Cracauer writes:

>If you want a secure filesystem I think that at this particular time
>it would be entirely reasonable to use both gbde and geli stacked on
>top of each other[...]

Nobody is going to break through the GELI or GBDE crypto, they'll
find their way to the keys instead, or more likely, jail you until
you sing.

But neither GELI og GBDE alone or together give you a secure filesystem.

The very first requirement for a secure filesystem is that you can
trust the computer it is mounted on.

No commercially available smartphone, tablet, laptop, server or
desktop computer can be trusted by the owner at this point in time.

Want a secure filesystem ?

First step is to mount it on RaspBerry or Beaglebone without network
connectivity...

But more importantly:  There is no technical fix for lost privacy,
that is a political problem, and it must be solved by political
means.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

2015-10-23 Thread Martin Cracauer 
If I can open the soapbox for a moment.

If you want a secure filesystem I think that at this particular time
it would be entirely reasonable to use both gbde and geli stacked on
top of each other, assuming you have CPU/battery to spare.  (there
should be enough cores but the battery might be unhappy)

Nobody is going to go at your encrypted filesystem at the cipher
level.  The problem with using a less-testing system like either of
these is that there might be errors in setup that have reduced the
search space for the correct key.  That happens all the time.  The
protocols to set up the actual cipher aren't trivial to get right.  So
if you stack both you would guard yourself against screwups in either,
even if you use the same actual cipher for both layers.

In addition there is a fashion right now that people with lots of
brain and time go after the block chaining modes for block device
encryption.  It looks semi-ugly I'd say although not really
spectacular right now.

If you stack both gbde and geli on top of each other you can use
different block chaining modes and you would also guard yourself
against a failure there.

Just don't do it on top of a consumer SATA SSD...

Having said this, now that I looked at gbde's block chaining, it seems
it simply inherits CBC from geom_aes.c, is that right?

Martin

Yonas Yanfa wrote on Mon, Oct 19, 2015 at 08:43:00PM -0400: 
> Hi Martin, thanks, that raises some interesting points. After reading PHK's
> paper on GBDE, I can see enough differences between GDBE and GELI that
> warrant keeping GDBE.
> 
> [ At this point for me, this part is theoretical, but it's still
> interesting ] I've seen the concerned made a few times that we need to
> support existing users. That's true up to a point. There's always going to
> be a way to transition from GDBE to GELI if we really want to (eg. a
> conversion tool), or were forced to for any reason (full decrypt and
> re-encrypt), so we shouldn't be keeping GDBE in the tree solely for this
> reason alone. GDBE should be in the tree for it's technical merits (which
> I've found it does have). However, if it turns out in X years from today
> GELI can do everything GDBE can do and better, then I would say we should
> figure out a way to remove GDBE.
> 
> On Mon, Oct 19, 2015 at 7:44 PM, Martin Cracauer  wrote:
> 
> > Yonas Yanfa wrote on Sun, Oct 18, 2015 at 06:36:19AM -0400:
> > >
> > > Is there any objection to removing gbde? How many people use gbde? When
> > > have you used gbde over geli, and why?
> >
> > You would exclude all current users from accessing their existing
> > filesystems or whatever they put into that block device.
> >
> > A conversion tool would pretty much be forced to use the current
> > kernel layers (doing the block chaining in userspace would be
> > annoying), and it would be fundamentally unsafe to have your
> > half-converted filesystem on disk in case of an interruption.  Plus I
> > think GELI uses a bigger header so you might fall short by a couple of
> > bytes and you can't do anything about it on the block level with no
> > access to the filesystem.
> >
> > And people might not have their gbde units accessible right now, it
> > might be on a laptop in a closet on a different continent.
> >
> > Martin
> > --
> > %%%
> > Martin Cracauer    http://www.cons.org/cracauer/
> >

-- 
%%%
Martin Cracauer    http://www.cons.org/cracauer/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Make installworld fails on file not found (Error code 71)

2015-10-23 Thread Thomas Mueller 
> > It looks like a problem with WITHOUT_MANCOMPRESS.

> > I am looking into it.


> A fix is now committed. It has been broken since June.

> Regards,
> Bryan Drewery

Thanks for the fix, computer is now busy with NetBSD update from 6.99.44 (16 
months old) to 7.99.21 for both amd64 and i386, but I intend to get back to the 
FreeBSD update after that is done.

I checked /etc/src.conf and found
WITHOUT_MANCOMPRESS=yes
WITHOUT_DOCCOMPRESS=yes

I looked in other directions for the problem and would have just been wasting 
time and computer energy.

Compressed man pages can be a nuisance, and not really necessary or helpful 
with today's big hard drives and USB sticks.

Good I was able to expose a bug of four months' standing.

Tom

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