date:20160106

Re: r 293304: BROKEN: buildkernel fails due to error: error: no member named 't_maxopd' in 'struct tcpcb'

2016-01-06 Thread NGie Cooper


> On Jan 6, 2016, at 21:31, O. Hartmann  wrote:
> 
> Recent r293304 fails to build kernel due to the error below:
> 
> [...]
> --- kern_testfrwk.o ---
> cc  -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror
> -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
> -include /usr/obj/usr/src/sys/FREYJA/opt_global.h -I. -I/usr/src/sys
> -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> -I/usr/obj/usr/src/sys/FREYJA  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
> -fstack-protector -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/tests/framework/../../../tests/framework/kern_testfrwk.c
> -o kern_testfrwk.o --- all_subdir_tcp/fastpath
> --- 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:481:6:
> error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen))
> { ^
> ~~ 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
> note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
> &&   \
> ^ 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:606:8:
> error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen) &&
> tlen != 0) ^
> ~~ 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
> note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
> &&   \ ^ --- sctp_indata.o --- ctfconvert -L
> VERSION sctp_indata.o ERROR: ctfconvert: sctp_indata.o doesn't have type data
> to convert --- modules-all --- --- all_subdir_sfxge --- --- siena_vpd.o --- cc
> -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror -D_KERNEL
> -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
> -include /usr/obj/usr/src/sys/FREYJA/opt_global.h -I. -I/usr/src/sys
> -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> -I/usr/obj/usr/src/sys/FREYJA  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
> -fstack-protector -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/sfxge/../../dev/sfxge/common/siena_vpd.c -o 
> siena_vpd.o
> --- all_subdir_tcp/fastpath
> --- 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:1545:8:
> error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen))
> ^
> ~~ 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
> note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
> &&   \ ^ 3 errors generated. *** [fastpath.o]
> Error code 1
> 
> make[4]: stopped in /usr/src/sys/modules/tcp/fastpath
> 1 error
> 
> make[4]: stopped in /usr/src/sys/modules/tcp/fastpath
> *** [all_subdir_tcp/fastpath] Error code 2
> 
> make[3]: stopped in /usr/src/sys/modules
> --- all_subdir_sfxge ---
> --- siena_sram.o ---
> ctfconvert -L VERSION siena_sram.o
> ERROR: ctfconvert: siena_sram.o doesn't have type data to convert
> --- all_subdir_tests/callout_test ---
> ctfconvert -L VERSION callout_test.o
> ERROR: ctfconvert: callout_test.o doesn't have type data to convert
> A failure has been detected in another branch of the parallel make
> 
> make[4]: stopped in /usr/src/sys/modules/tests/callout_test
> *** [all_subdir_tests/callout_test] Error code 2
> 
> make[3]: stopped in /usr/src/sys/modules
> --- sctp_input.o ---
> ctfconvert -L VERSION sctp_input.o

I sent an email to glebius about the build breakage. In the meantime, please 
feel free to revert r293284.
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"

r 293304: BROKEN: buildkernel fails due to error: error: no member named 't_maxopd' in 'struct tcpcb'

2016-01-06 Thread O. Hartmann

Recent r293304 fails to build kernel due to the error below:

[...]
--- kern_testfrwk.o ---
cc  -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror
-D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
-include /usr/obj/usr/src/sys/FREYJA/opt_global.h -I. -I/usr/src/sys
-fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/obj/usr/src/sys/FREYJA  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -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/tests/framework/../../../tests/framework/kern_testfrwk.c
-o kern_testfrwk.o --- all_subdir_tcp/fastpath
--- 
/usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:481:6:
error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen))
{ ^
~~ 
/usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
&&   \
^ 
/usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:606:8:
error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen) &&
tlen != 0) ^
~~ 
/usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
&&   \ ^ --- sctp_indata.o --- ctfconvert -L
VERSION sctp_indata.o ERROR: ctfconvert: sctp_indata.o doesn't have type data
to convert --- modules-all --- --- all_subdir_sfxge --- --- siena_vpd.o --- cc
-O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror -D_KERNEL
-DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
-include /usr/obj/usr/src/sys/FREYJA/opt_global.h -I. -I/usr/src/sys
-fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/obj/usr/src/sys/FREYJA  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -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/sfxge/../../dev/sfxge/common/siena_vpd.c -o siena_vpd.o
--- all_subdir_tcp/fastpath
--- 
/usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:1545:8:
error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen))
^
~~ 
/usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
&&   \ ^ 3 errors generated. *** [fastpath.o]
Error code 1

make[4]: stopped in /usr/src/sys/modules/tcp/fastpath
1 error

make[4]: stopped in /usr/src/sys/modules/tcp/fastpath
*** [all_subdir_tcp/fastpath] Error code 2

make[3]: stopped in /usr/src/sys/modules
--- all_subdir_sfxge ---
--- siena_sram.o ---
ctfconvert -L VERSION siena_sram.o
ERROR: ctfconvert: siena_sram.o doesn't have type data to convert
--- all_subdir_tests/callout_test ---
ctfconvert -L VERSION callout_test.o
ERROR: ctfconvert: callout_test.o doesn't have type data to convert
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/sys/modules/tests/callout_test
*** [all_subdir_tests/callout_test] Error code 2

make[3]: stopped in /usr/src/sys/modules
--- sctp_input.o ---
ctfconvert -L VERSION sctp_input.o
___
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 #2054 - Still Failing

2016-01-06 Thread jenkins-admin

FreeBSD_HEAD_i386 - Build #2054 - Still Failing:

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

Change summaries:

293295 by mjg:
cache: ansify functions and fix some style issues

No functional changes.



The end of the build log:

[...truncated 202671 lines...]
===> sysvipc (all)
--- all_subdir_sysvmsg ---
===> sysvipc/sysvmsg (all)
--- all_subdir_syscons ---
--- all_subdir_plasma ---
ctfconvert -L VERSION -g plasma_saver.o
--- plasma_saver.kld ---
ld -d -warn-common -r -d -o plasma_saver.kld fp16.o plasma_saver.o
ctfmerge -L VERSION -g -o plasma_saver.kld fp16.o plasma_saver.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk plasma_saver.kld  export_syms | xargs 
-J% objcopy % plasma_saver.kld
--- plasma_saver.ko.full ---
ld -Bshareable -d -warn-common -o plasma_saver.ko.full plasma_saver.kld
--- plasma_saver.ko.debug ---
objcopy --only-keep-debug plasma_saver.ko.full plasma_saver.ko.debug
--- plasma_saver.ko ---
objcopy --strip-debug --add-gnu-debuglink=plasma_saver.ko.debug  
plasma_saver.ko.full plasma_saver.ko
--- all_subdir_snake ---
===> syscons/snake (all)
--- all_subdir_sysvipc ---
--- sysv_msg.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/sysvipc/sysvmsg/../../../kern/sysv_msg.c -o sysv_msg.o
--- all_subdir_syscons ---
--- snake_saver.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/syscons/snake/../../../dev/syscons/snake/snake_saver.c -o 
snake_saver.o
--- all_subdir_sound ---
ctfconvert -L VERSION -g sb16.o
--- snd_sb16.kld ---
ld -d -warn-common -r -d -o snd_sb16.kld sb16.o
ctfmerge -L VERSION -g -o snd_sb16.kld sb16.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk snd_sb16.kld  export_syms | xargs -J% 
objcopy % snd_sb16.kld
--- snd_sb16.ko.full ---
ld -Bshareable -d -warn-common -o snd_sb16.ko.full snd_sb16.kld
--- snd_sb16.ko.debug ---
objcopy --only-keep-debug snd_sb16.ko.full snd_sb16.ko.debug
--- snd_sb16.ko ---
objcopy --strip-debug --add-gnu-debuglink=snd_sb16.ko.debug  snd_sb16.ko.full 
snd_sb16.ko
--- all_subdir_sb8 ---
===> sound/driver/sb8 (all)
--- all_subdir_syscons ---
ctfconvert -L VERSION -g snake_saver.o
--- snake_saver.kld ---
ld -d -warn-common -r -d -o snake_saver.kld snake_saver.o
ctfmerge -L VERSION -g -o snake_saver.kld snake_saver.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk snake_saver.kld  export_syms | xargs -J% 
objcopy % snake_saver.kld
--- snake_saver.ko.full ---
ld -Bshareable -d -warn-common -o snake_saver.ko.full snake_saver.kld
--- snake_saver.ko.debug ---
objcopy --only-keep-debug snake_saver.ko.full snake_saver.ko.debug
--- snake_saver.ko ---
objcopy --strip-debug --add-gnu-debuglink=snake_saver.ko.debug  
snake_saver.ko.full snake_saver.ko
--- all_subdir_sound ---
--- sb8.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-t

