Re: SVN r311568 breaks build

2017-01-06 Thread Ngie Cooper (yaneurabeya) 

> On Jan 6, 2017, at 17:33, Michael Butler  wrote:
> 
> With the introduction of MSG_MORETOCOME, the build of libsysdecode is
> broken.
> 
> Was the following patch the intended but missed fix?

Addressed in r311584 — thank you for the submission!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

FreeBSD_HEAD_i386 - Build #4588 - Still Failing

2017-01-06 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #4588 - Still Failing:

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

Change summaries:

311581 by allanjude:
Capsicum: add capability mode to users binary

Submitted by:   Tyler Littlefield 
Reviewed by:cem, oshogbo
Differential Revision:  https://reviews.freebsd.org/D9046



The end of the build log:

[...truncated 55598 lines...]
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -I. -I/usr/src/lib/libthread_db   -MD 
 -MF.depend.libpthread_md.o -MTlibpthread_md.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
 -Qunused-arguments  -c /usr/src/lib/libthread_db/arch/i386/libpthread_md.c -o 
libpthread_md.o
--- all_subdir_lib/libstand ---
--- closeall.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe   -I/usr/src/lib/libstand 
-DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY 
-I/usr/src/lib/libstand/../../contrib/zlib -ffreestanding -Wformat -mno-mmx 
-mno-sse -mno-avx -D_STANDALONE -msoft-float -MD  -MF.depend.closeall.o 
-MTcloseall.o -std=gnu99 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments  -c 
/usr/src/lib/libstand/closeall.c -o closeall.o
--- all_subdir_lib/libthread_db ---
--- libpthread_db.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -I. -I/usr/src/lib/libthread_db   -MD 
 -MF.depend.libpthread_db.o -MTlibpthread_db.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
 -Qunused-arguments  -c /usr/src/lib/libthread_db/libpthread_db.c -o 
libpthread_db.o
--- all_subdir_lib/libucl ---
===> lib/libucl (all)
--- .depend ---
echo libprivateucl.so.1.full: /usr/obj/usr/src/tmp/usr/lib/libm.a >> .depend
--- ucl_emitter_streamline.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -I/usr/src/contrib/libucl/include  
-I/usr/src/contrib/libucl/src  -I/usr/src/contrib/libucl/uthash  
-I/usr/src/contrib/libucl/klib   -MD  -MF.depend.ucl_emitter_streamline.o 
-MTucl_emitter_streamline.o -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments  -c 
/usr/src/contrib/libucl/src/ucl_emitter_streamline.c -o ucl_emitter_streamline.o
--- all_subdir_lib/libstand ---
--- dev.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe   -I/usr/src/lib/libstand 
-DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY 
-I/usr/src/lib/libstand/../../contrib/zlib -ffreestanding -Wformat -mno-mmx 
-mno-sse -mno-avx -D_STANDALONE -msoft-float -MD  -MF.depend.dev.o -MTdev.o 
-std=gnu99 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments  -c 
/usr/src/lib/libstand/dev.c -o dev.o
--- ioctl.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe   -I/usr/src/lib/libstand 
-DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY 
-I/usr/src/lib/libstand/../../contrib/zlib -ffreestanding -Wformat -mno-mmx 
-mno-sse -mno-avx -D_STANDALONE -msoft-float -MD  -MF.depend.ioctl.o -MTioctl.o

FreeBSD_HEAD_i386 - Build #4587 - Still Failing

2017-01-06 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #4587 - Still Failing:

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

Change summaries:

311580 by adrian:
[net80211] add some more bits.

311579 by adrian:
[ifconfig] add initial VHT (802.11ac) configuration and channel support to 
ifconfig.

This is very preliminary and mostly enough for me (with other patches)
to work on VHT support.

It adds:

* VHT20, VHT40 and VHT80 regulatory/band awareness
* VHT20, VHT40 and VHT80 channel configuration / population
* Parses vht channel specifications (eg ifconfig wlan0 create wlandev athp0 
wlanmode monitor channel 36:vht/80)
* Configuration of VHT, VHT40, VHT80, VHT80+80, VHT160 channel
  width (IEEE80211_FVHT_VHT* flags in net80211)

TODO:

* No VHT80+80 or VHT160 channels yet - I don't yet have hardware, and I'm
  not yet sure how to support/populate VHT80+80 channels.
* No, I won't update the manpage until this is "more done", lest someone
  tries using vht and gets upset with me.
* No, I won't commit the regulatory database I'm testing with, so you'll
  just end up with no VHT channels ever populated.  Which is good, as there
  isn't an 11ac driver in-tree yet to try it with.

311578 by adrian:
[net80211] add VHT ioctl parameters and driver capabilities

* Add the VHT capability element to the driver capabilities so ifconfig
  can see if VHT is available
* Add ioctl plumbing for enabling/disabling VHT and each of the VHT
  widths.

Note: this DOES change the ABI (the driver caps ioctl struct size, sigh)
so this will require a recompile of at least ifconfig.

311577 by adrian:
[lib80211] add VHT bands and channel flags.

This is preparation work for 11ac support.  The regulatory database
needs to know about VHT channel flags and 80MHz (and later 160MHz)
available channel bands.

Whilst here, add the 2GHz VHT band (which is a terrible, terrible vendor
extension that almost all vendors do) just in preparation, even though
I don't (yet) plan on supporting it.

311576 by adrian:
[net80211] add VHT IEs to scan elements.

In preparation for VHT station support, we need to store VHT IEs when
scanning so we can choose to upgrade to VHT.

This doesn't change the ABI - it just steals spare[] entries.



The end of the build log:

[...truncated 55668 lines...]
 ^
/usr/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c:65:24: warning: 
macro expansion producing 'defined' has undefined behavior 
[-Wexpansion-to-defined]
/usr/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c:64:35: note: 
expanded from macro 'SOLARIS'
#define SOLARIS (defined(sun) && (defined(__SVR4) || defined(__svr4__)))
  ^
/usr/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c:65:24: warning: 
macro expansion producing 'defined' has undefined behavior 
[-Wexpansion-to-defined]
/usr/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c:64:54: note: 
expanded from macro 'SOLARIS'
#define SOLARIS (defined(sun) && (defined(__SVR4) || defined(__svr4__)))
 ^
3 warnings generated.
--- bpf_image.pico ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -fpic -DPIC -g -O2 -pipe   -DHAVE_CONFIG_H 
-Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -D_U_="__attribute__((unused))" 
-DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -DHAVE_NET_PFVAR_H 
-I/usr/src/lib/libpcap/../../contrib/libpcap -MD  -MF.depend.bpf_image.pico 
-MTbpf_image.pico -std=gnu99 -fstack-protector-strong -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  
-Qunused-arguments  -c /usr/src/lib/libpcap/../../contrib/libpcap/bpf_image.c 
-o bpf_image.pico
--- all_subdir_lib/libstand ---
--- _infback.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe   -I/usr/src/lib/libstand 
-DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY 
-I/usr/src/lib/libstand/../../contrib/zlib -ffreestanding -Wformat -mno-mmx 
-mno-sse -mno-avx -D_STANDALONE -msoft-float -MD  -MF.depend._infback.o 
-MT_infback.o -std=gnu99 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments  -c _infback.c 
-o _infback.o
--- all_subdir_lib/libpcap ---
--- bpf_dump.pico ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp

