FreeBSD_HEAD_i386 - Build #3463 - Fixed

2016-06-27 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3463 - Fixed:

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

Change summaries:

302242 by kib:
Fix userspace build after r302235: do not expose bool field of the
structure, change it to int.

The real fix is to sanitize user-visible definitions in sys/event.h,
e.g. the affected struct knlist is of no use for userspace programs.

Reported and tested by: jkim
Sponsored by:   The FreeBSD Foundation
MFC after:  2 weeks
Approved by:re (gjb)

___
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 #3462 - Failure

2016-06-27 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3462 - Failure:

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

Change summaries:

302236 by kib:
If the vm_fault() handler raced with the vm_object_collapse()
sleepable scan, iteration over the shadow chain looking for a page
could find an OBJ_DEAD object.  Such state of the mapping is only
transient, the dead object will be terminated and removed from the
chain shortly.  We must not return KERN_PROTECTION_FAILURE unless the
object type is changed to OBJT_DEAD in the chain, indicating that
paging on this address is really impossible.  Returning
KERN_PROTECTION_FAILURE prematurely causes spurious SIGSEGV delivered
to processes, or kernel accesses to UVA spuriously failing with
EFAULT.

If the object with OBJ_DEAD flag is found, only return
KERN_PROTECTION_FAILURE when object type is already OBJT_DEAD.
Otherwise, sleep a tick and retry the fault handling.

Ideally, we would wait until the OBJ_DEAD flag is resolved, e.g. by
waiting until the paging on this object is finished.  But to do so, we
need to reference the dead object, while vm_object_collapse() insists
on owning the final reference on the collapsed object.  This could be
fixed by e.g. changing the assert to shared reference release between
vm_fault() and vm_object_collapse(), but it seems to be too much
complications for rare boundary condition.

PR: 204426
Tested by:pho
Reviewed by:  alc
Sponsored by: The FreeBSD Foundation
X-Differential revision:https://reviews.freebsd.org/D6085
MFC after:  2 weeks
Approved by:re (gjb)

302235 by kib:
When filt_proc() removes event from the knlist due to the process
exiting (NOTE_EXIT->knlist_remove_inevent()), two things happen:
- knote kn_knlist pointer is reset
- INFLUX knote is removed from the process knlist.
And, there are two consequences:
- KN_LIST_UNLOCK() on such knote is nop
- there is nothing which would block exit1() from processing past the
  knlist_destroy() (and knlist_destroy() resets knlist lock pointers).
Both consequences result either in leaked process lock, or
dereferencing NULL function pointers for locking.

Handle this by stopping embedding the process knlist into struct proc.
Instead, the knlist is allocated together with struct proc, but marked
as autodestroy on the zombie reap, by knlist_detach() function.  The
knlist is freed when last kevent is removed from the list, in
particular, at the zombie reap time if the list is empty.  As result,
the knlist_remove_inevent() is no longer needed and removed.

Other changes:

In filt_procattach(), clear NOTE_EXEC and NOTE_FORK desired events
from kn_sfflags for knote registered by kernel to only get NOTE_CHILD
notifications.  The flags leak resulted in excessive
NOTE_EXEC/NOTE_FORK reports.

Fix immediate note activation in filt_procattach().  Condition should
be either the immediate CHILD_NOTE activation, or immediate NOTE_EXIT
report for the exiting process.

In knote_fork(), do not perform racy check for KN_INFLUX before kq
lock is taken.  Besides being racy, it did not accounted for notes
just added by scan (KN_SCAN).

Some minor and incomplete style fixes.

Analyzed and tested by: Eric Badger 
Reviewed by:jhb
Sponsored by:   The FreeBSD Foundation
MFC after:  2 weeks
Approved by:re (gjb)
Differential revision:  https://reviews.freebsd.org/D6859



The end of the build log:

[...truncated 31154 lines...]
--- mskanji.o ---
cc   -O2 -pipe   -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include 
-I/usr/src/lib/libc/i386 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/usr/src/lib/libc/../../contrib/gdtoa 
-I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include 
-I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD  
-MF.depend.mskanji.o -MTmskanji.o -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-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-prom
 oted-parameter  -Qunused-arguments  -I/usr/src/lib/libutil 
-I/usr/src/lib/msun/i387 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c 
/usr/src/lib/libc/locale/mskanji.c -o mskanji.o
--- nextwctype.o ---
cc   -O2 -pipe   -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include 
-I/usr/src/lib/libc/i386 -DNLS  -D__DBINTERFACE_PRIVATE

Re: Restarting rtwn(0)-based interface causes reproducible kernel panics

2016-06-27 Thread Otacílio 

Em 27/06/2016 14:14, Marcus von Appen escreveu:

Hi,

restarting the network interface for my rtwn(0)-based RTL8188CE card
causes a reproducible kernel panic:

# service netif restart
[...]
panic: Memory modified after free 0xf80005c22800(2048) val=8018 @ 
0xf80005c22800
[...]

Unread portion of the kernel message buffer:
panic: Memory modified after free 0xf80005c22800(2048) val=8018 @ 
0xf80005c22800

cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe045362b670
vpanic() at vpanic+0x186/frame 0xfe045362b6f0
panic() at panic+0x43/frame 0xfe045362b750
trash_ctor() at trash_ctor+0x4b/frame 0xfe045362b760
mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe045362b7a0
uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe045362b800
ieee80211_getmgtframe() at ieee80211_getmgtframe+0x120/frame 0xfe045362b840
ieee80211_send_probereq() at ieee80211_send_probereq+0x104/frame 
0xfe045362b8e0
ieee80211_swscan_probe_curchan() at ieee80211_swscan_probe_curchan+0x5a/frame 
0xfe045362b920
scan_curchan() at scan_curchan+0x68/frame 0xfe045362b960
scan_curchan_task() at scan_curchan_task+0x247/frame 0xfe045362b9e0
taskqueue_run_locked() at taskqueue_run_locked+0x13c/frame 0xfe045362ba40
taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfe045362ba70
fork_exit() at fork_exit+0x84/frame 0xfe045362bab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe045362bab0
[...]