FreeBSD_HEAD_amd64_gcc4.9 - Build #1004 - Failure

2016-01-06 Thread jenkins-admin

FreeBSD_HEAD_amd64_gcc4.9 - Build #1004 - Failure:

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

Change summaries:

293289 by bdrewery:
Update dependencies after r292622 moved the ioctl script.

Sponsored by:   EMC / Isilon Storage Division

293288 by bdrewery:
Revert r293286.   It was not intended to come in yet.

293287 by bdrewery:
Add in DIRDEPS_BUILD support.

Sponsored by:   EMC / Isilon Storage Division

293286 by bdrewery:
Move the MAKEOBJDIRPREFIX value guard to sys.mk and expand to MAKEOBJDIR.

This will ensure that the variable was not set as a make override, in
make.conf, src.conf or src-env.conf.  It allows setting the value in
src-env.conf when using WITH_AUTO_OBJ since that case properly handles
changing .OBJDIR (except if MAKEOBJDIRPREFIX does not yet exist which is
being discussed to be changed).

This change allows setting a default MAKEOBJDIRPREFIX via local.sys.env.mk.

Sponsored by:   EMC / Isilon Storage Division

293285 by emaste:
Switch GNU ld to be installed as ld.bfd and linked as ld

We intend to replace GNU ld with LLVM's lld, and on the path to there
we'll experiment with having lld installed or linked as /usr/bin/ld.
Thus, make ld.bfd the primary install target for GNU ld, to later
facilitate making the ld link optional.

Reviewed by:davide, dim
Differential Revision:  https://reviews.freebsd.org/D4790

293284 by glebius:
Historically we have two fields in tcpcb to describe sender MSS: t_maxopd,
and t_maxseg. This dualism emerged with T/TCP, but was not properly cleaned
up after T/TCP removal. After all permutations over the years the result is
that t_maxopd stores a minimum of peer offered MSS and MTU reduced by minimum
protocol header. And t_maxseg stores (t_maxopd - TCPOLEN_TSTAMP_APPA) if
timestamps are in action, or is equal to t_maxopd otherwise. That's a very
rough estimate of MSS reduced by options length. Throughout the code it
was used in places, where preciseness was not important, like cwnd or
ssthresh calculations.

With this change:

- t_maxopd goes away.
- t_maxseg now stores MSS not adjusted by options.
- new function tcp_maxseg() is provided, that calculates MSS reduced by
  options length. The functions gives a better estimate, since it takes
  into account SACK state as well.

Reviewed by:jtl
Differential Revision:  https://reviews.freebsd.org/D3593

293282 by glebius:
Provide knob NO_INSTALLEXTRAKERNELS. If defined, extra kernels in KERNCONF
won't be installed, only the first one would.

293281 by emaste:
Use standard name for ASCII LF and FF control codes

PR: 205778
MFC after:  2 weeks

293274 by smh:
style(9) fixes for EFI boot

Fix some style(9) nits for EFI boot code, no functional changes.

MFC after:  2 weeks
X-MFC-With: r293268
Sponsored by:   Multiplay

293271 by smh:
Fix const conversion warning in lz4_decompress

Fix const conversion warning in lz4_decompress which shows when warnings
are enabled (to be done later).

MFC after:  2 weeks
X-MFC-With: r293268
Sponsored by:   Multiplay

293269 by smh:
Fix return from zfs_probe_dev

Ensure zfs_probe_dev returns the correct value.

Also fix a style(9) trailing whitespace issue while here.

MFC after:  2 weeks
X-MFC-With: r293268
Sponsored by:   Multiplay

293268 by smh:
Fix _MSC_EXTENSIONS checks

Use #ifdef instead of #if checks to prevent warnings generated by checks
to be enabled shortly.

MFC after:  2 weeks
Sponsored by:   Multiplay

293247 by emaste:
libunwind: Include header for dl_unwind_find_exidx for ARM EHABI

293245 by emaste:
loader.efi style(9) cleanup

Submitted by:   smh

293244 by emaste:
Introduce and use new EFI_ERROR_CODE macro for EFI errors

Submitted by:   smh
MFC after:  1 week

293241 by emaste:
Add fls() to libstand

Although we don't use it in tree yet libstand is installed as user-
facing /usr/liblibstand.a, and some work in progress makes use of it.
Instead of conflicting with ongoing libstand Makefile deduplication,
just add it now.

293240 by imp:
Try a little harder to remove firstboot and firstboot-reboot files in
case they accidentally get created as directories or with flags that
prevent their removal. While I wouldn't normally go the extra mile
here and let the normal unix rules prevail, the effects of failure are
large enough that extra care is warranted.

293234 by emaste:
Enable the beastie menu for the UEFI console

As of r293233 the UEFI console includes basic terminal emulator support.

MFC after:  2 weeks
Relnotes:   Yes

293233 by emaste:
loader.efi: add terminal emulation support

This is based on the vidconsole implementation.

Submitted by:   Toomas Soome 
Reviewed by:adrian
MFC after:  2 weeks
Relnotes:   Yes
Differential Revision:  https://reviews.freebsd.org/D4797

Re: after update to r292778 no interface ath0 and wlan0

2016-01-06 Thread Matthias Apitz

El día Thursday, January 07, 2016 a las 03:04:24AM +0100, Michael Gmelin 
escribió:

> > On 07 Jan 2016, at 02:49, Matthias Apitz  wrote:
> > 
> > 
> > Hello,
> > 
> > I have updated my Acer C720 netbook (amd64) from r285885 to r292778 and
> > now I do not see any network devices; the kernel is just GENERIC;
> > 
> > the lines in /etc/rc.conf are
> > 
> > wlans_ath0="wlan0"
> > ifconfig_wlan0="WPA DHCP"
> > 
> > (i.e. unchanged as they worked before); in dmesg the aht0 is shown as
> > usual with:
> > 
> 
> See https://lists.freebsd.org/pipermail/freebsd-net/2015-August/042976.html 
> and don't forget to run mergemaster to update rc scripts.
> 

I run in fact mermaster after installworld, but with flag -a; I have now moved 
from the
temproot:

# cd /var/tmp/temproot.*/etc/rc.d
# mv * /etc/rc.d
# cd ..
# rm group motd
# for i in *; do test -f $i && mv $i /etc ; done

and the network is fine again; thanks for the fast help;

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, 🌐 http://www.unixarea.de/  ☎ 
+49-176-38902045
___
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 #2053 - Failure

2016-01-06 Thread jenkins-admin

FreeBSD_HEAD_i386 - Build #2053 - Failure:

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

Change summaries:

293289 by bdrewery:
Update dependencies after r292622 moved the ioctl script.

Sponsored by:   EMC / Isilon Storage Division

293288 by bdrewery:
Revert r293286.   It was not intended to come in yet.

293287 by bdrewery:
Add in DIRDEPS_BUILD support.

Sponsored by:   EMC / Isilon Storage Division

293286 by bdrewery:
Move the MAKEOBJDIRPREFIX value guard to sys.mk and expand to MAKEOBJDIR.

This will ensure that the variable was not set as a make override, in
make.conf, src.conf or src-env.conf.  It allows setting the value in
src-env.conf when using WITH_AUTO_OBJ since that case properly handles
changing .OBJDIR (except if MAKEOBJDIRPREFIX does not yet exist which is
being discussed to be changed).

