RE: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]

[Mark Millard]

https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html 
reports an RPI-B alignment fault for -r301815 (the snapshot) "when connecting 
via WiFi".

-r301872 ( 
https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html ) has a 
fix for networking vs. alignment handling for armv6 contexts that might be 
needed. Quoting:

> Author: ian
> Date: Mon Jun 13 16:48:27 2016
> New Revision: 301872
> URL: 
> https://svnweb.freebsd.org/changeset/base/301872
> 
> 
> Log:
>   Do not define __NO_STRICT_ALIGNMENT for armv6.  While the requirements
>   are no longer natural-alignment strict, there are still some restrictions.
>   
>   FreeBSD network code assumes data is naturally-aligned or is running
>   on a platform with no restrictions; pointers are not annotated to
>   indicate the data pointed to may be packed or unaligned.  The clang
>   optimizer can sometimes combine the load or store of a pair of adjacent
>   32-bit values into a single doubleword load/store, and that operation
>   requires at least 4-byte alignment.  __NO_STRICT_ALIGNMENT can lead
>   to tcp headers being only 2-byte aligned.
>   
>   Note that alignment faults remain disabled on armv6, this change reverts
>   only the defining of the symbol which leads to some overly-agressive code
>   shortcuts when building common/shared drivers and network code for arm.
>   
>   Approved by:re(kib)
> 
> Modified:
>   head/sys/arm/include/_types.h
> 
> Modified: head/sys/arm/include/_types.h
> ==
> --- head/sys/arm/include/_types.h Mon Jun 13 11:19:06 2016
> (r301871)
> +++ head/sys/arm/include/_types.h Mon Jun 13 16:48:27 2016
> (r301872)
> @@ -43,10 +43,6 @@
>  #error this file needs sys/cdefs.h as a prerequisite
>  #endif
>  
> -#if __ARM_ARCH >= 6
> -#define __NO_STRICT_ALIGNMENT
> -#endif
> -
>  /*
>   * Basic types upon which most other types are built.
>   */



===
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: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Marcelo Araujo]

I hear too!!! And that is why we are having this talk here around ypldap.

Best,

2016-06-16 10:50 GMT+08:00 Outback Dingo :

>
>
> On Wed, Jun 15, 2016 at 10:15 PM, Marcelo Araujo 
> wrote:
>
>> No worries Nikolai! If one day I will do it, will be on 12-RELEASE.
>>
>> Br,
>>
>> 2016-06-15 20:03 GMT+08:00 Nikolai Lifanov :
>>
>> > On 06/14/2016 21:05, Marcelo Araujo wrote:
>> > > 2016-06-15 8:17 GMT+08:00 Chris H :
>> > >
>> > >> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo <
>> > araujobsdp...@gmail.com>
>> > >> 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.
>> > >
>> >
>> > Please don't, at least for now. NIS is fast, simple, reliable, and works
>> > on first boot without additional software. I have passwords in
>> > Kerberos, so the usual cons doesn't apply. This is very valuable to me.
>> >
>> > It's not hurting anyone. What's the motivation behind removing it?
>>
>
>
> Removing NIS is a BAD idea, there are still plenty of people that use it,
> and plenty of businesses rely on it, I still hear people asking for it
>
>
>
>> >
>> > >
>> > >>
>> > >> --Chris
>> > >>>
>> > >>>
>> > >>> Best,
>> > >>> --
>> > >>>
>> > >>> --
>> > >>> Marcelo Araujo(__)ara...@freebsd.org
>> > >>> \\\'',)http://www.FreeBSD.org 

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

[Outback Dingo]

On Wed, Jun 15, 2016 at 10:15 PM, Marcelo Araujo 
wrote:

> No worries Nikolai! If one day I will do it, will be on 12-RELEASE.
>
> Br,
>
> 2016-06-15 20:03 GMT+08:00 Nikolai Lifanov :
>
> > On 06/14/2016 21:05, Marcelo Araujo wrote:
> > > 2016-06-15 8:17 GMT+08:00 Chris H :
> > >
> > >> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo <
> > araujobsdp...@gmail.com>
> > >> 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.
> > >
> >
> > Please don't, at least for now. NIS is fast, simple, reliable, and works
> > on first boot without additional software. I have passwords in
> > Kerberos, so the usual cons doesn't apply. This is very valuable to me.
> >
> > It's not hurting anyone. What's the motivation behind removing it?
>


Removing NIS is a BAD idea, there are still plenty of people that use it,
and plenty of businesses rely on it, I still hear people asking for it



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

Re: Support for Elantech trackpads (common on new laptops)

[Adrian Chadd]

I'll test it out tonight to see if anything is regressing


a-


On 15 June 2016 at 16:50, Ben Woods  wrote:
> Hi everyone,
>
> Raphael Poss has kindly submitted a patch to bring support for Elantech
> trackpads, which are common in new laptops.
>
> I have tidied the patch so that it applies cleanly to 11-current (as of
> r301929). It is attached to PR205690.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205690
>
> Could someone familiar with moused and mice drivers in sys/dev/atkbdc/psm.c
> please have a look?
>
> Thanks,
> 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"
___
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

[Marcelo Araujo]

No worries Nikolai! If one day I will do it, will be on 12-RELEASE.

Br,

2016-06-15 20:03 GMT+08:00 Nikolai Lifanov :

> On 06/14/2016 21:05, Marcelo Araujo wrote:
> > 2016-06-15 8:17 GMT+08:00 Chris H :
> >
> >> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo <
> araujobsdp...@gmail.com>
> >> 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.
> >
>
> Please don't, at least for now. NIS is fast, simple, reliable, and works
> on first boot without additional software. I have passwords in
> Kerberos, so the usual cons doesn't apply. This is very valuable to me.
>
> It's not hurting anyone. What's the motivation behind removing it?
>
> >
> >>
> >> --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"
> >>
> >
> >
> >
>
> ___
> 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"

RPI-B 11.0-ALPHA3 r301815 panic

[Keith White]

I get the following panic when connecting via WiFi to an RPI-B
running the r301815 snapshot:

Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xc18f28c0
FSR=0001, FAR=c21a287a, spsr=6013
r0 =c07a6548, r1 =0004, r2 =c060513d, r3 =07b6
r4 =c18f2a28, r5 =c18f2b40, r6 =c21a2876, r7 =c1cce3e0
r8 =c1cce3e0, r9 =c21a2876, r10=c18f2b40, r11=c18f2988
r12=, ssp=c18f2950, slr=c1a48370, pc =c0449928

Suggestions on where to start to track this down?


Here's the console output over the serial port from boot to panic:

U-Boot 2016.01 (Jun 11 2016 - 12:28:01 +)

DRAM:  224 MiB
RPI Model B (no P5) (0x3)
MMC:   bcm2835_sdhci: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In:serial
Out:   lcd
Err:   lcd
Net:   Net Initialization Skipped
No ethernet found.
reading uEnv.txt
** Unable to read file uEnv.txt **
Hit any key to stop autoboot:  0 
starting USB...

USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Booting from: mmc 0 ubldr.bin
reading ubldr.bin
223912 bytes read in 30 ms (7.1 MiB/s)
## No elf image at address 0x0020
## Starting application at 0x0020 ...
Consoles: U-Boot console 
Compatible U-Boot API signature found @0xdb464d0


FreeBSD/armv6 U-Boot loader, Revision 1.2
(r...@releng2.nyi.freebsd.org, Sat Jun 11 12:55:20 UTC 2016)

DRAM: 224MB
Number of U-Boot devices: 2
U-Boot env: loaderdev='mmc 0'
Found U-Boot device: disk
  Checking unit=0 slice= partition=... good.
Booting from disk0s2a:
/boot/kernel/kernel data=0x606164+0xfde9c syms=[0x4+0xcaf70+0x4+0x984e7]

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]... 
Using DTB provided by U-Boot at address 0x100.