FreeBSD_HEAD_i386 - Build #4586 - Failure

2017-01-06 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #4586 - Failure:

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

Change summaries:

311575 by adrian:
[net80211] add VHT node flag; parsed chanwidth.

The VHT operational element (VHTOPMODE) isn't a uint32_t - it's
the MCS sets, freq1/freq2 parameters and channel width.
So, store the channel width too in lieu of just storing the
IE struct.

This changes the VHT parameter layout in ieee80211_node but it
doesn't change ABI at all.

311574 by adrian:
[net80211] add FVHT flags for channel widths.

The 11n code uses these bits for both configuration /and/ controlling
the channel width on softmac chips - it uses it to find the widest
width for all VAPs (eg a HT20 vap and a HT40 vap) to know what to
configure the ic_curchan.

For fullmac devices it isn't /as/ important, as each virtual device
exposed by the firmware will likely have its own configuration and the
firmware figures out what to do to enable it.

311573 by adrian:
[net80211] Remove duplicate VHTOPMODE configuration bits.

These came from Linux mac80211 headers and are configuration bits, not
VHTOPMODE field parameters.

Whilst here, add the field names for the VHTCAP bits.

Tested:

* ath10k, 11ac STA mode

311572 by asomers:
Fix file descriptor leaks in cmp(1)

Also, add a few test cases

Reported by:Coverity
CID:271624 275338
Reviewed by:ngie
MFC after:  4 weeks
Sponsored by:   Spectra Logic Corp
Differential Revision:  https://reviews.freebsd.org/D9074

311570 by dim:
In tcpdump's print-tcp.c, avoid increasing alignment when taking the
addresses of members of struct ip, which is packed.  Since the pointers
are only used for memcmp'ing, they can be pointing to void instead.

Note that upstream has removed the src and dst variables, in the mean
time.

MFC after:  3 days

311569 by np:
Fix comment in t4_tom.  No functional change.

MFC after:  3 days

311568 by jhb:
Set MORETOCOME for AIO write requests on a socket.

Add a MSG_MOREOTOCOME message flag. When this flag is set, sosend*
set PRUS_MOREOTOCOME when invoking the protocol send method. The aio
worker tasks for sending on a socket set this flag when there are
additional write jobs waiting on the socket buffer.

Reviewed by:adrian
MFC after:  1 month
Sponsored by:   Chelsio Communications
Differential Revision:  https://reviews.freebsd.org/D8955

311567 by jhb:
Enable /usr/lib32 for o32 binaries on mips64.

Build and install an o32 set of libraries on mips64 suitable for
running o32 binaries via COMPAT_FREEBSD32. Enable COMPAT_FREEBSD32 in
MALTA64.

Reviewed by:jmallett, imp
Sponsored by:   DARPA / AFRL
Differential Revision:  https://reviews.freebsd.org/D9032

311566 by jhb:
Set -m32 in MD LIB32CPUCFLAGS rather than MI LIB32CFLAGS.

Both amd64 and powerpc64 use -m32 to compile 32-bit binaries, but not
all platforms follow this convention.  Move the -m32 compile flag into
the per-architecture flags to accomodate other architectures.

Sponsored by:   DARPA / AFRL

311565 by dim:
Link llvm-ar to llvm-ranlib, if WITH_CLANG_EXTRAS is enabled.  When
invoked as llvm-ranlib, it can create an archive symbol table for
archives of objects compiled for LTO by an LLVM compiler.

Submitted by:   Dan McGregor 
MFC after:  3 days



The end of the build log:

[...truncated 55879 lines...]
--- _setjmp.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe   -I/usr/src/lib/libstand 
-DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY 
-I/usr/src/lib/libstand/../../contrib/zlib -ffreestanding -Wformat -mno-mmx 
-mno-sse -mno-avx -D_STANDALONE -msoft-float -MD  -MF.depend._setjmp.o 
-MT_setjmp.o -std=gnu99 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments-c 
/usr/src/lib/libstand/i386/_setjmp.S -o _setjmp.o
--- all_subdir_lib/libstdthreads ---
--- tss.pico ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -fpic -DPIC -g -O2 -pipe   -MD  
-MF.depend.tss.pico -MTtss.pico -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
 -Qunused-arguments

SVN r311568 breaks build

2017-01-06 Thread Michael Butler 
With the introduction of MSG_MORETOCOME, the build of libsysdecode is
broken.

Was the following patch the intended but missed fix?


Index: lib/libsysdecode/mktables
===
--- lib/libsysdecode/mktables   (revision 311572)
+++ lib/libsysdecode/mktables   (working copy)
@@ -142,7 +142,7 @@
 gen_table "fcntlcmd"
"F_[A-Z0-9_]+[[:space:]]+[0-9]+[[:space:]]+"   "sys/fcntl.h"
"F_CANCEL|F_..LCK"
 gen_table "mmapflags"   "MAP_[A-Z_]+[[:space:]]+0x[0-9A-Fa-f]+"
   "sys/mman.h"
 gen_table "rtpriofuncs" "RTP_[A-Z]+[[:space:]]+[0-9]+"
   "sys/rtprio.h"
-gen_table "msgflags""MSG_[A-Z]+[[:space:]]+0x[0-9]+"
   "sys/socket.h"  "MSG_SOCALLBCK"
+gen_table "msgflags""MSG_[A-Z]+[[:space:]]+0x[0-9]+"
   "sys/socket.h"  "MSG_SOCALLBCK|MSG_MORETOCOME"
 gen_table "sigcode" "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"
   "sys/signal.h"
 gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"
   "sys/umtx.h"
 gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"
   "sys/umtx.h"
___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Adrian Chadd 
email freebsd-wireless with the wifi details. i know our iwm driver
gets antenna configs wrong sometimes and that can cause issues.


-a


On 6 January 2017 at 11:07, Jonathan Anderson  wrote:
> On 6 Jan 2017, at 13:53, Pete Wright wrote:
>>
>>
>> i've been having the same problems with iwm too (failing to load firmware
>> on boot).  my trick has been to either boot into an old kernel where iwm was
>> mostly usable.  also i've commented out the line enabling wlan0 in my
>> rc.conf then uncommented it after boot and manually running "service netif
>> start" to bring up iwm.  that method works most of the time...
>> -pete
>
>
> I am able to load iwm (iwm7265fw), but there are some networks that I just
> can't connect to (INIT -> INIT, swscan_cancel_scan, repeat). Attaching to an
> iPhone hotspot is one example of a not-entirely-helpful network, but there
> is other, more typical infrastructure that gives trouble too. There is an
> iwm8xxx in the room that seems to work fine, however... I do not meddle in
> the affairs of wi-fi, for it is subtle and quick to anger. :)
>
>
> Jon
> --
> Jonathan Anderson
> jonat...@freebsd.org
>
> ___
> 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-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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Jonathan Anderson 

