patch for smartmontools on latest head

[Andriy Gapon]

http://dpaste.com/1B04AVB

I believe that this patch should do the right thing on all version of FreeBSD,
so it could be better to integrate it upstream, if possible.

Without the patch the port fails with errors like:
./freebsd_nvme_ioctl.h:34:8: error: redefinition of 'nvme_command'

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

11.0 -r301900 and cross builds: the transition from not using WITH_META_MODE=yes to using it still seems to require cleanworld between

[Mark Millard]

[The following is after having updated and booted the host amd64 environment to 
-r301900. The activity reported on is cross building targeting a rpi2 
(armv7-a/cortex-a7). It is trying to go from not haivng used WITH_META_MODE=yes 
last time I cross built to now using WITH_META_MODE=yes this time.]

Again when the prior buildworld buildkernel installkernel installworld 
mergemaster sequence was by omitting WITH_META_MODE=yes and then a rebuild 
buildworld buildkernel was attempted using WITH_META_MODE=yes I got the "sh: 
./make_keys: Exec format error" notice:


> --- lib/ncurses/ncursesw__L ---
> --- init_keytry.h ---
> sh: ./make_keys: Exec format error
> *** [init_keytry.h] Error code 126
> 
> make[4]: stopped in /usr/src/lib/ncurses/ncursesw
> .ERROR_TARGET='init_keytry.h'
> .ERROR_META_FILE='/usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/init_keytry.h.meta'
> .MAKE.LEVEL='4'
> MAKEFILE=''
> .MAKE.MODE='meta verbose missing-meta=yes silent=yes missing-filemon=yes meta 
> verbose missing-meta=yes silent=yes missing-filemon=yes meta verbose 
> missing-meta=yes silent=yes missing-filemon=yes meta verbose missing-meta=yes 
> silent=yes missing-filemon=yes meta verbose missing-meta=yes silent=yes 
> missing-filemon=yes'
> .CURDIR='/usr/src/lib/ncurses/ncursesw'
> .MAKE='make'
> .OBJDIR='/usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw'
> .TARGETS='all'
> DESTDIR='/usr/obj/clang/arm.armv6/usr/src/tmp'
> LD_LIBRARY_PATH=''
> MACHINE='arm'
> MACHINE_ARCH='armv6'
> MAKEOBJDIRPREFIX='/usr/obj/clang/arm.armv6'
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20160606'
> PATH='/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/clang/arm.armv6/usr/src/tmp/usr/sbin:/usr/obj/clang/arm.armv6/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP='/usr/src'
> OBJTOP='/usr/obj/clang/arm.armv6/usr/src'
> .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
> /usr/src/share/mk/src.sys.env.mk 
> /root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host 
> /usr/src/share/mk/bsd.mkopt.mk /root/src.configs/make.conf 
> /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf 
> /usr/src/lib/ncurses/ncursesw/Makefile 
> /usr/src/lib/ncurses/ncursesw/../ncurses/Makefile 
> /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk 
> /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk 
> /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk 
> /usr/src/lib/ncurses/ncursesw/../config.mk /usr/src/share/mk/bsd.lib.mk 
> /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk 
> /usr/src/share/mk/src.init.mk /usr/src/lib/ncurses/ncursesw/../Makefile.inc 
> /usr/src/lib/ncurses/ncursesw/../../Makefile.inc 
> /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
> /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
> /usr/src/share/mk/bsd.files.mk 
 /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.confs.mk 
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk 
/usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk 
/usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk'
> .PATH='. /usr/src/lib/ncurses/ncursesw 
> /usr/src/lib/ncurses/ncursesw/../ncurses 
> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include 
> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/base 
> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo 
> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tty 
> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/widechar 
> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/trace 
> /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/man'
> 1 error

So I'm trying cleanworld using WITH_META_MODE=yes before trying buildworld 
buidlkernel using WITH_META_MODE=yes . . .

I'll report later how this goes.


===
Mark Millard
markmi at dsl-only.net

___
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

[Eric Badger]

Oops, I don't think my attachment worked. This should do the trick: 
https://drive.google.com/open?id=0B8Lj3D-GnaCcS0taVVNlQktQRkk


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

Kqueue races causing crashes

[Eric Badger]

Hi there,

There seems to be some racy code in kern_event.c which is causing me to 
run into some crashes. I’ve attached the test program used to generate 
these crashes (build it and run the “go” script). They were produced in 
a VM with 4 cores on 11 Alpha 3 (and originally 10.3). The crashes I’ve 
seen come in a few varieties:


1. “userret: returning with the following locks held”. This one is the 
easiest to hit (assuming witness is enabled).


userret: returning with the following locks held:
exclusive sleep mutex process lock (process lock) r = 0 
(0xf80006956120) locked @ /usr/src/sys/kern/kern_event.c:2125

panic: witness_warn
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe39d8e0

vpanic() at vpanic+0x182/frame 0xfe39d960
kassert_panic() at kassert_panic+0x126/frame 0xfe39d9d0
witness_warn() at witness_warn+0x3c6/frame 0xfe39daa0
userret() at userret+0x9d/frame 0xfe39dae0
amd64_syscall() at amd64_syscall+0x406/frame 0xfe39dbf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe39dbf0
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x800b8a0ba, rsp = 
0x7fffea98, rbp = 0x7fffeae0 ---