This change allows setting a default MAKEOBJDIRPREFIX via local.sys.env.mk.

Sponsored by:   EMC / Isilon Storage Division

293285 by emaste:
Switch GNU ld to be installed as ld.bfd and linked as ld

We intend to replace GNU ld with LLVM's lld, and on the path to there
we'll experiment with having lld installed or linked as /usr/bin/ld.
Thus, make ld.bfd the primary install target for GNU ld, to later
facilitate making the ld link optional.

Reviewed by:davide, dim
Differential Revision:  https://reviews.freebsd.org/D4790

293284 by glebius:
Historically we have two fields in tcpcb to describe sender MSS: t_maxopd,
and t_maxseg. This dualism emerged with T/TCP, but was not properly cleaned
up after T/TCP removal. After all permutations over the years the result is
that t_maxopd stores a minimum of peer offered MSS and MTU reduced by minimum
protocol header. And t_maxseg stores (t_maxopd - TCPOLEN_TSTAMP_APPA) if
timestamps are in action, or is equal to t_maxopd otherwise. That's a very
rough estimate of MSS reduced by options length. Throughout the code it
was used in places, where preciseness was not important, like cwnd or
ssthresh calculations.

With this change:

- t_maxopd goes away.
- t_maxseg now stores MSS not adjusted by options.
- new function tcp_maxseg() is provided, that calculates MSS reduced by
  options length. The functions gives a better estimate, since it takes
  into account SACK state as well.

Reviewed by:jtl
Differential Revision:  https://reviews.freebsd.org/D3593



The end of the build log:

[...truncated 201274 lines...]
ctfconvert -L VERSION -g hdaa.o
--- all_subdir_neomagic ---
--- neomagic.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/sound/driver/neomagic/../../../../dev/sound/pci/neomagic.c 
-o neomagic.o
--- all_subdir_hda ---
--- snd_hda.kld ---
ld -d -warn-common -r -d -o snd_hda.kld hdaa.o hdaa_patches.o hdac.o hdac_if.o 
hdacc.o
ctfmerge -L VERSION -g -o snd_hda.kld hdaa.o hdaa_patches.o hdac.o hdac_if.o 
hdacc.o
:> export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk snd_hda.kld  export_syms | xargs -J% 
objcopy % snd_hda.kld
--- snd_hda.ko.full ---
ld -Bshareable -d -warn-common -o snd_hda.ko.full snd_hda.kld
--- snd_hda.ko.debug ---
objcopy --only-keep-debug snd_hda.ko.full snd_hda.ko.debug
--- snd_hda.ko ---
objcopy --strip-debug --add-gnu-debuglink=snd_hda.ko.debug  snd_hda.ko.full 
snd_hda.ko
--- all_subdir_sysvipc ---
--- all_subdir_sysvsem ---
===> sysvipc/sysvsem (all)
--- sysv_sem.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  -

Re: after update to r292778 no interface ath0 and wlan0

2016-01-06 Thread Michael Gmelin



> On 07 Jan 2016, at 02:49, Matthias Apitz  wrote:
> 
> 
> Hello,
> 
> I have updated my Acer C720 netbook (amd64) from r285885 to r292778 and
> now I do not see any network devices; the kernel is just GENERIC;
> 
> the lines in /etc/rc.conf are
> 
> wlans_ath0="wlan0"
> ifconfig_wlan0="WPA DHCP"
> 
> (i.e. unchanged as they worked before); in dmesg the aht0 is shown as
> usual with:
> 

See https://lists.freebsd.org/pipermail/freebsd-net/2015-August/042976.html and 
don't forget to run mergemaster to update rc scripts.

- Michael

___
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: after update to r292778 no interface ath0 and wlan0

2016-01-06 Thread Adrian Chadd

it's there; just not called ath0

sysctl net.wlan.devices

and just create it - ifconfig wlan0 create wlandev ath0

You need to update your /etc for it all to work again out of the box. :)


-a


On 6 January 2016 at 17:49, Matthias Apitz  wrote:
>
> Hello,
>
> I have updated my Acer C720 netbook (amd64) from r285885 to r292778 and
> now I do not see any network devices; the kernel is just GENERIC;
>
> the lines in /etc/rc.conf are
>
> wlans_ath0="wlan0"
> ifconfig_wlan0="WPA DHCP"
>
> (i.e. unchanged as they worked before); in dmesg the aht0 is shown as
> usual with:
>
> ath0:  mem 0xe040-0xe047 at device 0.0 on pci1
> ath0: [HT] enabling HT modes
> ath0: [HT] enabling short-GI in 20MHz mode
> ath0: [HT] 1 stream STBC receive enabled
> ath0: [HT] 1 stream STBC transmit enabled
> ath0: [HT] 2 RX streams; 2 TX streams
> ath0: AR9460 mac 640.2 RF5110 phy 48.10
> ath0: 2GHz radio: 0x; 5GHz radio: 0x
>
> The full dmesg is attached. What do I missed as changes in CURRENT?
> Thanks
>
> matthias
>
>
>
> Copyright (c) 1992-2015 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 11.0-CURRENT #0 r292778: Mon Dec 28 05:45:37 CET 2015
> 
> root@poudriere-amd64:/usr/local/r292778/obj/usr/local/r292778/src/sys/GENERIC 
> amd64
> FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): resolution 640x480
> CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
>   
> Features=0xbfebfbff
>   
> Features2=0x4ddaebbf
>   AMD Features=0x2c100800
>   AMD Features2=0x21
>   Structured Extended Features=0x2603
>   XSAVE Features=0x1
>   VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 4301258752 (4102 MB)
> avail memory = 1917681664 (1828 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s)
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  2
> random: unblocking device.
> ioapic0  irqs 0-39 on motherboard
> random: entropy device external interface
> kbd1 at kbdmux0
> netmap: loaded module
> module_register_init: MOD_LOAD (vesa, 0x80ee1ed0, 0) error 19
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> vtvga0:  on motherboard
> cryptosoft0:  on motherboard
> acpi0:  on motherboard
> acpi0: Power Button (fixed)
> Timecounter "HPET" frequency 14318180 Hz quality 950
> Event timer "HPET" frequency 14318180 Hz quality 550
> Event timer "HPET1" frequency 14318180 Hz quality 440
> Event timer "HPET2" frequency 14318180 Hz quality 440
> Event timer "HPET3" frequency 14318180 Hz quality 440
> Event timer "HPET4" frequency 14318180 Hz quality 440
> Event timer "HPET5" frequency 14318180 Hz quality 440
> Event timer "HPET6" frequency 14318180 Hz quality 440
> cpu0:  on acpi0
> cpu1:  on acpi0
> atrtc0:  port 0x70-0x77 on acpi0
> Event timer "RTC" frequency 32768 Hz quality 0
> attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Event timer "i8254" frequency 1193182 Hz quality 100
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
> acpi_ec0:  port 0x62,0x66 on acpi0
> acpi_lid0:  on acpi0
> acpi_button0:  on acpi0
> acpi_button1:  irq 37 on acpi0
> acpi_button2:  irq 38 on acpi0
> pcib0:  port 0xcf8-0xcff on acpi0
> pci0:  on pcib0
> vgapci0:  port 0x1800-0x183f mem 
> 0xe000-0xe03f,0xd000-0xdfff at device 2.0 on pci0
> vgapci0: Boot video device
> hdac0:  mem 0xe051-0xe0513fff at device 3.0 
> on pci0
> xhci0:  mem 0xe050-0xe050 at 
> device 20.0 on pci0
> xhci0: 32 bytes context size, 64-bit DMA
> xhci0: Port routing mask set to 0x
> usbus0 on xhci0
> pci0:  at device 21.0 (no driver attached)
> ig4iic0:  mem 
> 0xe051a000-0xe051afff,0xe051b000-0xe051bfff at device 21.1 on pci0
> ig4iic0: Using MSI
> ig4iic1:  mem 
> 0xe051c000-0xe051cfff,0xe051d000-0xe051dfff at device 21.2 on pci0
> ig4iic1: Using MSI
> hdac1:  mem 0xe0514000-0xe0517fff at 
> device 27.0 on pci0
> pcib1:  at device 28.0 on pci0
> pci1:  on pcib1
> ath0:  mem 0xe040-0xe047 at device 0.0 on pci1
> ar9300_attach: calling ar9300_hw_attach
> ar9300_hw_attach: calling ar9300_eeprom_attach
> ar9300_flash_map: unimplemented for now
> Restoring Cal data from DRAM
> Restoring Cal data from EEPROM
> Restoring Cal data from Flash
> Restoring Cal data from Flash
> Restoring Cal data from OTP
> ar9300_hw_attach: ar9300_eeprom_attach returned 0
> ath0: [HT] enabling HT modes
> ath0: [HT]