On 6 Jan 2017, at 14:26, Matthew Macy wrote:

Thanks. Pete already filed that as part of #108. With luck markj@ will 
have that fixed this weekend.


-M


Fantastic, I'll subscribe to that issue.

Cheers,


Jon
--
jonathan.ander...@ieee.org
___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Jonathan Anderson 

On 6 Jan 2017, at 14:06, Matthew Macy wrote:

kernel cores tend to be large (all of wired memory after all) and 
unless I have exactly the same kernel as you with the same sources at 
the same changeset, not useful. A backtrace is a good place to start.

kgdb /boot/kernel/kernel /var/crash/vmcore.last

% bt

-M


Ok, here we are:

#0  doadump (textdump=0) at pcpu.h:222
#1  0x82a445e7 in vt_kms_postswitch (arg=)
at 
/usr/home/jon/freebsd/graphics/sys/modules/drm/drm/../../../dev/drm/linux_fb.c:82

#2  0x808de76b in vt_window_switch (vw=0x81760ea8)
at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:540
#3  0x808dc280 in vtterm_cngrab (tm=)
at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:1465
#4  0x809f3e02 in cngrab () at 
/usr/home/jon/freebsd/graphics/sys/kern/kern_cons.c:368
#5  0x80a4d27a in vpanic (fmt=0x80ff218f "Assertion %s 
failed at %s:%d",
ap=0xfe0233e6f5f0) at 
/usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:765

#6  0x80a4d166 in kassert_panic (fmt=)
at /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:669
#7  0x80d2b93c in vm_fault_hold (map=0xf8010c9aa000, 
vaddr=34369822720,

fault_type=, fault_flags=0, m_hold=0x0)
at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:389
#8  0x80d2a1b8 in vm_fault (map=0xf8010c9aa000, vaddr=optimized out>,

fault_type=2 '\002', fault_flags=)
at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:474
#9  0x80ebb412 in trap_pfault (frame=0xfe0233e6f9c0, 
usermode=1)

at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:708
#10 0x80ebaba2 in trap (frame=0xfe0233e6f9c0)
at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:326
#11 0x80e9b181 in calltrap ()
at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/exception.S:236
#12 0x0008022a3876 in ?? ()

It looks like the other core files have the same backtrace. Please let 
me know if any other details would help...



Jon
--
jonathan.ander...@ieee.org
___
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: ABI differences between stable/10 and head?