and (probably) a variant:

# service netif restart
[...]
panic: Memory modified after free 0xf80005c07800(2048) val=19 @ 
0xf80005c07800
[...]
Unread portion of the kernel message buffer:
panic: Memory modified after free 0xf80005c07800(2048) val=19 @ 
0xf80005c07800

cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0455213540
vpanic() at vpanic+0x186/frame 0xfe04552135c0
panic() at panic+0x43/frame 0xfe0455213620
trash_ctor() at trash_ctor+0x4b/frame 0xfe0455213630
mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe0455213670
uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe04552136d0
m_getm2() at m_getm2+0x12d/frame 0xfe0455213740
m_uiotombuf() at m_uiotombuf+0x62/frame 0xfe0455213790
sosend_generic() at sosend_generic+0x356/frame 0xfe0455213850
kern_sendit() at kern_sendit+0x244/frame 0xfe0455213900
sendit() at sendit+0x1af/frame 0xfe0455213950
sys_sendto() at sys_sendto+0x4d/frame 0xfe04552139a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0455213ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0455213ab0
[...]

Let me know how to help on getting this fixed.

Cheers
Marcus


What is the revision that you are using? I have faced a similar problem 
on APLHA4, but now, on ALPHA5 it is working fine.


[]'s

-Otacilio

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

Restarting rtwn(0)-based interface causes reproducible kernel panics

2016-06-27 Thread Marcus von Appen 
Hi,

restarting the network interface for my rtwn(0)-based RTL8188CE card
causes a reproducible kernel panic:

# service netif restart
[...]
panic: Memory modified after free 0xf80005c22800(2048) val=8018 @ 
0xf80005c22800
[...]

Unread portion of the kernel message buffer:
panic: Memory modified after free 0xf80005c22800(2048) val=8018 @ 
0xf80005c22800

cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe045362b670
vpanic() at vpanic+0x186/frame 0xfe045362b6f0
panic() at panic+0x43/frame 0xfe045362b750
trash_ctor() at trash_ctor+0x4b/frame 0xfe045362b760
mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe045362b7a0
uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe045362b800
ieee80211_getmgtframe() at ieee80211_getmgtframe+0x120/frame 0xfe045362b840
ieee80211_send_probereq() at ieee80211_send_probereq+0x104/frame 
0xfe045362b8e0
ieee80211_swscan_probe_curchan() at ieee80211_swscan_probe_curchan+0x5a/frame 
0xfe045362b920
scan_curchan() at scan_curchan+0x68/frame 0xfe045362b960
scan_curchan_task() at scan_curchan_task+0x247/frame 0xfe045362b9e0
taskqueue_run_locked() at taskqueue_run_locked+0x13c/frame 0xfe045362ba40
taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfe045362ba70
fork_exit() at fork_exit+0x84/frame 0xfe045362bab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe045362bab0
[...]

and (probably) a variant:

# service netif restart
[...]
panic: Memory modified after free 0xf80005c07800(2048) val=19 @ 
0xf80005c07800
[...]
Unread portion of the kernel message buffer:
panic: Memory modified after free 0xf80005c07800(2048) val=19 @ 
0xf80005c07800

cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0455213540
vpanic() at vpanic+0x186/frame 0xfe04552135c0
panic() at panic+0x43/frame 0xfe0455213620
trash_ctor() at trash_ctor+0x4b/frame 0xfe0455213630
mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe0455213670
uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe04552136d0
m_getm2() at m_getm2+0x12d/frame 0xfe0455213740
m_uiotombuf() at m_uiotombuf+0x62/frame 0xfe0455213790
sosend_generic() at sosend_generic+0x356/frame 0xfe0455213850
kern_sendit() at kern_sendit+0x244/frame 0xfe0455213900
sendit() at sendit+0x1af/frame 0xfe0455213950
sys_sendto() at sys_sendto+0x4d/frame 0xfe04552139a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0455213ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0455213ab0
[...]

Let me know how to help on getting this fixed.

Cheers
Marcus


signature.asc
Description: PGP signature

FreeBSD_HEAD_amd64_gcc - Build #1308 - Failure

2016-06-27 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1308 - Failure:

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

Change summaries:

30 by delphij:
Fix build: explicitly reference the generated magic.h as dependency
of mkmagic and point its location.

Reported by:jenkins
Pointy hat to:  delphij
MFC after:  2 weeks
X-MFC-With: 302221
Approved by:re (kib)

302221 by delphij:
MFV r302218: file 5.28.

Relnotes:   yes
MFC after:  2 weeks
Approved by:re (gjb)

302216 by kib:
When sleeping waiting for either local or remote advisory lock,
interrupt sleeps with the ERESTART on the suspension attempts.
Otherwise, single-threading requests are deferred until the locks are
granted for NFS files, which causes hangs.

When retrying local registration of the remotely-granted adv lock,
allow full suspension and check for suspension, for usual reasons.

Reported by:markj, pho
Reviewed by:jilles
Tested by:  pho
Sponsored by:   The FreeBSD Foundation
MFC after:  2 weeks
Approved by:re (gjb)

302215 by kib:
Rewrite sigdeferstop(9) and sigallowstop(9) into more flexible
framework allowing to set the suspension policy for the dynamic block.
Extend the currently possible policies of stopping on interruptible
sleeps and ignoring such sleeps by two more: do not suspend at
interruptible sleeps, but interrupt them with either EINTR or ERESTART.

Reviewed by:jilles
Tested by:  pho
Sponsored by:   The FreeBSD Foundation
MFC after:  2 weeks
Approved by:re (gjb)