after update to r292778 no interface ath0 and wlan0

2016-01-06 Thread Matthias Apitz


Hello,

I have updated my Acer C720 netbook (amd64) from r285885 to r292778 and
now I do not see any network devices; the kernel is just GENERIC;

the lines in /etc/rc.conf are

wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"

(i.e. unchanged as they worked before); in dmesg the aht0 is shown as
usual with:

ath0:  mem 0xe040-0xe047 at device 0.0 on pci1
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9460 mac 640.2 RF5110 phy 48.10
ath0: 2GHz radio: 0x; 5GHz radio: 0x

The full dmesg is attached. What do I missed as changes in CURRENT?
Thanks

matthias



Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 r292778: Mon Dec 28 05:45:37 CET 2015

root@poudriere-amd64:/usr/local/r292778/obj/usr/local/r292778/src/sys/GENERIC 
amd64
FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): resolution 640x480
CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
  
Features=0xbfebfbff
  
Features2=0x4ddaebbf
  AMD Features=0x2c100800
  AMD Features2=0x21
  Structured Extended Features=0x2603
  XSAVE Features=0x1
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 4301258752 (4102 MB)
avail memory = 1917681664 (1828 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  2
random: unblocking device.
ioapic0  irqs 0-39 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80ee1ed0, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
Event timer "HPET4" frequency 14318180 Hz quality 440
Event timer "HPET5" frequency 14318180 Hz quality 440
Event timer "HPET6" frequency 14318180 Hz quality 440
cpu0:  on acpi0
cpu1:  on acpi0
atrtc0:  port 0x70-0x77 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
acpi_ec0:  port 0x62,0x66 on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  irq 37 on acpi0
acpi_button2:  irq 38 on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0x1800-0x183f mem 
0xe000-0xe03f,0xd000-0xdfff at device 2.0 on pci0
vgapci0: Boot video device
hdac0:  mem 0xe051-0xe0513fff at device 3.0 
on pci0
xhci0:  mem 0xe050-0xe050 at 
device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
xhci0: Port routing mask set to 0x
usbus0 on xhci0
pci0:  at device 21.0 (no driver attached)
ig4iic0:  mem 
0xe051a000-0xe051afff,0xe051b000-0xe051bfff at device 21.1 on pci0
ig4iic0: Using MSI
ig4iic1:  mem 
0xe051c000-0xe051cfff,0xe051d000-0xe051dfff at device 21.2 on pci0
ig4iic1: Using MSI
hdac1:  mem 0xe0514000-0xe0517fff at device 
27.0 on pci0
pcib1:  at device 28.0 on pci0
pci1:  on pcib1
ath0:  mem 0xe040-0xe047 at device 0.0 on pci1
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_attach: calling ar9300_eeprom_attach
ar9300_flash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
Restoring Cal data from Flash
Restoring Cal data from Flash
Restoring Cal data from OTP
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9460 mac 640.2 RF5110 phy 48.10
ath0: 2GHz radio: 0x; 5GHz radio: 0x
ehci0:  mem 0xe051f800-0xe051fbff 
at device 29.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
isab0:  at device 31.0 on pci0
isa0:  on isab0
ahci0:  port 
0x1860-0x1867,0x1870-0x1873,0x1868-0x186f,0x1874-0x1877,0x1840-0x185f mem 
0xe051f000-0xe051f7ff

Re: Panic in ld_ldt() @r292914 (amd64) -- just after launching CPUs

2016-01-06 Thread Bryan Drewery

On 12/30/15 6:25 AM, Konstantin Belousov wrote:
> On Wed, Dec 30, 2015 at 05:54:07AM -0800, David Wolfskill wrote:
>> Found this on both my build machine and my laptop, each of which just
>> built head @r292914 (while running r292864 during the build) -- e.g.:
>>
>> FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #287  
>> r292864M/292864:1100092: Tue Dec 29 05:01:42 PST 2015 
>> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>>
>> Unfortunately, the panic occurs early enough that I can't get a crash
>> dump (I'm don't think the swap device has yet been discovered), and
>> serial console isn't working for my build machine.
>>
>> I took some screen shots of the laptop, but I don't seem to be able
>> to connect the phone to the laptop in a way to allow data interchange,
>> so I'll try to hand-transcribe the more obviously-relevant bits:
>>
>> ...
>> SMP: AP CPU #5 Launched!
>> kernel trap 9 with interrupts disabled
>>
>> Fatal trap 9: general protection fault while in kernel mode
>> cpuid = 6; apic id = 86
>> instruction pointer  = 0x28:0x80d9b505
>> stack pointer= 0x28:0xfe06015ca8f0
>> frame pointer= 0x28:0xfe06015ca950
>> code segment = base 0x0, limit 0xf, type 0x1b
>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = resume, IOPL = 0
>> current process  = 11 (idle: cpu6)
>> [ thread pid 11 tid 100010 ]
>> Stopped at   0x80d9b505 = ld_ldt:lldt%ax
>> db> bt
>> Tracing pid 11 tid 100010 td 0xf800067f69a0
>> ld_ldt() at 0x80d9b505 = ld_ldt/frame 0xfe06015ca900
>> sched_switch() at 0x80a176c5 = sched_switch+0x495/frame 
>> 0xfe06015ca950
>> mi_switch() at 0x809f8759 = mi_switch+0x169/frame 0xfe06015ca980
>> sched_idletd() at 0x80a1a211 = sched_idletd+0x391/frame 
>> 0xfe06015caa70
>> fork_exit() at 0x809b5324 = fork_exit+0x84/frame 0xfe06015aab0
>> fork_trampoline() at 0x80d9eade = fork_trampoline+0xe/frame 
>> 0xfe06015caab0
>> --- trap 0, rip = 0, rsp = 0, rpb = 0 ---
>> db> 
>>
>> I'm happy to try testing, but as I actually use the laptop for
>> day-to-day activities, I'm likely to need to do some priority-shifting.
>>
> 
> Try clean build first.  struct proc layout was changed recently, and the
> instruction at ld_ldt would fault if using the wrong offsets.

This sounds like another incremental build bug.  The last one David
reported I was unable to figure out.  I'll look at this one soon.


-- 
Regards,
Bryan Drewery
___
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: poudriere ports -c ... checks out the base system instead of the ports

2016-01-06 Thread Bryan Drewery

On 12/31/15 2:13 AM, Matthias Apitz wrote:
> El día Wednesday, December 30, 2015 a las 03:39:11PM +0100, Matthias Apitz 
> escribió:
> 
>>> # pkg info
>>> dialog4ports-0.1.5_2   Console Interface to configure ports
>>> pkg-1.6.2  Package manager
>>> poudriere-devel-3.1.99.20151204 Port build and test system
>>>
>>> # uname -a
>>> FreeBSD poudriere-amd64 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r292778:
>>> Mon Dec 28 05:45:37 CET 2015
>>> root@poudriere-amd64:/usr/local/r292778/obj/usr/local/r292778/src/sys/GENERIC
>>> amd64
>>>
>>> When I now want to creat the ports it does not checkout the ports tree, but
>>> the base system:
>>
>> yep, even the 'ps ax' shows this:
>>
>> 1201  0  S+0:00.02 sh /usr/local/share/poudriere/ports.sh -c -v -p 
>> ports-20151230 -m svn+http
>> 1237  0  S+0:00.08 /usr/bin/svnlite co http://svn.freebsd.org/base/head 
>> /usr/local/poudriere/po
>> 1200  1  Ss0:00.00 -sh (sh)
>> 1238  1  R+0:00.00 ps ax
>>
>> I can it make working with the options -m svn -U svn://svn.freebsd.org/ports/
> 
> I have had a look into the script /usr/local/share/poudriere/ports.sh
> which does the work for creating(...) ports. I has a new option:
> 
> Options:
> -U url-- URL where to fetch the ports tree from.
> 
> All is working fine now and the only which remains is updating the man
> page of poudriere for this.
> 
> Thanks
> 
>   matthias
> 

FYI this was fixed in poudriere-devel-3.1.99.20151204_1.

-- 
Regards,
Bryan Drewery
___
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: Does anyone use kgzip / kgzldr?

2016-01-06 Thread Devin Teske


> On Nov 23, 2015, at 6:35 PM, Ed Maste  wrote:
> 
> Hiya, I wanted to forward this to you in case you're not reading -current at 
> the moment so you don't miss it. A PR of yours from 2013 is the only recent 
> evidence I found of someone using kgzldr :-)
> 