2017-01-06 Thread Konstantin Belousov 
On Fri, Jan 06, 2017 at 09:54:50AM -0500, Kurt Lidl wrote:
> Yesterday, I upgraded the kernel on my sparc64 to -head,
> so I was running a mis-matched kernel and userland.
> The userland was a recent (as of two days ago) stable/10.
> 
> In the nightly report, I noticed the following:
> 
> > Network interface status:
> > NameMtu Network   Address  Ipkts Ierrs IdropOpkts 
> > Oerrs  Coll  Drop
> > bge0  -   00:03:ba:e0:ce:070 64691 00   
> >   0 11494817 2025493932409880576
> > bge0  - fe80::203:baf fe80::203:baff:fe0 - -0   
> >   - - -
> > bge0  - spork.pix.net 2001:470:e254:10:0 - -0   
> >   - - -
> > bge0  - 192.168.16.0  spork0 - -0   
> >   - - -
> > bge1  -   00:03:ba:e0:ce:080 0 00   
> >   0 0 4040291828690585088
> > bge2  -   00:03:ba:e0:ce:090 0 00   
> >   0 0 4040291832985552384
> > bge3  -   00:03:ba:e0:ce:0a0 0 00   
> >   0 0 4040291837582442496
> > lo0   -    074 00   
> >   0 38794 2025493932409880576
> > lo0   - localhost ::1  0 - -0   
> >   - - -
> > lo0   - fe80::1%lo0   fe80::1%lo0  0 - -0   
> >   - - -
> > lo0   - your-net  localhost0 - -0   
> >   - - -
> 
> As you can see, the "drop" column for the host has
> completely outrageous values.
> 
> When representing those numbers as binary, there's
> an awful lot of zeros in the low order bits, like
> some structure is being referenced off by a word or
> two.
> 
> lidl@torb-142: bc -l
> bc 1.06
> Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
> This is free software with ABSOLUTELY NO WARRANTY.
> For details type `warranty'.
> obase=2
> 2025493932409880576
> 111011100
> 
> I also find it more than slightly curious that the "drop" values for
> bge0 and lo0 are identical.
> 
> Do we have some subtle ABI differences between the two systems
> (stable/10 vs -head)?

We have not subtle, but large ABI breakage regularly with the management
interfaces, esp. with network and CAM interfaces. Do not expect that
network configuration tools like ifconfig or route, or network statistic
tools like netstat, work between major releases.
___
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: How many CPU cores does FreeBSD support?

2017-01-06 Thread John Baldwin 
On Wednesday, January 04, 2017 09:59:09 PM Konstantin Belousov wrote:
> On Wed, Jan 04, 2017 at 06:53:23PM +, Eric Joyner wrote:
> > Adding freebsd-current, because that's a good idea.
> > 
> > I see these lines in the beginning of dmesg:
> > 
> > MADT: Ignoring local APIC ID 256 (too high)
> > 
> > 
> >   [907/911]
> > MADT: Ignoring local APIC ID 260 (too high)
> > 
> > 
> >   [906/911]
> > MADT: Ignoring local APIC ID 264 (too high)
> > 
> > 
> >   [905/911]
> > MADT: Ignoring local APIC ID 268 (too high)
> > 
> > 
> >   [904/911]
> > MADT: Ignoring local APIC ID 272 (too high)
> > 
> > 
> >   [903/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> > 
> > 
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> > 
> > 
> >   [901/911]
> > MADT: Ignoring local APIC ID 272 (too high)
> > 
> > 
> >   [903/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> > 
> > 
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> > 
> > 
> >   [901/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> > 
> > 
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> > MADT: Ignoring local APIC ID 284 (too high)
> > MADT: Ignoring local APIC ID 288 (too high)
> > MADT: Ignoring local APIC ID 292 (too high)
> > MADT: Ignoring local APIC ID 296 (too high)
> > MADT: Ignoring local APIC ID 300 (too high)
> > MADT: Ignoring local APIC ID 257 (too high)
> > MADT: Ignoring local APIC ID 261 (too high)
> > MADT: Ignoring local APIC ID 265 (too high)
> > MADT: Ignoring local APIC ID 269 (too high)
> > MADT: Ignoring local APIC ID 273 (too high)
> > MADT: Ignoring local APIC ID 277 (too high)
> > MADT: Ignoring local APIC ID 281 (too high)
> > MADT: Ignoring local APIC ID 285 (too high)
> > MADT: Ignoring local APIC ID 289 (too high)
> > MADT: Ignoring local APIC ID 293 (too high)
> > MADT: Ignoring local APIC ID 297 (too high)
> > MADT: Ignoring local APIC ID 301 (too high)
> > MADT: Ignoring local APIC ID 258 (too high)
> > MADT: Ignoring local APIC ID 262 (too high)
> > MADT: Ignoring local APIC ID 266 (too high)
> > MADT: Ignoring local APIC ID 270 (too high)
> > MADT: Ignoring local APIC ID 274 (too high)
> > MADT: Ignoring local APIC ID 278 (too high)
> > MADT: Ignoring local APIC ID 282 (too high)
> > MADT: Ignoring local APIC ID 286 (too high)
> > MADT: Ignoring local APIC ID 290 (too high)
> > MADT: Ignoring local APIC ID 294 (too high)
> > MADT: Ignoring local APIC ID 298 (too high)
> > MADT: Ignoring local APIC ID 302 (too high)
> > MADT: Ignoring local APIC ID 255 (too high)
> > MADT: Ignoring local APIC ID 259 (too high)
> > MADT: Ignoring local APIC ID 263 (too high)
> > MADT: Ignoring local APIC ID 267 (too high)
> > MADT: Ignoring local APIC ID 271 (too high)
> > MADT: Ignoring local APIC ID 275 (too high)
> > MADT: Ignoring local APIC ID 279 (too high)
> > MADT: Ignoring local APIC ID 283 (too high)
> > MADT: Ignoring local APIC ID 287 (too high)
> > MADT: Ignoring local APIC ID 291 (too high)
> > MADT: Ignoring local APIC ID 295 (too high)
> > MADT: Ignoring local APIC ID 299 (too high)
> > MADT: Ignoring local APIC ID 303 (too high)
> > Copyright (c) 1992-2016 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-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016
> > r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM
> > 3.8.0)
> > SRAT: No CPU found for memory domain 1
> > VT(efifb): resolution 800x600
> > CPU: Intel(R) Xeon Phi(TM) CPU 7250 @ 1.40GHz (1396.80-MHz K8-class CPU)
> >   Origin="GenuineIntel"  Id=0x50671  Family=0x6  Model=0x57  Stepping=1
> > 
> > Features=0xbfebfbff
> > 
> > Features2=0x7ff8f39f
> >   AMD Features=0x2c100800
> >   AMD Features2=0x121
> >   Structured Extended
> > Features=0x1c0d23ab
> >   Structured Extended Features2=0x1
> >   XSAVE Features=0x1
> >   TSC: P-state invariant, performance statistics
> > real memory  = 223332007936 (212986 MB)
> > avail memory = 216976429056 (206924 MB)
> > Event timer "LAPIC" quality 600
> > ACPI APIC Table: 
> > FreeBSD/SMP: Multiprocessor System Detected: 223 CPUs
> > FreeBSD/SMP: Non-uniform topology
> > 
> > It sounds like those MADT errors point to the problem?
> 
> In sys/x86/acpica/madt.c file, function madt_add_cpu(), just remove
> the block
>   if

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-06 Thread John Baldwin 
On Thursday, January 05, 2017 08:17:56 PM Sean Bruno wrote:
> tl;dr --> igbX devices will become emX devices
> 
> We're about to commit an update to sys/dev/e1000 that will implement and
> activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks
> who can test and poke at the drivers to do so this week.  This will have
> some really great changes for performance and standardization that have
> been bouncing around inside of various FreeBSD shops that have been
> collaborating with Matt Macy over the last year.
> 
> This will implement multiple queues for certain em(4) devices that are
> capable of such things and add some new sysctl's for you to poke at in
> your monitoring tools.
> 
> Due to limitations of device registration, igbX devices will become emX
> devices.  So, you'll need to make a minor update to your rc.conf and
> scripts that manipulate the network devices.
> 
> UPDATING will be bumped to reflect these changes.
> 
> MFC to stable/11 will have a legacy implementation that doesn't use
> IFLIB for compatibility reasons.
> 
> A documentation and man page update will follow in the next few days
> explaining how to work with the changed driver.

This is a very invasive change, and seems unnecessary.  The only thing you
can't share between two drivers with different names is the probe routine
(which you would want to be different since they would cover different
PCI ID lists).  That is, you only need:

static int
igb_probe(device_t dev)
{
/* check igb PCI ID list */
}

static int
em_probe(device_t dev)
{
/* check em PCI ID list */
}

static int
foo_attach(device_t dev)
{
   ...
}

static int
foo_detach(device_t dev)
{
   ...
}

static device_method_t igb_methods[] = {
DEVMETHOD(device_probe,   igb_probe),
DEVMETHOD(device_attach,  foo_attach),
/* Other methods all use foo_* */
};

static device_method_t em_methods[] = {
DEVMETHOD(device_probe,   em_probe),
DEVMETHOD(device_attach,  foo_attach),
/* Other methods all use foo_* */
};

static driver_t igb_driver = {
"igb", igb_methods, sizeof(struct foo_softc)
};

static driver_t em_driver = {
"em", em_methods, sizeof(struct foo_softc)
};

DRIVER_MODULE(igb, pci, igb_driver, ...);
DRIVER_MODULE(em, pci, em_driver, ...);

This isn't a huge amount of code to carry around, and seems a very small
price to pay compared to the cost of breaking existing machines (and
existing documentation, so now things have to document <= 11 and >= 12
differently, etc.).

(FWIW, this approach is what cxgbe uses to have the same driver code manage
cxgbe/cxl/cc.)

-- 
John Baldwin
___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Jonathan Anderson 

On 6 Jan 2017, at 12:48, Pete Wright wrote:


On 1/6/17 9:14 AM, Matthew Macy wrote:


I just did the merge and it's using a relatively untested new KPI so 
regressions aren't too surprising I'm afraid. #96 is more or less 
content free in terms of providing useful information. Getting a core 
+ backtrace would be a lot more helpful. See the repo's wiki for 
details on improving your odds of getting a core.




I have found the following has enabled me to catch kernel panic's 
pretty reliably on the drm-next branch when i have the i915kms module 
loaded:


dev.drm.skip_ddb=1


Excellent: I turned that on and got a core, then got another core while 
tar'ing up the first core. :)


The machine in question is currently not connected to any network (iwm 
is being a bit unhappy), but once it is, where can I put the tarball?



Jon
--
jonathan.ander...@ieee.org
___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Matthew Macy 
Thanks. Pete already filed that as part of #108. With luck markj@ will have 
that fixed this weekend.

-M


  On Fri, 06 Jan 2017 11:24:00 -0800 Jonathan Anderson 
 wrote  
 > On 6 Jan 2017, at 14:06, Matthew Macy wrote: 
 >  
 > > kernel cores tend to be large (all of wired memory after all) and  
 > > unless I have exactly the same kernel as you with the same sources at  
 > > the same changeset, not useful. A backtrace is a good place to start. 
 > >> kgdb /boot/kernel/kernel /var/crash/vmcore.last 
 > > % bt 
 > > 
 > > -M 
 >  
 > Ok, here we are: 
 >  
 > #0  doadump (textdump=0) at pcpu.h:222 
 > #1  0x82a445e7 in vt_kms_postswitch (arg=) 
 >  at  
 > /usr/home/jon/freebsd/graphics/sys/modules/drm/drm/../../../dev/drm/linux_fb.c:82
 >  
 > #2  0x808de76b in vt_window_switch (vw=0x81760ea8) 
 >  at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:540 
 > #3  0x808dc280 in vtterm_cngrab (tm=) 
 >  at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:1465 
 > #4  0x809f3e02 in cngrab () at  
 > /usr/home/jon/freebsd/graphics/sys/kern/kern_cons.c:368 
 > #5  0x80a4d27a in vpanic (fmt=0x80ff218f "Assertion %s  
 > failed at %s:%d", 
 >  ap=0xfe0233e6f5f0) at  
 > /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:765 
 > #6  0x80a4d166 in kassert_panic (fmt=) 
 >  at /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:669 
 > #7  0x80d2b93c in vm_fault_hold (map=0xf8010c9aa000,  
 > vaddr=34369822720, 
 >  fault_type=, fault_flags=0, m_hold=0x0) 
 >  at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:389 
 > #8  0x80d2a1b8 in vm_fault (map=0xf8010c9aa000, vaddr= optimized out>, 
 >  fault_type=2 '\002', fault_flags=) 
 >  at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:474 
 > #9  0x80ebb412 in trap_pfault (frame=0xfe0233e6f9c0,  
 > usermode=1) 
 >  at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:708 
 > #10 0x80ebaba2 in trap (frame=0xfe0233e6f9c0) 
 >  at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:326 
 > #11 0x80e9b181 in calltrap () 
 >  at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/exception.S:236 
 > #12 0x0008022a3876 in ?? () 
 >  
 > It looks like the other core files have the same backtrace. Please let  
 > me know if any other details would help... 
 >  
 >  
 > Jon 
 > -- 
 > jonathan.ander...@ieee.org 
 > 


___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Jonathan Anderson 

On 6 Jan 2017, at 13:53, Pete Wright wrote:


i've been having the same problems with iwm too (failing to load 
firmware on boot).  my trick has been to either boot into an old 
kernel where iwm was mostly usable.  also i've commented out the line 
enabling wlan0 in my rc.conf then uncommented it after boot and 
manually running "service netif start" to bring up iwm.  that method 
works most of the time...

-pete


I am able to load iwm (iwm7265fw), but there are some networks that I 
just can't connect to (INIT -> INIT, swscan_cancel_scan, repeat). 
Attaching to an iPhone hotspot is one example of a not-entirely-helpful 
network, but there is other, more typical infrastructure that gives 
trouble too. There is an iwm8xxx in the room that seems to work fine, 
however... I do not meddle in the affairs of wi-fi, for it is subtle and 
quick to anger. :)



Jon
--
Jonathan Anderson
jonat...@freebsd.org
___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Matthew Macy 
kernel cores tend to be large (all of wired memory after all) and unless I have 
exactly the same kernel as you with the same sources at the same changeset, not 
useful. A backtrace is a good place to start. 
> kgdb /boot/kernel/kernel /var/crash/vmcore.last 
% bt

-M

  On Fri, 06 Jan 2017 10:53:03 -0800 Pete Wright  
wrote  
 >  
 >  
 > On 1/6/17 10:44 AM, Jonathan Anderson wrote: 
 > > On 6 Jan 2017, at 12:48, Pete Wright wrote: 
 > > 
 > >> On 1/6/17 9:14 AM, Matthew Macy wrote: 
 > >>> 
 > >>> I just did the merge and it's using a relatively untested new KPI so 
 > >>> regressions aren't too surprising I'm afraid. #96 is more or less 
 > >>> content free in terms of providing useful information. Getting a core 
 > >>> + backtrace would be a lot more helpful. See the repo's wiki for 
 > >>> details on improving your odds of getting a core. 
 > >>> 
 > >> 
 > >> I have found the following has enabled me to catch kernel panic's 
 > >> pretty reliably on the drm-next branch when i have the i915kms module 
 > >> loaded: 
 > >> 
 > >> dev.drm.skip_ddb=1 
 > > 
 > > Excellent: I turned that on and got a core, then got another core while 
 > > tar'ing up the first core. :) 
 > > 
 > > The machine in question is currently not connected to any network (iwm 
 > > is being a bit unhappy), but once it is, where can I put the tarball? 
 > > 
 > > 
 > oh great! 
 >  
 > i've been having the same problems with iwm too (failing to load  
 > firmware on boot).  my trick has been to either boot into an old kernel  
 > where iwm was mostly usable.  also i've commented out the line enabling  
 > wlan0 in my rc.conf then uncommented it after boot and manually running  
 > "service netif start" to bring up iwm.  that method works most of the  
 > time... 
 > -pete 
 >  
 > --  
 > Pete Wright 
 > p...@nomadlogic.org 
 > nomadlogicLA 
 > ___ 
 > 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-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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Pete Wright 



On 1/6/17 10:44 AM, Jonathan Anderson wrote:

On 6 Jan 2017, at 12:48, Pete Wright wrote:


On 1/6/17 9:14 AM, Matthew Macy wrote:


I just did the merge and it's using a relatively untested new KPI so
regressions aren't too surprising I'm afraid. #96 is more or less
content free in terms of providing useful information. Getting a core
+ backtrace would be a lot more helpful. See the repo's wiki for
details on improving your odds of getting a core.



I have found the following has enabled me to catch kernel panic's
pretty reliably on the drm-next branch when i have the i915kms module
loaded:

dev.drm.skip_ddb=1


Excellent: I turned that on and got a core, then got another core while
tar'ing up the first core. :)

The machine in question is currently not connected to any network (iwm
is being a bit unhappy), but once it is, where can I put the tarball?



oh great!

i've been having the same problems with iwm too (failing to load 
firmware on boot).  my trick has been to either boot into an old kernel 
where iwm was mostly usable.  also i've commented out the line enabling 
wlan0 in my rc.conf then uncommented it after boot and manually running 
"service netif start" to bring up iwm.  that method works most of the 
time...

-pete

--
Pete Wright
p...@nomadlogic.org
nomadlogicLA
___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Pete Wright 



On 1/6/17 9:14 AM, Matthew Macy wrote:


 > > Please try the drm-next branch now. Up until very recently, the
 > > shrinkers responsible for culling ttm/gem allocations were never run.
 > > I've now implemented the shrinker, but it's driven from vm_lowmem, so
 > > you'll probably still see what looks like a leak until you hit low
 > > memory conditions. The shrinker should probably be run from
 > > uma_timeout, but there isn't an eventhandler for that and I haven't
 > > looked any further.
 > >
 > > -M
 >
 > Hi,
 >
 > I am now testing the `drm-next` branch, but I'm finding it crashes much
 > more frequently (a la
 > https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than
 > `drm-next-4.7`. While the 4.7 branch would sometimes only last a few
 > minutes, it would sometimes run for a day or more. On `drm-next`,
 > however, I think I'm yet to have 20 minutes of uptime. So, I haven't run
 > into the memory shrinker yet because I haven't had enough uptime to use
 > lots of memory. :) I will continue testing... any specific things I
 > ought to be doing?
 >



I just did the merge and it's using a relatively untested new KPI so 
regressions aren't too surprising I'm afraid. #96 is more or less content free 
in terms of providing useful information. Getting a core + backtrace would be a 
lot more helpful. See the repo's wiki for details on improving your odds of 
getting a core.



I have found the following has enabled me to catch kernel panic's pretty 
reliably on the drm-next branch when i have the i915kms module loaded:


dev.drm.skip_ddb=1


-pete

--
Pete Wright
p...@nomadlogic.org
nomadlogicLA
___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Matthew Macy 

 > > Please try the drm-next branch now. Up until very recently, the  
 > > shrinkers responsible for culling ttm/gem allocations were never run.  
 > > I've now implemented the shrinker, but it's driven from vm_lowmem, so  
 > > you'll probably still see what looks like a leak until you hit low  
 > > memory conditions. The shrinker should probably be run from  
 > > uma_timeout, but there isn't an eventhandler for that and I haven't  
 > > looked any further. 
 > > 
 > > -M 
 >  
 > Hi, 
 >  
 > I am now testing the `drm-next` branch, but I'm finding it crashes much  
 > more frequently (a la  
 > https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than  
 > `drm-next-4.7`. While the 4.7 branch would sometimes only last a few  
 > minutes, it would sometimes run for a day or more. On `drm-next`,  
 > however, I think I'm yet to have 20 minutes of uptime. So, I haven't run  
 > into the memory shrinker yet because I haven't had enough uptime to use  
 > lots of memory. :) I will continue testing... any specific things I  
 > ought to be doing? 
 >  
 


I just did the merge and it's using a relatively untested new KPI so 
regressions aren't too surprising I'm afraid. #96 is more or less content free 
in terms of providing useful information. Getting a core + backtrace would be a 
lot more helpful. See the repo's wiki for details on improving your odds of 
getting a core.

-M





___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Jonathan Anderson 

On 5 Jan 2017, at 0:17, Matthew Macy wrote:

  On Mon, 02 Jan 2017 06:01:50 -0800 Jonathan Anderson 
 wrote 

Hi all,

I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly 
close
to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use 
of
not-quite-CURRENT, it's also very possible that I don't understand 
how the
laundry queue is supposed to work. Nonetheless, I thought I'd check 
whether
there is a tunable I should change, an issue with the laundry queue 
itself,

etc.

After running X overnight (i915 can now run overnight on 
drm-next-4.7!), I
end up with a little over half of my system memory in the laundry 
queue and
a bunch of swap utilization. Even after closing X and shutting down 
lots of

services, I see the following in top:



Please try the drm-next branch now. Up until very recently, the 
shrinkers responsible for culling ttm/gem allocations were never run. 
I've now implemented the shrinker, but it's driven from vm_lowmem, so 
you'll probably still see what looks like a leak until you hit low 
memory conditions. The shrinker should probably be run from 
uma_timeout, but there isn't an eventhandler for that and I haven't 
looked any further.


-M


Hi,

I am now testing the `drm-next` branch, but I'm finding it crashes much 
more frequently (a la 
https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than 
`drm-next-4.7`. While the 4.7 branch would sometimes only last a few 
minutes, it would sometimes run for a day or more. On `drm-next`, 
however, I think I'm yet to have 20 minutes of uptime. So, I haven't run 
into the memory shrinker yet because I haven't had enough uptime to use 
lots of memory. :) I will continue testing... any specific things I 
ought to be doing?



Jon
--
jonat...@freebsd.org
___
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: PQ_LAUNDRY: unexpected behaviour

2017-01-06 Thread Jonathan Anderson 

On 2 Jan 2017, at 13:33, Mark Johnston wrote:


On Mon, Jan 02, 2017 at 10:31:50AM -0330, Jonathan Anderson wrote:

Hi all,

I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly 
close
to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use 
of
not-quite-CURRENT, it's also very possible that I don't understand 
how the
laundry queue is supposed to work. Nonetheless, I thought I'd check 
whether
there is a tunable I should change, an issue with the laundry queue 
itself,

etc.


My suspicion is that this is a memory leak of some sort and unrelated 
to
PQ_LAUNDRY itself. That is, with the previous policy you would see 
lots

of swap usage and a large inactive queue instead.


That sounds very plausible... I'm testing with the new DRM drivers to 
see if that helps.



After running X overnight (i915 can now run overnight on 
drm-next-4.7!), I
end up with a little over half of my system memory in the laundry 
queue and
a bunch of swap utilization. Even after closing X and shutting down 
lots of

services, I see the following in top:

```
Mem: 977M Active, 31M Inact, 4722M Laundry, 1917M Wired, 165M Free
ARC: 697M Total, 67M MFU, 278M MRU, 27K Anon, 22M Header, 331M Other
Swap: 4096M Total, 2037M Used, 2059M Free, 49% Inuse

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU
COMMAND
  911 root  1  520 57788K  4308K select  1   0:00   0.00% 