302214 by nwhitehorn:
Enter 64-bit mode as early as possible in the 64-bit PowerPC boot sequence.
Most of the effect of setting MSR[SF] is that the CPU will stop ignoring
the high 32 bits of registers containing addresses in load/store
instructions. As such, the kernel was setting it only when it began to
need access to high memory. MSR[SF] also affects the operation of some
conditional instructions, however, and so setting it at late times could
subtly break code at very early times. This fixes use of the FDT mode in
loader, and FDT boot more generally, on 64-bit PowerPC systems.

Hardware provided by: IBM LTC
Approved by: re (kib)

302213 by dchagin:
Fix a bug introduced in r283433.

[1] Remove unneeded sockaddr conversion before kern_recvit() call as the from
argument is used to record result (the source address of the received message) 
only.

[2] In Linux the type of msg_namelen member of struct msghdr is signed but 
native
msg_namelen has a unsigned type (socklen_t). So use the proper storage to fetch 
fromlen
from userspace and than check the user supplied value and return EINVAL if it 
is less
than 0 as a Linux do.

Reported by:Thomas Mueller  [1]
Reviewed by:kib@
Approved by:re (gjb, kib)
MFC after:  3 days

302212 by tuexen:
This patch fixes two bugs related to the SCTP message recovery
for messages which have been put on the send queue:
* Do not report any DATA or I-DATA chunk padding.
* Correctly deal with the I-DATA chunk header instead of the DATA
  chunk header when the I-DATA extension is used.

Approved by:re (kib)
MFC after:  1 week

302211 by novel:
bhyve: improve memory size documentation

A couple of minor memory size option related nits:

 - use common name 'memsize' (instead of 'max-size' or just 'size')
 - bhyve: update usage with memsize unit suffix, drop legacy "MB"
   unit
 - bhyveload: update usage with memsize unit suffix
 - bhyve(8): document default size
 - bhyveload(8): use memsize formatting like it's done
   in bhyve(8)

Reviewed by:wblock, grehan
Approved by:re (kib), wblock, grehan
Differential Revision:  https://reviews.freebsd.org/D6952

302210 by kib:
Clean other flags in ncl_inactive, only.  Add comment explaining why other
flags should be unset.

Suggested and reviewed by:  rmacklem
Sponsored by:   The FreeBSD Foundation
MFC after:  12 days
Approved by:re (gjb)

302207 by tuexen:
This patch fixes a locking bug when a send() call blocks
on an SCTP socket and the association is aborted by the
peer.

Approved by:re (kib)
MFC after:  1 week

302206 by asomers:
Skip lastcomm and sa tests on unsupported architectures

usr.bin/lastcom/tests/Makefile
usr.sbin/sa/tests/Makefile
Set allow_architectures appropriately.  These tests depend on golden
files that must be generated for each architecture, and haven't yet
been generated for all of them.

PR: 210566
PR: 204154
Reviewed by:ngie
Approved by:re (gjb)
MFC after:  4 weeks
Sponsored by:   Spectra Logic Corp
Differential Revision:  https://reviews.freebsd.org/D6960

302204 by bz:
Unbreak building of LINT kernels after r302163.

Approved by:re (gjb)

302202 by adrian:
[net80211] re-revert the ibss "is this local to

Re: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

2016-06-27 Thread Otacílio 

Em 27/06/2016 14:06, Marcus von Appen escreveu:

Hi,

thanks to previous efforts, the rtwn(0) connection for my RTL8188CE
wireless card is far more stable. It seems to come at the price of
relatively bad performance, though. After r302035 from avos@, I
can't get more than 500 kbit/s downstream from anywhere.

Let me know, what information is necessary to isolate and correct
that issue. I'll gladly test it. :-)

Cheers
Marcus


I have helped doing some tests with the urtwn. You can try creating the 
interface with -ht parameter. Here this improves performance.


[]'s

-Otacílio

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

Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

2016-06-27 Thread Marcus von Appen 
Hi,

thanks to previous efforts, the rtwn(0) connection for my RTL8188CE
wireless card is far more stable. It seems to come at the price of
relatively bad performance, though. After r302035 from avos@, I
can't get more than 500 kbit/s downstream from anywhere.

Let me know, what information is necessary to isolate and correct
that issue. I'll gladly test it. :-)

Cheers
Marcus


signature.asc
Description: PGP signature

Build failed in Jenkins: FreeBSD_HEAD_sparc64 #100

2016-06-27 Thread jenkins-admin 
See 

--
[...truncated 106378 lines...]
cc  -pg  -O2 -pipe   
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl
 -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H 
-DB_ENDIAN 
-I/builds/workspace/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes
 -MD  -MF.depend.dh_pmeth.po -MTdh_pmeth.po -std=gnu89 -fstack-protector-strong 
-Wno-pointer-sign -c 
/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dh/dh_pmeth.c
 -o dh_pmeth.po
--- all_subdir_sbin ---
--- interactive.o ---
cc  -O2 -pipe -DRRESTORE -D_ACL_PRIVATE   -g -MD  -MF.depend.interactive.o 
-MTinteractive.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c 
/builds/workspace/FreeBSD_HEAD_sparc64/src/sbin/restore/interactive.c -o 
interactive.o
--- all_subdir_secure ---
--- dh_prn.po ---
cc  -pg  -O2 -pipe   
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl
 -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H 
-DB_ENDIAN 
-I/builds/workspace/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes
 -MD  -MF.depend.dh_prn.po -MTdh_prn.po -std=gnu89 -fstack-protector-strong 
-Wno-pointer-sign -c 
/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dh/dh_prn.c
 -o dh_prn.po
--- all_subdir_lib ---
--- sha2.po ---
cc  -pg  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/lib/libldns/../../contrib/ldns   
-MD  -MF.depend.sha2.po -MTsha2.po -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized 
-Wno-pointer-sign -c 
/builds/workspace/FreeBSD_HEAD_sparc64/src/lib/libldns/../../contrib/ldns/sha2.c
 -o sha2.po