Not on -current -- didn't get the original (thanks for the forward).

> 
> -- Forwarded message --
> From: Ed Maste mailto:ema...@freebsd.org>>
> Date: 23 November 2015 at 20:25
> Subject: Does anyone use kgzip / kgzldr?
> To: FreeBSD Current  >
> 
> 
> I disconnected kgzldr from the build in r291113 because I thought
> kgzip was already disconnected. As it happens kgzip was disconnected
> only from the release builds, in r281658.
> 

nods.


> kgzip / kgzldr only works on i386, and for quite some time the
> recommended way to use a compressed kernel has been via loader(8). Is
> there a compelling use case for kgzldr and loader(8)-less i386 boot?

Custom media used by some enterprises. It certainly is not the norm, I'll say,
but it does work. Being "i386 only" isn't of much concern for, say, my previous
employer whereat I had modified the installer (sysinstall) to more-aggressively
sandbox itself, allowing it to do things like boot/execute i386 but lay down an
amd64 release (so long as a little bit of CPUID x86 ASM yielded a positive hit
on CPU LongMode).


> I'll reconnect kgzldr (on i386 only) if it's useful, or otherwise
> continue with the removal.
> 

I'd like to see it reconnected. I think that's what
we had discussed last.
-- 
Cheers,
Devin


___
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: FYI: "WITH_FAST_DEPEND" vs. head @r292831

2016-01-06 Thread Bryan Drewery

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 1/6/16 2:54 PM, Bryan Drewery wrote:
> On 12/28/15 5:35 AM, David Wolfskill wrote:
>> Doing native in-place sourceupdate from:
> 
>> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD
>> 11.0-CURRENT #1940  r292767M/292769:1100092: Sun Dec 27 05:16:13
>> PST 2015 
>> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC 
>> amd64
> 
> 
>> to r292831 with 'WITH_FAST_DEPEND=1' specified in /etc/src.conf,
>> I found that "make -j16 -DNO_CLEAN buildworld" failed:
> 
>> ... --- lib/libcrypt__L --- make[4]: make[4]: don't know how to 
>> make /usr/src/lib/libcrypt/../libmd/sha512c.c. Stop 
> 
>> I then started "make -j16 buildworld", and it has completed (and
>>  gone on to the "make kernel").
> 
>> All of this was done withing script(1), so I have the typescripts
>>  available.  And it happened on bothe my laptop and my build 
>> machine.
> 
>> Please let me know if there's any other information I can
>> provide that might be of use to you in your efforts to get
>> "-DNO_CLEAN" working reliably.
> 
>> Peace, david
> 
> 
> Thanks. This is a real bug with FAST_DEPEND that I am looking
> into.
> 
> 

It is due to sha512c.c "moving" and still being within .PATH. It's
easy to fix but not nicely. I'm thinking about it still.

- -- 
Regards,
Bryan Drewery
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJWjZvXAAoJEDXXcbtuRpfPgdoH/RvpwpT5bU6Gw2bax9sOY9bL
isqXRJE4GPxXS8Q58CCgc3C2PGO3LxE+f+L8XzuyP79DHKmOlpC7EGyLfeiiWSYm
cxwDKCfAkQDQZW5uKQDCgO0ZAqs4kWlCxOKv2Fvkw6VQr6sTUayn3abVFFWPtsLV
AaL6a1/ZLquJ4C9R9qk3/a4RsAcvO4Av4HZe64zCa4k0mKRHcfH7q4cuXpl1rMnO
3Dr1ozjHL7rWOsPaBzUVV/lnvhe9p0e0GGzww5G1Iz52xfh+NVeb6HhvyEYh1Nbw
qqrsDyDQzzly1TuyaBlcLaAggRhesZJVUu4GoSRpFHbZNJIRm3cFOnswp6hYSb8=
=Tk2O
-END PGP SIGNATURE-
___
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 panic by enabling net.inet.ip.random_id

2016-01-06 Thread Shawn Webb

Yup, calling ip_initid() in the SYSINIT works! Thanks for the help.

Thanks,

Shawn