KDB: enter: panic
[ thread pid 64855 tid 100106 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db> show all locks
Process 64855 (watch) thread 0xf800066c3000 (100106)
exclusive sleep mutex process lock (process lock) r = 0 
(0xf80006956120) locked @ /usr/src/sys/kern/kern_event.c:2125

Process 64855 (watch) thread 0xf8000696a500 (100244)
exclusive sleep mutex pmap (pmap) r = 0 (0xf800068c3138) locked @ 
/usr/src/sys/amd64/amd64/pmap.c:4067
exclusive sx vm map (user) (vm map (user)) r = 0 (0xf800068f6080) 
locked @ /usr/src/sys/vm/vm_map.c:3315
exclusive sx vm map (user) (vm map (user)) r = 0 (0xf800068c3080) 
locked @ /usr/src/sys/vm/vm_map.c:3311

db> ps
  pid  ppid  pgrp   uid   state   wmesg wchancmd
64855   690   690 0  R+  (threaded)  watch
100106   Run CPU 2   main
100244   Run CPU 1 procmaker
100245   Run CPU 3 reaper

2.  “Sleeping thread owns a non-sleepable lock”. This one first drew my 
attention by showing up in a real world application at work.


Sleeping thread (tid 100101, pid 76857) owns a non-sleepable lock
KDB: stack backtrace of thread 100101:
sched_switch() at sched_switch+0x2a5/frame 0xfe257690
mi_switch() at mi_switch+0xe1/frame 0xfe2576d0
sleepq_catch_signals() at sleepq_catch_signals+0x16c/frame 
0xfe257730

sleepq_timedwait_sig() at sleepq_timedwait_sig+0xf/frame 0xfe257760
_sleep() at _sleep+0x234/frame 0xfe2577e0
kern_kevent_fp() at kern_kevent_fp+0x38a/frame 0xfe2579d0
kern_kevent() at kern_kevent+0x9f/frame 0xfe257a30
sys_kevent() at sys_kevent+0x12a/frame 0xfe257ae0
amd64_syscall() at amd64_syscall+0x2d4/frame 0xfe257bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe257bf0
--- syscall (363, FreeBSD ELF64, sys_kevent), rip = 0x800b6afea, rsp = 
0x7fffea88, rbp = 0x7fffead0 ---

panic: sleeping thread
cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe225590

kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe225640
vpanic() at vpanic+0x126/frame 0xfe225680
panic() at panic+0x43/frame 0xfe2256e0
propagate_priority() at propagate_priority+0x166/frame 0xfe225710
turnstile_wait() at turnstile_wait+0x282/frame 0xfe225750
__mtx_lock_sleep() at __mtx_lock_sleep+0x26b/frame 0xfe2257d0
__mtx_lock_flags() at __mtx_lock_flags+0x5e/frame 0xfe2257f0
proc_to_reap() at proc_to_reap+0x46/frame 0xfe225840
kern_wait6() at kern_wait6+0x202/frame 0xfe2258f0
sys_wait4() at sys_wait4+0x72/frame 0xfe225ae0
amd64_syscall() at amd64_syscall+0x2d4/frame 0xfe225bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe225bf0
--- syscall (7, FreeBSD ELF64, sys_wait4), rip = 0x800b209ba, rsp = 
0x7fffdfdfcf48, rbp = 0x7fffdfdfcf80 ---

KDB: enter: panic
[ thread pid 76857 tid 100225 ]
Stopped at  kdb_enter+0x3e: movq$0,kdb_why
db> show allchains
chain 1:
 thread 100225 (pid 76857, reaper) blocked on lock 0xf800413105f0 
(sleep mutex) "process lock"

 thread 100101 (pid 76857, main) inhibited

(3./4.) There are a few others that I hit less frequently (“page fault 
while in kernel mode”,  "Kernel page fault with the following 
non-sleepable locks held”. I don’t have a backtrace handy for these.


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 

Re: mergemaster internally using make [for example] vs. WITH_META_MODE?

[Mark Millard]

On 2016-Jun-14, at 6:48 PM, Bryan Drewery  wrote:

> On 6/14/2016 5:13 PM, Mark Millard wrote:
>>> The targets (at top-level) that META_MODE is applied to is a whitelist
>>> now after r301887.  So it's safe to always pass it when building from
>>> the top-level.  If it's an unsupported target it will internally disable
>>> META_MODE.
>> So WITH_META_MODE=yes is now always allowed. That still leaves the questions 
>> of when WITH_META_MODE=yes is necessary: For example, is it ever required 
>> for the likes of mergemaster? (I'll use mergemaster to illustrate a more 
>> general question that applies to other potential scripts as well.)
> 
> There is no point to provide it to mergemaster or for it to use it
> internally.  The recommended way to use this feature is to add it to
> /etc/src-env.conf and forget about it or specify it for
> buildworld/buildkernel/universe (build) targets.  There is also no harm
> in always defining it.  That is the goal at least.
> 
> -- 
> Regards,
> Bryan Drewery

Okay. Thanks for the information.

I asked in part because mergemaster [as an example] has code like:

> # grep -i make /usr/sbin/mergemaster | more
. . .
> MM_MAKE="make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk"
. . .
>  ${MM_MAKE} _obj SUBDIR_OVERRIDE=etc >/dev/null &&
. . .
>  ${MM_MAKE} everything SUBDIR_OVERRIDE=etc >/dev/null &&
. . .

and "_obj" and "everything" overlap with the latest whitelist edit:

>  META_TGT_WHITELIST+= \
>   _* build32 buildfiles buildincludes buildkernel buildsoft \
>   buildworld everything kernel-toolchains kernels libraries \
> - native-xtools tinderbox toolchain toolchains universe worlds \
> - xdev xdev-build
> + native-xtools showconfig tinderbox toolchain toolchains universe \
> + worlds xdev xdev-build

but in mergemaster are just specifically for SUBDIR_OVERRIDE=etc .

===
Mark Millard
markmi at dsl-only.net

___
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: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Bryan Drewery]

On 6/13/2016 7:26 PM, Mark Millard wrote:
> [The following is after the svnltie update -r301873 /usr/src .]
> 
> For the following in a amd64 rebuild on amd64 (a WITH_META_MODE=yes 
> buidlworld buidlkernel just after a without meta mode buildworld buildkernel 
> [no install]). . .
> 
>> # more sys/modules/drm2/radeonkmsfw/Makefile.inc 
>> # $FreeBSD: head/sys/modules/drm2/radeonkmsfw/Makefile.inc 254885 2013-08-25 
>> 19:37:15Z dumbbell $
>> #
>> # Common rules for building firmware.  Note this gets auto-included
>> # by the subdir Makefile's as a consequence of included bsd.kmod.mk.
>>
>> _FIRM=  ${IMG}.bin
>>
>> CLEANFILES+=${_FIRM}
>>
>> FIRMWS= ${_FIRM}:${KMOD}
>>
>> #
>> # Note that a license ack is not needed for iwn.
>> #
>> #FIRMWARE_LICENSE=
>>
>> ${_FIRM}: ${.CURDIR}/../../../../contrib/dev/drm2/radeonkmsfw/${_FIRM}.uu
>> uudecode -p $? > ${.TARGET}
> 
> 
> I just had . . .
> (Note the uudecode line in the .meta file, the reference to stdin, and the 
> resultant "begin" line error.)
> 
>> # more 
>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta
>>  
>> # Meta data file 
>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta
>> CMD uudecode -p  > ARUBA_me.bin
>> CWD 
>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me
>> TARGET ARUBA_me.bin
>> -- command output --
>> uudecode: stdin: missing or bad "begin" line
>> *** Error code 1
>>

This should be fixed after r301900.  Note that it is only fixed once you
get the new bmake installed from that revision.

>> -- filemon acquired metadata --
>> # filemon version 5
>> # Target pid 7146
>> # Start 1465867565.855820
>> V 5
>> E 7163 /bin/sh
>> R 7163 /etc/libmap.conf
>> R 7163 /var/run/ld-elf.so.hints
>> R 7163 /lib/libedit.so.7
>> R 7163 /lib/libc.so.7
>> R 7163 /lib/libncursesw.so.8
>> F 7163 7164
>> W 7164 ARUBA_me.bin
>> E 7164 /usr/bin/uudecode
>> R 7164 /etc/libmap.conf
>> R 7164 /var/run/ld-elf.so.hints
>> R 7164 /lib/libc.so.7
>> X 7164 1 0
>> X 7163 1 0
>> # Stop 1465867565.868045
>> # Bye bye
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: mergemaster internally using make [for example] vs. WITH_META_MODE?

[Bryan Drewery]

On 6/14/2016 5:13 PM, Mark Millard wrote:
>> The targets (at top-level) that META_MODE is applied to is a whitelist
>> now after r301887.  So it's safe to always pass it when building from
>> the top-level.  If it's an unsupported target it will internally disable
>> META_MODE.
> So WITH_META_MODE=yes is now always allowed. That still leaves the questions 
> of when WITH_META_MODE=yes is necessary: For example, is it ever required for 
> the likes of mergemaster? (I'll use mergemaster to illustrate a more general 
> question that applies to other potential scripts as well.)

There is no point to provide it to mergemaster or for it to use it
internally.  The recommended way to use this feature is to add it to
/etc/src-env.conf and forget about it or specify it for
buildworld/buildkernel/universe (build) targets.  There is also no harm
in always defining it.  That is the goal at least.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[David Wolfskill]

On Tue, Jun 14, 2016 at 05:17:19PM -0700, Chris H wrote:
> ...
> Honestly, I think the best way to motivate people to do the right thing(tm)
> Would be to remove Yellow Pages from the tree, entirely. :-)
> It's been dead for *years*, and as you say, isn't safe, anyway..
> 