--- all_subdir_secure ---
--- dh_rfc5114.po ---
cc  -pg  -O2 -pipe   
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl
 -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H 
-DB_ENDIAN 
-I/builds/workspace/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes
 -MD  -MF.depend.dh_rfc5114.po -MTdh_rfc5114.po -std=gnu89 
-fstack-protector-strong -Wno-pointer-sign -c 
/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dh/dh_rfc5114.c
 -o dh_rfc5114.po
--- dsa_ameth.po ---
cc  -pg  -O2 -pipe   
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl
 -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H 
-DB_ENDIAN 
-I/builds/workspace/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes
 -MD  -MF.depend.dsa_ameth.po -MTdsa_ameth.po -std=gnu89 
-fstack-protector-strong -Wno-pointer-sign -c 
/builds/workspace/FreeBSD_HEAD_sparc64/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dsa/dsa_ameth.c
 -o dsa_ameth.po
--- all_subdir_sbin ---
--- restore.o ---
cc  -O2 -pipe

Build failed in Jenkins: FreeBSD_HEAD #333

2016-06-27 Thread jenkins-admin 
See 

--
[...truncated 267146 lines...]
--- all_subdir_mlx ---
ctfconvert -L VERSION -g mlx_pci.o
--- all_subdir_mfi ---
ctfconvert -L VERSION -g mfi_syspd.o
--- all_subdir_mlx ---
--- mlx_disk.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/sys/GENERIC/opt_global.h
 -I. -I/builds/workspace/FreeBSD_HEAD/src/sys -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/sys/GENERIC
  -MD  -MF.depend.mlx_disk.o -MTmlx_disk.o -mcmodel=kernel -mno-red-zone 
-mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -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-s
 hift-negative-value  -mno-aes -mno-avx  -std=iso9899:1999 -c 
/builds/workspace/FreeBSD_HEAD/src/sys/modules/mlx/../../dev/mlx/mlx_disk.c -o 
mlx_disk.o
--- all_subdir_mfi ---
--- mfi_tbolt.o ---
--- all_subdir_mlx5 ---
--- pci_if.h ---
--- all_subdir_mfi ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/sys/GENERIC/opt_global.h
 -I. -I/builds/workspace/FreeBSD_HEAD/src/sys -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/sys/GENERIC
  -MD  -MF.depend.mfi_tbolt.o -MTmfi_tbolt.o -mcmodel=kernel -mno-red-zone 
-mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -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 
/builds/workspace/FreeBSD_HEAD/src/sys/modules/mfi/../../dev/mfi/mfi_tbolt.c -o 
mfi_tbolt.o
--- all_subdir_mlx5 ---
awk -f /builds/workspace/FreeBSD_HEAD/src/sys/tools/makeobjops.awk 
/builds/workspace/FreeBSD_HEAD/src/sys/dev/pci/pci_if.m -h
--- mlx5_cmd.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-I/builds/workspace/FreeBSD_HEAD/src/sys/modules/mlx5/../../ofed/include 
-I/builds/workspace/FreeBSD_HEAD/src/sys/modules/mlx5/../../compat/linuxkpi/common/include
 -DHAVE_KERNEL_OPTION_HEADERS -include 
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/sys/GENERIC/opt_global.h
 -I. -I/builds/workspace/FreeBSD_HEAD/src/sys -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/sys/GENERIC
  -MD  -MF.depend.mlx5_cmd.o -MTmlx5_cmd.o -mcmodel=kernel -mno-red-zone 
-mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unkno
 wn-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 -Wno-cast-qual -Wno-pointer-arith  -c 
/builds/workspace/FreeBSD_HEAD/src/sys/modules/mlx5/../../dev/mlx5/mlx5_core/mlx5_cmd.c
 -o mlx5_cmd.o
--- all_subdir_mlx ---
ctfconvert -L VERSION -g mlx_disk.o
--- mlx.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/sys/GENERIC/opt_global.h
 -I. -I/builds/workspace/FreeBSD_HEAD/src/sys -fno-common -g 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/sys/GENERIC
  -MD  -MF.depend.mlx.o -MTmlx.o -mcmodel=kernel -mno-red-zone -mno-mmx 
-mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs

Jenkins build is still unstable: FreeBSD_HEAD #335

2016-06-27 Thread jenkins-admin 
See 

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

Skylake PMC support?

2016-06-27 Thread Matthew Macy 

Does anyone have PMC patches for Skylake?

Thanks in advance.

-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: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

2016-06-27 Thread Adrian Chadd 
Heh, there isn't any 11n support in rtwn (and won't be until I unify
rtwn and urtwn post-11.)

I'll go find the rtwn NIC and see if I can figure out what's going on.



-a


On 27 June 2016 at 10:21, Otacílio  wrote:
> Em 27/06/2016 14:06, Marcus von Appen escreveu:
>>
>> Hi,
>>
>> thanks to previous efforts, the rtwn(0) connection for my RTL8188CE
>> wireless card is far more stable. It seems to come at the price of
>> relatively bad performance, though. After r302035 from avos@, I
>> can't get more than 500 kbit/s downstream from anywhere.
>>
>> Let me know, what information is necessary to isolate and correct
>> that issue. I'll gladly test it. :-)
>>
>> Cheers
>> Marcus
>
>
> I have helped doing some tests with the urtwn. You can try creating the
> interface with -ht parameter. Here this improves performance.
>
> []'s
>
> -Otacílio
>
> ___
> 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: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

2016-06-27 Thread Marcus von Appen 
On, Mon Jun 27, 2016, Adrian Chadd wrote:

> Heh, there isn't any 11n support in rtwn (and won't be until I unify
> rtwn and urtwn post-11.)