Kernel entry at 0x0x400100...
Kernel args: (null)
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-ALPHA3 #0 r301815: Sat Jun 11 13:02:45 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
3.8.0)
VT: init without driver.
sema_sysinit
CPU: ARM1176JZ-S rev 7 (ARM11J core)
 Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext
 WB enabled LABT branch prediction disabled
  16KB/32B 4-way instruction cache
  16KB/32B 4-way write-back-locking-C data cache
real memory  = 234876928 (223 MB)
avail memory = 219312128simplebus0:  mem 
0x2000-0x20ff on ofwbus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
intc0:  mem 0x10001c-0x100027 on simplebus0
gpio0:  mem 0x20-0x2000af on simplebus0
gpio0: read-only pins: 46-53.
gpio0: reserved pins: 48-53.
gpiobus0:  on gpio0
gpioled0:  at pin 16 on gpiobus0
gpioc0:  on gpio0
iichb0:  mem 0x205000-0x20501f on simplebus0
iicbus0:  on iichb0
iic0:  on iicbus0
iichb1:  mem 0x804000-0x80401f on simplebus0
iicbus1:  on iichb1
iic1:  on iicbus1
spi0:  mem 0x204000-0x20401f on simplebus0
spibus0:  on spi0
bcm_dma0:  mem 0x7000-0x7fff,0xe05000-0xe05fff on 
simplebus0
mbox0:  mem 0xb880-0xb8bf on simplebus0
sdhci_bcm0:  mem 0x30-0x3000ff on simplebus0
mmc0:  on sdhci_bcm0
uart0:  mem 0x201000-0x201fff on simplebus0
uart0: console (115200,n,8,1)
vchiq0:  mem 0xb800-0xb84f on simplebus0
vchiq: local ver 8 (min 3), remote ver 8.
pcm0:  on vchiq0
bcm283x_dwcotg0:  mem 
0x98-0x99 on simplebus0
usbus0 on bcm283x_dwcotg0
fb0:  on ofwbus0
fbd0 on fb0
VT: initialize with new VT driver "fb".
fb0: 656x416(656x416@0,0) 24bpp
fb0: fbswap: 1, pitch 1968, base 0x0eaac000, screen_size 818688
cryptosoft0: 
Timecounters tick every 10.000 msec
usbus0: 480Mbps High Speed USB v2.0
bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
ugen0.1:  at usbus0
uhub0:  at mmc0 
41.6MHz/4bit/65535-block
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
warning: no time-of-day clock registered, system time will not be set accurately
ugen0.2:  at usbus0
uhub1:  on 
usbus0
uhub1: MTT enabled
uhub1: 3 ports with 2 removable, self powered
Setting hostuuid: 4af361f9-2fd5-11e6-bfe7-b827ebdc1f36.
Setting hostid: 0xe2d1bb69.
No suitable dump device was found.
Starting file system checks:
ugen0.3:  at usbus0
smsc0:  on usbus0
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
ukphy0:  PHY 1 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: Ethernet address: b8:27:eb:dc/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING 
CHECKS
/dev/ufs/rootfs: clean, 276308 free (196 frags, 34514 blocks, 0.0% 
fragmentation)
ugen0.4:  at usbus0
Mounting local filesystems:.
ELF ldconfig 

Jenkins build is back to normal : FreeBSD_HEAD #309

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

Support for Elantech trackpads (common on new laptops)

[Ben Woods]

Hi everyone,

Raphael Poss has kindly submitted a patch to bring support for Elantech
trackpads, which are common in new laptops.

I have tidied the patch so that it applies cleanly to 11-current (as of
r301929). It is attached to PR205690.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205690

Could someone familiar with moused and mice drivers in sys/dev/atkbdc/psm.c
please have a look?

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

Re: patch for smartmontools on latest head

[Samorukov,Alexey]

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


Thank you! I already found report in the list but had no time to look on it. 