"Safe" for what, precisely?

It's a lookup service.  It is not limited to looking up authentication
information, and never has been.

And it's a mechanism that has been widely implemented.

The catchphrase "Tools, not policy" comes to mind.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Marcelo Araujo]

2016-06-15 8:17 GMT+08:00 Chris H :

> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo 
> wrote
>
> > Hey,
> >
> > Thanks for the CFT Craig.
> >
> > 2016-06-09 14:41 GMT+08:00 Xin Li :
> >
> > >
> > >
> > > On 6/8/16 23:10, Craig Rodrigues wrote:
> > > > Hi,
> > > >
> > > > I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
> > > > current.
> > > >
> > > > In latest current, it should be possible to put in /etc/rc.conf:
> > > >
> > > > nis_ypldap_enable="YES"
> > > > to activate the ypldap daemon.
> > > >
> > > > When set up properly, it should be possible to log into FreeBSD, and
> have
> > > > the backend password database come from an LDAP database such
> > > > as OpenLDAP
> > > >
> > > > There is some documentation for setting this up, but it is OpenBSD
> > > specific:
> > > >
> > > > http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
> > > > http://puffysecurity.com/wiki/ypldap.html#2
> > > >
> > > > I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
> > > > information
> > > > does not apply.  I figure that openldap from ports should work fine.
> > > >
> > > > I was wondering if there is someone out there familiar enough with
> LDAP
> > > > and has a setup they can test this stuff out with, provide feedback,
> and
> > > > help
> > > > improve the documentation for FreeBSD?
> > >
> > > Looks like it would be a fun weekend project.  I've cc'ed a potential
> > > person who may be interested in this as well.
> > >
> > > But will this worth the effort? (I think the current implementation
> > > would do everything with plaintext protocol over wire, so while it
> > > extends life for legacy applications that are still using NIS/YP, it
> > > doesn't seem to be something that we should recommend end user to use?)
> > >
> >
> > I can see two good point to use ypldap that would be basically for users
> > that needs to migrate from NIS to LDAP or need to make some integration
> > between legacy(NIS) and LDAP during a transition period to LDAP.
> >
> > As mentioned, NIS is 'plain text' not safe by its nature, however there
> are
> > still lots of people out there using NIS, and ypldap(8) is a good tool to
> > help these people migrate to a more safe tool like LDAP.
> >
> >
> > >
> > > > I would also be interested in hearing from someone who can see if
> > > > ypldap can work against a Microsoft Active Directory setup?
> > >
> > > Cheers,
> > >
> > >
> > All my tests were using OpenLDAP, I used the OpenBSD documentation to
> setup
> > everything, and the file share/examples/ypldap/ypldap.conf can be a good
> > start to anybody that wants to start to work with ypldap(8).
> >
> > Would be nice hear from other users how was their experience using ypldap
> > with MS Active Directory and perhaps some HOWTO how they made all the
> setup
> > would be amazing to have.
> >
> > Also, would be useful to know who are still using NIS and what kind of
> > setup(user case), maybe even the reason why they are still using it.
>
> Honestly, I think the best way to motivate people to do the right thing(tm)
> Would be to remove Yellow Pages from the tree, entirely. :-)
> It's been dead for *years*, and as you say, isn't safe, anyway..
>

Yes, I have a plan for that, but I don't believe it will happens before
FreeBSD 12-RELEASE.


>
> --Chris
> >
> >
> > Best,
> > --
> >
> > --
> > Marcelo Araujo(__)ara...@freebsd.org
> > \\\'',)http://www.FreeBSD.org    \/  \ ^
> > Power To Server. .\. /_)
> > ___
> > 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"
>



-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
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: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Chris H]

On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo 
wrote