I do not know about that. My experience from pre-r302035 were 1-2 Mbit/s
downstream from some servers, but often enough just for a minute or two
before everything stopped working.

>
> I'll go find the rtwn NIC and see if I can figure out what's going on.

Let me know, if and how I can assist with it.

Cheers
Marcus


signature.asc
Description: PGP signature

Re: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

2016-06-27 Thread Otacílio 

Em 27/06/2016 15:34, Marcus von Appen escreveu:

On, Mon Jun 27, 2016, Adrian Chadd wrote:


Heh, there isn't any 11n support in rtwn (and won't be until I unify
rtwn and urtwn post-11.)

I do not know about that. My experience from pre-r302035 were 1-2 Mbit/s
downstream from some servers, but often enough just for a minute or two
before everything stopped working.


I'll go find the rtwn NIC and see if I can figure out what's going on.

Let me know, if and how I can assist with it.

Cheers
Marcus


About everything stopping I have faced a problem similar to this. Bellow 
is a log of a session where the problem occurs. I'm testing using netperf.


% netperf -H squitch
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch ()
port 0
AF_INET : histogram : interval : dirty data : demo
Recv   SendSend
Socket Socket  Message  Elapsed
Size   SizeSize Time Throughput
bytes  bytes   bytessecs.10^6bits/sec

  65536  32768  3276814.03   0.02
shutdown_control: no response received  errno 28
% ping squitch
PING squitch (192.168.0.13): 56 data bytes
^C
--- squitch ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
% urtwn0: device timeout
urtwn0: device timeout

___
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: Restarting rtwn(0)-based interface causes reproducible kernel panics

2016-06-27 Thread Marcus von Appen 
On, Mon Jun 27, 2016, Otacílio wrote:

[...]

> What is the revision that you are using? I have faced a similar problem
> on APLHA4, but now, on ALPHA5 it is working fine.

FreeBSD 11.0-ALPHA5 #3 r302191M: Sat Jun 25 14:21:12 CEST 2016

Note that rtwn and urtwn are using different firmware and a slightly
different driver implementations.

Cheers
Marcus

signature.asc
Description: PGP signature

Re: r 302222: broken USB?

2016-06-27 Thread O. Hartmann 
Am Mon, 27 Jun 2016 14:41:58 +0200
Hans Petter Selasky  schrieb:

> On 06/27/16 14:36, Tomoaki AOKI wrote:
> > On Mon, 27 Jun 2016 12:21:30 +0200
> > Hans Petter Selasky  wrote:
> >  
> >> On 06/27/16 11:28, O. Hartmann wrote:  
> >>> Running most recent CURRENT aka 11.0-ALPHA5 r30, after the box went to
> >>> multiuser there is no USB support in X11 anymore: no keyboard, no mouse.
> >>>
> >>> This is with nVidia GPU and driver BLOB 367.27.
> >>>
> >>> Version 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #12 r302170: Fri Jun 24 07:17:43 
> >>> CEST
> >>> 2016 amd64 is working well (this is my kernel.old for now).
> >>>
> >>> Does anyone also experience USB loss with graphical output?
> >>>
> >>> I regret having not checked against plain (non-X11), since with the most 
> >>> recent
> >>> nVidia drivers and vt(4), console is broken/unusable.
> >>>
> >>> Regards,
> >>>
> >>> Oliver  
> >>  
> 
> Hi,
> 
> Is it possible to get "dmesg" working and non-working?
> 
> Does the USB mouse/keyboard work before X11 is started?
> 
> --HPS
[...]

I see this problem only on one particular machine. All other systems with 
similar
setups/configs seem all right.

I'll test the keyboard in non-X11 mode with nvidia-modeset.ko NOT loaded.

Running the previous kernel (kernel.old)  works as expected.

I can provide more informations earliest tomorrow morning.

Regards,

Oliver


pgpPJCHoMN8ry.pgp
Description: OpenPGP digital signature

Jenkins build is unstable: FreeBSD_HEAD #334

2016-06-27 Thread jenkins-admin 
See 

___
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: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

2016-06-27 Thread Andriy Voskoboinyk 
Mon, 27 Jun 2016 20:06:20 +0300 було написано Marcus von Appen  
:


Hi,

the attached patch may fix this issue (probably)


Hi,

thanks to previous efforts, the rtwn(0) connection for my RTL8188CE
wireless card is far more stable. It seems to come at the price of
relatively bad performance, though. After r302035 from avos@, I
can't get more than 500 kbit/s downstream from anywhere.


I don't think that this is a regression - that was already noted in PR  
203105:



-Speed seems limited to 16Mbps rate (around 120 kbps on downstream),
even though the ifconfig summary show 802.11g/56mbps.




Let me know, what information is necessary to isolate and correct
that issue. I'll gladly test it. :-)


You can check number of input errors (netstat -I wlan0); it should be
relatively small (or even zero).



Cheers
Marcus

patch-rtwn-rxfilter-busdma.diff
Description: Binary data
___
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: Kqueue races causing crashes

2016-06-27 Thread Alan Somers 
I opened PR210641 to track this after I hit it on i386 during the
sys/kqueue/kqueue_test:main ATF test.  I hit the panic two times in 9
tries.
-Alan