On Wed, Jan 06, 2016 at 01:24:53PM -0500, Shawn Webb wrote:
> That's what gets toggled via the sysctl. I think I figured out that I
> need to call ip_initid() in the SYSINIT. Compiling and testing now.
> 
> Thanks,
> 
> Shawn
> 
> On Wed, Jan 06, 2016 at 10:15:08AM -0800, Adrian Chadd wrote:
> > Why'd you condition the vimage definition? :)
> > 
> > 
> > 
> > -a
> > 
> > 
> > On 6 January 2016 at 06:46, Shawn Webb  wrote:
> > > (kgdb) list *(0x80b5de9e)
> > > 0x80b5de9e is in ip_fillid (/usr/src/sys/netinet/ip_id.c:237).
> > > warning: Source file is more recent than executable.
> > >
> > > 232 new_id = 0;
> > > 233 do {
> > > 234 if (new_id != 0)
> > > 235 V_random_id_collisions++;
> > > 236 arc4rand(&new_id, sizeof(new_id), 0);
> > > 237 } while (bit_test(V_id_bits, new_id) || new_id == 0);
> > > 238 bit_clear(V_id_bits, V_id_array[V_array_ptr]);
> > > 239 bit_set(V_id_bits, new_id);
> > > 240 V_id_array[V_array_ptr] = new_id;
> > > 241 V_array_ptr++;
> > >
> > > This is the change I made to ip_id.c that caused the underlying kernel
> > > panic:
> > > https://github.com/HardenedBSD/hardenedBSD/commit/52d5a93b92097e7a79be8d2e0eb9c1a58b8337d1
> > >
> > > Ideally, we should be able to just toggle that variable and all would be
> > > well. But it seems with the VIMAGE work, something is preventing that.
> > >
> > > Thanks,
> > >
> > > Shawn
> > >
> > > On Tue, Jan 05, 2016 at 06:22:34PM -0800, Adrian Chadd wrote:
> > >> try list *(0x[address]) .
> > >>
> > >> That line is mtx_unlock(), which makes no sense (as mtx_lock succeeded 
> > >> fine.)
> > >>
> > >>
> > >> -a
> > >>
> > >>
> > >> On 5 January 2016 at 18:13, Shawn Webb  
> > >> wrote:
> > >> > Thanks for the quick reply! Here's some more debugging output:
> > >> >
> > >> > === Begin Log ===
> > >> > (kgdb) bt
> > >> > #0  doadump (textdump=0) at pcpu.h:221
> > >> > #1  0x8037c78b in db_dump (dummy=, 
> > >> > dummy2=false, dummy3=0, dummy4=0x0) at 
> > >> > /usr/src/sys/ddb/db_command.c:533
> > >> > #2  0x8037c57e in db_command (cmd_table=0x0) at 
> > >> > /usr/src/sys/ddb/db_command.c:440
> > >> > #3  0x8037c314 in db_command_loop () at 
> > >> > /usr/src/sys/ddb/db_command.c:493
> > >> > #4  0x8037edab in db_trap (type=, code=0) 
> > >> > at /usr/src/sys/ddb/db_main.c:251
> > >> > #5  0x80a5c563 in kdb_trap (type=12, code=0, tf= > >> > optimized out>) at /usr/src/sys/kern/subr_kdb.c:654
> > >> > #6  0x80e6b7e1 in trap_fatal (frame=0xfe02c33894d0, 
> > >> > eva=) at /usr/src/sys/amd64/amd64/trap.c:829
> > >> > #7  0x80e6ba2d in trap_pfault (frame=0xfe02c33894d0, 
> > >> > usermode=) at /usr/src/sys/amd64/amd64/trap.c:684
> > >> > #8  0x80e6b15f in trap (frame=0xfe02c33894d0) at 
> > >> > /usr/src/sys/amd64/amd64/trap.c:435
> > >> > #9  0x80e4af97 in calltrap () at 
> > >> > /usr/src/sys/amd64/amd64/exception.S:234
> > >> > #10 0x80b5de9e in ip_fillid (ip=0xf8000ef8cb88) at 
> > >> > /usr/src/sys/netinet/ip_id.c:237
> > >> > #11 0x80b6c41b in ip_output (m=, 
> > >> > opt=, ro=, flags=0, imo=0x0, 
> > >> > inp=0xf8000e66e960) at /usr/src/sys/netinet/ip_output.c:268
> > >> > #12 0x80bf0612 in udp_send (so=, 
> > >> > flags=, m=, addr=0x0, 
> > >> > control=, td=0xf8000ef8cb88) at 
> > >> > /usr/src/sys/netinet/udp_usrreq.c:1517
> > >> > #13 0x80aa3872 in sosend_dgram (so=0xf8000e6422e8, 
> > >> > addr=0x0, uio=, top=0xf8000ef8cb00, 
> > >> > control=0x0, flags=, td=0x81bef2ec) at 
> > >> > /usr/src/sys/kern/uipc_socket.c:1164
> > >> > #13 0x80aa3872 in sosend_dgram (so=0xf8000e6422e8, 
> > >> > addr=0x0, uio=, top=0xf8000ef8cb00, 
> > >> > control=0x0, flags=, td=0x81bef2ec) at 
> > >> > /usr/src/sys/kern/uipc_socket.c:1164
> > >> > #14 0x80aaa03b in kern_sendit (td=0xf8000e4cd9c0, s=6, 
> > >> > mp=, flags=0, control=0x0, segflg=UIO_USERSPACE) 
> > >> > at /usr/src/sys/kern/uipc_syscalls.c:906
> > >> > #15 0x80aaa336 in sendit (td=0xf8000e4cd9c0, s= > >> > optimized out>, mp=0xfe02c3389970, flags=3980) at 
> > >> > /usr/src/sys/kern/uipc_syscalls.c:833
> > >> > #16 0x80aaa1fd in sys_sendto (td=0x0, uap= > >> > out>) at /usr/src/sys/kern/uipc_syscalls.c:957
> > >> > #17 0x80e6bfdb in amd64_syscall (td=0xf8000e4cd9c0, 
> > >> > traced=0) at subr_syscall.c:135
> > >> > #18 0x80e4b27b in Xfast_syscall () at 
> > >> > /usr/src/sys/amd64/amd64/exception.S:394
> > >> > #19 0x03e339782e8a in ?? ()
> > >> > (kgdb) x/i 0x80b5de9e
> > >> > 0x80b5de9e : movzbl (%rax,%rcx,1),%esi
> > >> > (kgdb) info reg
> > >> > rax0x0  0
> > >> > rbx0x0  0

Re: kernel panic by enabling net.inet.ip.random_id

2016-01-06 Thread Shawn Webb

That's what gets toggled via the sysctl. I think I figured out that I
need to call ip_initid() in the SYSINIT. Compiling and testing now.

Thanks,

Shawn

On Wed, Jan 06, 2016 at 10:15:08AM -0800, Adrian Chadd wrote:
> Why'd you condition the vimage definition? :)
> 
> 
> 
> -a
> 
> 
> On 6 January 2016 at 06:46, Shawn Webb  wrote:
> > (kgdb) list *(0x80b5de9e)
> > 0x80b5de9e is in ip_fillid (/usr/src/sys/netinet/ip_id.c:237).
> > warning: Source file is more recent than executable.
> >
> > 232 new_id = 0;
> > 233 do {
> > 234 if (new_id != 0)
> > 235 V_random_id_collisions++;
> > 236 arc4rand(&new_id, sizeof(new_id), 0);
> > 237 } while (bit_test(V_id_bits, new_id) || new_id == 0);
> > 238 bit_clear(V_id_bits, V_id_array[V_array_ptr]);
> > 239 bit_set(V_id_bits, new_id);
> > 240 V_id_array[V_array_ptr] = new_id;
> > 241 V_array_ptr++;
> >
> > This is the change I made to ip_id.c that caused the underlying kernel
> > panic:
> > https://github.com/HardenedBSD/hardenedBSD/commit/52d5a93b92097e7a79be8d2e0eb9c1a58b8337d1
> >
> > Ideally, we should be able to just toggle that variable and all would be
> > well. But it seems with the VIMAGE work, something is preventing that.
> >
> > Thanks,
> >
> > Shawn
> >
> > On Tue, Jan 05, 2016 at 06:22:34PM -0800, Adrian Chadd wrote:
> >> try list *(0x[address]) .
> >>
> >> That line is mtx_unlock(), which makes no sense (as mtx_lock succeeded 
> >> fine.)
> >>
> >>
> >> -a
> >>
> >>
> >> On 5 January 2016 at 18:13, Shawn Webb  wrote:
> >> > Thanks for the quick reply! Here's some more debugging output:
> >> >
> >> > === Begin Log ===
> >> > (kgdb) bt
> >> > #0  doadump (textdump=0) at pcpu.h:221
> >> > #1  0x8037c78b in db_dump (dummy=, 
> >> > dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
> >> > #2  0x8037c57e in db_command (cmd_table=0x0) at 
> >> > /usr/src/sys/ddb/db_command.c:440
> >> > #3  0x8037c314 in db_command_loop () at 
> >> > /usr/src/sys/ddb/db_command.c:493
> >> > #4  0x8037edab in db_trap (type=, code=0) 
> >> > at /usr/src/sys/ddb/db_main.c:251
> >> > #5  0x80a5c563 in kdb_trap (type=12, code=0, tf= >> > out>) at /usr/src/sys/kern/subr_kdb.c:654
> >> > #6  0x80e6b7e1 in trap_fatal (frame=0xfe02c33894d0, 
> >> > eva=) at /usr/src/sys/amd64/amd64/trap.c:829
> >> > #7  0x80e6ba2d in trap_pfault (frame=0xfe02c33894d0, 
> >> > usermode=) at /usr/src/sys/amd64/amd64/trap.c:684
> >> > #8  0x80e6b15f in trap (frame=0xfe02c33894d0) at 
> >> > /usr/src/sys/amd64/amd64/trap.c:435
> >> > #9  0x80e4af97 in calltrap () at 
> >> > /usr/src/sys/amd64/amd64/exception.S:234
> >> > #10 0x80b5de9e in ip_fillid (ip=0xf8000ef8cb88) at 
> >> > /usr/src/sys/netinet/ip_id.c:237
> >> > #11 0x80b6c41b in ip_output (m=, opt= >> > optimized out>, ro=, flags=0, imo=0x0, 
> >> > inp=0xf8000e66e960) at /usr/src/sys/netinet/ip_output.c:268
> >> > #12 0x80bf0612 in udp_send (so=, 
> >> > flags=, m=, addr=0x0, 
> >> > control=, td=0xf8000ef8cb88) at 
> >> > /usr/src/sys/netinet/udp_usrreq.c:1517
> >> > #13 0x80aa3872 in sosend_dgram (so=0xf8000e6422e8, addr=0x0, 
> >> > uio=, top=0xf8000ef8cb00, control=0x0, 
> >> > flags=, td=0x81bef2ec) at 
> >> > /usr/src/sys/kern/uipc_socket.c:1164
> >> > #13 0x80aa3872 in sosend_dgram (so=0xf8000e6422e8, addr=0x0, 
> >> > uio=, top=0xf8000ef8cb00, control=0x0, 
> >> > flags=, td=0x81bef2ec) at 
> >> > /usr/src/sys/kern/uipc_socket.c:1164
> >> > #14 0x80aaa03b in kern_sendit (td=0xf8000e4cd9c0, s=6, 
> >> > mp=, flags=0, control=0x0, segflg=UIO_USERSPACE) at 
> >> > /usr/src/sys/kern/uipc_syscalls.c:906
> >> > #15 0x80aaa336 in sendit (td=0xf8000e4cd9c0, s= >> > optimized out>, mp=0xfe02c3389970, flags=3980) at 
> >> > /usr/src/sys/kern/uipc_syscalls.c:833
> >> > #16 0x80aaa1fd in sys_sendto (td=0x0, uap=) 
> >> > at /usr/src/sys/kern/uipc_syscalls.c:957
> >> > #17 0x80e6bfdb in amd64_syscall (td=0xf8000e4cd9c0, 
> >> > traced=0) at subr_syscall.c:135
> >> > #18 0x80e4b27b in Xfast_syscall () at 
> >> > /usr/src/sys/amd64/amd64/exception.S:394
> >> > #19 0x03e339782e8a in ?? ()
> >> > (kgdb) x/i 0x80b5de9e
> >> > 0x80b5de9e : movzbl (%rax,%rcx,1),%esi
> >> > (kgdb) info reg
> >> > rax0x0  0
> >> > rbx0x0  0
> >> > rcx0x0  0
> >> > rdx0x0  0
> >> > rsi0x0  0
> >> > rdi0x0  0
> >> > rbp0xfe02c3388fe0   0xfe02c3388fe0
> >> > rsp0xfe02c3388fc8   0xfe02c3388fc8
> >> > r8 0x0  0
> >> > r9 0x0  0
> >> > r100x0  0
> >> > r11