I will check it and commit to the source.
___
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

[Matthew Macy]

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

Re: arm64 diagnostic when running 'make tinderbox'

[Bryan Drewery]

On 6/10/16 6:45 AM, Kurt Lidl wrote:
> Greetings all -
> 
> I periodically run the following on one of my hosts
> (an amd64 machine, running 10.3+patches), to make sure
> that I haven't broken the build for clang and gcc 4.2.1
> based architectures before committing.
> 
> I've noticed that I *always* get a diagnostic message
> about arm64, even though I'm not compiling for it...
> 
>   root@hydra-892: make -k -s -j 24 tinderbox TARGETS="sparc64 amd64"
>   --
>   >>> Building an up-to-date bmake(1)
>   --
>   --
>   >>> make universe started on Fri Jun 10 09:40:53 EDT 2016
>   --
>   >> arm64 skipped - install aarch64-binutils port or package to build
> ^
>   >> amd64 started on Fri Jun 10 09:40:53 EDT 2016
>   >> sparc64 started on Fri Jun 10 09:40:53 EDT 2016
>   >> amd64.amd64 buildworld started on Fri Jun 10 09:40:53 EDT 2016
>   >> sparc64.sparc64 buildworld started on Fri Jun 10 09:40:53 EDT 2016
> 

I have a fix out to re@ for approval that fixes this that will be in
later today.


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

Re: Kqueue races causing crashes

[Konstantin Belousov]

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 ?

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 we are working on the version of fix.


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

Re: Kqueue races causing crashes

[Matthew Macy]

You can use dwarf4 if you use GDB from ports  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 familiar 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 as the knlist lock). > This 
sounds as a good and correct analysis. I tried your test program > for around a 
hour on 8-threads machine, but was not able to trigger the > issue. Might be 
Peter have better luck reproducing them. Still, I think > that the problem is 
there. >  > IMO we should simply avoid clearing kn_knlist in knlist_remove().  
The > member is only used to get the locking function pointers, otherwise > 
code relies on KN_DETACHED flag to detect on-knlist condition.  See > the patch 
below. >  > >  > > Apropos of the knlist lock and its provenance: why is a lock 
from the  > > event producing entity used to control access to the knlist and 
knote?  > > Is it generally desirable to, for example, hold the process lock 
while  > > operating on a knlist attached to that process? It???s not obvious 
to me  > > that this is required or even desirable. This might suggest that a  
> > knlist should have its own lock rather than using a lock from the event  > 
> producing entity, which might make addressing this problem more  > > 
straightforward. >  > Consider the purpose of knlist. It serves as a container 
for all knotes > registered on the given subsystem object, like all knotes of 
the socket, > process etc which must be fired on event. See the knote() code. 
The > consequence is that the subsystem which fires knote() typically already > 
holds a lock protecting its own state. As result, it is natural to > protect 
the list of the knotes to activate on subsystem event, by the > subsystem lock. 
>  > diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c > index 
0614903..3f45dca 100644 > --- a/sys/kern/kern_event.c  There is not much gdb 
info here; I'll try to rebuild kgdb.  
https://people.freebsd.org/~pho/stress/log/kostik900.txt  The number of CPUs 
seems important to this test. Four works for me.  - Peter 
___ 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: 11.0 -r301900 and cross builds: the transition from not using WITH_META_MODE=yes to using it still seems to require cleanworld between

[Bryan Drewery]