On Wed, Jun 15, 2016 at 1:34 PM, Matthew Macy  wrote:
>
>
>
>   On Wed, 15 Jun 2016 10:45:24 -0700 Konstantin Belousov 
>  wrote 
>  > On Wed, Jun 15, 2016 at 10:39:42AM -0700, Matthew Macy wrote:
>  > >
>  > >
>  > >
>  > >
>  > > You can use dwarf4 if you use GDB from ports
>  > How would it help ?
>
> The following statement to a  native speaker would imply that GDB is the 
> problem: "There is not much gdb info here; I'll try to rebuild kgdb."
>
> If in fact %rip has been smashed that's a bit like saying "the light doesn't 
> show anything on the table, I'll replace the light bulb" - when in fact there 
> isn't anything on the table.
>
>  > Problem for kgdb is that %rip is zero, due to function pointer being set
>  > to NULL in a destroyed knlist.  Either version of kgdb would not find
>  > neither code nor unwind annotations for zero address.
>  >
>  > But the issue is understood and
>
> Yes. Since the initial e-mail.
>
>
>> we are working on the version of fix.
>
> I'm glad you're on it.
>
> -M
>
>
>
>  >
>  >   On Wed, 15 Jun 2016 04:50:00 -0700  Peter Holm wrote 
> On Wed, Jun 15, 2016 at 11:11:43AM +0300, Konstantin Belousov wrote: > On 
> Tue, Jun 14, 2016 at 10:26:14PM -0500, Eric Badger wrote: > > I believe they 
> all have more or less the same cause. The crashes occur  > > because we 
> acquire a knlist lock via the KN_LIST_LOCK macro, but when we  > > call 
> KN_LIST_UNLOCK, the knote???s knlist reference (kn->kn_knlist) has  > > been 
> cleared by another thread. Thus we are unable to unlock the  > > previously 
> acquired lock and hold it until something causes us to crash  > > (such as 
> the witness code noticing that we???re returning to userland with  > > the 
> lock still held). > ... > > I believe there???s also a small window where the 
> KN_LIST_LOCK macro  > > checks kn->kn_knlist and finds it to be non-NULL, but 
> by the time it  > > actually dereferences it, it has become NULL. This would 
> produce the  > > ???page fault while in kernel mode??? crash. > >  > > If 
> someone fa
 mi
>  liar with this code sees an obvious fix, I???ll be happy to  > > test it. 
> Otherwise, I???d appreciate any advice on fixing this. My first  > > thought 
> is that a ???struct knote??? ought to have its own mutex for  > > controlling 
> access to the flag fields and ideally the ???kn_knlist??? field.  > > I.e., 
> you would first acquire a knote???s lock and then the knlist lock,  > > thus 
> ensuring that no one could clear the kn_knlist variable while you  > > hold 
> the knlist lock. The knlist lock, however, usually comes from  > > whichever 
> event producing entity the knote tracks, so getting lock  > > ordering right 
> between the per-knote mutex and this other lock seems  > > potentially hard. 
> (Sometimes we call into functions in kern_event.c with  > > the knlist lock 
> already held, having been acquired in code outside of  > > kern_event.c. 
> Consider, for example, calling KNOTE_LOCKED from  > > kern_exit.c; the 
> PROC_LOCK macro has already been used to acquire the  > > process lock, also 
> serving
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  >
>
> ___
> 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"

FreeBSD_HEAD_i386 - Build #3461 - Fixed

2016-06-27 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3461 - Fixed:

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

Change summaries:

30 by delphij:
Fix build: explicitly reference the generated magic.h as dependency
of mkmagic and point its location.

Reported by:jenkins
Pointy hat to:  delphij
MFC after:  2 weeks
X-MFC-With: 302221
Approved by:re (kib)

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

pkg SAT_SOLVER bugs

2016-06-27 Thread Hans Petter Selasky 

Hi,

I found some bugs in PKG with regard to the SAT_SOLVER environment 
variable. Please find patch attached :-)


Issues fixed:
1) No need to use hash table when generating SAT rules for external 
solver. Variables are already in a linear array. Fix encoding and 
decoding of SAT data.

2) Endless variable loop caused pkg to crash.
3) it->inverse was checked for non-zero, while it should actually be 
checked for -1 only. SAT rules produces were all negative.


How to verify:

make -C /usr/ports/math/picosat all install clean

env SAT_SOLVER=picosat pkg upgrade

--HPS
--- ./work/pkg-1.8.99.6/libpkg/pkg_solve.c.orig	2016-06-27 10:32:46.11981 +0200
+++ ./work/pkg-1.8.99.6/libpkg/pkg_solve.c	2016-06-27 12:28:07.901757000 +0200
@@ -118,8 +118,6 @@
 #define PKG_SOLVE_CHECK_ITEM(item)\
 	((item)->var->to_install ^ (item)->inverse)
 
-#define PKG_SOLVE_VAR_NEXT(a, e) ((e) == NULL ? [0] : (e + 1))
-
 /*
  * Utilities to convert jobs to SAT rule
  */
@@ -1302,45 +1300,23 @@
 	fprintf(file, "}\n");
 }
 
-struct pkg_solve_ordered_variable {
-	struct pkg_solve_variable *var;
-	int order;
-	UT_hash_handle hh;
-};
-
 int
 pkg_solve_dimacs_export(struct pkg_solve_problem *problem, FILE *f)
 {
-	struct pkg_solve_ordered_variable *ordered_variables = NULL, *nord;
-	struct pkg_solve_variable *var;
 	struct pkg_solve_rule *rule;
 	struct pkg_solve_item *it;
-	int cur_ord = 1;
-
-	/* Order variables */
-	var = NULL;
-	while ((var = PKG_SOLVE_VAR_NEXT(problem->variables, var))) {
-		nord = calloc(1, sizeof(struct pkg_solve_ordered_variable));
-		nord->order = cur_ord ++;
-		nord->var = var;
-		HASH_ADD_PTR(ordered_variables, var, nord);
-	}
 
 	fprintf(f, "p cnf %d %zu\n", (int)problem->nvars, kv_size(problem->rules));
 
 	for (unsigned int i = 0; i < kv_size(problem->rules); i++) {
 		rule = kv_A(problem->rules, i);
 		LL_FOREACH(rule->items, it) {
-			HASH_FIND_PTR(ordered_variables, >var, nord);
-			if (nord != NULL) {
-fprintf(f, "%s%d ", (it->inverse ? "-" : ""), nord->order);
-			}
+			size_t order = it->var - problem->variables;
+			if (order < problem->nvars)
+fprintf(f, "%ld ", (long)((order + 1) * it->inverse));
 		}
 		fprintf(f, "0\n");
 	}
-
-	HASH_FREE(ordered_variables, free);
-
 	return (EPKG_OK);
 }
 