sshd

  974 root  1  200 43780K 0K wait2   0:00   0.00%

 1406 jon   1  200 33520K  2748K select  0   0:04   0.00%
gpg-agent
 2038 jon   1  200 31280K  5452K ttyin   3   0:18   0.00% 
zsh
 1251 jon   1  220 31280K  4500K pause   3   0:02   1.46% 
zsh
 7102 jon   1  200 31280K  3744K ttyin   0   0:00   0.00% 
zsh
 1898 jon   1  200 31280K  3036K ttyin   1   0:00   0.00% 
zsh
 1627 jon   1  210 31280K 0K pause   0   0:00   0.00% 

22989 jon   1  200 31152K  6020K ttyin   1   0:01   0.00% 
zsh
22495 jon   1  490 31152K  6016K ttyin   0   0:02   0.00% 
zsh
 1621 jon   1  200 28196K  8816K select  2   0:40   0.00% 
tmux
 6214 jon   1  520 27008K  2872K ttyin   1   0:00   0.00% 
zsh
 6969 jon   1  520 27008K  2872K ttyin   3   0:00   0.00% 
zsh

 6609 root  1  200 20688K  4604K select  1   0:00   0.00%
wpa_supplicant
  914 root  1  200 20664K  5232K select  2   0:02   0.00%