On 6/15/16 1:36 AM, Mark Millard wrote:
> On 2016-Jun-14, at 11:00 PM, Mark Millard  wrote:
> 
>> [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
>>>

Ah yes, this is a bit of a special case that requires cleaning first.  I
think it should only happen from previously bad builds though (missing
recent fixes) rather than a cleanworld -> non-meta cross build -> meta
cross-build.

>>> 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.m
 k /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
> 
> The WITH_META_MODE=yes based re-cross-build after cleanworld worked fine.
> 
> Immediately re-running the re-build using WITH_META_MODE=yes again also 
> worked fine.
> 
> Rebuilding using WITH_META_MODE=yes yet again but after. . .
> 
> To DESTDIR=/usr/obj/DESTDIRs/clang-rpi2-installkernelworld (-D for 
> mergemaster):
> 
> installkernel
> mergemaster -FUp [no use of WITH_META_MODE=yes for mergemaster]
> installworld
> mergemaster -FUPi [no 

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

[Nikolai Lifanov]

On 06/14/2016 21:05, Marcelo Araujo wrote:
> 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.
> 

Please don't, at least for now. NIS is fast, simple, reliable, and works
on first boot without additional software. I have passwords in
Kerberos, so the usual cons doesn't apply. This is very valuable to me.

It's not hurting anyone. What's the motivation behind removing it?

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

___
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

[Peter Holm]

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 familiar 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 as the knlist lock).
> This sounds as a good and correct analysis. I tried your test program
> for around a hour on 8-threads machine, but was not able to trigger the
> issue. Might be Peter have better luck reproducing them. Still, I think
> that the problem is there.
> 
> IMO we should simply avoid clearing kn_knlist in knlist_remove().  The
> member is only used to get the locking function pointers, otherwise
> code relies on KN_DETACHED flag to detect on-knlist condition.  See
> the patch below.
> 
> > 
> > Apropos of the knlist lock and its provenance: why is a lock from the 
> > event producing entity used to control access to the knlist and knote? 
> > Is it generally desirable to, for example, hold the process lock while 
> > operating on a knlist attached to that process? It???s not obvious to me 
> > that this is required or even desirable. This might suggest that a 
> > knlist should have its own lock rather than using a lock from the event 
> > producing entity, which might make addressing this problem more 
> > straightforward.
> 
> Consider the purpose of knlist. It serves as a container for all knotes
> registered on the given subsystem object, like all knotes of the socket,
> process etc which must be fired on event. See the knote() code. The
> consequence is that the subsystem which fires knote() typically already
> holds a lock protecting its own state. As result, it is natural to
> protect the list of the knotes to activate on subsystem event, by the
> subsystem lock.
> 
> diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
> index 0614903..3f45dca 100644
> --- a/sys/kern/kern_event.c

There is not much gdb info here; I'll try to rebuild kgdb.

https://people.freebsd.org/~pho/stress/log/kostik900.txt

The number of CPUs seems important to this test. Four works for me.

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

[Peter Holm]

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 familiar 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 as the knlist lock).
> This sounds as a good and correct analysis. I tried your test program
> for around a hour on 8-threads machine, but was not able to trigger the
> issue. Might be Peter have better luck reproducing them. Still, I think
> that the problem is there.
> 

I got this after 10 runs:

userret: returning with the following locks held:
exclusive sleep mutex process lock (process lock) r = 0 (0xcb714758) locked @ 
kern/kern_event.c:2125
panic: witness_warn
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c15b7f5c,c1844da8,0,c158b3fc,f3b29af8,...) at 
db_trace_self_wrapper+0x2a/frame 0xf3b29ac8
kdb_backtrace(c17a92d1,0,c1228287,f3b29b94,0,...) at kdb_backtrace+0x2d/frame 
0xf3b29b30
vpanic(c1228287,f3b29b94,c1228287,f3b29b94,f3b29b94,...) at vpanic+0x115/frame 
0xf3b29b64
kassert_panic(c1228287,c15bc2c4,cb714758,c15aa7c1,84d,...) at 
kassert_panic+0xd9/frame 0xf3b29b88
witness_warn(2,0,c15ba937,f3b29ca8,c0c018d0,...) at witness_warn+0x32a/frame 
0xf3b29bdc
userret(cc2e1340,f3b29ce8,c15aadd7,4,0,...) at userret+0x92/frame 0xf3b29c20
syscall(f3b29ce8) at syscall+0x50e/frame 0xf3b29cdc