Re: kernel panic by enabling net.inet.ip.random_id

2016-01-06 Thread Adrian Chadd

Why'd you condition the vimage definition? :)



-a


On 6 January 2016 at 06:46, Shawn Webb  wrote:
> (kgdb) list *(0x80b5de9e)
> 0x80b5de9e is in ip_fillid (/usr/src/sys/netinet/ip_id.c:237).
> warning: Source file is more recent than executable.
>
> 232 new_id = 0;
> 233 do {
> 234 if (new_id != 0)
> 235 V_random_id_collisions++;
> 236 arc4rand(&new_id, sizeof(new_id), 0);
> 237 } while (bit_test(V_id_bits, new_id) || new_id == 0);
> 238 bit_clear(V_id_bits, V_id_array[V_array_ptr]);
> 239 bit_set(V_id_bits, new_id);
> 240 V_id_array[V_array_ptr] = new_id;
> 241 V_array_ptr++;
>
> This is the change I made to ip_id.c that caused the underlying kernel
> panic:
> https://github.com/HardenedBSD/hardenedBSD/commit/52d5a93b92097e7a79be8d2e0eb9c1a58b8337d1
>
> Ideally, we should be able to just toggle that variable and all would be
> well. But it seems with the VIMAGE work, something is preventing that.
>
> Thanks,
>
> Shawn
>
> On Tue, Jan 05, 2016 at 06:22:34PM -0800, Adrian Chadd wrote:
>> try list *(0x[address]) .
>>
>> That line is mtx_unlock(), which makes no sense (as mtx_lock succeeded fine.)
>>
>>
>> -a
>>
>>
>> On 5 January 2016 at 18:13, Shawn Webb  wrote:
>> > Thanks for the quick reply! Here's some more debugging output:
>> >
>> > === Begin Log ===
>> > (kgdb) bt
>> > #0  doadump (textdump=0) at pcpu.h:221
>> > #1  0x8037c78b in db_dump (dummy=, 
>> > dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
>> > #2  0x8037c57e in db_command (cmd_table=0x0) at 
>> > /usr/src/sys/ddb/db_command.c:440
>> > #3  0x8037c314 in db_command_loop () at 
>> > /usr/src/sys/ddb/db_command.c:493
>> > #4  0x8037edab in db_trap (type=, code=0) at 
>> > /usr/src/sys/ddb/db_main.c:251
>> > #5  0x80a5c563 in kdb_trap (type=12, code=0, tf=> > out>) at /usr/src/sys/kern/subr_kdb.c:654
>> > #6  0x80e6b7e1 in trap_fatal (frame=0xfe02c33894d0, eva=> > optimized out>) at /usr/src/sys/amd64/amd64/trap.c:829
>> > #7  0x80e6ba2d in trap_pfault (frame=0xfe02c33894d0, 
>> > usermode=) at /usr/src/sys/amd64/amd64/trap.c:684
>> > #8  0x80e6b15f in trap (frame=0xfe02c33894d0) at 
>> > /usr/src/sys/amd64/amd64/trap.c:435
>> > #9  0x80e4af97 in calltrap () at 
>> > /usr/src/sys/amd64/amd64/exception.S:234
>> > #10 0x80b5de9e in ip_fillid (ip=0xf8000ef8cb88) at 
>> > /usr/src/sys/netinet/ip_id.c:237
>> > #11 0x80b6c41b in ip_output (m=, opt=> > optimized out>, ro=, flags=0, imo=0x0, 
>> > inp=0xf8000e66e960) at /usr/src/sys/netinet/ip_output.c:268
>> > #12 0x80bf0612 in udp_send (so=, flags=> > optimized out>, m=, addr=0x0, control=> > optimized out>, td=0xf8000ef8cb88) at 
>> > /usr/src/sys/netinet/udp_usrreq.c:1517
>> > #13 0x80aa3872 in sosend_dgram (so=0xf8000e6422e8, addr=0x0, 
>> > uio=, top=0xf8000ef8cb00, control=0x0, 
>> > flags=, td=0x81bef2ec) at 
>> > /usr/src/sys/kern/uipc_socket.c:1164
>> > #13 0x80aa3872 in sosend_dgram (so=0xf8000e6422e8, addr=0x0, 
>> > uio=, top=0xf8000ef8cb00, control=0x0, 
>> > flags=, td=0x81bef2ec) at 
>> > /usr/src/sys/kern/uipc_socket.c:1164
>> > #14 0x80aaa03b in kern_sendit (td=0xf8000e4cd9c0, s=6, 
>> > mp=, flags=0, control=0x0, segflg=UIO_USERSPACE) at 
>> > /usr/src/sys/kern/uipc_syscalls.c:906
>> > #15 0x80aaa336 in sendit (td=0xf8000e4cd9c0, s=> > optimized out>, mp=0xfe02c3389970, flags=3980) at 
>> > /usr/src/sys/kern/uipc_syscalls.c:833
>> > #16 0x80aaa1fd in sys_sendto (td=0x0, uap=) 
>> > at /usr/src/sys/kern/uipc_syscalls.c:957
>> > #17 0x80e6bfdb in amd64_syscall (td=0xf8000e4cd9c0, traced=0) 
>> > at subr_syscall.c:135
>> > #18 0x80e4b27b in Xfast_syscall () at 
>> > /usr/src/sys/amd64/amd64/exception.S:394
>> > #19 0x03e339782e8a in ?? ()
>> > (kgdb) x/i 0x80b5de9e
>> > 0x80b5de9e : movzbl (%rax,%rcx,1),%esi
>> > (kgdb) info reg
>> > rax0x0  0
>> > rbx0x0  0
>> > rcx0x0  0
>> > rdx0x0  0
>> > rsi0x0  0
>> > rdi0x0  0
>> > rbp0xfe02c3388fe0   0xfe02c3388fe0
>> > rsp0xfe02c3388fc8   0xfe02c3388fc8
>> > r8 0x0  0
>> > r9 0x0  0
>> > r100x0  0
>> > r110x0  0
>> > r120x817c0b80   -2122577024
>> > r130x817c1470   -2122574736
>> > r140x1  1
>> > r150x4  4
>> > rip0x80a1fae3   0x80a1fae3 
>> > eflags 0x0  0
>> > cs 0x0  0
>> > ss 0x0  0
>> > ds 0x0  0
>> > es 0x0  0
>> >