> Hey,
> 
> Thanks for the CFT Craig.
> 
> 2016-06-09 14:41 GMT+08:00 Xin Li :
> 
> >
> >
> > On 6/8/16 23:10, Craig Rodrigues wrote:
> > > Hi,
> > >
> > > I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
> > > current.
> > >
> > > In latest current, it should be possible to put in /etc/rc.conf:
> > >
> > > nis_ypldap_enable="YES"
> > > to activate the ypldap daemon.
> > >
> > > When set up properly, it should be possible to log into FreeBSD, and have
> > > the backend password database come from an LDAP database such
> > > as OpenLDAP
> > >
> > > There is some documentation for setting this up, but it is OpenBSD
> > specific:
> > >
> > > http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
> > > http://puffysecurity.com/wiki/ypldap.html#2
> > >
> > > I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
> > > information
> > > does not apply.  I figure that openldap from ports should work fine.
> > >
> > > I was wondering if there is someone out there familiar enough with LDAP
> > > and has a setup they can test this stuff out with, provide feedback, and
> > > help
> > > improve the documentation for FreeBSD?
> >
> > Looks like it would be a fun weekend project.  I've cc'ed a potential
> > person who may be interested in this as well.
> >
> > But will this worth the effort? (I think the current implementation
> > would do everything with plaintext protocol over wire, so while it
> > extends life for legacy applications that are still using NIS/YP, it
> > doesn't seem to be something that we should recommend end user to use?)
> >
> 
> I can see two good point to use ypldap that would be basically for users
> that needs to migrate from NIS to LDAP or need to make some integration
> between legacy(NIS) and LDAP during a transition period to LDAP.
> 
> As mentioned, NIS is 'plain text' not safe by its nature, however there are
> still lots of people out there using NIS, and ypldap(8) is a good tool to
> help these people migrate to a more safe tool like LDAP.
> 
> 
> >
> > > I would also be interested in hearing from someone who can see if
> > > ypldap can work against a Microsoft Active Directory setup?
> >
> > Cheers,
> >
> >
> All my tests were using OpenLDAP, I used the OpenBSD documentation to setup
> everything, and the file share/examples/ypldap/ypldap.conf can be a good
> start to anybody that wants to start to work with ypldap(8).
> 
> Would be nice hear from other users how was their experience using ypldap
> with MS Active Directory and perhaps some HOWTO how they made all the setup
> would be amazing to have.
> 
> Also, would be useful to know who are still using NIS and what kind of
> setup(user case), maybe even the reason why they are still using it.

Honestly, I think the best way to motivate people to do the right thing(tm)
Would be to remove Yellow Pages from the tree, entirely. :-)
It's been dead for *years*, and as you say, isn't safe, anyway..

--Chris
> 
> 
> Best,
> -- 
> 
> -- 
> Marcelo Araujo(__)ara...@freebsd.org
> \\\'',)http://www.FreeBSD.org    \/  \ ^
> Power To Server. .\. /_)
> ___
> 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: mergemaster internally using make [for example] vs. WITH_META_MODE?

[Mark Millard]

On 2016-Jun-14, at 9:25 AM, Bryan Drewery  wrote:

> On 6/13/2016 4:31 PM, Mark Millard wrote:
>> On 2016-Jun-13, at 3:27 PM, Bryan Drewery  wrote:
>> 
>>> On 6/11/2016 7:28 PM, Mark Millard wrote:
 mergemaster [as an example] has code like:
 
> # grep -i make /usr/sbin/mergemaster | more
 . . .
> MM_MAKE="make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk"
>   ${MM_MAKE} DESTDIR=${DESTDIR} distrib-dirs >/dev/null
> ${MM_MAKE} DESTDIR=${TEMPROOT} distrib-dirs >/dev/null &&
> ${MM_MAKE} _obj SUBDIR_OVERRIDE=etc >/dev/null &&
> ${MM_MAKE} everything SUBDIR_OVERRIDE=etc >/dev/null &&
> ${MM_MAKE} DESTDIR=${TEMPROOT} distribution >/dev/null;} ||
 . . .
 
 If one is using WITH_META_MODE= for buildworld, buidlkernel, 
 installkernel, installworld what is appropriate for scripts or other uses 
 of make for other makefile-targets?
 
 Are there explicit mixes of using WITH_META_MODE= for some makefile 
 targets and not using WITH_META_MODE= for other makefile targets that need 
 to be avoided? Does one need to force some scripts to use [or not use] 
 WITH_META_MODE= for their "internal" make usage?
 
>>> 
>>> Is there an actual bug with mergemaster with WITH_META_MODE?
>>> 
>>> 
>>> -- 
>>> Regards,
>>> Bryan Drewery
>> 
>> I do not know. I was not sure if lack of WITH_META_MODE=yes for 
>> mergemaster's internal make uses might mess up later make commands that use 
>> WITH_META_MODE=yes for explicit make activities. Overall that would be a mix 
>> of with and without.
>> 
>> As stands I use the following script for mergemaster (TARGET_ARCH=amd64 
>> example):
>> 
>> # more ~/sys_build_scripts.amd64-host/mergemaster_amd64-amd64-host.sh 
>> script ~/sys_typescripts/typescript_mergemaster_amd64-amd64-host-$(date 
>> +%Y-%m-%d:%H:%M:%S) \
>> env __MAKE_CONF="/root/src.configs/make.conf" 
>> SRC_ENV_CONF="/root/src.configs/src.conf.amd64-clang-bootstrap.amd64-host" \
>> MAKEOBJDIRPREFIX="/usr/obj/clang/amd64.amd64" \
>> mergemaster -A amd64 $*
>> 
>> I've not added WITH_META_MODE=yes to the env yet.
>> 
>> 
>> I've been wondering if I should add WITH_META_MODE=yes to such scripts when 
>> the matching "make" script uses WITH_META_MODE=yes --such as:
>> 
>> # more 
>> ~/sys_build_scripts.amd64-host/make_amd64_nodebug_clang_bootstrap-amd64-host.sh
>>  
>> kldload -n filemon && \
>> script 
>> ~/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-host-$(date
>>  +%Y-%m-%d:%H:%M:%S) \
>> env __MAKE_CONF="/root/src.configs/make.conf" 
>> SRC_ENV_CONF="/root/src.configs/src.conf.amd64-clang-bootstrap.amd64-host" \
>> WITH_META_MODE=yes \
>> MAKEOBJDIRPREFIX="/usr/obj/clang/amd64.amd64" \
>> make $*
>> 
> 
> The targets (at top-level) that META_MODE is applied to is a whitelist
> now after r301887.  So it's safe to always pass it when building from
> the top-level.  If it's an unsupported target it will internally disable
> META_MODE.

So WITH_META_MODE=yes is now always allowed. That still leaves the questions of 
when WITH_META_MODE=yes is necessary: For example, is it ever required for the 
likes of mergemaster? (I'll use mergemaster to illustrate a more general 
question that applies to other potential scripts as well.)

As far as I can tell scripts such as mergemaster currently never supply 
WITH_META_MODE=yes to their internal make commands on their own.

It may be that this never interferes with anything, including use of 
WITH_META_MODE=yes for buildworld, installworld, and the like. If so then 
WITH_META_MODE=yes need never be used for mergemaster.

But if omitting WITH_META_MODE=yes for mergemaster can interfere with 
WITH_META_MODE=yes for buildworld, installworld, and the like then it would be 
important that "env WITH_META_MODE=yes mergemaster" be used if one is using 
WITH_META_MODE=yes for buildworld and the like.

Is it known which is the case? If yes, then which is the case?

If one orientation for meta mode status always is okay for mergemaster no 
matter which way is in use for buildworld and the like, then it would likely be 
best if mergemaster was coded to always/automatically use that orientation.

>> 
>> [Based on current behavior I normally only use WITH_META_MODE=yes for the 
>> host targeting its own architecture.]
> 
> Cross should be fine now.