sendmail
  917 smmsp 1  200 20664K 0K pause   0   0:00   0.00%

24206 jon   1  230 20168K  3500K CPU00   0:00   0.00% 
top
  921 root  1  200 12616K   608K nanslp  1   0:00   0.00% 
cron

```

Are there any things I could do (e.g., sysctls, tunables) to figure 
out
what's happening? Can I manually force the laundry to be done? 
`swapoff -a`

fails due to a lack of memory.


Is that the full list of processes? Does "ipcs -m" show any named shm
segments?

Looking at the DRM code, the GEM uses swap objects to back allocations
by the drivers, so this could be the result of a kernel page leak in 
the

drm-next branch. If so, you'll need a reboot to recover.


That was the full list of processes, yes. I haven't been able to 
reproduce this particular issue on new DRM code, as I'm now confronted 
with a different issue. :) If I do get back to this condition, I'll try 
checking `ipcs -m`, thanks.



Jon
--
jonat...@freebsd.org
___
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: ACPI Error on HP ProBook 430 G2

2017-01-06 Thread Alexandr Krivulya 

03.01.2017 20:21, Jung-uk Kim пишет:

On 01/03/2017 11:22, Hans Petter Selasky wrote:

On 01/03/17 16:26, Moore, Robert wrote:

Not sure I understand. The fix has been committed, and is part of
version 20161222.



Hi Robert,

 From what I can see that patches have been pushed to the following
branch, vendor-sys/acpica/20161222/, see:

https://svnweb.freebsd.org/changeset/base/310451

But not yet to "master" (12-current) ?

Is that correct?

My console has been filling up with messages like this:


ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
[OpcodeName unavailable] (20161117/dswexec-498)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC._Q50] (Node 0xf800047fce40),
AE_AML_OPERAND_TYPE (20161117/psparse-560)
acpi_ec0: evaluation of query method _Q50 failed: AE_AML_OPERAND_TYPE

over the holidays, so I assume that means the previous version of ACPI,
20161117 which the 20161222 version is supposed to fix.

I was AFK for two weeks.  I will merge ACPICA 20161222 to FreeBSD head
this week when I find some free time.




I don't know if my problem related to this topic, but a few weeks I see 
in KDE battery capacity -1%. acpiconf shows no battery:


root@thinkpad:/home/shurik # acpiconf -i0
Design capacity:0 mWh
Last full capacity: 0 mWh
Technology: primary (non-rechargeable)
Design voltage: 0 mV
Capacity (warn):0 mWh
Capacity (low): 0 mWh
Low/warn granularity:   0 mWh
Warn/full granularity:  0 mWh
Model number:
Serial number:
Type:
OEM info:
State:  not present
Present voltage:12611 mV

Just updated to r311492 and problem still present. There is no such 
problem on previous kernel r310241. And there is no more error messages:


Jan  6 09:22:39 thinkpad kernel: ACPI Error: Needed type [Reference], 
found [Processor] 0xf800055d5000 (20161117/exresop-111)
Jan  6 09:22:39 thinkpad kernel: ACPI Error: Method parse/execution 
failed [\PNOT] (Node 0xf80005595bc0), AE_AML_OPERAND_TYPE 
(20161117/psparse-560)
Jan  6 09:22:39 thinkpad kernel: ACPI Error: Method parse/execution 
failed [\_SB.PCI0.LPCB.EC0._REG] (Node 0xf8000558a040), 
AE_AML_OPERAND_TYPE (20161117/psparse-560)



--
___
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: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-06 Thread Sean Bruno 


On 01/06/17 03:48, Steven Hartland wrote:
> Hmm I'm not sure about everyone else but I we treat emX as legacy
> devices (not used one in years) but igbX is very common here.
> 
> The impact of changing a nic device name is quite a bit more involved
> than just rc.conf it effects other areas too, jails etc so given we can
> loose access to the machine on reboot if everything isn't done right, it
> would be worth considering:
> 
>  * Change emX -> igbX to lower the impact.
>  * Add shims / alias so that operations on the device name going away
>still work.
> 
> What do people think?
> 

We have a "legacy" code implementation that does exactly what you're
describing and we intend on putting that version into 11-stable so that
existing users won't bang their heads against it.

The amount of code in the tree dropped *significantly* when we dropped
this implementation, hence why we wanted to make 12-current a clean break.

sean

bcc matt
> 
> On 06/01/2017 03:17, Sean Bruno wrote:
>> tl;dr --> igbX devices will become emX devices
>>
>> We're about to commit an update to sys/dev/e1000 that will implement and
>> activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks
>> who can test and poke at the drivers to do so this week.  This will have
>> some really great changes for performance and standardization that have
>> been bouncing around inside of various FreeBSD shops that have been
>> collaborating with Matt Macy over the last year.
>>
>> This will implement multiple queues for certain em(4) devices that are
>> capable of such things and add some new sysctl's for you to poke at in
>> your monitoring tools.
>>
>> Due to limitations of device registration, igbX devices will become emX
>> devices.  So, you'll need to make a minor update to your rc.conf and
>> scripts that manipulate the network devices.
>>
>> UPDATING will be bumped to reflect these changes.
>>
>> MFC to stable/11 will have a legacy implementation that doesn't use
>> IFLIB for compatibility reasons.
>>
>> A documentation and man page update will follow in the next few days
>> explaining how to work with the changed driver.
>>
>> sean
>>
>> bcc net@ current@ re@
>>
>>
>>
> 
> ___
> 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"
> 



signature.asc
Description: OpenPGP digital signature

ABI differences between stable/10 and head?

2017-01-06 Thread Kurt Lidl 

Yesterday, I upgraded the kernel on my sparc64 to -head,
so I was running a mis-matched kernel and userland.
The userland was a recent (as of two days ago) stable/10.

In the nightly report, I noticed the following:


Network interface status:
NameMtu Network   Address  Ipkts Ierrs IdropOpkts Oerrs 
 Coll  Drop
bge0  -   00:03:ba:e0:ce:070 64691 00 0 
11494817 2025493932409880576
bge0  - fe80::203:baf fe80::203:baff:fe0 - -0 - 
- -
bge0  - spork.pix.net 2001:470:e254:10:0 - -0 - 
- -
bge0  - 192.168.16.0  spork0 - -0 - 
- -
bge1  -   00:03:ba:e0:ce:080 0 00 0 
0 4040291828690585088
bge2  -   00:03:ba:e0:ce:090 0 00 0 
0 4040291832985552384
bge3  -   00:03:ba:e0:ce:0a0 0 00 0 
0 4040291837582442496
lo0   -    074 00 0 
38794 2025493932409880576
lo0   - localhost ::1  0 - -0 - 
- -
lo0   - fe80::1%lo0   fe80::1%lo0  0 - -0 - 
- -
lo0   - your-net  localhost0 - -0 - 
- -


As you can see, the "drop" column for the host has
completely outrageous values.

When representing those numbers as binary, there's
an awful lot of zeros in the low order bits, like
some structure is being referenced off by a word or
two.

lidl@torb-142: bc -l
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
obase=2
2025493932409880576
111011100

I also find it more than slightly curious that the "drop" values for
bge0 and lo0 are identical.

Do we have some subtle ABI differences between the two systems
(stable/10 vs -head)?

-Kurt
___
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: ACPI Error on HP ProBook 430 G2

2017-01-06 Thread Edward Tomasz Napierala 
I've just updated, and the problem is gone.  Thanks!

On 1221T1520, Moore, Robert wrote:
> We have fixed this issue for the latest version of ACPICA that will happen 
> this week, probably 22 december.
> 
> 
> > -Original Message-
> > From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> > a...@freebsd.org] On Behalf Of Edward Tomasz Napierala
> > Sent: Wednesday, December 21, 2016 3:15 AM
> > To: O. Hartmann 
> > Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> > Zakharov 
> > Subject: Re: ACPI Error on HP ProBook 430 G2
> > 
> > On 1220T1734, O. Hartmann wrote:
> > > Am Tue, 20 Dec 2016 18:09:20 +0300
> > > Vladimir Zakharov  schrieb:
> > >
> > > > Hello!
> > > >
> > > > Some time ago new ACPI messages appeared on console and in
> > > > /var/log/messages. Like
> > > > these:
> > > >
> > > > ACPI Error: Needed type [Reference], found [Processor]
> > > > 0xf800043b8980
> > > > (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While
> > > > resolving operands for [OpcodeName unavailable]
> > > > (20161117/dswexec-498) ACPI Error: Method parse/execution failed
> > > > [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640),
> > > > AE_AML_OPERAND_TYPE
> > > > (20161117/psparse-560) ACPI Error: Method parse/execution failed
> > > > [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40),
> > > > AE_AML_OPERAND_TYPE
> > > > (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04
> > failed:
> > > > AE_AML_OPERAND_TYPE
> > > >
> > > > I'm sure that there were no such messages earlier. Suspend/resume
> > > > works for me. But after disconnecting power line hw.acpi.acline
> > > > still equals to 1. And powerd/powerdxx do not adjust CPU frequency
> > anymore.
> > > >
> > > > System info:
> > > > $ uname -a
> > > > FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M:
> > > > Tue Dec 20 16:42:21 MSK 2016
> > > > root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > > >
> > > > dmesg: http://pastebin.com/cYD8cR0b
> > > > hw.acpi: http://pastebin.com/Tht9B0FZ
> > > > acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl
> > > >
> > > >
> > > > PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.
> > > >
> > >
> > > I see lots of ACPI errors also shortly on a Lenovo E540 UEFI notebook
> > > running most recent CURRENT ...
> > 
> > +1, I see the same on Thinkpad T420.
> > 
> > ___
> > freebsd-a...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> > To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
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: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-06 Thread Steven Hartland 
Hmm I'm not sure about everyone else but I we treat emX as legacy 
devices (not used one in years) but igbX is very common here.


The impact of changing a nic device name is quite a bit more involved 
than just rc.conf it effects other areas too, jails etc so given we can 
loose access to the machine on reboot if everything isn't done right, it 
would be worth considering:


 * Change emX -> igbX to lower the impact.
 * Add shims / alias so that operations on the device name going away
   still work.

What do people think?


On 06/01/2017 03:17, Sean Bruno wrote:

tl;dr --> igbX devices will become emX devices

We're about to commit an update to sys/dev/e1000 that will implement and
activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks
who can test and poke at the drivers to do so this week.  This will have
some really great changes for performance and standardization that have
been bouncing around inside of various FreeBSD shops that have been
collaborating with Matt Macy over the last year.

This will implement multiple queues for certain em(4) devices that are
capable of such things and add some new sysctl's for you to poke at in
your monitoring tools.

Due to limitations of device registration, igbX devices will become emX
devices.  So, you'll need to make a minor update to your rc.conf and
scripts that manipulate the network devices.

UPDATING will be bumped to reflect these changes.

MFC to stable/11 will have a legacy implementation that doesn't use
IFLIB for compatibility reasons.

A documentation and man page update will follow in the next few days
explaining how to work with the changed driver.

sean

bcc net@ current@ re@





___
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: linuxkpi

2017-01-06 Thread Hans Petter Selasky 

On 01/06/17 11:04, blubee blubeeme wrote:

I was looking at the linuxkpi source code in /sys/compat/linuxkpi and I had
a question.

A lot of those files just look like linux files brought over to FreeBSD, is
there any reason why those files couldn't be implemented in BSD w/o the
dependencies on the other Linux headers?

For example this header file:
sys/compat/linuxkpi/common/include/linux/workqueue.h

the workqueue.h, there doesn't seem to be anything special in there that
couldn't be implemented in BSD without relying on the Linux import
statements.

Maybe I'm missing something but why can't these files and functions be
implemented directly with their BSD equivalents?


Hi Owen,

Many of the conversion macros you find in the LinuxKPI are very simple 
as you've already figured out. The main reason to have them is to avoid 
modifying the OS-shared code, even if this can be scripted.


At the moment tinkering starts with the OS-shared code, applying patches 
from a so-called "upstream" branch will be made harder, depending on if 
the place a patch covers was rewritten to BSD-native API's or not.


The LinuxKPI also allows a shared-code vendor to gradually make code 
more BSD native, if it wishes. In the beginning all kernel APIs used 
might be through the LinuxKPI, but later on this can easily be changed 
for critical areas where there is a substantial difference between BSD 
and Linux.


The LinuxKPI is meant to be a bridge builder. There is also a similar 
"LinuxKPI" in /usr/ports/multimedia/webcamd for user-space if you are 
interested in that.


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

linuxkpi

2017-01-06 Thread blubee blubeeme 
I was looking at the linuxkpi source code in /sys/compat/linuxkpi and I had
a question.

A lot of those files just look like linux files brought over to FreeBSD, is
there any reason why those files couldn't be implemented in BSD w/o the
dependencies on the other Linux headers?

For example this header file:
sys/compat/linuxkpi/common/include/linux/workqueue.h

the workqueue.h, there doesn't seem to be anything special in there that
couldn't be implemented in BSD without relying on the Linux import
statements.

Maybe I'm missing something but why can't these files and functions be
implemented directly with their BSD equivalents?

Best,
Owen
___
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"