Re: kernel panic by enabling net.inet.ip.random_id

2016-01-06 Thread Shawn Webb

(kgdb) list *(0x80b5de9e)
0x80b5de9e is in ip_fillid (/usr/src/sys/netinet/ip_id.c:237).
warning: Source file is more recent than executable.

232 new_id = 0;
233 do {
234 if (new_id != 0)
235 V_random_id_collisions++;
236 arc4rand(&new_id, sizeof(new_id), 0);
237 } while (bit_test(V_id_bits, new_id) || new_id == 0);
238 bit_clear(V_id_bits, V_id_array[V_array_ptr]);
239 bit_set(V_id_bits, new_id);
240 V_id_array[V_array_ptr] = new_id;
241 V_array_ptr++;

This is the change I made to ip_id.c that caused the underlying kernel
panic:
https://github.com/HardenedBSD/hardenedBSD/commit/52d5a93b92097e7a79be8d2e0eb9c1a58b8337d1

Ideally, we should be able to just toggle that variable and all would be
well. But it seems with the VIMAGE work, something is preventing that.

Thanks,

Shawn

On Tue, Jan 05, 2016 at 06:22:34PM -0800, Adrian Chadd wrote:
> try list *(0x[address]) .
> 
> That line is mtx_unlock(), which makes no sense (as mtx_lock succeeded fine.)
> 
> 
> -a
> 
> 
> On 5 January 2016 at 18:13, Shawn Webb  wrote:
> > Thanks for the quick reply! Here's some more debugging output:
> >
> > === Begin Log ===
> > (kgdb) bt
> > #0  doadump (textdump=0) at pcpu.h:221
> > #1  0x8037c78b in db_dump (dummy=, 
> > dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
> > #2  0x8037c57e in db_command (cmd_table=0x0) at 
> > /usr/src/sys/ddb/db_command.c:440
> > #3  0x8037c314 in db_command_loop () at 
> > /usr/src/sys/ddb/db_command.c:493
> > #4  0x8037edab in db_trap (type=, code=0) at 
> > /usr/src/sys/ddb/db_main.c:251
> > #5  0x80a5c563 in kdb_trap (type=12, code=0, tf= > out>) at /usr/src/sys/kern/subr_kdb.c:654
> > #6  0x80e6b7e1 in trap_fatal (frame=0xfe02c33894d0, eva= > optimized out>) at /usr/src/sys/amd64/amd64/trap.c:829
> > #7  0x80e6ba2d in trap_pfault (frame=0xfe02c33894d0, 
> > usermode=) at /usr/src/sys/amd64/amd64/trap.c:684
> > #8  0x80e6b15f in trap (frame=0xfe02c33894d0) at 
> > /usr/src/sys/amd64/amd64/trap.c:435
> > #9  0x80e4af97 in calltrap () at 
> > /usr/src/sys/amd64/amd64/exception.S:234
> > #10 0x80b5de9e in ip_fillid (ip=0xf8000ef8cb88) at 
> > /usr/src/sys/netinet/ip_id.c:237
> > #11 0x80b6c41b in ip_output (m=, opt= > optimized out>, ro=, flags=0, imo=0x0, 
> > inp=0xf8000e66e960) at /usr/src/sys/netinet/ip_output.c:268
> > #12 0x80bf0612 in udp_send (so=, flags= > optimized out>, m=, addr=0x0, control= > out>, td=0xf8000ef8cb88) at /usr/src/sys/netinet/udp_usrreq.c:1517
> > #13 0x80aa3872 in sosend_dgram (so=0xf8000e6422e8, addr=0x0, 
> > uio=, top=0xf8000ef8cb00, control=0x0, 
> > flags=, td=0x81bef2ec) at 
> > /usr/src/sys/kern/uipc_socket.c:1164
> > #13 0x80aa3872 in sosend_dgram (so=0xf8000e6422e8, addr=0x0, 
> > uio=, top=0xf8000ef8cb00, control=0x0, 
> > flags=, td=0x81bef2ec) at 
> > /usr/src/sys/kern/uipc_socket.c:1164
> > #14 0x80aaa03b in kern_sendit (td=0xf8000e4cd9c0, s=6, 
> > mp=, flags=0, control=0x0, segflg=UIO_USERSPACE) at 
> > /usr/src/sys/kern/uipc_syscalls.c:906
> > #15 0x80aaa336 in sendit (td=0xf8000e4cd9c0, s= > out>, mp=0xfe02c3389970, flags=3980) at 
> > /usr/src/sys/kern/uipc_syscalls.c:833
> > #16 0x80aaa1fd in sys_sendto (td=0x0, uap=) at 
> > /usr/src/sys/kern/uipc_syscalls.c:957
> > #17 0x80e6bfdb in amd64_syscall (td=0xf8000e4cd9c0, traced=0) 
> > at subr_syscall.c:135
> > #18 0x80e4b27b in Xfast_syscall () at 
> > /usr/src/sys/amd64/amd64/exception.S:394
> > #19 0x03e339782e8a in ?? ()
> > (kgdb) x/i 0x80b5de9e
> > 0x80b5de9e : movzbl (%rax,%rcx,1),%esi
> > (kgdb) info reg
> > rax0x0  0
> > rbx0x0  0
> > rcx0x0  0
> > rdx0x0  0
> > rsi0x0  0
> > rdi0x0  0
> > rbp0xfe02c3388fe0   0xfe02c3388fe0
> > rsp0xfe02c3388fc8   0xfe02c3388fc8
> > r8 0x0  0
> > r9 0x0  0
> > r100x0  0
> > r110x0  0
> > r120x817c0b80   -2122577024
> > r130x817c1470   -2122574736
> > r140x1  1
> > r150x4  4
> > rip0x80a1fae3   0x80a1fae3 
> > eflags 0x0  0
> > cs 0x0  0
> > ss 0x0  0
> > ds 0x0  0
> > es 0x0  0
> > fs 0x0  0
> > gs 0x0  0
> > === End Log ===
> >
> > Thanks,
> >
> > Shawn
> >
> > On Tue, Jan 05, 2016 at 06:06:41PM -0800, Adrian Chadd wrote:
> >> looks like a null pointer deference. What's kgdb show at that IP?
> >>
> >>

Re: r 293304: BROKEN: buildkernel fails due to error: error: no member named 't_maxopd' in 'struct tcpcb'

r 293304: BROKEN: buildkernel fails due to error: error: no member named 't_maxopd' in 'struct tcpcb'

FreeBSD_HEAD_i386 - Build #2054 - Still Failing

FreeBSD_HEAD_amd64_gcc4.9 - Build #1004 - Failure

Re: after update to r292778 no interface ath0 and wlan0

FreeBSD_HEAD_i386 - Build #2053 - Failure

Re: after update to r292778 no interface ath0 and wlan0

Re: after update to r292778 no interface ath0 and wlan0

after update to r292778 no interface ath0 and wlan0

Re: Panic in ld_ldt() @r292914 (amd64) -- just after launching CPUs

Re: poudriere ports -c ... checks out the base system instead of the ports

Re: Does anyone use kgzip / kgzldr?

Re: FYI: "WITH_FAST_DEPEND" vs. head @r292831

Re: kernel panic by enabling net.inet.ip.random_id

Re: kernel panic by enabling net.inet.ip.random_id

Re: kernel panic by enabling net.inet.ip.random_id

Re: kernel panic by enabling net.inet.ip.random_id

17 matches

Site Navigation

Mail list logo

Footer information