At some point I'll experiment with it again. It may be a while before I get to 
that.

>> ===
>> Mark Millard
>> markmi at dsl-only.net
>> 
> 
> 
> -- 
> Regards,
> Bryan Drewery


===
Mark Millard
markmi at dsl-only.net


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

[Glen Barber]

On Tue, Jun 14, 2016 at 03:46:13PM -0700, Pete Wright wrote:
> hi there - i have a question regarding pkg base.
> 
> is it possible to only have "make packages" package specific files rather
> than all 700-odd files that compose the base system? specifically, i'd like
> to only create new kernel packages as I'm helping test the updated i915kms
> stuff.  not having to package the whole base, and download install it on my
> test rig, would be a nice time saver.
> 

Short answer: no.

Longer answer: you can set PKG_VERSION to the last known version your
packages were created.  They *should* obey such changes, however this is
in part why pkgbase is beta for 11.0-RELEASE.

Glen



signature.asc
Description: PGP signature

pkg base

[Pete Wright]

hi there - i have a question regarding pkg base.

is it possible to only have "make packages" package specific files 
rather than all 700-odd files that compose the base system? 
specifically, i'd like to only create new kernel packages as I'm helping 
test the updated i915kms stuff.  not having to package the whole base, 
and download install it on my test rig, would be a nice time saver.


thanks!
-pete

--
Pete Wright
p...@nomadlogic.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 #3391 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #3391 - Fixed:

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

Change summaries:

301895 by bdrewery:
Renegerate for WITH_META_MODE updates.

Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301894 by bdrewery:
Fix makeman showing dependency of DIRDEPS_BUILD->META_MODE.

This broke in r301887 with the meta mode whitelist.  'make showconfig'
still needs WITH_META_MODE support.

Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301893 by bdrewery:
Fix build from stable/10 with fmake.

This was broken in r301888.

fmake does not look in share/mk by default and thus does not yet
have MK_META_MODE set with default.

Pointyhat to:   bdrewery
Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301892 by bdrewery:
Bump __FreeBSD_version for r301602.

Reported by:ngie, Ben Lavery
PR: 210229
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"

Re: HWPMC on SkyLake

[Matthew Macy]

I think rrs@ may have done it.Randall? On Tue, 14 Jun 2016 
08:06:55 -0700  Doug Rabson wrote Did you get any feedback 
on this? I would like to be able to use hwpmc but my desktop is a recent 
skylake and I also get the 'hwpc_core: unknown PMC architecture: 4' error.  
CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4008.14-MHz K8-class CPU)   
Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3  
Features=0xbfebfbff
  
Features2=0x7ffafbbf
   AMD Features=0x2c100800   AMD 
Features2=0x121   Structured Extended 
Features=0x29c6fbb   XSAVE Features=0xf   VT-x: 
PAT,HLT,MTF,PAUSE,EPT,UG,VPID   TSC: P-state invariant, performance statistics  
hwpc_core: unknown PMC architecture: 4 hwpmc: 
SOFT/16/64/0x67On 20 February 2016 at 12:49, Larry 
Rosenman  wrote:  > Is there anything I can do to help: > > 
hwpc_core: unknown PMC architecture: 4 > hwpmc: 
SOFT/16/64/0x67 > > CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 
2.60GHz (2592.13-MHz K8-class CPU) >   Origin="GenuineIntel"  Id=0x506e3  
Family=0x6  Model=0x5e  Stepping=3 > > 
Features=0xbfebfbff
 > > 
Features2=0x7ffafbbf
 >   AMD Features=0x2c100800 >   AMD Features2=
 0x121 >   Structured Extended > 
Features=0x29c6fbf
 >   XSAVE Features=0xf >   VT-x: 
PAT,HLT,MTF,PAUSE,EPT,UG,VPID >   TSC: P-state invariant, performance 
statistics > > > -- > Larry Rosenman 
http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: 
l...@lerctr.org > US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 > 
___ > 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-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: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Eric van Gyzen]

On 06/ 9/16 05:49 PM, Matthew Seaman wrote:
> On 09/06/2016 18:34, Craig Rodrigues wrote:
>> There is still value to ypldap as it is now, and getting feedback from
>> users (especially Active Directory) would be very useful.
>> If someone could document a configuration which uses IPSEC or OpenSSH
>> forwarding, that would be nice.
>>
>> In future, maybe someone in OpenBSD or FreeBSD will implement things like
>> LDAP over SSL.
> What advantages does ypldap offer over nss-pam-ldapd (in ports) ?
> nss-pam-ldapd can use both ldap+STARTTLS or ldaps to encrypt data in
> transit, and I find it works very well for using OpenLDAP as a central
> account database.  I believe it works with AD, but haven't tried that
> myself.

nss-pam-ldapd works very well with Active Directory.  At work, dozens of
people use it on their workstations and hundreds of people use it on the
build servers.  We've been doing this for years with no issues.  Well,
we've caused some issues for ourselves, of course...  ;)

Eric
___
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: FreeBSD_HEAD_i386 - Build #3390 - Failure

[Bryan Drewery]

On 6/14/2016 10:16 AM, jenkins-ad...@freebsd.org wrote:
> make: "/usr/src/Makefile" line 222: Malformed conditional (${MK_META_MODE} == 
> "yes")

Fixed.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

FreeBSD_HEAD_i386 - Build #3390 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #3390 - Failure:

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

Change summaries:

301891 by bdrewery:
DIRDEPS_BUILD: Update dependencies

Approved by:re (gjb)
Sponsored by:   EMC / Isilon Storage Division

301890 by andrew:
Move the arm call to intr_pic_init_secondary earlier in the secondary CPU
initialisation. This ensures it will complete before signalling to the boot
CPU it has booted. This fixes a race with the GIC where the arm_gic_map may
not be populated before it is used to bind interrupts leading to some
interrupts becoming bound to no CPUs.

Approved by:re (kib)
Sponsored by:   ABT Systems Ltd

301889 by bdrewery:
WITH_META_MODE: Enable printing of some of make's environment on error.

This will print a set of variables from make on error using
MAKE_PRINT_VAR_ON_ERROR.  It is already enabled for the DIRDEPS_BUILD.
It may make sense to enable this in the non-meta mode as well once
people are more used to its more verbose error output.

This makes it much simpler to see which .meta file is used when a
command files so that it may be inspected for the build command.

Suggested by:   sjg
Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301888 by bdrewery:
WITH_META_MODE: Lessen the filemon(4) requirement scope.

- Move the sys.mk filemon requirement to bsd.init.mk as a warning.
  This is intended only to show when building directly in a subdirectory
  without filemon loaded.