@@ -1443,26 +1419,42 @@
 	return (EPKG_OK);
 }
 
+static bool
+pkg_solve_parse_sat_output_store(struct pkg_solve_problem *problem, const char *var_str)
+{
+	struct pkg_solve_variable *var;
+	ssize_t order;
+
+	order = strtol(var_str, NULL, 10);
+	if (order == 0)
+		return (true);
+	if (order < 0) {
+		/* negative value means false */
+		order = - order - 1;
+		if ((size_t)order < problem->nvars) {
+			var = problem->variables + order;
+			var->flags &= ~PKG_VAR_INSTALL;
+		}
+	} else {
+		/* positive value means true */
+		order = order - 1;
+		if ((size_t)order < problem->nvars) {
+			var = problem->variables + order;
+			var->flags |= PKG_VAR_INSTALL;
+		}
+	}
+	return (false);
+}
+
 int
 pkg_solve_parse_sat_output(FILE *f, struct pkg_solve_problem *problem)
 {
-	struct pkg_solve_ordered_variable *ordered_variables = NULL, *nord;
-	struct pkg_solve_variable *var;
-	int cur_ord = 1, ret = EPKG_OK;
+	int ret = EPKG_OK;
 	char *line = NULL, *var_str, *begin;
 	size_t linecap = 0;
 	ssize_t linelen;
 	bool got_sat = false, done = false;
 
-	/* Order variables */
-	var = NULL;
-	while ((var = PKG_SOLVE_VAR_NEXT(problem->variables, var))) {
-		nord = calloc(1, sizeof(struct pkg_solve_ordered_variable));
-		nord->order = cur_ord ++;
-		nord->var = var;
-		HASH_ADD_INT(ordered_variables, order, nord);
-	}
-
 	while ((linelen = getline(, , f)) > 0) {
 		if (strncmp(line, "SAT", 3) == 0) {
 			got_sat = true;
@@ -1474,22 +1466,8 @@
 /* Skip unexpected lines */
 if (var_str == NULL || (!isdigit(*var_str) && *var_str != '-'))
 	continue;
-cur_ord = 0;
-cur_ord = abs((int)strtol(var_str, NULL, 10));
-if (cur_ord == 0) {
+if (pkg_solve_parse_sat_output_store(problem, var_str))
 	done = true;
-	break;
-}
-
-HASH_FIND_INT(ordered_variables, _ord, nord);
-if (nord != NULL) {
-	if (*var_str == '-') {
-		nord->var->flags &= ~PKG_VAR_INSTALL;
-	}
-	else {
-		nord->var->flags |= PKG_VAR_INSTALL;
-	}
-}
 			} while (begin != NULL);
 		}
 		else if (strncmp(line, "v ", 2) == 0) {
@@ -1499,23 +1477,8 @@
 /* Skip unexpected lines */
 if (var_str == NULL || (!isdigit(*var_str) && *var_str != '-'))
 	continue;
-cur_ord = 0;
-cur_ord = abs((int)strtol(var_str, NULL, 10));
-if (cur_ord == 0) {
+if (pkg_solve_parse_sat_output_store(problem, var_str))
 	done = true;
-	break;
-}
-
-HASH_FIND_INT(ordered_variables, _ord, nord);
-
-if (nord != NULL) {
-	if (*var_str == '-') {
-		nord->var->flags &= ~PKG_VAR_INSTALL;
-	}
-	else {
-		nord->var->flags |= PKG_VAR_INSTALL;
-	}
-}
 			} while (begin != NULL);
 		}
 		else {
@@ -1531,7 +1494,6 @@
 		ret = EPKG_FATAL;
 	}
 
-

Re: HEADS UP: caution required with updates using custom kernels

2016-06-27 Thread Erich Dollansky 
Hi,

On Thu, 23 Jun 2016 21:07:51 +
Brooks Davis  wrote:

> Kernel config minimalists and those running aarch64 and riscv systems
> will want to head this UPDATING message.
> 
> In practice, if you're fairly up to date, doing installworld before
> installkernel will also work (I've tested that case from ALPHA4), but
> is always somewhat risky.
> 
there is another scenario in which you will use a word starting with an
f followed by three letters. I did a normal update, compiled a custom
kernel but did not re-compile my own application. As the application is
required for the start of the machine, I was left with a system which
could not be used. So, downgrading it, recompile the kernel with the
compatibility option, compile the program and then it should work again
is the way.

Erich

> -- Brooks
> 
> - Forwarded message from Brooks Davis  -
> 
> Date: Thu, 23 Jun 2016 21:02:05 + (UTC)
> From: Brooks Davis 
> To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
>   svn-src-h...@freebsd.org
> Subject: svn commit: r302152 - head
> 
> Author: brooks
> Date: Thu Jun 23 21:02:05 2016
> New Revision: 302152
> URL: https://svnweb.freebsd.org/changeset/base/302152
> 
> Log:
>   Add an UPDATING entry for the pipe() -> pipe2() transition.
>   
>   Approved by:re (gjb)
>   Sponsored by:   DARPA, AFRL
> 
> Modified:
>   head/UPDATING
> 
> Modified: head/UPDATING
> ==
> --- head/UPDATING Thu Jun 23 20:59:13 2016(r302151)
> +++ head/UPDATING Thu Jun 23 21:02:05 2016(r302152)
> @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11
>   disable the most expensive debugging functionality run
>   "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
>  
> +20160622:
> + The the libc stub for the pipe(2) system call has been
> replaced with
> + a wrapper which calls the pipe2(2) system call and the
> pipe(2) is now
> + only implemented by the kernels which include "options
> + FREEBSD10_COMPAT" in their config file (this is the default).

Shouldn't it read 'COMPAT_FREEBSD10'?

Erich
___
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: r 302222: broken USB?

2016-06-27 Thread Tomoaki AOKI 
On Mon, 27 Jun 2016 12:21:30 +0200
Hans Petter Selasky  wrote:

> On 06/27/16 11:28, O. Hartmann wrote:
> > Running most recent CURRENT aka 11.0-ALPHA5 r30, after the box went to
> > multiuser there is no USB support in X11 anymore: no keyboard, no mouse.
> >
> > This is with nVidia GPU and driver BLOB 367.27.
> >
> > Version 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #12 r302170: Fri Jun 24 07:17:43 
> > CEST
> > 2016 amd64 is working well (this is my kernel.old for now).
> >
> > Does anyone also experience USB loss with graphical output?
> >
> > I regret having not checked against plain (non-X11), since with the most 
> > recent
> > nVidia drivers and vt(4), console is broken/unusable.
> >
> > Regards,
> >
> > Oliver
> 
> Hi,
> 
> Might this be due to the pthread's issue with console-kit?

Hi.

Might not.
The problematic commit (r302194) is already reverted at r302201, so
r30 would be OK for it.

Moreover, if it's the console-kit issue, X server would die immediately
due to the lack of session. Not only keyboards and mice.

FYI, atkbd and psm are OK at r302204 with nvidia BLOB 364.19 for me,
amd64. But with 367.27 installed, xorg-server didn't build, so I
switched back to 364.19. (Sorry, no build logs are kept.)

Note that 367.27 runs fine with already-built (with 364.19) xorg-server.

Regards.

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


-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
___
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: r 302222: broken USB?

2016-06-27 Thread Hans Petter Selasky 

On 06/27/16 14:36, Tomoaki AOKI wrote:

On Mon, 27 Jun 2016 12:21:30 +0200
Hans Petter Selasky  wrote:


On 06/27/16 11:28, O. Hartmann wrote:

Running most recent CURRENT aka 11.0-ALPHA5 r30, after the box went to
multiuser there is no USB support in X11 anymore: no keyboard, no mouse.

This is with nVidia GPU and driver BLOB 367.27.

Version 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #12 r302170: Fri Jun 24 07:17:43 CEST
2016 amd64 is working well (this is my kernel.old for now).

Does anyone also experience USB loss with graphical output?

I regret having not checked against plain (non-X11), since with the most recent
nVidia drivers and vt(4), console is broken/unusable.

Regards,

Oliver




Hi,

Is it possible to get "dmesg" working and non-working?

Does the USB mouse/keyboard work before X11 is started?

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

Re: pkg SAT_SOLVER bugs

2016-06-27 Thread Kubilay Kocak 
On 27/06/2016 8:38 PM, Hans Petter Selasky wrote:
> Hi,
> 
> I found some bugs in PKG with regard to the SAT_SOLVER environment
> variable. Please find patch attached :-)

Nice! Can you report upstream @ https://github.com/freebsd/pkg if you
haven't already

> Issues fixed:
> 1) No need to use hash table when generating SAT rules for external
> solver. Variables are already in a linear array. Fix encoding and
> decoding of SAT data.
> 2) Endless variable loop caused pkg to crash.
> 3) it->inverse was checked for non-zero, while it should actually be
> checked for -1 only. SAT rules produces were all negative.
> 
> How to verify:
> 
> make -C /usr/ports/math/picosat all install clean
> 
> env SAT_SOLVER=picosat pkg upgrade
> 
> --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"

r 302222: broken USB?

2016-06-27 Thread O. Hartmann 
Running most recent CURRENT aka 11.0-ALPHA5 r30, after the box went to
multiuser there is no USB support in X11 anymore: no keyboard, no mouse.

This is with nVidia GPU and driver BLOB 367.27.

Version 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #12 r302170: Fri Jun 24 07:17:43 CEST
2016 amd64 is working well (this is my kernel.old for now).

Does anyone also experience USB loss with graphical output?

I regret having not checked against plain (non-X11), since with the most recent
nVidia drivers and vt(4), console is broken/unusable.

Regards,

Oliver
___
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: pkg SAT_SOLVER bugs

2016-06-27 Thread Baptiste Daroussin 
On Mon, Jun 27, 2016 at 12:38:02PM +0200, Hans Petter Selasky wrote:
> Hi,
> 
> I found some bugs in PKG with regard to the SAT_SOLVER environment variable.
> Please find patch attached :-)
> 
> Issues fixed:
> 1) No need to use hash table when generating SAT rules for external solver.
> Variables are already in a linear array. Fix encoding and decoding of SAT
> data.
> 2) Endless variable loop caused pkg to crash.
> 3) it->inverse was checked for non-zero, while it should actually be checked
> for -1 only. SAT rules produces were all negative.
> 
> How to verify:
> 
> make -C /usr/ports/math/picosat all install clean
> 
> env SAT_SOLVER=picosat pkg upgrade
> 
> --HPS

Thank you I will look into shortly

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: r 302222: broken USB?

2016-06-27 Thread Hans Petter Selasky 

On 06/27/16 11:28, O. Hartmann wrote:

Running most recent CURRENT aka 11.0-ALPHA5 r30, after the box went to
multiuser there is no USB support in X11 anymore: no keyboard, no mouse.

This is with nVidia GPU and driver BLOB 367.27.

Version 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #12 r302170: Fri Jun 24 07:17:43 CEST
2016 amd64 is working well (this is my kernel.old for now).

Does anyone also experience USB loss with graphical output?

I regret having not checked against plain (non-X11), since with the most recent
nVidia drivers and vt(4), console is broken/unusable.

Regards,

Oliver


Hi,

Might this be due to the pthread's issue with console-kit?

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