I'll apply the patch and test.

- Peter
___
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 -r301900 and cross builds: the transition from not using WITH_META_MODE=yes to using it still seems to require cleanworld between

[Mark Millard]

On 2016-Jun-14, at 11:00 PM, Mark Millard  wrote:

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

The WITH_META_MODE=yes based re-cross-build after cleanworld worked fine.

Immediately re-running the re-build using WITH_META_MODE=yes again also worked 
fine.

Rebuilding using WITH_META_MODE=yes yet again but after. . .

To DESTDIR=/usr/obj/DESTDIRs/clang-rpi2-installkernelworld (-D for 
mergemaster):

installkernel
mergemaster -FUp [no use of WITH_META_MODE=yes for mergemaster]
installworld
mergemaster -FUPi [no use of WITH_META_MODE=yes for mergemaster]
check-old
delete-old

also worked fine.

So as far as I can tell a first cross-build buildworld use of 
WITH_META_MODE=yes after having not used WITH_META_MODE=yes for the prior 
cross-build buildworld is the only place in the sequence needing an explicit 
cleanworld beforehand.

Cross-builds do seem to be working using 

Re: Kqueue races causing crashes

[Konstantin Belousov]

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 familiar 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 as the knlist lock).
This sounds as a good and correct analysis. I tried your test program
for around a hour on 8-threads machine, but was not able to trigger the
issue. Might be Peter have better luck reproducing them. Still, I think
that the problem is there.

IMO we should simply avoid clearing kn_knlist in knlist_remove().  The
member is only used to get the locking function pointers, otherwise
code relies on KN_DETACHED flag to detect on-knlist condition.  See
the patch below.

> 
> Apropos of the knlist lock and its provenance: why is a lock from the 
> event producing entity used to control access to the knlist and knote? 
> Is it generally desirable to, for example, hold the process lock while 
> operating on a knlist attached to that process? It???s not obvious to me 
> that this is required or even desirable. This might suggest that a 
> knlist should have its own lock rather than using a lock from the event 
> producing entity, which might make addressing this problem more 
> straightforward.

Consider the purpose of knlist. It serves as a container for all knotes
registered on the given subsystem object, like all knotes of the socket,
process etc which must be fired on event. See the knote() code. The
consequence is that the subsystem which fires knote() typically already
holds a lock protecting its own state. As result, it is natural to
protect the list of the knotes to activate on subsystem event, by the
subsystem lock.

diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index 0614903..3f45dca 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -1341,11 +1341,12 @@ findkn:
}
 
/*
-* We can get here with kn->kn_knlist == NULL.  This can happen when
-* the initial attach event decides that the event is "completed" 
-* already.  i.e. filt_procattach is called on a zombie process.  It
-* will call filt_proc which will remove it from the list, and NULL
-* kn_knlist.
+* We can get here with kn->kn_knlist == NULL or the knote
+* detached.  This can happen when the initial attach event
+* decides that the event is "completed" already,
+* i.e. filt_procattach is called on a zombie process.  It
+* will call filt_proc which will not add it to the list, and
+* leave NULL kn_knlist.
 */
 done_ev_add:
if ((kev->flags & EV_ENABLE) != 0)
@@ -2073,7 +2075,6 @@ knlist_remove_kq(struct knlist *knl, struct knote *kn, 
int knlislocked, int kqis
if (!knlislocked)
knl->kl_lock(knl->kl_lockarg);
SLIST_REMOVE(>kl_list, kn, knote, kn_selnext);
-   kn->kn_knlist = NULL;
if (!knlislocked)
knl->kl_unlock(knl->kl_lockarg);
if (!kqislocked)
___
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

[Daniel Braniss]

> On 15 Jun 2016, at 04:22, David Wolfskill  wrote:
> 
> 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

probably this is a bit too late, but we have been using MIT’s DNS/Hesiod since 
the days
when:
ypserver not responding
was popular, and true, it’s not only for password/group.

my .5 cents

danny


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

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"