- Move the error into Makefile and only apply it when building
  from the META_TGT_WHITELIST target list.

-DNO_FILEMON can be used to suppress both the warning and the error but
makes WITH_META_MODE less useful.  It will only compare build commands
in this mode rather than track all dependencies.

This fixes installing from a jail which doesn't need filemon in this
phase [1].

Reported by:Nikolai Lifanov  [1]
Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301887 by bdrewery:
WITH_META_MODE: Whitelist targets that are meta-mode-safe.

META_TGT_WHITELIST is added to define which build targets are safe for
meta mode.  See comments for more details.

This fixes 'make delete-old-libs' to properly show the interactive
prompt.

Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301886 by bdrewery:
WITH_META_MODE: Set MK_META_MODE=no with -B.

Using -B already sets .MAKE.MODE=compat but it was leaving
MK_META_MODE set which could still cause other MK_META_MODE==yes
checks to trigger.

Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301885 by bdrewery:
Add more missing .PHONY

Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301884 by bdrewery:
WITH_META_MODE: Fix rebuilding maketab outside of build-tools.

The bsd.dep.mk yacc targets rely on only the .c file getting a .meta
file.  However the previous code here relying on only the .h file meant
that it would be generated with a .meta file.  r301285 made it so that
the .h file is never expected to get a .meta file.  To keep this
restriction in place add in an extra dependency on the .c file so that
it is generated at this time.  It's a hack but the best for the patterns
we have at the moment for handling build-tools and side-effect-generated
files.

Reported by:Mark Millard
Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301883 by bdrewery:
Define targets in same order as .ORDER

This is a NOP but is done for style and to reduce confusion.

Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301882 by bdrewery:
WITH_META_MODE: Fix rescue rebuilding build-tools.

This is the same issue as r297997.

Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301881 by bdrewery:
WITH_META_MODE: Fix bin/csh rebuilding tc.const.h

This is the same issue as r297997, but was missed in it.

The WARNS value changes between 'build-tools' (MK_WARNS=no) and
'everything' resulting in a rebuild of this file.

Approved by:re (implicit)
Sponsored by:   EMC / Isilon Storage Division

301880 by bdrewery:
WITH_META_MODE+WITH_DEBUG_FILES: Fix library symlinks causing bogus rebuilds.

A simplified example of the library targets with WITH_DEBUG_FILES is:

  libgeom.so.5: libgeom.so.5.full
 cp libgeom.so.5.full libgeom.so.5

  libgeom.so.5.full:
 ln -s libgeom.so.5 libgeom.so
 cc -o libgeom.so.5.full *.o

Before, or without, WITH_DEBUG_FILES it is:

  libgeom.so.5:
 ln -s libgeom.so.5 libgeom.so
 cc -o libgeom.so.5 *.o

The problem is that bmake considers the link source for the libgeom.so
link in the libgeom.so.5.full target as being a dependency for
libgeom.so.5.full.  That resolves to libgeom.so.5.  Thus a cyclic
dependency is created.  The result

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Simon J. Gerraty]

Bryan Drewery  wrote:
> I think my point is getting lost.  With the new missing-meta feature, if

> Yet, via meta_oodate, if there is already a .meta file and .OODATE is
> used and has an empty source list then $.OODATE is forced to be .ALLSRC:

Ah yes forgot about that.
___
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: WITH_META_MODE vs. delete-old and delete-old-libs

[Bryan Drewery]

On 6/13/2016 2:52 PM, Bryan Drewery wrote:
> On 6/13/2016 2:51 PM, Ngie Cooper wrote:
>> On Mon, Jun 13, 2016 at 2:12 PM, Mark Millard  wrote:
>>> I've been using the following script to run my make commands for amd64 
>>> builds (as an example):
>>>
 # more 
 ~/sys_build_scripts.amd64-host/make_amd64_nodebug_clang_bootstrap-amd64-host.sh
 kldload -n filemon && \
 script 
 ~/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-host-$(date
  +%Y-%m-%d:%H:%M:%S) \
 env __MAKE_CONF="/root/src.configs/make.conf" 
 SRC_ENV_CONF="/root/src.configs/src.conf.amd64-clang-bootstrap.amd64-host" 
 \
 WITH_META_MODE=yes \
 MAKEOBJDIRPREFIX="/usr/obj/clang/amd64.amd64" \
 make $*
>>>
>>> When the WITH_META_MODE=yes is present (as shown) delete-old and 
>>> delete-old-libs command line arguments to the script do not display the 
>>> prompts but the process does wait for the y/n answers. I've actually used 
>>> top in another window to see what it is waiting for an answer to. After 
>>> I've answered all the questions then the list of prompts finally is shown 
>>> all at once.
>>>
>>> Without WITH_META_MODE= each prompt text is displayed before it waits for 
>>> the answer to that prompt.
>>>
>>>
>>> This sort of fits in with my earlier questions about make usage that is in 
>>> the likes of, say, mergemaster and if/where care about WITH_META_MODE=yes 
>>> use vs. disuse might be important for such. For example: Should "env 
>>> WITH_META_MODE=yes" be used with mergemaster if it was used with 
>>> buildworld, buildkernel, installkernel, and installworld?
>>
>> I generally do:
>>
>> yes | sudo make delete-old
>>
> 
> The problem is that the y/n prompt don't show at all.
> 
> 

This is fixed after r301887.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: mergemaster internally using make [for example] vs. WITH_META_MODE?

[Bryan Drewery]

On 6/13/2016 4:31 PM, Mark Millard wrote:
> On 2016-Jun-13, at 3:27 PM, Bryan Drewery  wrote:
> 
>> On 6/11/2016 7:28 PM, Mark Millard wrote:
>>> mergemaster [as an example] has code like:
>>>
 # grep -i make /usr/sbin/mergemaster | more
>>> . . .
 MM_MAKE="make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk"
${MM_MAKE} DESTDIR=${DESTDIR} distrib-dirs >/dev/null
  ${MM_MAKE} DESTDIR=${TEMPROOT} distrib-dirs >/dev/null &&
  ${MM_MAKE} _obj SUBDIR_OVERRIDE=etc >/dev/null &&
  ${MM_MAKE} everything SUBDIR_OVERRIDE=etc >/dev/null &&
  ${MM_MAKE} DESTDIR=${TEMPROOT} distribution >/dev/null;} ||
>>> . . .
>>>
>>> If one is using WITH_META_MODE= for buildworld, buidlkernel, installkernel, 
>>> installworld what is appropriate for scripts or other uses of make for 
>>> other makefile-targets?
>>>
>>> Are there explicit mixes of using WITH_META_MODE= for some makefile targets 
>>> and not using WITH_META_MODE= for other makefile targets that need to be 
>>> avoided? Does one need to force some scripts to use [or not use] 
>>> WITH_META_MODE= for their "internal" make usage?
>>>
>>
>> Is there an actual bug with mergemaster with WITH_META_MODE?
>>
>>
>> -- 
>> Regards,
>> Bryan Drewery
> 
> I do not know. I was not sure if lack of WITH_META_MODE=yes for mergemaster's 
> internal make uses might mess up later make commands that use 
> WITH_META_MODE=yes for explicit make activities. Overall that would be a mix 
> of with and without.
> 
> As stands I use the following script for mergemaster (TARGET_ARCH=amd64 
> example):
> 
> # more ~/sys_build_scripts.amd64-host/mergemaster_amd64-amd64-host.sh 
> script ~/sys_typescripts/typescript_mergemaster_amd64-amd64-host-$(date 
> +%Y-%m-%d:%H:%M:%S) \
> env __MAKE_CONF="/root/src.configs/make.conf" 
> SRC_ENV_CONF="/root/src.configs/src.conf.amd64-clang-bootstrap.amd64-host" \
> MAKEOBJDIRPREFIX="/usr/obj/clang/amd64.amd64" \
> mergemaster -A amd64 $*
> 
> I've not added WITH_META_MODE=yes to the env yet.
> 
> 
> I've been wondering if I should add WITH_META_MODE=yes to such scripts when 
> the matching "make" script uses WITH_META_MODE=yes --such as:
> 
> # more 
> ~/sys_build_scripts.amd64-host/make_amd64_nodebug_clang_bootstrap-amd64-host.sh
>  
> kldload -n filemon && \
> script 
> ~/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-host-$(date
>  +%Y-%m-%d:%H:%M:%S) \
> env __MAKE_CONF="/root/src.configs/make.conf" 
> SRC_ENV_CONF="/root/src.configs/src.conf.amd64-clang-bootstrap.amd64-host" \
> WITH_META_MODE=yes \
> MAKEOBJDIRPREFIX="/usr/obj/clang/amd64.amd64" \
> make $*
> 

The targets (at top-level) that META_MODE is applied to is a whitelist
now after r301887.  So it's safe to always pass it when building from
the top-level.  If it's an unsupported target it will internally disable
META_MODE.

> 
> [Based on current behavior I normally only use WITH_META_MODE=yes for the 
> host targeting its own architecture.]

Cross should be fine now.

> 
> 
> ===
> Mark Millard
> mar...@dsl-only.net
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

[Bryan Drewery]

On 6/11/2016 9:55 PM, Mark Millard wrote:
> Doing cleanworld instead of "-j 5 buildworld buildkernel" and then retrying 
> "-j 5 buildworld buildkernel" resulted in the same sort of thing but for 
> maketab instead:

This is fixed after r301884.  You'll need to clean the objdir for
usr.bin/awk at the least to fix the problem.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Simon J. Gerraty]

Bryan Drewery  wrote:
> Actually it does seem to be meta-missing bug since $? (.OODATE) is empty
> and yet it is requiring a .meta file.

As I said; .meta files and targets that use $? (.OODATE)
are fundamentally incompatible.

Such a target will not work correctly, if meta_oodate returns TRUE
so add .NOMETA or change the target to not use $?
___
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: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Bryan Drewery]

On 6/13/2016 8:18 PM, Simon J. Gerraty wrote:
> Bryan Drewery  wrote:
 ${_FIRM}: ${.CURDIR}/../../../../contrib/dev/drm2/radeonkmsfw/${_FIRM}.uu
 uudecode -p $? > ${.TARGET}
> Targets like this that use $? or ${.OODATE} are a bad fit with META mode.
> 
> If the normal make rules think the target is up to date, .OODATE will be
> empty, thus if meta_oodate says the target is out-of-date, the script
> will run with no args - because $? expands to nothing.
> 
> So either the use of $? should be replaced with ${.ALLSRC} or something
> else that will be consistent, or the target should be marked .NOMETA

I think my point is getting lost.  With the new missing-meta feature, if
a target uses .OODATE and has no .meta file then it is forced to run
*Even if no targets are out-of-date* and yields an empty result.

Yet, via meta_oodate, if there is already a .meta file and .OODATE is
used and has an empty source list then $.OODATE is forced to be .ALLSRC:

> if (oodate && needOODATE) {   
> /*
>  * Target uses .OODATE which is empty; or we wouldn't be here.
>  * We have decided it is oodate, so .OODATE needs to be set.  
>  * All we can sanely do is set it to .ALLSRC. 
>  */   
> Var_Delete(OODATE, gn);   
> Var_Set(OODATE, Var_Value(ALLSRC, gn, &cp), gn, 0);   
> free(cp); 
> } 

What's missing is setting of needOODATE in the metaMissing case so that
it auto applies the .OODATE=.ALLSRC hack/fixup which is what you're
suggesting as well.

I don't think it is right to force manually adding .NOMETA to all
.OODATE usages since there's already logic to handle .OODATE in the
.meta existing case.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Simon J. Gerraty]

Bryan Drewery  wrote:
> The problem is missing-meta requiring a .meta file here.  The $?/.OODATE
> comparison exception is only used meta_oodate() if there is already a
> .meta file, not for the new missing .meta logic.

Even if there is already a .meta file, if meta_oodate ever returns TRUE
the target will not work correctly.
___
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: HWPMC on SkyLake

[Larry Rosenman]

I have not.  

On 2016-06-14 10:06, Doug Rabson wrote:

> Did you get any feedback on this? I would like to be able to use hwpmc but my 
> desktop is a recent skylake and I also get the 'hwpc_core: unknown PMC 
> architecture: 4' error.
> 
> CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4008.14-MHz K8-class CPU)
> Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
> Features=0xbfebfbff
> Features2=0x7ffafbbf
> AMD Features=0x2c100800
> AMD Features2=0x121
> Structured Extended 
> Features=0x29c6fbb
> XSAVE Features=0xf
> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> TSC: P-state invariant, performance statistics
> 
> hwpc_core: unknown PMC architecture: 4
> hwpmc: SOFT/16/64/0x67
> 
> On 20 February 2016 at 12:49, Larry Rosenman  wrote:
> 
>> Is there anything I can do to help:
>> 
>> hwpc_core: unknown PMC architecture: 4
>> hwpmc: SOFT/16/64/0x67
>> 
>> CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class CPU)
>> Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
>> Features=0xbfebfbff
>> Features2=0x7ffafbbf
>> AMD Features=0x2c100800
>> AMD Features2=0x121
>> Structured Extended 
>> Features=0x29c6fbf
>> XSAVE Features=0xf
>> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>> TSC: P-state invariant, performance statistics
>> 
>> -- 
>> Larry Rosenman http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640 [1] E-Mail: l...@lerctr.org
>> US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
>> ___
>> 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"

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 

Links:
--
[1] tel:%2B1%20214-642-9640
___
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: HWPMC on SkyLake

[Doug Rabson]

Did you get any feedback on this? I would like to be able to use hwpmc but
my desktop is a recent skylake and I also get the 'hwpc_core: unknown PMC
architecture: 4' error.

CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4008.14-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3

Features=0xbfebfbff

Features2=0x7ffafbbf
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended
Features=0x29c6fbb
  XSAVE Features=0xf
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics

hwpc_core: unknown PMC architecture: 4
hwpmc: SOFT/16/64/0x67



On 20 February 2016 at 12:49, Larry Rosenman  wrote:

> Is there anything I can do to help:
>
> hwpc_core: unknown PMC architecture: 4
> hwpmc: SOFT/16/64/0x67
>
> CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
>
> Features=0xbfebfbff
>
> Features2=0x7ffafbbf
>   AMD Features=0x2c100800
>   AMD Features2=0x121
>   Structured Extended
> Features=0x29c6fbf
>   XSAVE Features=0xf
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
> ___
> 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: rtwn connection stops working on CURRENT

[Andriy Voskoboinyk]

Tue, 14 Jun 2016 08:24:01 +0300 було написано Marcus von Appen  
:


Hi!

Try attached patch (adds some busdma synchronization,
unloads data instead of descriptor in rtwn_tx_done() and improves
watchdog logic for a bit).


Hi,

I'm running into a somewhat weird issue with the rtwn driver
on CURRENT. It usually works for a couple of minutes (if there's
not too much of troughput happening) before the downstream and
upstream rates just "dry up" and the interface stops working.
It happens faster, if there are multiple connections open at the
same time, e.g. having a browser open or fetching mail and doing
a portsnap update.

Once the connection stopped working, dhclient will report the
following:

  Jun 11 12:22:22 athena dhclient[474]: send_packet: no buffer space  
available

  Jun 11 12:24:08 athena last message repeated 4 times
  ...

wpa_supplicant reports:

  Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0:  
CTRL-EVENT-DISCONNECTED bssid=... reason=3 locally_generated=1
  Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: WPA: 4-Way  
Handshake failed - pre-shared key may be incorrect
  Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0:  
CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="..." auth_failures=8  
duration=100 reason=WRONG_KEY
  Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0:  
CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="..." auth_failures=9  
duration=152 reason=CONN_FAILED


pciconf -lv:

rtwn0@pci0:3:0:0: class=0x028000 card=0x819510ec chip=0x817610ec  
rev=0x01 hdr=0x00

  vendor = 'Realtek Semiconductor Co., Ltd.'
  device = 'RTL8188CE 802.11b/g/n WiFi Adapter'
  class  = network

An pointers on tracking this issue down and getting it fixed are
highly appreciated.

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

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

Battery status indicates discharging when it is fully charged and connected to power source

[Anders Bolt-Evensen]

Hello!

Over the last months I've had a "problem" regarding battery status on my 
laptop which has been running FreeBSD CURRENT in order to have a working 
Intel driver (Haswell).


My problem/question is that when I boot the laptop with a fully charged 
battery and it is still connected to a power source, acpiconf reports 
that the battery is discharging, even if it is not:


[andersbo@freebsd-acer: it]$ acpiconf -i0
Design capacity:   4605 mAh
Last full capacity:  3523 mAh
Technology:   secondary (rechargeable)
Design voltage: 11400 mV
Capacity (warn):   245 mAh
Capacity (low): 192 mAh
Low/warn granularity:  53 mAh
Warn/full granularity:   3278 mAh
Model number:AC14A8L
Serial number: 13475
Type:   LION
OEM info:LGC
State:  discharging
Remaining capacity:98%
Remaining time:  unknown
Present rate:  0 mA (0 mW)
Present voltage: 12619 mV

However, if I do discharge the battery and then charge it up to full 
again, acpiconf correctly reports battery status as "high":


[andersbo@freebsd-acer: it]$ acpiconf -i0
Design capacity:   4605 mAh
Last full capacity:  3584 mAh
Technology:  secondary (rechargeable)
Design voltage:11400 mV
Capacity (warn):  245 mAh
Capacity (low): 192 mAh
Low/warn granularity:  53 mAh
Warn/full granularity:   3339 mAh
Model number:AC14A8L
Serial number:13475
Type:   LION
OEM info:LGC
State:  high
Remaining capacity:100%
Remaining time:  unknown
Present rate:  0 mA (0 mW)
Present voltage: 12823 mV

Last Thursday I updated the sources to ALPHA2:
[andersbo@freebsd-acer: it]$ uname -a
FreeBSD freebsd-acer.local 11.0-ALPHA2 FreeBSD 11.0-ALPHA2 #1 r301745: 
Thu Jun  9 20:25:35 CEST 2016 
root@freebsd-acer.local:/usr/obj/usr/src/sys/GENERIC  amd64


Do you have any tips on how to fix this little "problem?"

Thanks in advance.

Anders

___
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: libpam.so lost in update to 11.0-ALPHA3

[Ben Woods]

On Tuesday, 14 June 2016, Pavel Timofeev  wrote:

>
> 14 июня 2016 г. 10:37 пользователь "Ben Woods"  > написал:
> >
> > On 14 June 2016 at 09:11, René Ladan  > wrote:
> >
> > > Hi,
> > >
> > > I updated my pkgbase installation (11.0-amd64 from a few weeks ago) to
> > > 11.0-ALPHA3. Building and installing went fine but it turns out that
> > > libpam.so* is lost in the update (both the symlink and the actual so,
> > > currently so.6) :
> > >
> > > # pkg upgrade
> > > # pkg autoremove
> > >< > > version lower)
> > >   << yes, I forgot to run mergemaster>>
> > > # reboot
> > >   < > >
> > > Is this a known bug?
> > >
> > > Regards,
> > > René
> > >
> >
> > Michael Lucas mentioned on twitter a few days ago that pam was broken
> > recently in FreeBSD current.
> >
> > Michael: was this a problem with libpam.so going missing? Were you using
> > pkgbase, or is this an issue with the normal build/install system also?
> >
> > Regards,
> > Ben
> >
> > --
>
> Hi!
> I have the same problem with normal build/install system.
>

Ok, thanks for the feedback.

Bringing in the FreeBSD-current@ mailing list as it is not a problem with
PkgBase, but with 11-current.

Regards,
Ben


-- 

--
From: Benjamin Woods
woods...@gmail.com
___
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"