Breakage with sys.kern.ptrace_test.{ptrace__parent_sees_exit_after_child_debugger, parent_sees_exit_after_unrelated_debugger} after r325719:325721

[Ngie Cooper (yaneurabeya)]

Hi Mateusz,
Per Jenkins, these two tests are broken after r325719:325721: 
https://ci.freebsd.org/job/FreeBSD-head-amd64-test/4987/ 
 .
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP

"make universe" broken by r325697

[Ngie Cooper (yaneurabeya)]

Per Jenkins: https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/5391/ .
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: iwm not in GENERIC kernel

[Ngie Cooper]

> On Nov 2, 2017, at 09:53, Adrian Chadd  wrote:
> 
> ugh okay
> 
> So it's a chicken/egg problem.
> 
> You can't finish the device probe/attach until the firmware loads.
> 
> For iwn, you can read the chipset abilities and mac address from
> EPROM/flash on the chip without the firmware being loaded, so you can
> complete probe/attach before the root filesystem is mounted.
> 
> For iwm, you have to load the firmware before you can read the chipset
> abilities and MAC address so you can't complete probe/attach until
> AFTER the root filesystem is mounted.
> 
> If someone wants to go add all of that support in to have probe/attach
> deferred until after rootfs is available then please do so. Or, just
> support the firmware being 100% compiled in- but when I tried this the
> last time I ran out of some firmware arena size preventing other
> firmware for other chipsets from being loaded.
> 
> Otherwise this is the current hack. :)

It’s ok (better than nothing)!

Could you please write up bugs with your findings?

Thanks so much!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD Documentation

[Ngie Cooper]

> On Oct 29, 2017, at 13:53, Rodney W. Grimes 
>  wrote:
> 
> -- Start of PGP signed section.
> [ Charset UTF-8 unsupported, converting... ]
>>> On 2017-10-29 11:00, Kurt Jaeger wrote:
>>> Hi!
>>> 
 How can we suggest edits for the docs?
>>> 
>>> Checkout the docs repo:
>>> 
>>> svn checkout https://svnweb.freebsd.org/doc/head/ .
>>> 
>>> Change the relevant files, create a new problem report on
>>> 
>>> https://bugs.freebsd.org/
>>> 
>>> and attach the svn diff to that problem report.
>> 
>> Since the document in question is a man page, it actually lives in the
>> src tree.
>> 
>> svn checkout https://svn.freebsd.org/base/head/ .
>> 
>> cd usr.sbin/jail
>> 
>> vi jail.8
>> 
>> svn diff > jail_manpage.patch
>> 
>> And then attach that patch to a bugzilla, or upload it to
>> reviews.freebsd.org
> 
> Lets make this MUCH easier on a user.
> cp /usr/share/man/man8/jail.8.gz /tmp
> cd /tmp
> gzip -d jail.8.gz
> cp -p jail.8 jail.8.orig
> vi jail.8
> diff -u jail.8.orig jail.8 >jail.8.patch
> 
> And then attach that patch to a bugzilla
> 
> More commands, but much shorter amount of time.
> 
> (Of cource broken if your system is not -current or close to it)

No. Just do a sparse checkout of share/man/man8 ... less error prone and one 
has a usable diff instead of a diff that might contain local modifications, or 
be a few revisions behind.

> -- 
> Rod Grimes rgri...@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: iwm not in GENERIC kernel

[Ngie Cooper (yaneurabeya)]

> On Oct 29, 2017, at 10:26, Kevin Oberman  wrote:

…

> But I thought that all modern wireless interfaces and many others load blobs. 
> Is the source for the firmware blob for iwn (which is in GENERIC)  available?

There’s a piece that’s open sourced that a BSD developer has written, 
but there’s also a binary payload that we have no insight into.
Cheers,
-Ngie

$ file sys/contrib/dev/iwm/*.uu
sys/contrib/dev/iwm/iwm-3160-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-3160-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-3160-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7260-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7260-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7260-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7265-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7265D-17.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265D-22.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-16.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-17.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-22.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8265-22.fw.uu:  uuencoded or xxencoded, ASCII text


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: iwm not in GENERIC kernel

[Ngie Cooper (yaneurabeya)]

> On Oct 29, 2017, at 02:46, Thomas Mueller  wrote:

…

> Is that binary blob the reason why rsu is not in GENERIC?
> 
> I use rsu for Hiro H50191 USB wireless adapter.

Yup.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: iwm not in GENERIC kernel

[Ngie Cooper (yaneurabeya)]

> On Oct 28, 2017, at 18:09, Gordon Tetlow  wrote:
> 
> I have an Intel NUC that uses an Intel 8260 wireless driver. This works
> flawlessly if I load the module if_iwm via the loader or the rc.conf
> kld_list directive.
> 
> Do we know if the iwm driver not being in GENERIC is an oversight or on
> purpose? I couldn't find anything in the list history.

It’s on purpose since it has a binary blob firmware driver that it relies on, 
IIRC.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

r324870 breaks boot on amd64 with WITNESS (was "svn commit: r324870 - in head/sys: amd64/include kern")

[Ngie Cooper (yaneurabeya)]

All,
I highly advise not upgrading to this revision if you use WITNESS. 
Please see the attached message for more details and reply to the commit log.
Cheers,
-Ngie

> Begin forwarded message:
> 
> From: "Ngie Cooper (yaneurabeya)" <yaneurab...@gmail.com>
> Subject: Re: svn commit: r324870 - in head/sys: amd64/include kern
> Date: October 22, 2017 at 17:19:32 PDT
> To: Mateusz Guzik <m...@freebsd.org>
> Cc: src-committers <src-committ...@freebsd.org>, svn-src-...@freebsd.org, 
> svn-src-h...@freebsd.org
> 
> 
>> On Oct 22, 2017, at 13:43, Mateusz Guzik <m...@freebsd.org> wrote:
>> 
>> Author: mjg
>> Date: Sun Oct 22 20:43:50 2017
>> New Revision: 324870
>> URL: https://svnweb.freebsd.org/changeset/base/324870
>> 
>> Log:
>> Make the sleepq chain hash size configurable per-arch and bump on amd64.
>> 
>> While here cache-align chains.
>> 
>> This shortens longest found chain during poudriere -j 80 from 32 to 16.
>> 
>> Pushing this higher up will probably require allocation on boot.
> 
> Hi Mateusz,
>   This change causes the Jenkins VMs to panic at boot with "panic: 
> witness_init: pending locks list is too small, increase WITNESS_PENDLIST” 
> when WITNESS is enabled: 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/4781/console .
>   Please fix or revert.
> Thanks,
> -Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: latest iwm patches don't work with my 8265 chip

[Ngie Cooper]

> not sure if this is the correct way to get things working, but this diff
>> fixes things up on my end (allows the firmware to load):
>> 
>> diff --git a/sys/modules/iwmfw/Makefile b/sys/modules/iwmfw/Makefile
>> index d38f5424153..73e401b3ea9 100644
>> --- a/sys/modules/iwmfw/Makefile
>> +++ b/sys/modules/iwmfw/Makefile
>> @@ -1,5 +1,5 @@
>>  # $FreeBSD$
>> 
>> -SUBDIR=iwm3160fw iwm7260fw iwm7265fw iwm8000Cfw iwm7265Dfw
>> +SUBDIR=iwm3160fw iwm7260fw iwm7265fw iwm8000Cfw iwm8265fw
>> iwm7265Dfw
>> 
>>  .include 
>> 
>> 
>> w/o the diff the iwm8265fw doesn't get built afaict.

Hi Pete,
I submitted your patch as r324470.
Take care!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD awk bug ?

[Ngie Cooper (yaneurabeya)]

> On Aug 15, 2017, at 20:15, KIRIYAMA Kazuhiko  wrote:
> 
> At Wed, 16 Aug 2017 10:36:36 +0900,
> Tomoya Tabuchi wrote:
>> 
>> On Wed, Aug 16, 2017 at 10:14:46AM +0900, KIRIYAMA Kazuhiko wrote:
>>> admin@tbedfpc:~/tmp % ll
>>> total 12
>>> -rw-r--r--  1 admin  admin  235 Aug 16 10:01 regex-1.sh
>>> -rw-r--r--  1 admin  admin  236 Aug 16 10:01 regex-2.sh
>>> -rw-r--r--  1 admin  admin  260 Aug 16 10:01 regex.sh
>>> admin@tbedfpc:~/tmp % cat regex.sh
>>> #!/bin/sh
>>> 
>>> data='1 2 3 4 5 6
>>> 1 2 3 4 5
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> 1 2 3 4
>>> 1 2 3'
>>> 
>>> IFS=$'\n'
>>> for datum in $data; do
>>>if echo "$datum" | egrep -q  '^([^[:space:]]+[[:space:]]+){5}'; then
>>>echo "$datum"
>>>else
>>>echo "Not 6 components! : \"$datum\""
>>>fi
>>> done
>>> admin@tbedfpc:~/tmp % sh ./regex.sh
>>> 1 2 3 4 5 6
>>> Not 6 components! : "1 2 3 4 5"
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> Not 6 components! : "1 2 3 4"
>>> Not 6 components! : "1 2 3"
>>> admin@tbedfpc:~/tmp % cat regex-1.sh
>>> #!/bin/sh
>>> 
>>> _f_awk='
>>> {
>>>if ($0 ~ /^([^[:space:]]+[[:space:]]+){5}/) {
>>>print $0
>>>} else {
>>>print "Not 6 components! : \"" $0 "\""
>>>}
>>> }'
>>> 
>>> data='1 2 3 4 5 6
>>> 1 2 3 4 5
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> 1 2 3 4
>>> 1 2 3'
>>> 
>>> echo "$data" | awk "$_f_awk"
>>> admin@tbedfpc:~/tmp % sh ./regex-1.sh
>>> Not 6 components! : "1 2 3 4 5 6"
>>> Not 6 components! : "1 2 3 4 5"
>>> Not 6 components! : "1 2 3 4 5 6"
>>> Not 6 components! : "1 2 3 4 5 6"
>>> Not 6 components! : "1 2 3 4"
>>> Not 6 components! : "1 2 3"
>>> admin@tbedfpc:~/tmp % cat regex-2.sh
>>> #!/bin/sh
>>> 
>>> _f_awk='
>>> {
>>>if ($0 ~ /^([^[:space:]]+[[:space:]]+){5}/) {
>>>print $0
>>>} else {
>>>print "Not 6 components! : \"" $0 "\""
>>>}
>>> }'
>>> 
>>> data='1 2 3 4 5 6
>>> 1 2 3 4 5
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> 1 2 3 4
>>> 1 2 3'
>>> 
>>> echo "$data" | gawk "$_f_awk"
>>> admin@tbedfpc:~/tmp % sh ./regex-2.sh
>>> 1 2 3 4 5 6
>>> Not 6 components! : "1 2 3 4 5"
>>> 1 2 3 4 5 6
>>> 1 2 3 4 5 6
>>> Not 6 components! : "1 2 3 4"
>>> Not 6 components! : "1 2 3"
>>> admin@tbedfpc:~/tmp % uname -a
>>> FreeBSD tbedfpc 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r321597: Thu Jul 27 
>>> 12:30:57 UTC 2017 root@tbedfc:/usr/obj/usr/src/sys/GENERIC  amd64
>>> admin@tbedfpc:~/tmp % pkg info -aI|grep gawk
>>> gawk-4.1.4_1   GNU version of Awk
>>> admin@tbedfpc:~/tmp %
>>> 
>>> 
>>> Is this the BSD awk (/usr/bin/awk) bug ?
>> 
>> Hello Kiriyama-san,
>> 
>> The man page awk(1) says that {m,n} matcning is not supported. The "{5}"
>> part matches the literal sequence of characters it's made out of, I suppose.
> 
> Oops. I missed "STANDARDS" section. Thanks for pointed out.
> 
> # But as it says in front "awk supports extended regular
> # expressions (EREs).  See re_format(7) for more information
> # on regular expressions.", I'd like to coinside with
> # re_format(7) spec.

Hello Kiriyama-san,
I asked this same question a while back and was told that the {n} form 
didn’t work with nawk. I’ll have to dig up the exact post if it’s somewhere 
public.
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ipfw kernel module not being built

[Ngie Cooper]

> On Aug 11, 2017, at 12:34, Bob Willcox  wrote:
> 
>> On Fri, Aug 11, 2017 at 12:21:49PM -0700, Mark Johnston wrote:
>> On Fri, Aug 11, 2017 at 02:06:02PM -0500, Bob Willcox wrote:
> On Aug 11, 2017, at 10:36, Bob Willcox  wrote:
> 
> When I rebuild my kernel on Jun 13th none of the previous ipfw kernel 
> modules were built:
> 
> ipfw.ko
> ipfw_nat.ko
> ipfw_nat64.ko
> ipfw_nptv6.ko
> ng_ipfw.ko
> 
> and only this ipfw module was built:
> 
> ng_ipfw.ko
> 
> However, the verson of /etc/rc.d/ipfw that I'm running (from the
> freebsd-base-graphics branch) is failing to load ipfw so my firewall isn't
> starting.
> 
> So, what am I missing? Is it possible that the freebsd-base-graphics 
> branch
> that I'm running has an old or improper version of /etc/rc.d/ipfw?
>> 
>> [...]
>> 
>>> include GENERIC_DRM
>> 
>> GENERIC_DRM sets MODULES_OVERRIDE, so only the specified modules are
>> built. In particular, ipfw*.ko does not get built. You'll need to either
>> remove the MODULES_OVERRIDE setting in GENERIC_DRM (which will make
>> kernel builds somewhat slower), or add
>> 
>> makeoptionsMODULES_OVERRIDE+= ipfw ...
>> 
>> to your custom config.

Or add "MODULES_OVERRIDE+= ipfw..." to your src.conf.
Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ipfw kernel module not being built

[Ngie Cooper]

> On Aug 11, 2017, at 10:36, Bob Willcox  wrote:
> 
> When I rebuild my kernel on Jun 13th none of the previous ipfw kernel modules 
> were built:
> 
> ipfw.ko
> ipfw_nat.ko
> ipfw_nat64.ko
> ipfw_nptv6.ko
> ng_ipfw.ko
> 
> and only this ipfw module was built:
> 
> ng_ipfw.ko
> 
> However, the verson of /etc/rc.d/ipfw that I'm running (from the
> freebsd-base-graphics branch) is failing to load ipfw so my firewall isn't
> starting.
> 
> So, what am I missing? Is it possible that the freebsd-base-graphics branch
> that I'm running has an old or improper version of /etc/rc.d/ipfw?

Hi Bob,
Can you please provide your make.conf, src.conf, and KERNCONF?
Thank you!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper (yaneurabeya)]

> On Aug 6, 2017, at 14:57, Ian Lepore  wrote:

…

> The thanks seem appropriate enough, given the tone and content of your
> previous emails.  What's missing is the very-much-required apology.

I don’t need an apology, I just hope/ask for a bit more patience next 
time. I’ve made similar claims out of surprise and frustration in the past, so 
I’m equally guilty of the same/similar tone.
Take care,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper (yaneurabeya)]

> On Aug 6, 2017, at 13:47, Julian H. Stacey  wrote:
> 
> Hi, Reference:
>> From:"Julian H. Stacey" 
>> Date:Sun, 06 Aug 2017 22:25:02 +0200
> 
> "Julian H. Stacey" wrote:
> The half baked mod. to src/libexec/Makefile could be backed out
>> 
>> I was wrong, sorry, code is not half baked, cos further down I spotted :
>>  .if ${MK_RCMDS} != "no"
>>  _rlogind=   rlogind
>>  _rshd=  rshd
>>  .endif
>> 
>> cd /usr/src; find . -type f | xargs grep MK_RCMDS | grep -v Makefile:
>>  ./tools/build/mk/OptionalObsoleteFiles.inc:.if ${MK_RCMDS} == no
>> 
>> I'm reading that while make world continues.
> 
> Finaly found it, after guessing some shell might roll MK_RCMDS from
> a list including RCMDS, & finding man src.conf with WITH_RCMDS
> Took me a while to find.  Thanks Ngie for your time.

Hi Julian,
Oh, ok.
Yes, the default for MK_RCMDS was changed recently from on to off. 
UPDATING also mentions it.
You must have upgraded from a major version to another recently or over 
a several month period — MK_* has been enhanced quite a bit over the past few 
months to “better respect optional features”. I left things on by default for 
POLA sake, but you’re free to remove them as need be. The defaults may change 
in the future (as you discovered with MK_RCMDS).
Cheers,
-Ngie

$ svn blame ^/head/share/mk/src.opts.mk | grep RCMDS
320530jlh RCMDS \
$ svn log -c 320530 ^/

r320530 | jlh | 2017-07-01 03:04:42 -0700 (Sat, 01 Jul 2017) | 12 lines

Disable RCMDS by default.

This was announced in this thread:
https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html

Applying plan proposed by ngie@ in:
https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018249.html

The port has been submitted as net/bsdrcmds in r444814.

Approved by:bapt, roberto, and others


$ grep -n 20170701 -A 2 UPDATING
66:20170701:
67- WITHOUT_RCMDS is now the default. Set WITH_RCMDS if you need them to be
68- built with the base system.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper]

> On Aug 6, 2017, at 11:38, Julian H. Stacey <j...@berklix.com> wrote:
> 
> "Ngie Cooper (yaneurabeya)" wrote:
>> --Apple-Mail=_7653CBF4-A533-4B1C-8D92-2E3AF5958F08
>> Content-Transfer-Encoding: 7bit
>> Content-Type: text/plain;
>>charset=us-ascii
>> 
>> 
>>> On Aug 6, 2017, at 09:36, Julian H. Stacey <j...@berklix.com> wrote:
>>> 
>>> Hi freebsd-current@freebsd.org
>>> with current src
>>>.ctm_status src-cur 13120
>>>.svn_revision322111
>>> libexec/Makefile has been butchered, eg
>>> rshd & other builds silently omitted
>>> unless one debugs & learns to do eg
>>>setenv _rshd Something
>>> A find & grep of src/ shows no other ref. to _rshd except
>>>./libexec/Makefile: ${_rshd} \
>>>./libexec/Makefile:_rshd=   rshd
>>> 
>>> I sampled _pppoed same error !
>>>./libexec/Makefile: ${_pppoed} \
>>>./libexec/Makefile:_pppoed= pppoed
>>> 
>>> Others turned off are:
>>>   ${_atf} \ ${_atrun} \ ${_blacklistd-helper} \ ${_comsat} \
>>>   ${_dma} \ ${_mail.local} \ ${_makewhatis.local} \ ${_mknetid}
>>>   \ ${_pppoed} \ ${_rlogind} \ ${_rshd} \ ${_rtld-elf} \
>>>   ${_smrsh} \ ${_telnetd} \ ${_tests} \ ${_tftp-proxy} \ ${_ypxfr}
>>> 
>>> If src/ annoyingly insists to force everyone to silently Not build src/,
>>> there should at least be some switch & reference doc in eg
>>>src/share/mk
>>>src/share/man/man5/src.conf
>> 
>> Julian,
>>Could you please post your build error (in its entirety) somewhere?
>> Thank you,
>> -Ngie
> 
> Why ?  Problem is fully identified.  Please read source.
> The half baked mod. to src/libexec/Makefile could be backed out
> as it fails to be supported by src/share/mk & src.conf.

Hi Julian,
The reason why I need more context is that I was unable to repro the issue. 
I need more details to help isolate/fix the problem.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper (yaneurabeya)]

> On Aug 6, 2017, at 09:36, Julian H. Stacey  wrote:
> 
> Hi freebsd-current@freebsd.org
> with current src
>   .ctm_status src-cur 13120
>   .svn_revision322111
> libexec/Makefile has been butchered, eg
> rshd & other builds silently omitted
> unless one debugs & learns to do eg
>   setenv _rshd Something
> A find & grep of src/ shows no other ref. to _rshd except
>   ./libexec/Makefile: ${_rshd} \
>   ./libexec/Makefile:_rshd=   rshd
> 
> I sampled _pppoed same error !
>   ./libexec/Makefile: ${_pppoed} \
>   ./libexec/Makefile:_pppoed= pppoed
> 
> Others turned off are:
>${_atf} \ ${_atrun} \ ${_blacklistd-helper} \ ${_comsat} \
>${_dma} \ ${_mail.local} \ ${_makewhatis.local} \ ${_mknetid}
>\ ${_pppoed} \ ${_rlogind} \ ${_rshd} \ ${_rtld-elf} \
>${_smrsh} \ ${_telnetd} \ ${_tests} \ ${_tftp-proxy} \ ${_ypxfr}
> 
> If src/ annoyingly insists to force everyone to silently Not build src/,
> there should at least be some switch & reference doc in eg
>   src/share/mk
>   src/share/man/man5/src.conf

Julian,
Could you please post your build error (in its entirety) somewhere?
Thank you,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper (yaneurabeya)]

> On Aug 6, 2017, at 09:54, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:
> 
>> 
>> On Aug 6, 2017, at 09:36, Julian H. Stacey <j...@berklix.com> wrote:
>> 
>> Hi freebsd-current@freebsd.org
>> with current src
>>  .ctm_status src-cur 13120
>>  .svn_revision322111
>> libexec/Makefile has been butchered, eg
>> rshd & other builds silently omitted
>> unless one debugs & learns to do eg
>>  setenv _rshd Something
>> A find & grep of src/ shows no other ref. to _rshd except
>>  ./libexec/Makefile: ${_rshd} \
>>  ./libexec/Makefile:_rshd=   rshd
>> 
>> I sampled _pppoed same error !
>>  ./libexec/Makefile: ${_pppoed} \
>>  ./libexec/Makefile:_pppoed= pppoed
>> 
>> Others turned off are:
>>   ${_atf} \ ${_atrun} \ ${_blacklistd-helper} \ ${_comsat} \
>>   ${_dma} \ ${_mail.local} \ ${_makewhatis.local} \ ${_mknetid}
>>   \ ${_pppoed} \ ${_rlogind} \ ${_rshd} \ ${_rtld-elf} \
>>   ${_smrsh} \ ${_telnetd} \ ${_tests} \ ${_tftp-proxy} \ ${_ypxfr}
>> 
>> If src/ annoyingly insists to force everyone to silently Not build src/,
>> there should at least be some switch & reference doc in eg
>>  src/share/mk
>>  src/share/man/man5/src.conf
> 
> Julian,
>   Could you please post your build error (in its entirety) somewhere?
> Thank you,

Also, please provide your make.conf and src.conf.
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: zfs.ko no longer loads after r320156: unresolved symbol: abd_is_linear

[Ngie Cooper (yaneurabeya)]

> On Aug 1, 2017, at 09:21, John Baldwin <j...@freebsd.org> wrote:
> 
> On Tuesday, August 01, 2017 09:47:41 AM Andriy Gapon wrote:
>> On 01/08/2017 02:31, Ngie Cooper wrote:
>>> Hi,
>>> I tried upgrading my host from 11.1-STABLE to 12.0-CURRENT, and it 
>>> didn’t work because abd_is_linear is an undefined symbol (it exists in 
>>> sys/conf/files, but not sys/modules/zfs/Makefile). I tried adding abd.c to 
>>> sys/modules/zfs/Makefile and it didn’t immediately fix my compilation 
>>> problem (ran into a linker error instead).
>>> If it isn’t fixed in the next few hours I’ll try my hand at fixing the 
>>> problem.
>> 
>> I am not sure what exact problem you have...
>> abd.c should be added to the list of source files via
>> .include "${SUNW}/uts/common/Makefile.files"
>> 
>> Perhaps something to do with "inline"...
> 
> Oh, yes.  If you use -fno-inline-funcs or the like.  I forgot to
> send this to Andriy earlier, but here is the fix I'm using:
> 
> https://github.com/freebsd/freebsd/commit/574dc95cf8272e16f6d44aff6cb4e08dede08886

Unfortunately… this is head, verbatim, which means that the bug still 
exists.
This gives me an idea of where I should look though.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

zfs.ko no longer loads after r320156: unresolved symbol: abd_is_linear

[Ngie Cooper]

Hi,
I tried upgrading my host from 11.1-STABLE to 12.0-CURRENT, and it 
didn’t work because abd_is_linear is an undefined symbol (it exists in 
sys/conf/files, but not sys/modules/zfs/Makefile). I tried adding abd.c to 
sys/modules/zfs/Makefile and it didn’t immediately fix my compilation problem 
(ran into a linker error instead).
If it isn’t fixed in the next few hours I’ll try my hand at fixing the 
problem.
Thank you,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

tools/tools/zfsboottest doesn't compile on ^/head

[Ngie Cooper]

Hi,
It looks like zfsboottest no longer compiles on ^/head (guessing it has 
to do with the clang upgrade).
If someone doesn’t fix this build breakage in the next few hours, I’ll 
take a stab at fixing it.
Thanks,
-Ngie

PS zfsboottest should really be compiled with world if MK_ZFS != no.

$ (cd tools/tools/zfsboottest/; make obj; make)
cc  -O1  -I/usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs  
-I/usr/src/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs  -I.  
-fdiagnostics-show-option  -W -Wextra -Wno-sign-compare -Wno-unused-parameter 
-m32   -g --coverage -MD  -MF.depend.zfsboottest.o -MTzfsboottest.o -std=gnu99 
-fstack-protector-strong-Qunused-arguments  -c 
/usr/src/tools/tools/zfsboottest/zfsboottest.c -o zfsboottest.o
In file included from /usr/src/tools/tools/zfsboottest/zfsboottest.c:56:
/usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs/zfsimpl.c:797:9: error: 
returning 'void' from a function with incompatible result type 'int'
return (pager_output(line));
   ^~~~
/usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs/zfsimpl.c:2356:17: 
warning: array index 264 is past the end of the array (which contains 192 
elements) [-Warray-bounds]
memcpy(path, >dn_bonus[sizeof(znode_phys_t)], psize);
  ^
/usr/src/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs/zfsimpl.h:910:2: 
note: array 'dn_bonus' declared here
uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)];
^
1 warning and 1 error generated.
*** Error code 1

Stop.
make: stopped in /usr/src/tools/tools/zfsboottest

157873imp void
157873imp printf(const char *fmt,…)
104679phk static void printf(const char *,...);
___
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: zfs.ko no longer loads after r320156: unresolved symbol: abd_is_linear

[Ngie Cooper (yaneurabeya)]

> On Jul 31, 2017, at 16:31, Ngie Cooper <yaneg...@gmail.com> wrote:
> 
> Hi,
>   I tried upgrading my host from 11.1-STABLE to 12.0-CURRENT, and it 
> didn’t work because abd_is_linear is an undefined symbol (it exists in 
> sys/conf/files, but not sys/modules/zfs/Makefile). I tried adding abd.c to 
> sys/modules/zfs/Makefile and it didn’t immediately fix my compilation problem 
> (ran into a linker error instead).
>   If it isn’t fixed in the next few hours I’ll try my hand at fixing the 
> problem.

(Resending to fix my sending email address)
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: tools/tools/zfsboottest doesn't compile on ^/head

[Ngie Cooper (yaneurabeya)]

> On Jul 31, 2017, at 16:21, Ngie Cooper <yaneg...@gmail.com> wrote:
> 
> Hi,
>   It looks like zfsboottest no longer compiles on ^/head (guessing it has 
> to do with the clang upgrade).
>   If someone doesn’t fix this build breakage in the next few hours, I’ll 
> take a stab at fixing it.
> Thanks,
> -Ngie
> 
> PS zfsboottest should really be compiled with world if MK_ZFS != no.
> 
> $ (cd tools/tools/zfsboottest/; make obj; make)
> cc  -O1  -I/usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs  
> -I/usr/src/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs  -I.  
> -fdiagnostics-show-option  -W -Wextra -Wno-sign-compare -Wno-unused-parameter 
> -m32   -g --coverage -MD  -MF.depend.zfsboottest.o -MTzfsboottest.o 
> -std=gnu99 -fstack-protector-strong-Qunused-arguments  -c 
> /usr/src/tools/tools/zfsboottest/zfsboottest.c -o zfsboottest.o
> In file included from /usr/src/tools/tools/zfsboottest/zfsboottest.c:56:
> /usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs/zfsimpl.c:797:9: 
> error: returning 'void' from a function with incompatible result type 'int'
>return (pager_output(line));
>   ^~~~
> /usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs/zfsimpl.c:2356:17: 
> warning: array index 264 is past the end of the array (which contains 192 
> elements) [-Warray-bounds]
>memcpy(path, >dn_bonus[sizeof(znode_phys_t)], psize);
>  ^
> /usr/src/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs/zfsimpl.h:910:2: 
> note: array 'dn_bonus' declared here
>uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)];
>^
> 1 warning and 1 error generated.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/tools/tools/zfsboottest
> 
> 157873imp void
> 157873imp printf(const char *fmt,…)
> 104679phk static void printf(const char *,...);

The declaration for putchar is not ANSI compliant either — which is 
probably another fun hurdle that someone’s going to have to deal with in terms 
of fixing sys/boot and libstand.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: i386 build fail

[Ngie Cooper]

Hi Shane,

> On Jul 25, 2017, at 23:25, Shane Ambler  wrote:
> 
> 
> Having just updated my testing bhyve system to 12-current r321405M I
> then started updating my poudriere 12-current jails, the amd64 jail
> built fine at r321457 and then building i386 (should have got r321457
> as well) failed with the following errors -

Please update to r321486--I accidentally introduced some build errors that 
I finally fixed on that revision.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Run binary from test suite

[Ngie Cooper]

On Tue, Jul 11, 2017 at 10:38 AM, Panagiotes Mousikides
 wrote:
> (Resending due to moderation.)
>
> Hello!
>
> I'm a Google Summer of Code student, writing some tests for the FreeBSD test
> suite, and putting them under src/tests.  I need to run some binaries,
> specifically pfctl.
>
> How should I call pfctl from my test scripts?  Should I call it directly and
> let the shell find the binary in the path?  Or should I find where the build
> version got created (somewhere under /usr/obj) and call that? How do I find
> where the binary ended up getting created in that case?
>
> Best regards,
> Panagiotes

Hello Panagiotes,
Please call pfctl from $PATH -- don't hardcode the path, ever.
I'll be looking at making "make check" more developer friendly in the
next 3-6 months, so running "make check" from usr.sbin/pf/... will
automatically add a set path/environment which hooks in to *.test.mk.
The goal of this is to simplify developer use for "make check".
Also, if the tests (for whatever reason) aren't going to be
installed alongside pfctl, e.g., tests/sys/pf/... please add 'atf_set
"require.progs" "pfctl"' to the header to ensure that the test is
skipped if/when pfctl isn't installed on the system.
Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory

[Ngie Cooper]

> On Jun 27, 2017, at 13:21, Cy Schubert  wrote:

...

> Yes. I've had issues with parallel installs breaking badly before this.

Be that what it may be, papering the issue over via poudriere is the wrong 
approach to fixing the problem imho.

Bryan's out for a few more days on vacation.. I'll see if I can look into this 
while he's gone.

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

Re: Compiler more strict on 12 with r320337 ?

[Ngie Cooper (yaneurabeya)]

> On Jun 26, 2017, at 23:31, Kurt Jaeger  wrote:
> 
> Hi!
> 
> Compiling devel/lfcbase, it fails while including sys/socketvar.h with
> this error:
> 
> In file included from Net.cc:36:
> /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an
>  anonymous struct
>enum {
>^
> 1 error generated.
> 
> Should sys/socketvar.h be included at all ?

Hi Kurt,
What compiler/CFLAGS (in particular, -std=) are you using to 
compile devel/lfcbase?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: hwpmc and Xeon E5 v4

[Ngie Cooper]

On Thu, Jun 15, 2017 at 12:44 AM, Andriy Gapon  wrote:
>
> It seems that hwpmc does not support newer Xeon processors:
>   pmc: Unknown Intel CPU.

What FreeBSD version is this?
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

[Ngie Cooper]

On Fri, Jun 9, 2017 at 3:55 PM, David Wolfskill  wrote:

...

> Gleb committed r319754; I finally(!) had a chance to revert the
> reversion of r319722, then apply r319754 and rebuild; the follow-up
> smoke test was successful.

...

> [Apparently hald invokes stat(2) on a listening socket, which was ...
> unexpected.]

This might have been caught by lib/libc/sys/stat_test:stat_socket . If
only the compat stuff was working on ci.freebsd.org as well, or the
test(s) had been run...
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: old syslog (jail) and new kernel = 100% CPU

[Ngie Cooper (yaneurabeya)]

> On Jun 5, 2017, at 08:20, Bryan Drewery  wrote:
> 
> On 6/5/2017 2:34 AM, Alexander Leidinger wrote:
>> 
>> Quoting Bryan Drewery  (from Sun, 4 Jun 2017 14:38:07
>> -0700):
>> 
>>> On 6/4/17 5:09 AM, Alexander Leidinger wrote:
 Hi,
 
 new kernel (surely r318877 and later) and old syslog in a jail = NOK.
 
>>> 
>>> What branch and revision is the syslogd? From my understanding the bug
>>> exists in a head version of syslogd only, maybe MFC'd to stable/11, but
>>> not released.  If it was MFC'd we need to fix it before the 11.1 release.
>> 
>> This was a syslogd from head for sure.
>> 
>> So the issue was that for an intermediate period of time a bug was in
>> syslogd in head which was causing this, and if I would have upgraded a
>> system were the jail would have been head from before the or after the
>> bug, then I wouldn't have noticed it?
>> 
> 
> Yes, that's my understanding.  So it's ultimately a non-issue for
> releases since it is just a temporary issue on head.

Yes. syslogd was refactored on ^/head. Some of the refactoring caused the issue 
Alexander brought up. The changes were never backported though, so the concern 
you had in the previous message isn’t something to be worried about, since the 
code hasn’t seen the changes the ^/head copy has.
Cheers!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r318757 - head

[Ngie Cooper (yaneurabeya)]

> On May 24, 2017, at 11:10, O. Hartmann  wrote:
> 
> Am Wed, 24 May 2017 13:04:30 -0500
> Larry Rosenman  schrieb:

…

> I use the traditional "make" way (via portmaster)

There were some reports about needing to do “make clean” before “make 
install”. Memory serves me correctly there are ways in portmaster to bypass 
“make clean” before running “make install”. Could you please provide your 
portmasterrc file?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Ngie Cooper]

> On May 24, 2017, at 08:15, David Wolfskill  wrote:

...

> It completed successfully and a reboot shows:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

Hi David!
There was another report on the list about a stale MAKEOBJDIRPREFIX causing 
someone grief. I think it's safe to say that meta mode and -DNO_CLEAN might not 
work across this transition--in particular meta mode tends to err on the side 
of not to rebuilding things.
Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Bug in make setting wrong MAKESYSPATH

[Ngie Cooper]

On Sun, May 21, 2017 at 1:54 AM, Thomas Mueller  wrote:
> I tried building ports, starting with ports-mgmt/synth, on HEAD (12-current) 
> and ran into difficulties with syntax error in bsd.compiler.mk .
>
> With PORTSDIR on another partition, mounted as /BETA1, I got these errors, 
> but not when I null-mounted /BETA1/usr/ports as /usr/ports.
>
> I shouldn't have to resort to this kludge, didn't have to in the recent past.
>
> This bug shows in both 11.0-STABLE and 12.0-CURRENT.
>
> I looked into "man make" and found that make got the wrong path for 
> MAKESYSPATH, setting to /BETA1/usr/share/mk instead of what it should be, 
> /usr/share/mk .
>
> Going into /BETA1/usr/ports/archivers/zip (for a short and simple example),
> make all-depends-list   produced
>
> sh: Syntax error: ")" unexpected
> make: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
> 4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero 
> status
> sh: Syntax error: ")" unexpected
> make[1]: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
> 4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero 
> status
> /BETA1/usr/ports/ports-mgmt/pkg
>
> make -m /usr/share/mk all-depends-list produces
> /BETA1/usr/ports/ports-mgmt/pkg
>
> This looks like a bug that ought to be fixed, though there is a workaround 
> using "make -m /usr/share/mk ..." every time, or presumably, setting
> MAKESYSPATH=/usr/share/mk
> in the environment.
>
> Should I file a bug report?
>
> I could get much more verbose outputs when there are more dependencies, such 
> as in /BETA1/usr/ports/ports-mgmt/synth, or more so,
> /BETA1/usr/ports/www/seamonkey
>
> I also noticed that in newer versions of FreeBSD, 
> /usr/share/mk/bsd.compiler.mk has greatly increased in size (not a bug. 
> except when "make" goes to the wrong MAKESYSPATH.
>
> Maybe add in .cshrc and .profile
> MAKESYSPATH=/usr/share/mk
> ?

Hi Tom,

make isn't at fault here as much as there's something else leaking
bsd.compiler.mk into the ports build. That's not supposed to happen.

Are you including any bsd.*.mk or src.*.mk files from /etc/make.conf ,
/etc/src.conf , etc?

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

Re: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 11:01, Beeblebrox  wrote:
> 
>> I was looking at the "make: Unknown modifier ‘c’” warnings — which
>> were a symptom of the bug that was fixed late last week. I don’t
>> genuinely know if ccache works or doesn’t work. Thanks, -Ngie
> 
> Thanks,
> I still do see those exact "make: Unknown modifier ‘c’” warnings
> along with the original fail.

More up-to-date information would help someone trying to diagnose your issue. 
Based on the original report, you are currently using sources from April 20th, 
which means that you would be affected by the bmake bug.

Would you please execute the following and attach your output?

$ make -VMAKE_VERSION
20170510

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 10:46, Beeblebrox  wrote:
> 
>> Upgrade make — it was a bug with it, fixed in the past few days.
>> HTH,
> 
> I just rebuilt and installed a clean world without using ccache
> After reboot I tried buildworld with ccache enabled, but got same error.
> 
> So, did not work unless you meant a particular port?

I was looking at the "make: Unknown modifier ‘c’” warnings — which were a 
symptom of the bug that was fixed late last week. I don’t genuinely know if 
ccache works or doesn’t work.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 01:20, Beeblebrox  wrote:
> 
> I have been getting ccache errors during buildworld. Ports for example does 
> not have this problem. I compleely reset the cache data some 2 months ago and 
> ccache seemed to play with that much more nicely.
> 
> Apart from the error below, I'm also getting some "cc not found" errors when 
> doing src stuff, whether ccache is enabled or not. For example installworld 
> (no ccache) broke with that message so I decided to re-build.
> 
> uname: 12.0-CURRENT 1200028 bedc15ffb71(drm-next)-dirty: Thu Apr 20 2017
> 
> /etc/make.conf
> CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
> CXX:=${cxx:c,^C\+\+,/usr/local/libexec/ccache/world/clang++,1}
> 
> ls /usr/local/libexec/ccache/world/
> c++   CCclang clang++40 g++5
> ccccacheclang++   clang40   gcc5
> 
> # make buildworld =>
> make: Unknown modifier 'c'
> make: Unknown modifier 'c'
> make[1]: Unknown modifier 'c'
> make[1]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> --
 World build started
> .
 stage 1.2: bootstrap tools
> --
> cd /asp/git/src; MAKEOBJDIRPREFIX=/asp/obj/asp/git/src/tmp  INSTALL="sh 
> /asp/git/src/tools/install.sh"  TOOLS_PREFIX=/asp/obj/asp/git/src/tmp  
> PATH=/asp/obj/asp/git/src/tmp/legacy/usr/sbin:/asp/obj/asp/git/src/tmp/legacy/usr/bin:/asp/obj/asp/git/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
>   WORLDTMP=/asp/obj/asp/git/src/tmp  MAKEFLAGS="-m 
> /asp/git/src/tools/build/mk  -m /asp/git/src/share/mk" make  -f Makefile.inc1 
>  DESTDIR=  BOOTSTRAPPING=1200030  SSP_CFLAGS=  MK_HTML=no NO_LINT=yes 
> MK_MAN=no  -DNO_PIC MK_PROFILE=no -DNO_SHARED  -DNO_CPU_CFLAGS MK_WARNS=no 
> MK_CTF=no  MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no  
> MK_INCLUDES=yes bootstrap-tools
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> ===> lib/clang/libllvmminimal (obj,all,install)
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> -O2 -pipe -I/asp/git/src/lib/clang/include 
> -I/asp/git/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD 
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS 
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
> -DDEFAULT_SYSROOT=\"/asp/obj/asp/git/src/tmp\" -ffunction-sections 
> -fdata-sections -DNDEBUG -MD -MF.depend.Support_APInt.o -MTSupport/APInt.o 
> -Qunused-arguments -I/asp/obj/asp/git/src/tmp/legacy/usr/include -std=c++11 
> -fno-exceptions -fno-rtti  -stdlib=libc++ -Wno-c++11-extensions  -c 
> /asp/git/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o
> /bin/sh: -O2: not found
> *** Error code 127

Upgrade make — it was a bug with it, fixed in the past few days.
HTH,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Really weird behavior with terminals/sessions in past couple weeks

[Ngie Cooper (yaneurabeya)]

> On May 13, 2017, at 11:05, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:
> 
> 
>> On May 13, 2017, at 11:01, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
>> wrote:
>> 
>> Hi,
>>  I’ve been noticing some really weird behavior with terminal input after 
>> updating my kernel/userland — in particular, if I do `arc diff —create` 
>> (which opens vi/vim), and try to do edits/use ^c, it will terminate the 
>> running process for `arc diff —create`. Similarly, I was seeing really weird 
>> input via vim (when doing `svn ci`) where if I had one of the editing modes 
>> on, like insert, it would delete several lines at once; I worked around this 
>> by using ^c to terminate insert mode, but that’s a really bad hack. It 
>> worked ok with r316745, got worse in r317727, and doesn’t seem to be any 
>> better in r318250.
> 
> I forgot to mention: I’m using SSH to access my machine.

My gut feeling is the sc(4) commits might have tickled or introduced some bugs. 
I’ll try reverting the following commits over the next couple days to see 
whether or not my experience improves: r316827 r316830 r316865 r316878 r316974 
r316977 r317190 r317198 r317199 r317245 r317256 r317264.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Really weird behavior with terminals/sessions in past couple weeks

[Ngie Cooper (yaneurabeya)]

> On May 13, 2017, at 11:01, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:
> 
> Hi,
>   I’ve been noticing some really weird behavior with terminal input after 
> updating my kernel/userland — in particular, if I do `arc diff —create` 
> (which opens vi/vim), and try to do edits/use ^c, it will terminate the 
> running process for `arc diff —create`. Similarly, I was seeing really weird 
> input via vim (when doing `svn ci`) where if I had one of the editing modes 
> on, like insert, it would delete several lines at once; I worked around this 
> by using ^c to terminate insert mode, but that’s a really bad hack. It worked 
> ok with r316745, got worse in r317727, and doesn’t seem to be any better in 
> r318250.

I forgot to mention: I’m using SSH to access my machine.
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Really weird behavior with terminals/sessions in past couple weeks

[Ngie Cooper (yaneurabeya)]

Hi,
I’ve been noticing some really weird behavior with terminal input after 
updating my kernel/userland — in particular, if I do `arc diff —create` (which 
opens vi/vim), and try to do edits/use ^c, it will terminate the running 
process for `arc diff —create`. Similarly, I was seeing really weird input via 
vim (when doing `svn ci`) where if I had one of the editing modes on, like 
insert, it would delete several lines at once; I worked around this by using ^c 
to terminate insert mode, but that’s a really bad hack. It worked ok with 
r316745, got worse in r317727, and doesn’t seem to be any better in r318250.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: make warning: ?: No such file or directory.

[Ngie Cooper]

On Wed, May 10, 2017 at 11:59 AM, Simon J. Gerraty  wrote:
> Bryan Drewery  wrote:
>> Oh now I get it too after updating system from head from r317177 to
>> r318116. So it seems to be a bug in bmake-20170420.
>
> What's in your env?
> Eg.
>
> env | grep MAKE
> ls

As I noted in the src commit, I think r318161 addresses the issue
(also identified by Coverity as CID: 1374641). Basically, buf2 was in
scope for the conditional as stack memory, `path` took the address
buf2 and used it out of scope (which may have triggered the compiler
to optimize/evaluate the code incorrectly since the case seemed
impossible).
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make warning: ?: No such file or directory.

[Ngie Cooper (yaneurabeya)]

> On May 9, 2017, at 21:37, O. Hartmann  wrote:
> 
> On recent CURRENT, the source tree /usr/src seems to have issues on some of my
> boxes and whenever I issue "make build", the message:
> 
> make warning: �: No such file or directory.
> 
> pops up. "svn st" doesn't reveal anything wrong.
> 
> My locale settings are:
> 
> LANG=
> LC_CTYPE="C"
> LC_COLLATE="C"
> LC_TIME="C"
> LC_NUMERIC="C"
> LC_MONETARY="C"
> LC_MESSAGES="C"
> LC_ALL=
> 
> (just for the record). Those spooky non-printables are seen on xterm(s) of
> various other systems (11.0, 11-STABLE, 12-CURRENT) when connecting to the
> systems in question.
> 
> What is this?
> 
> Kind regards and thanks in advance,

I see similar oddness when running some commands. It seems to be happening as 
of the last month or two.
Thanks,
-Ngie

$ make buildenv TARGET_ARCH=armv6
make warning: I: No such file or directory.
make warning: I: No such file or directory.
Entering world for armv6:arm
$


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ${src}/release/release.sh fails at makefs state

[Ngie Cooper (yaneurabeya)]

> On May 8, 2017, at 06:07, Alastair Hogge <a...@fastmail.fm> wrote:
> 
> On Fri, 5 May 2017 11:26:44 PM Ngie Cooper wrote:
>> (CCing emaste)
>> 
>>> On May 5, 2017, at 21:55, Alastair Hogge <a...@fastmail.fm> wrote:
>> …
>> 
>>> Calculated size of `memstick.img.part': 485474304 bytes, 9435 inodes
>>> Extent size set to 8192
>>> memstick.img.part: 463.0MB (948192 sectors) block size 8192, fragment size
>>> 1024
>>> 
>>>   using 9 cylinder groups of 54.38MB, 6960 blks, 1152 inodes.
>>> 
>>> super-block backups (for fsck -b #) at:
>>>32, 111392, 222752, 334112, 445472, 556832, 668192, 779552, 890912,
>>> 
>>> Populating `memstick.img.part'
>>> makefs: bread: read 8192 (684294144) returned 0: No error: 0
>>> makefs failed
>>> *** Error code 1
> 
> Thanks Ngie.
> 
> It look like r317744 is causing the problem:
> https://svnweb.freebsd.org/base?view=revision=317744
> 
> That is the checkout that breaks release building for me, prior revisions
> cause no problem.

Hi Alastair,
r317967 should allow you to build release images again.
Cheers!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: filemon: weird full-time build although filemon enabled

[Ngie Cooper (yaneurabeya)]

> On May 6, 2017, at 00:22, O. Hartmann  wrote:
> 
> I build CURRENT on two technically similar systems on a almost daily basis. 
> Therefore, it
> was a great relief having WITH_META_MODE=yes set in /etc/src-env.conf for 
> incremental
> builds. To make my understanding of this clear (just in case I'm wrong): 
> setting
> WITH_META_MODE builds only portions that does not need to be build in the 
> make context.
> 
> Well, the reason writing this email is: on one system, I run almost every 
> reboot into a
> "full build" and this puzzles me a bit. The long-lasting and time exhausting 
> builds are
> within the LLVM/CLANG tree. They consume a lot of time. The box in question 
> does have a
> weak CPU, only two physical cores, four threads, 8GB of RAM and builds the 
> /usr/obj
> residing on a SSD. The reference machine does have the same motherboard, also 
> a SSD, but
> has 16 GB RAM and a 4-core/8 threads XEON CPU - but both are "IvyBridge". The 
> XEON
> usually needs 30 - 40 minutes to compile a full world/kernel from a clean 
> /usr/obj, the
> "weak" box takes approximately 120 minutes - it is understandable that a 
> shortage of the
> build time is appreciated.
> 
> Well, having said this, I need to mention that both systems use almost
> identical /etc/src.conf setting - except the order of appearance of the WITH_ 
> tags. In
> fact, they are identical except the KERNCONF (naming of the kernel) and 
> PORTS_MODULES=,
> the "weak" box incorporates x11/nvidia-driver and 
> emulators/virtualbox-ose-kmod, so these
> modules are build every time the system gets rebuild, but the time taken by 
> those is
> negligible.
> 
> The problem: to make my point clear: the "weak" box starts compiling almost 
> everytime now
> the LLVM/CLANG tree while the XEON box does not. This is spooky.
> 
> I deleted on both  systems recently /usr/obj completely from its content and 
> restarted a
> buildworld again to hope, that the problem was introduced due to some files
> necessary for the BSD make environment to indicate the incremental build. But 
> no success.
> Even more spooky is the fact, that after a build on the "weak" box and a 
> build again, the
> box bevaves as expected not rebuilding everything again, but in some cases 
> after a
> reboot, a rebuild the hits again the build of LLVM/CLANG tree, while the XEON 
> box does
> not.
> 
> I think there is something missing an I'd like to ask what is the suggested 
> way to
> initially restart a full build to ensure that WITH_META_MODE gets initialised 
> correctly.
> 
> Well, I'm not a developer, so please be patient with my naive report.
> 
> Thanks in advance,

Dumb question: which kernel are you using on which machine (GENERIC, 
GENERIC-NODEBUG, a custom kernel with or without debug hooks, e.g., INVARIANTS, 
enabled)? Also, how are you building the system (locally using UFS or ZFS, 
remotely, e.g., over NFS, etc)?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ${src}/release/release.sh fails at makefs state

[Ngie Cooper (yaneurabeya)]

(CCing emaste)

> On May 5, 2017, at 21:55, Alastair Hogge  wrote:

…

> Calculated size of `memstick.img.part': 485474304 bytes, 9435 inodes
> Extent size set to 8192
> memstick.img.part: 463.0MB (948192 sectors) block size 8192, fragment size
> 1024
>using 9 cylinder groups of 54.38MB, 6960 blks, 1152 inodes.
> super-block backups (for fsck -b #) at:
> 32, 111392, 222752, 334112, 445472, 556832, 668192, 779552, 890912,
> Populating `memstick.img.part'
> makefs: bread: read 8192 (684294144) returned 0: No error: 0
> makefs failed
> *** Error code 1

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: make buildworld broken at r317821 (libsysdecode)

[Ngie Cooper]

On Fri, May 5, 2017 at 4:43 PM, Cy Schubert  wrote:

...

> You have a bad DIMM. I had this same problem on my laptop but not on my
> servers downstairs. That suggested that since all four machines were
> running the same software the difference between them was hardware.
> Replacing the memory in my laptop made this problem go away.
>
> I have a question for you. Do you use ZFS? ZFS exercises memory quite
> aggressively. I also had this problem when I replaced my UFS filesystems
> with ZFS on my testbed many moons ago. It even suffered random kernel
> panics. Here again, replacing the memory resolved the issue.

We need more information first before saying "bad hardware" -- in
particular, was the machine overtaxed, were the input files proper,
etc?

I'm asking because clang has a number of bugs in bugzilla where the
host ran out of memory trying to compile things and clang didn't fail
gracefully when allocating memory, handling inputs, etc.

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

Re: old snapshot install images?

[Ngie Cooper (yaneurabeya)]

> On May 3, 2017, at 10:39, Michael W. Lucas <mwlu...@michaelwlucas.com> wrote:
> 
> On Wed, May 03, 2017 at 09:52:09AM -0700, Ngie Cooper wrote:
>> Ok. How big is your freebsd-boot partition?
> 
> The size created by the installer. ;)
> 
> I've run another install, this one with the r317181 snapshot (20
> April.)
> 
> gpart show ada4 shows this (hand-copied)
> 
> 40   125045344ada4  GPT (60G)
> 40   1024 1 freebsd-boot (512K)
> 1064 984- free - (492K)
> 2048 4194304  2 freebsd-swap (2.0G)
> 4196352  1208483843 freebsd-zfs (58G)
> 125044736  648  - free - (324K)
> 
> ada5 is identical. It's a two-satadom mirror.
> 
> I used the guided install, had it blow the disks away.

Ok. You aren’t afflicted by the “freebsd-boot” partition is too small issue 
that many legacy users will have to suffer with coming from 8.x/9.x.
Cheers!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: old snapshot install images?

[Ngie Cooper]

> On May 3, 2017, at 09:41, Michael W. Lucas <mwlu...@michaelwlucas.com> wrote:
> 
>> On Wed, May 03, 2017 at 09:37:04AM -0700, Ngie Cooper (yaneurabeya) wrote:
>> Ok. I was curious because there has been a period of time when 512b/sector 
>> disks have been broken and vice versa.
>> 
>> I’m going to operate under the impression that one of tsoome’s recent 
>> changes to zfsboot fixed things (there was some breakage over the past 
>> couple months based on posts to current@ and svn-src-*@), but I can’t count 
>> on it 100%.
> 
> 
> The most recent installer snapshot has the exact same problem.
> 
> Every installer snapshot on the FTP site has the exact same problem.
> 
> I've gotten some installer snapshots from October and from
> mid-2015. Trying those.
> 
> My goal is to find out when the problem appeared and include the time
> window in the PR.

Ok. How big is your freebsd-boot partition?
Thanks,
-Ngie
> 
> 
> -- 
> Michael W. LucasTwitter @mwlauthor 
> nonfiction: https://www.michaelwlucas.com/
> fiction: https://www.michaelwarrenlucas.com/
> blog: http://blather.michaelwlucas.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: old snapshot install images?

[Ngie Cooper (yaneurabeya)]

> On May 3, 2017, at 09:34, Michael W. Lucas <mwlu...@michaelwlucas.com> wrote:
> 
> On Wed, May 03, 2017 at 01:01:10AM -0700, Ngie Cooper wrote:
>> Hi Michael!
>> - What sources are you using/revision are you at?
> 
> Using r311461 amd64 install memstick at the moment. Uname says built
> "Thu Jan 5 22:46:38 UTC 2017”

Ok. What version were you going to?

>> - Are your drives the 512 byte/sector or 4kB/sector variety?
> 
> They all claim to be 512 byte/sector. FWIW. ;-)

Ok. I was curious because there has been a period of time when 512b/sector 
disks have been broken and vice versa.

I’m going to operate under the impression that one of tsoome’s recent changes 
to zfsboot fixed things (there was some breakage over the past couple months 
based on posts to current@ and svn-src-*@), but I can’t count on it 100%.

HTH,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: old snapshot install images?

[Ngie Cooper]

Hi Michael!

> On May 2, 2017, at 12:15, Michael W. Lucas  wrote:
> 
> Hi,
> 
> About a year ago, I did a clean install on my desktop. No problems.
> 
> I tried a clean install now, and it dies with:
> 
> gtpzfsboot: error 1 lba 32
> error 1
> gptzfsboot: error 1 lba 4294967288
> gptzfsboot: error 1 lba 1
> gptzfsboot: no ZFS pools located, can't boot
> 
> The pool is visible in the live CD, and I can import it. I want to
> file a PR.
> 
> The sensible thing for me to do is to use old snapshot installers to
> determine when this machine could no longer install.
> 
> Unfortunately, the FTP servers only keep a month or so of snapshots.
> 
> ftp-archive doesn't have the old snapshots.
> 
> Does anyone have an archive of -current install media, either CD or
> ISO? I need to get this box back fairly quickly, but I don't mind
> burning a couple days to nail it down.

- What sources are you using/revision are you at?
- Are your drives the 512 byte/sector or 4kB/sector variety?
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Ngie Cooper (yaneurabeya)]

> On Apr 14, 2017, at 19:53, Mark Millard  wrote:
> 
> On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer  wrote:
> 
>> On Thu, 13 Apr 2017, Pedro Giffuni wrote:
>>> I didn’t want to get into this but the problem is that as part of it's
>>> build/bootstrapping process, GCC historically takes system headers
>>> and attempts to “fix” them. I am unsure the fixes do anything at all
>>> nowadays but the effect is that the compiler tends to take snapshots
>>> of the system headers when it is built. cdefs.h is used by all the
>>> system headers so changes in cdefs.h have good chances affecting
>>> such builds but any change are likely to cause similar trouble.
>>> 
>>> In the case of gcc-aux, it appears the compilation is based on a
>>> bootstrap compiler which already carries outdated headers.
>>> A workaround, suggested by gerald@ the last time a similar issue
>>> happened was to run for install-tools/fixinc.sh. I think that may
>>> regenerate the headers and let the build use updated headers.
>>> Ultimately gcc-aux needs maintainer intervention and using
>>> outdated headers will break sooner or later: especially on -current.
>> 
>> Indeed, thanks for the analysis/background, Pedro!
>> 
>> I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6,
>> and perhaps John (as the maintainer of that port) has plans to update
>> it?  Let me copy him.
> 
> [As I have a prior E-mail exchange with John M. indicating that
> he was not intending to be the lang/gcc6-aux maintainer, I
> avoid spamming him with this material: I've removed him from
> the CC list in this reply. I can send the material to him if I
> see evidence of his wanting it.]
> 
> Just FYI:
> 
> [Previously: temporarily adding __nonnull and __nonnull_all
> back into into my local head FreeBSD variant got problems
> with: __vm_ooffset_t and __vm_pindex_t no longer existing and
> also the same pid_t issue indicated below.]
> 
> 
> I tried using [on a Pine64+ 2GB aarch64 system]:
> 
> # 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarch64-aux-freebsd12.0/6.3.1/install-tools/mkheaders
>  /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap
> 
> to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and __vm_pindex_t.
> 
> I then built via portmaster -CDK usage. Various header issues
> did go away but the build of lang/gcc6-aux still stopped with:
> 
> In file included from 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:20:0:
> ./config.h:556:15: error: two or more data types in declaration specifiers
> #define pid_t int
>   ^
> 
> I'm guessing that the define for pid_t in config.h resulted
> in something like:
> 
> typedef ??? pid_t;
> 
> that turned into something like a:
> 
> typedef ??? int;
> 
> for the error listed above.
> 
> There were also implicit-declaration warnings:
> 
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:
>  In function 'simple_object_internal_read':
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:75:21:
>  warning: implicit declaration of function 'read' 
> [-Wimplicit-function-declaration]
>   ssize_t got = read (descriptor, buffer, size);
> ^~~~
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:
>  In function 'simple_object_internal_write':
> /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:119:23:
>  warning: implicit declaration of function 'write' 
> [-Wimplicit-function-declaration]
>   ssize_t wrote = write (descriptor, buffer, size);
>   ^
> 
> The implicit-declaration warnings for read and write may well
> also not be expected/desirable.
> 
> It may be that more than a script run is needed to make
> things be appropriate.

Is there a reason why you need ada support (that seems to be the only 
real reason for installing gcc6 vs gcc6-aux)? gcc6-aux uses a snapshot of gcc6 
with custom options.
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

buildkernel broken for META_MODE

[Ngie Cooper (yaneurabeya)]

Hi,
I ran into this error when trying to run a meta mode build (for the 
first time). It might be related to the recent assym* ordering changes.
Thanks!
-Ngie

$ cat /etc/src-env.conf
WITH_AUTO_OBJ=  yes
WITH_META_MODE= yes
UPDATE_DEPENDFILE=  yes
$ pwd
/usr/src
$ svnversion
316603M
$ svn st | grep -v \?
M   usr.bin/grep/tests/Makefile
$ env SRCCONF=/dev/null NO_FILEMON=1 script ~/bk.ts make buildkernel -j3
Script started on Fri Apr  7 11:52:38 2017
Command: time make buildkernel -j3
--- buildkernel ---
make[1]: "/usr/src/Makefile.inc1" line 146: SYSTEM_COMPILER: Determined that 
CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
--- buildkernel ---
--
>>> Kernel build for GENERIC started on Fri Apr  7 11:52:39 PDT 2017
--
===> GENERIC
mkdir -p /usr/obj/usr/src/sys
--
>>> stage 1: configuring the kernel
--
...
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/acpi_quirks.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/feeder_eq_gen.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/feeder_rate_gen.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/snd_fxdiv_gen.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/miidevs.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/pccarddevs.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/teken_state.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/usbdevs.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/vnode_if.h
Building /usr/obj/usr/obj/usr/src/sys/GENERIC/ia32_genassym.o
--- ia32_genassym.o ---
:1:10: fatal error: 'opt_global.h' file not found
#include "opt_global.h"
 ^~
1 error generated.
*** [ia32_genassym.o] Error code 1

make[2]: stopped in /usr/obj/usr/src/sys/GENERIC
.ERROR_TARGET='ia32_genassym.o'
.ERROR_META_FILE='/usr/obj/usr/obj/usr/src/sys/GENERIC/ia32_genassym.o.meta'


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: problem with ls, not show a correct list

[Ngie Cooper (yaneurabeya)]

> On Apr 6, 2017, at 22:15, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:
> 
> 
>> On Apr 6, 2017, at 21:28, Nilton José Rizzo <ri...@i805.com.br> wrote:
> 
> …
> 
>> [966] root@valfenda rizzo #locale
>> LANG=pt_BR.UTF-8
>> LC_CTYPE="pt_BR.UTF-8"
>> LC_COLLATE="pt_BR.UTF-8"
>> LC_TIME="pt_BR.UTF-8"
>> LC_NUMERIC="pt_BR.UTF-8"
>> LC_MONETARY="pt_BR.UTF-8"
>> LC_MESSAGES="pt_BR.UTF-8"
>> LC_ALL=
> 
>   I bet the fact that you’re using a non-ASCII-US locale is the reason 
> why you’re running into this. Could you please try the same thing with all of 
> these values unset.

I just saw your follow up email. Let me do some checking (in the meantime, 
please file a bug for this).
Thanks!
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: problem with ls, not show a correct list

[Ngie Cooper (yaneurabeya)]

> On Apr 6, 2017, at 21:28, Nilton José Rizzo  wrote:

…

> [966] root@valfenda rizzo #locale
> LANG=pt_BR.UTF-8
> LC_CTYPE="pt_BR.UTF-8"
> LC_COLLATE="pt_BR.UTF-8"
> LC_TIME="pt_BR.UTF-8"
> LC_NUMERIC="pt_BR.UTF-8"
> LC_MONETARY="pt_BR.UTF-8"
> LC_MESSAGES="pt_BR.UTF-8"
> LC_ALL=

I bet the fact that you’re using a non-ASCII-US locale is the reason 
why you’re running into this. Could you please try the same thing with all of 
these values unset?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: problem with ls, not show a correct list

[Ngie Cooper]

> On Apr 6, 2017, at 20:12, Nilton José Rizzo  wrote:
> 
>  Hi all 
> 
>  Look this command on a FreeBSD -current 
> 
> % ls -d /usr/ports/[a-z]*
> /usr/ports/accessibility /usr/ports/math
> /usr/ports/arabic /usr/ports/misc
> /usr/ports/archivers /usr/ports/Mk
> /usr/ports/astro /usr/ports/MOVED
> /usr/ports/audio /usr/ports/multimedia
> % echo /usr/ports/[a-z]*
> /usr/ports/accessibility /usr/ports/arabic /usr/ports/archivers
> /usr/ports/astro /usr/ports/audio /usr/ports/base /usr/ports/benchmarks
> /usr/ports/biology /usr/ports/cad /usr/ports/CHANGES /usr/ports/chinese
> /usr/ports/comms /usr/ports/CONT
> alguém sabe o motivo desse erro?
> % ls -d /usr/src/[a-z]*
> /usr/src/bin /usr/src/Makefile.libcompat
> /usr/src/cddl /usr/src/ObsoleteFiles.inc
> /usr/src/contrib /usr/src/README
> /usr/src/COPYRIGHT /usr/src/release 
> 
> What's I do wrong? 
> 
> % set 
> 
> addsuffix 
> anyerror 
> argv ()
> csubstnonl 
> cwd /home2/rizzo/src/repositorio/bsdday-2017
> dirstack /home2/rizzo/src/repositorio/bsdday-2017
> echo_style bsd
> edit 
> euid 1000
> euser rizzo
> gid 0
> group wheel
> history 100
> home /home2/rizzo
> killring 30
> loginsh 
> owd /home2/rizzo/src/repositorio/Rural
> path (/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin
> /home2/rizzo/bin)
> prompt %# 
> prompt2 %R? 
> prompt3 CORRECT>%R (y|n|e|a)? 
> shell /bin/csh
> shlvl 1
> status 0
> tcsh 6.18.01
> term screen
> tty pts/4
> uid 1000
> user rizzoversion tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-amd-FreeBSD)
> options wide,nls,dl,al,kan,sm,rh,color,filec
> % uname -a
> FreeBSD valfenda 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r313684: Sun Feb
> 12 20:52:19 BRST 2017 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64
> % 

Hi Nilton,
What's your locale set to and what's your filesystem?
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: increased power consumption lately?

[Ngie Cooper (yaneurabeya)]

> On Apr 5, 2017, at 10:39, Adrian Chadd  wrote:
> 
> hm, you could use dtrace to find what's calling that function and
> print out the call stack?

*does shrug* something like this (I realize it’s not printing out arg0 
— arg0 is a union that would need decoding)?
Thanks,
-Ngie

$ cat AcpiNsLookup.d
fbt:kernel:AcpiNsLookup:entry
{
printf("PathInfo: %s\nType: %d\nFlags: %u",
stringof(arg1), arg2, arg3);
}
$ sudo dtrace -s AcpiNsLookup.d


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: inetd startup script missing from /etc/rc.d in both -current and 11-stable

[Ngie Cooper (yaneurabeya)]

> On Apr 3, 2017, at 07:00, tech-lists  wrote:
> 
> Hello current@,
> 
> From https://www.freebsd.org/doc/handbook/network-inetd.html I should be
> able to start inetd like this:
> 
> service inetd start
> 
> ...after enabling it in /etc/rc.conf. The inetd options look like this:
> 
> inetd_enable="YES"
> inetd_program="/usr/sbin/inetd"
> inetd_flags="-wW -C 60"
> 
> The problem is that the startup script doesn't exist in /etc/rc.d. I get
> this error:
> 
> # service inetd start
> inetd does not exist in /etc/rc.d or the local startup
> directories (/usr/local/etc/rc.d), or is not executable
> 
> and the lines in rc.conf have no effect (inetd doesn't start).
> 
> I can, however, start it manually, as root, like this:
> 
> # inetd -wW -C 60
> 
> and it runs as expected.
> 
> This problem exists in 11-stable as well as -current. How can I fix this
> please?

Please double check your build options. If MK_INETD=no (WITHOUT_INETD=, 
typically) is set in src.conf, it won’t install this and other inetd-related 
items.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

[Ngie Cooper (yaneurabeya)]

> On Mar 29, 2017, at 01:26, Bruce Evans <b...@optusnet.com.au> wrote:
> 
> On Tue, 28 Mar 2017, Ngie Cooper wrote:
> 
>>> On Mar 28, 2017, at 21:40, Bruce Evans <b...@optusnet.com.au> wrote:
>>> 
>>>> On Wed, 29 Mar 2017, Bruce Evans wrote:
>>>> 
>>>>> On Wed, 29 Mar 2017, Andrey Chernov wrote:
>>>>> ...
>>>>> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode
>>>>> anymore - nothing happens. In the vt mode I can, but can't exit via "c"
>>>>> properly, all chars typed after "c" produce beep unless I switch to
>>>>> another screen and back.
>>>>> All it means that syscons becomes very broken now by itself and even
>>>>> damages the kernel operations.
> 
> I found a bug in screen resizing (the console context doesn't get resized).
> This doesn't cause any keyboard problems.
> 
>>>> ...
>>>> But I suspect it is a usb keyboard problem.  Syscons now does almost
>>>> correct locking for the screen, but not for the keyboard, and the usb
>>>> keyboard is especially fragile, especially in ddb mode.  Console input
>>>> is not used in normal operation except for checking for characters on
>>>> reboot.
>>>> 
>>>> Try using vt with syscons unconfigured.  Syscons shouldn't be used when
>>>> vt is selected, but unconfigure it to be sure.  vt has different bugs
>>>> using the usb keyboard.  I haven't tested usb keyboards recently.
>>> 
>>> ...
>>> I tested usb keyboards again.  They sometimes work, much the same as
>>> a few months ago after some fixes:
>>> ...
>>> 
>>> The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux.
>>> Other combinations and dynamic switching move the bugs around, and a
>>> serial console is needed to recover in cases where the bugs prevent any
>>> keyboard input.
>> 
>> I filed a bug a few years ago about USB keyboards and usability in ddb. If 
>> you increase the timeout so the USB hubs have enough time to probe/attach, 
>> they will work.
> 
> Is that for user mode or earlier?  ukb has some other fixes for ddb now, but
> of course it can't work before it finds the device.
> 
> I recently found that usb boot drives sometimes don't have enough time to
> probe/attach before they are used in mountroot, and the mount -a prompt
> does locking that doesn't allow them enough time if they are not ready
> before it.  The usb maintainers already know about this.

Ah, I misremembered my filing the bug — someone else did it: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133989 (it happens at 
mountroot, for example, because of probing order being what it is).
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

[Ngie Cooper]

> On Mar 28, 2017, at 21:40, Bruce Evans  wrote:
> 
>> On Wed, 29 Mar 2017, Bruce Evans wrote:
>> 
>>> On Wed, 29 Mar 2017, Andrey Chernov wrote:
>>> ...
>>> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode
>>> anymore - nothing happens. In the vt mode I can, but can't exit via "c"
>>> properly, all chars typed after "c" produce beep unless I switch to
>>> another screen and back.
>>> All it means that syscons becomes very broken now by itself and even
>>> damages the kernel operations.
>> 
>> ...
>> But I suspect it is a usb keyboard problem.  Syscons now does almost
>> correct locking for the screen, but not for the keyboard, and the usb
>> keyboard is especially fragile, especially in ddb mode.  Console input
>> is not used in normal operation except for checking for characters on
>> reboot.
>> 
>> Try using vt with syscons unconfigured.  Syscons shouldn't be used when
>> vt is selected, but unconfigure it to be sure.  vt has different bugs
>> using the usb keyboard.  I haven't tested usb keyboards recently.
> 
> I tested usb keyboards again.  They sometimes work, much the same as
> a few months ago after some fixes:
> - after booting with -d, they never work (give no input) at the ddb
>  prompt with either sc or vt.  usb is not initialized then, and no usb
>  keyboard is attached to sc or vt
> - after booting without loader with -a, sc rarely or never works (gives
>  no input) at the mountroot prompt
> - after booting with loader with -a, vt works at the mountroot prompt.
>  I don't normally use loader but need to use it to change the configuration.
>  This might be better than before.  There used to be a screen refresh bug.
> - after booting with loader with -a, sc works at the mountroot prompt too.
>  I previously debugged that vt worked better because it attaches the keyboard
>  before this point, while sc attaches it after.  Booting with loader
>  apparently fixes the order.
> - after any booting, sc works for user input (except sometimes after a
>  too-soft hard reset, the keyboard doesn't even work in the BIOS, and it
>  takes unplugging the keyboard to fix this)
> - after almost any booting, vt doesn't work for user input (gives no input).
>  However, if ddb is entered using a serial console, vt does work!  A few
>  months ago, normal input was fixed by configuring kbdmux (the default in
>  GENERIC).  It is not fixed by unplugging the keyboard.  kbdmux has a known
>  bug of not doing nested switching for the keyboard state.  Perhaps this
>  "fixes" ddb mode.  But I would have expected it to break ddb mode.
> - I didn't test sc after entering ddb, except early when it doesn't work.
> 
> The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux.
> Other combinations and dynamic switching move the bugs around, and a
> serial console is needed to recover in cases where the bugs prevent any
> keyboard input.

I filed a bug a few years ago about USB keyboards and usability in ddb. If you 
increase the timeout so the USB hubs have enough time to probe/attach, they 
will work.

I haven't taken the time to follow up on that and fix the issue, or at least 
propose a bit more functional workaround.

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

Re: shutdown -r doesn't execute rc.d sequence

[Ngie Cooper (yaneurabeya)]

> On Mar 28, 2017, at 14:27, Andrey Chernov  wrote:

…

>> Using rc_debug=yes I see that it is the kernel problem, not rc problem.
>> Sometimes rc backward sequence executed even fully, sometimes only
>> partly, but in unpredictable moment inside rc sequence the kernel decide
>> to reboot quickly (or even deadly hang in rare cases). Always without
>> any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal UFS,
>> no EFI, no GPT.
>> I change GELI swap to normal one, but it does not help. The same
>> untouched config works for years, I see this bug for the first time in
>> FreeBSD.
>> 
> 
> I forget to mention that typescript and dmesg does not survive after
> this reboot (or rare hang).

Good to note.
The simple explanation to the problem might be r307755, depending on when you 
last synced/built ^/head.

I have a few more questions (if reverting that doesn't pan out):
- What make/model of x86_64 are you running AMD (Bulldozer, etc) or Intel 
(Conroe/Nehalem/Westmere/Sandybridge/Haswell)?
- Is this a custom built machine? If so, what is your motherboard? If not, 
who’s the vendor?
- Is your system firmware up to date?
- What does your make.conf/src.conf look like?
- Are you running GENERIC or a custom kernel? If custom, could you please 
include the config somewhere?
- Are you loading any drivers in loader.conf?
- Are you using Linux emulation?
- Are you running any blob drivers, like nvidia?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: shutdown -r doesn't execute rc.d sequence

[Ngie Cooper (yaneurabeya)]

> On Mar 28, 2017, at 12:30, Andrey Chernov  wrote:
> 
> With latest -current amd64, reboot happens almost immediately, leaving
> FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence
> execution is shown. No deactivating GELI swap too.

Hi Andrey,
Do you have a typescript demonstrating this? Adding rc_debug=yes to 
/etc/rc.conf would be super helpful, along with `boot -v`, to see whether the 
issue is in userspace or rc(5).
I’ll double check my amd64/i386 VMs too (if possible, redirect the 
output over serial to a typescript for analysis).
Are you using vanilla FreeBSD, a fork, or a packaged variant (mfsbsd, 
nanobsd, etc)?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 2:19 PM, Bryan Drewery  wrote:
> 
> On 3/15/2017 2:10 PM, Bryan Drewery wrote:
>> On 3/15/2017 11:23 AM, David Wolfskill wrote:
>>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
 ...
 So where is /common/S4/obj coming from?
 
 Is there a symlink involved here for /usr/obj?
 
>>> 
>>> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
>>> a couple of decades, now
>> 
>> Ok, I don't think the symlink is the problem.  It's just the meta mode
>> handling forcing a realpath(3) on some of the output which causes the
>> confusion.
>> 
>> Still looking...
>> 
>> 
> 
> This should fix it: https://svnweb.freebsd.org/changeset/base/315332 
> 

Yeah, that would do it >_>…
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:24, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:
> 
> 
>> On Mar 15, 2017, at 11:23, David Wolfskill <da...@catwhisker.org> wrote:
>> 
>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
>>> ...
>>> So where is /common/S4/obj coming from?
>>> 
>>> Is there a symlink involved here for /usr/obj?
>>> 
>> 
>> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
>> a couple of decades, now
> 
> What happens if you revert r314808 and r315088 (the bmake-20170301 upgrade 
> and supporting commit)?

Alternatively, could you please revert just r313650 in another branch/workspace 
(I wonder if changing from .OBJDIR to OBJTOP had some unintended consequences 
that unrooted issues with how bmake evaluates paths)?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:23, David Wolfskill  wrote:
> 
> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
>> ...
>> So where is /common/S4/obj coming from?
>> 
>> Is there a symlink involved here for /usr/obj?
>> 
> 
> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
> a couple of decades, now

What happens if you revert r314808 and r315088 (the bmake-20170301 upgrade and 
supporting commit)?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:09, Bryan Drewery  wrote:
> 
> On 3/15/2017 10:04 AM, David Wolfskill wrote:
> 
>> --
> stage 1.1: legacy release compatibility shims
>> --
>> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp
> 
> Ok it is trying to use MAKEOBJDIRPREFIX=/usr/obj
> 
>> Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui
> 
> But all of the 'Building' lines are tryign to use
> MAKEOBJDIRPREFIX=/common/S4/obj/ ...
> 
>> --- all_subdir_cddl ---
>> --- all_subdir_cddl/usr.bin ---
>> --- all_subdir_cddl/usr.bin/zinject ---
>> ===> cddl/usr.bin/zinject (all)
>> --- all_subdir_gnu ---
>> --- gdbtui ---
>> cc: error: no such file or directory: 
>> '/usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a'
> 
> But then complains about a missing file in MAKEOBJDIRPREFIX=/usr/obj
> 
>> *** [gdbtui] Error code 1
>> 
>> bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui
>> .ERROR_TARGET='gdbtui'
>> .ERROR_META_FILE='/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui.meta'
>> .MAKE.LEVEL='6'
>> MAKEFILE=''
>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
>> .CURDIR='/usr/src/gnu/usr.bin/gdb/gdbtui'
>> .MAKE='/usr/obj/usr/src/make.amd64/bmake'
> ...
>> .OBJDIR='/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui'
> 
> And says here that there is an existing directory for
> MAKEOBJDIRPREFIX=/usr/obj for /usr/src/gnu/usr.bin/gdb/gdbtui, which is
> throwing off its paths for libbfd.a.
> 
> ...
>> MAKEOBJDIRPREFIX='/usr/obj'
> 
> And the meta error agrees it wants MAKEOBJDIRPREFIX=/usr/obj
> 
> 
> So where is /common/S4/obj coming from?
> 
> Is there a symlink involved here for /usr/obj?

^/head@r315175 doesn’t look like it’s causing a problem here. I don’t 
think my commit here recently (^/head@r313650) was a problem, but I wonder if 
it exposed a race or incomplete dependency logic…
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: buildworld error

[Ngie Cooper (yaneurabeya)]

> On Mar 11, 2017, at 18:24, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:

Hi Roberto,
The sbin/setkey issue should be resolved by r315181. Thank you for the 
report!
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX

[Ngie Cooper (yaneurabeya)]

> On Mar 11, 2017, at 18:27, Lawrence Stewart  wrote:
> 
> Hi Ian,

…

>> The MAKEOBJDIRPREFIX variable must be set in the environment, not in
>> make.conf or on the make command line (documented in build(7)).
> 
> Your assertion seems at odds with my past experience and my reading of
> the man page... from build(7):
> 
>   The build may be controlled by defining make(1) variables
>   described in the ENVIRONMENT section below, and by the
>   variables documented in make.conf(5).
> 
> ... which indicates they are make variables, not environment variables
> specifically. As a concrete example, TARGET and DESTDIR are listed under
> the "ENVIRONMENT" section of the man page, yet "EXAMPLES" shows:
> 
>   make TARGET=sparc64 buildworld
>   make TARGET=sparc64 DESTDIR=/clients/sparc64 installworld
> 
> I've certainly always set build vars documented in the "ENVIRONMENT"
> section of the man page on the make command line without issue. Pretty
> sure I've set MAKEOBJDIRPREFIX from the make command line also in the
> past, though perhaps it has been working for me "by accident" and a
> documentation tweak is in order if the distinction you make is in fact
> relevant...

Hi Lawrence,

Ian’s right per historical behavior, which should still be in effect today.

Unfortunately, setting MAKEOBJDIRPREFIX on the command line will result in bad 
things happening because of how bsd.obj.mk works and how MAKEOBJDIRPREFIX is 
manipulated in the build itself (see Makefile.libcompat — it affects some 
architectures, but maybe not sparc64). From …/Makefile (which should have 
triggered this error message to begin with):

171 MAKEOBJDIRPREFIX?=  /usr/obj
172 _MAKEOBJDIRPREFIX!= /usr/bin/env -i PATH=${PATH} MK_AUTO_OBJ=no ${MAKE} \
173 ${.MAKEFLAGS:MMAKEOBJDIRPREFIX=*} __MAKE_CONF=${__MAKE_CONF} \
174 -f /dev/null -V MAKEOBJDIRPREFIX dummy
175 .if !empty(_MAKEOBJDIRPREFIX)
176 .error MAKEOBJDIRPREFIX can only be set in environment, not as a global\
177 (in make.conf(5)) or command-line variable.
178 .endif

Are you sure your script/process didn’t catch a relevant build error?

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: buildworld error

[Ngie Cooper (yaneurabeya)]

> On Mar 11, 2017, at 15:51, Roberto Rodriguez Jr  
> wrote:
> 
> I figured the script command... here is the new error r315090
> 
> --- .depend ---
> echo setkey.full: /usr/obj/usr/src/tmp/usr/lib/libc.a
> /usr/obj/usr/src/tmp/usr/lib/libl.a
> /usr/obj/usr/src/tmp/usr/lib/liby.a
> /usr/obj/usr/src/tmp/usr/lib/libipsec.a >> .depend
> --- setkey.o ---
> /usr/local/libexec/ccache/cc  -O2 -pipe -march=btver2
> -I/usr/src/sbin/setkey -I/usr/src/lib/libipsec -I/usr/src/lib/libipsec
> -I/usr/src/sys/netipsec -DIPSEC_DEBUG -DYY_NO_UNPUT -DINET6 -I. -g -MD
> -MF.depend.setkey.o -MTsetkey.o -std=gnu99 -fstack-protector-strong
> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter
> -Wno-parentheses  -Qunused-arguments  -c /usr/src/sbin/setkey/setkey.c
> -o setkey.o
> --- all_subdir_lib ---
> --- jemalloc_nstime.po ---
> /usr/local/libexec/ccache/cc -pg  -O2 -pipe -march=btver2
> -I/usr/src/lib/libc/include -I/usr/src/include
> -I/usr/src/lib/libc/amd64 -DNLS  -D__DBINTERFACE_PRIVATE
> -I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6
> -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE
> -DPOSIX_MISTAKE -I/usr/src/lib/libmd
> -I/usr/src/contrib/jemalloc/include -I/usr/src/contrib/tzcode/stdtime
> -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES
> -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP
> -DNS_CACHING -DSYMBOL_VERSIONING -MD  -MF.depend.jemalloc_nstime.po
> -MTjemalloc_nstime.po -std=gnu99 -fstack-protector-strong
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter  -Qunused-arguments
> -I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64
> -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c jemalloc_nstime.c
> -o jemalloc_nstime.po
> --- all_subdir_rescue ---
> --- suffix.o ---
> /usr/local/libexec/ccache/cc  -O2 -pipe -DHAVE_CONFIG_H
> -I/usr/src/usr.bin/xz/../../lib/liblzma
> -I/usr/src/usr.bin/xz/../../contrib/xz/src/common -march=btver2
> -DRESCUE -MD  -MF.depend.suffix.o -MTsuffix.o -std=gnu99
> -fstack-protector-strong -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> -Wno-unused-local-typedef  -Qunused-arguments  -c
> /usr/src/usr.bin/xz/../../contrib/xz/src/xz/suffix.c -o suffix.o
> --- all_subdir_sbin ---
> /usr/src/sbin/setkey/setkey.c:154:15: error: use of undeclared
> identifier 'IPSEC_POLICYSCOPE_GLOBAL'
>f_scope |= IPSEC_POLICYSCOPE_GLOBAL;
>   ^
> /usr/src/sbin/setkey/setkey.c:157:15: error: use of undeclared
> identifier 'IPSEC_POLICYSCOPE_IFNET'
>f_scope |= IPSEC_POLICYSCOPE_IFNET;
>   ^

Some new symbols were added to sys/netipsec/… and unfortunately the system 
headers don’t provide that symbol.

This should fix the issue — I’ll run the change through make tinderbox before 
committing, then analyze the .depend files, just to make sure it's 
bootstrapping properly.

Thanks!
-Ngie

$ svn diff Makefile
Index: Makefile
===
--- Makefile(revision 315094)
+++ Makefile(working copy)
@@ -46,7 +46,7 @@
 # ipsec_strerror.c is for avoiding shlib reference to non-exported function.
 .PATH: ${SRCTOP}/lib/libipsec ${SRCTOP}/sys/netipsec
 SRCS+= pfkey.c pfkey_dump.c key_debug.c ipsec_strerror.c
-CFLAGS+= -I${SRCTOP}/sys/netipsec
+CFLAGS+= -I${SRCTOP}/sys

 SRCS+= y.tab.h
 y.tab.h: parse.y



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Building Current

[Ngie Cooper]

> On Mar 4, 2017, at 13:19, Roberto Rodriguez Jr  wrote:
> 
> Would make -DNO_CLEAN=NO also/maybe help as well?

Remove =NO from your invocation above. That would define a variable as: 
${NO_CLEAN=NO}=1
HTH,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build Fail: -CURRENT

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 11:50, Larry Rosenman  wrote:
> 
> --- all_subdir_usr.sbin/amd ---
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x13e): undefined reference 
> to `xdr_symlinkargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x14c): undefined reference 
> to `xdr_diropres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x151): undefined reference 
> to `xdr_createargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x15f): undefined reference 
> to `xdr_nfsstat'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x164): undefined reference 
> to `xdr_diropargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x172): undefined reference 
> to `xdr_readdirres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x177): undefined reference 
> to `xdr_readdirargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x185): undefined reference 
> to `xdr_statfsres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18a): undefined reference 
> to `xdr_nfs_fh'
> 
> stubs.o: In function `nfsproc_readlink_2_svc':
> 
> /usr/src/contrib/amd/hlfsd/stubs.c:356: undefined reference to 
> `xdr_readlinkres'
> 
> --- all_subdir_rescue ---
> 
> Building /usr/obj/usr/src/rescue/rescue/usr/src/sbin/ipf/ipf/printlookup.o
> 
> --- all_subdir_usr.sbin ---
> 
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> *** [hlfsd.full] Error code 1

Fixed in r314676. Apologies for the breakage :(…
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 12:12, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:
> 
> 
>> On Mar 4, 2017, at 09:33, Michael Butler <i...@protected-networks.net> wrote:
>> 
>> Seems that SVN r314659 broke this :-(
>> 
>>  Michael
> 
> Working on it :(.
> -Ngie

Fixed in r314676. Apologies for the breakage :(…
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 09:33, Michael Butler  wrote:
> 
> Seems that SVN r314659 broke this :-(
> 
>   Michael

Working on it :(.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Boot failure - svn up from this morning

[Ngie Cooper (yaneurabeya)]

> On Mar 2, 2017, at 21:16, Chris H  wrote:
> 
> On Thu, 2 Mar 2017 21:56:38 -0500 (EST) AN  wrote
> 
>> Hi:
>> 
>> I'm having a major problem after updating a 12-current machine today.
>> After buildworld/kernel/install cycle on reboot I'm getting the following
>> failure:
>> 
>> "/boot/kernel/kernel text=0xb7716f data=0x100548+0x398358
>> elf64_loadimage: read failed
>> can't load file '/boot/kernel/kernel': input/output error
>> can't load file '/boot/kernel/kernel': input/output error
>> 
>> OK boot kernel.old
>> elf64_loadimage: read failed
>> can't load file '/boot/kernel.old/kernel': input/output error
>> can't load file '/boot/kernel.old/kernel': input/output error"
>> 
>> I have never experienced this failure before, and don't know how to
>> proceed.  Any help recovering from this would be greatly appreciated.
>> Thanks in advance.
> 
> I don't suppose you could post the output of
> uname -a
> 
> and maybe a copy of dmesg(8) could you?

That would be good, but I don’t know if it’s possible (the OP is noting that 
the boot is broken when executing loader(8)..).
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: effect of strip(1) on du(1)

[Ngie Cooper]

On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes
 wrote:
...
> Even if that is the case file system cache effects should NOT be
> visible to a userland process.   This is NOT as if your running
> 2 different processing beating on a file.  Your test cases are
> serialially syncronous shell invoked commands seperated with
> && the results should be exact and predictable.
>
> When strip returns the operation from the userland perspecive
> is completed and any and all processeses started after that
> should have the view of the completed strip command.
>
> This IS a bug.

Would the same statement necessarily apply if the filesystem was
writing things asynchronously to the backing storage?
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Buildworld fails if WITHOUT_INET6=YES defined

[Ngie Cooper]

On Thu, Mar 2, 2017 at 11:40 AM, Alex Deiter  wrote:
> Hello,
>
> Please apply patch from upstream:
>
> https://github.com/the-tcpdump-group/libpcap/pull/541
>
> Fix compilation if INET6 isn't defined.
> Addresses GitHub issue #541, but differently from the pull request (it
> defines gen_gateway() with a function prototype rather than using a
> pre-prototype-style definition).
>
> https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390df7448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2

Hi Dieter,
Could you please open a bug and CC glebius@ and myself on it?
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Possible overlooked "svn add" in r314192?

[Ngie Cooper]

> On Feb 24, 2017, at 05:39, David Wolfskill  wrote:
> 
> Updating head in place from r314136 -> r314200, I find I can't build the
> kernel because:
> 
> ...
> ===> iwifw/iwi_ibss (all)
> --- all_subdir_iwifw/iwi_monitor ---
> ===> iwifw/iwi_monitor (all)
> --- all_subdir_ipmi ---
> --- all_subdir_ipmi/ipmi_linux ---
> ===> ipmi/ipmi_linux (all)
> --- all_subdir_iwm ---
> bmake[4]: bmake[4]: don't know how to make if_iwm_fw.c. Stop

CCes Adrian.
___
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: Buildworld fails if WITHOUT_INET6=YES defined

[Ngie Cooper (yaneurabeya)]

> On Feb 17, 2017, at 13:09, Bryan Drewery  wrote:

…

> Ignore me, my yacc is just outdated.

I’ll try again. This might have been part of my issue too.
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: xdev fixed

[Ngie Cooper (yaneurabeya)]

> On Feb 17, 2017, at 16:13, Bryan Drewery  wrote:
> 
> The issue reported here:
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-June/014065.html
> 
>> make XDEV=arm XDEV_ARCH=armv6 xdev
>> 
>> It failed!
>> 
>> sh /usr/src/tools/install.sh  -C -o root -g wheel -m 444  
>> /usr/src/gnu/lib/libdialog/../../../contrib/dialog/dialog.h 
>> /usr/src/gnu/lib/libdialog/../../../contrib/dialog/dlg_colors.h 
>> /usr/src/gnu/lib/libdialog/dlg_config.h 
>> /usr/src/gnu/lib/libdialog/../../../contrib/dialog/dlg_keys.h 
>> //usr/armv6-freebsd/usr/include/
>> ===> lib/libc++ (obj,all,install)
>> /usr/obj/armv6-freebsd/usr/src/lib/libc++ created for /usr/src/lib/libc++
>> echo libc++.so.1.full: //usr/armv6-freebsd/usr/lib/libcxxrt.a >> .depend
>> c++ -isystem //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib  
>> --sysroot=//usr/armv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec  
>> -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib -mlong-calls -O 
>> -pipe -isystem /usr/src/lib/libc++/../../contrib/libc++/include -isystem 
>> /usr/src/lib/libc++/../../contrib/libcxxrt -nostdinc++ -nostdlib -DLIBCXXRT 
>> -MD -MF.depend.algorithm.o -MTalgorithm.o -Qunused-arguments  -std=c++11 
>> -Wno-c++11-extensions  -c 
>> /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp -o algorithm.o
>> In file included from 
>> /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10:
>> In file included from 
>> /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:624:
>> In file included from 
>> /usr/src/lib/libc++/../../contrib/libc++/include/initializer_list:47:
>> /usr/src/lib/libc++/../../contrib/libc++/include/cstddef:43:15: fatal error:
>>  'stddef.h' file not found
>> #include_next 
>>  ^
>> 1 error generated.
>> *** Error code 1
> 
> 
> This should now be fixed in head as of r313907.  Sorry for the long
> delay on it.  It likely came about due to the libc++ upgrade around
> r300873 in May 2016.  I will MFC the fix to stable/11 once I get more
> feedback or in 2 weeks otherwise.

*does a happy dance*
Thanks so much :)!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Buildworld fails if WITHOUT_INET6=YES defined

[Ngie Cooper (yaneurabeya)]

> On Feb 16, 2017, at 07:30, Oleg V. Nauman  wrote:
> 
> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
> B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=core2  -DHAVE_CONFIG_H -
> I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
> D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
> MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong -Wno-
> pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -
> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
> arguments  -c /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
> B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=core2  -DHAVE_CONFIG_H -
> I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
> D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
> MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -Wno-
> pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -
> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
> unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
> arguments  -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
> /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in
> 'struct _compiler_state'
>cstate.ai = NULL;
>~~ ^
> /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
> identifier 'cstate'
>bpf_error(cstate, "direction applied to 'gateway'");
>  ^
> /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
> identifier 'cstate'
>switch (cstate->linktype) {
>^
> /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
> identifier 'cstate'
>b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
> Q_HOST);
>  ^
> /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
> identifier 'cstate'
>tmp = gen_host(cstate, **alist++, 0x, proto,
> Q_OR,
>   ^
> /usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared
> identifier 'cstate'
>bpf_error(cstate, "illegal modifier of 'gateway'");
>  ^
> 6 errors generated.
> *** Error code 1
> 
> Stop.
> make[5]: stopped in /usr/src/lib/libpcap
> *** Error code 1

CCing Xin, who did the libpcap upgrade.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r313495 make perl File::Temp broken

[Ngie Cooper (yaneurabeya)]

> On Feb 10, 2017, at 05:55, Iblis Lin  wrote:
> 
> I just found i miss-typed the revision number in subject.
> It's r313495.
> 
> (https://svnweb.freebsd.org/base/head/sys/kern/vfs_vnops.c?r1=313495=313494=313495)
> 
> On Fri, Feb 10, 2017 at 09:09:52PM +0800, Iblis Lin wrote:
>> Hi,
>> 
>> as not a perl programmer myself. I have no idea what is going on.
>> I found this issue while compiling math/openblas.
>> 
>> [iblis@ns]% uname -a
>> FreeBSD ns 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r313500: Fri Feb 10 16:39:21
>> CST 2017 root@ns:/usr/obj/usr/src/sys/GENERIC  amd64
>> 
>> [iblis@ns]% cat test.pl
>> use File::Temp qw(tempfile);
>> $tmpf = new File::Temp( UNLINK => 1 );
>> 
>> [iblis@ns]% perl test.pl
>> Error in tempfile() using template /tmp/XX: Could not create temp 
>> file
>> /tmp/dI5uhUsijR: Bad file descriptor at test.pl line 2.
>> 
>> 
>> And part of truss's output:
>> 
>> close(3) = 0 (0x0)
>> stat("/tmp/",{ mode=drwxrwxrwt ,inode=24317568,size=1024,blksize=32768 }) = 
>> 0 (0x0)
>> stat("/tmp/",{ mode=drwxrwxrwt ,inode=24317568,size=1024,blksize=32768 }) = 
>> 0 (0x0)
>> openat(AT_FDCWD,"/tmp/Nn0Epra5ff",O_RDWR|O_EXLOCK|O_NOFOLLOW|O_CREAT|O_EXCL,0600)
>>  ERR#9 'Bad file descriptor'
>> stat("/usr/share/nls/C/libc.cat",0x7fffdcf8) ERR#2 'No such file or 
>> directory'
>> stat("/usr/share/nls/libc/C",0x7fffdcf8) ERR#2 'No such file or 
>> directory'
>> stat("/usr/local/share/nls/C/libc.cat",0x7fffdcf8) ERR#2 'No such file 
>> or directory'
>> stat("/usr/local/share/nls/libc/C",0x7fffdcf8) ERR#2 'No such file or 
>> directory'
>> Error in tempfile() using template /tmp/XX: Could not create temp 
>> file /tmp/Nn0Epra5ff: Bad file descriptor at test.pl line 2.
>> write(2,"Error in tempfile() using templa"...,135) = 135 (0x87)

Hi,
kib@ has a patch out for another related issue that was reported with 
dhclient — please give his patch a shot: 
https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064780.html .
Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 'Protocol not supported' on linux socket call ( r313313 amd64 )

[Ngie Cooper]

> On Feb 8, 2017, at 07:44, Oleg V. Nauman  wrote:
> 
> After upgrading of current on amd64 box to r313313 I noticed that skype has 
> stopped working.
> Below is the end of 'truss' output for skype:
> 
> 36723: linux_socketcall(1,{ LINUX_SOCKET, 0x0 }) ERR#-93 'Protocol not 
> supported'
> 36723: write(6,"@",1) = 1 (0x1)
> 36723: close(6)= 0 (0x0)
> 36723: close(5)= 0 (0x0)
> 36723: linux_rt_sigaction(0x11,0xbaf8,0xba6c,0x8) = 0 (0x0)
> 36723: linux_exit_group(0x1)
> 36723: process exit, rval = 1
> 
> My second current box ( r313090 i386 ) runs skype successfully.

Hi,
Please try reverting r312988.
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 1:03 PM, Ngie Cooper <yaneurab...@gmail.com> wrote:
> On Sat, Jan 28, 2017 at 12:17 PM, Ngie Cooper <yaneurab...@gmail.com> wrote:
> ...
>
>> After some creative hacking... tada!
>>
>> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
>> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
>> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
>> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
>> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
>
> Bah. It's still 2kB too big. I'll see if I can free up some more space
> in the text area (there was a patch kicking around at $work that might
> alleviate this a few more kB).

Ok, found the patch.

After applying all the changes, it's finally under 44kB and I can
write the bootcode to my disk:

$ sudo gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
partcode written to da0p1
bootcode written to da0

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 12:17 PM, Ngie Cooper <yaneurab...@gmail.com> wrote:
...

> After some creative hacking... tada!
>
> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

Bah. It's still 2kB too big. I'll see if I can free up some more space
in the text area (there was a patch kicking around at $work that might
alleviate this a few more kB).
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 12:21 PM, Allan Jude  wrote:

...

> The 'zfsboot' version, is dd's into the zfs boot code area. It is read
> by the assembly code there. It is important the file be the size that
> will be read, so it is padded out. That file is currently only used for
> MBR booting from ZFS.

Thank you for the info -- it would be really nice if this was noted in
the Makefile in more detail for the next soul who wonders why the
sizes are so different.
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 11:22 AM, Ngie Cooper <yaneurab...@gmail.com> wrote:
>> What created a partition that small?
>
> Me.
>
> gpart up until last summer said that users should create 44kB
> freebsd-boot partitions -- des@ corrected that in r303289:
>
> -This example uses 88 blocks (44 kB) so the next partition will be
> -aligned on a 64 kB boundary without the need to specify an explicit
> -offset or alignment.
> -The boot partition itself is aligned on a 4 kB boundary.
> +We create a 472-block (236 kB) boot partition at offset 40, which is
> +the size of the partition table (34 blocks or 17 kB) rounded up to the
> +nearest 4 kB boundary.
>  .Bd -literal -offset indent
> -/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
> +/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0

After some creative hacking... tada!

# find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
-rw-r--r--  1 root  wheel  131584 Jan 28 12:07
/usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
-rw-r--r--  1 root  wheel  47527 Jan 28 12:07
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

-- wait, why is the size of zfsboot vs gptzfsboot so different? Oh,
r304321 added that as `BOOT2SIZE`. Still, it seems a bit silly to only
increase the size of one bootloader and not the other 4 instances of
the bootloader :/. I don't understand the point in the size
restriction 100%, but I'll leave it be.

Patch will be available sometime next week if my testing goes well.

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> What created a partition that small?

Me.

gpart up until last summer said that users should create 44kB
freebsd-boot partitions -- des@ corrected that in r303289:

-This example uses 88 blocks (44 kB) so the next partition will be
-aligned on a 64 kB boundary without the need to specify an explicit
-offset or alignment.
-The boot partition itself is aligned on a 4 kB boundary.
+We create a 472-block (236 kB) boot partition at offset 40, which is
+the size of the partition table (34 blocks or 17 kB) rounded up to the
+nearest 4 kB boundary.
 .Bd -literal -offset indent
-/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
+/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude <allanj...@freebsd.org> wrote:
> On 2017-01-28 13:56, Ngie Cooper wrote:
>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh <i...@bsdimp.com> wrote:
>>
>> ...
>>
>>> So? It literally doesn't matter where the freebsd-boot partition
>>> lives, or what it's number is. You can put it at the start or end of
>>> the swap partition after adjusting its size. I've done this on several
>>> systems...  NanoBSD plays games with this stuff as well to be bootable
>>> on old / new systems.
>>
>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>> support large disks properly.
>>
>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>> need to make backups of my workstation so I don't lose anything
>> critical.
>
> Did gptzfsboot not fall below 64kb when you used the
> LOADER_NO_GELI_SUPPORT knob?

It did, but unfortunately that's still way too small for my
freebsd-boot partition (which apparently is only 44kB large :/..):

Before:

$ ls -l `make -V.OBJDIR`/gptzfsboot
-rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

After:

$ ls -l `make -V.OBJDIR`/gptzfsboot
-rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

Time to do some more tricks to pare down the bootloader size.

Sidenote to the folks who drive the release notes and upgrade
instructions for FreeBSD 12.x -- it needs to be clearly explained that
gptzfsboot has grown considerably in size and mitigation instructions
should be provided for updating gptzfsboot -- in particular with folks
who might be using freebsd-update, so don't have the luxury of the
choice of bootloader build options when upgrading.

Thanks,
-Ngie

$ gpart list da0
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 250069646
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
   Mediasize: 45056 (44K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: (null)
   length: 45056
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 127
   start: 40
2. Name: da0p2
   Mediasize: 128035593728 (119G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 65536
   Mode: r1w1e1
   rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 128035593728
   offset: 65536
   type: freebsd-zfs
   index: 2
   end: 250069646
   start: 128
Consumers:
1. Name: da0
   Mediasize: 128035676160 (119G)
   Sectorsize: 512
   Mode: r1w1e2
___
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: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:

...

> So? It literally doesn't matter where the freebsd-boot partition
> lives, or what it's number is. You can put it at the start or end of
> the swap partition after adjusting its size. I've done this on several
> systems...  NanoBSD plays games with this stuff as well to be bootable
> on old / new systems.

True. Hopefully my BIOS/disk controller isn't dumb enough to not
support large disks properly.

*sigh* Unfortunately, in my infinity cleverness I only put 2
partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
need to make backups of my workstation so I don't lose anything
critical.

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> On Jan 27, 2017, at 12:23, Toomas Soome  wrote:

...

>> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before 
>> the swap partition.
>> 
>> We have a similar problem at work with sys/boot unfortunately, but that's a 
>> side discussion for another time/place.
>> 
>> Thank you for the idea though -- I'll check when I get back to work.
>> 
>> -Ngie
> 
> Note the order of the partitions is not important, at least on paper anyhow. 
> Of course there are preferences in sense that it does look nice if 
> freebsd-boot is in front. Also, if you do have mirror setup, it is some work, 
> but you can re-arrange mirror side partitioning (with usual cautions like 
> having scrub done, having backup, having third disk would be helpful).

I have a raidz with 3 SSDs on it IIRC. Removing the SSD from the pool and 
readjusting partitions would probably be ok, but I'm not really keen on doing 
potentially destructive things like that, unless I absolutely have to do them 
:/..

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> On Jan 27, 2017, at 09:05, Warner Losh  wrote:

...

> I'm curious why you can't find the space for a bigger partition?
> Almost all drives these days are partitioned with a little wasted
> space, and that wasted space should be more than enough to cover us
> here. Also, most drives have a swap partition that can be shrunk a
> trivial amount to get space for this...

Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before the 
swap partition.

We have a similar problem at work with sys/boot unfortunately, but that's a 
side discussion for another time/place.

Thank you for the idea though -- I'll check when I get back to work.

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

gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper (yaneurabeya)]

Hi,
I tried upgrading one of my workstations and unfortunately the 
freebsd-boot partition is too small (I follow manpage directions, exactly, and 
those seem to be too small as of 10.3-RELEASE timeframe), and I don’t have 
enough space or ability to resize the partition and make it bigger. So, I’m in 
need of a build knob to control the bloat, and/or having an alternative boot 
loader without geli/skein/crypto support compiled in. Would you be opposed to 
the work?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r312348: igb broken: reporting wrong linkspeed!

[Ngie Cooper]

> On Jan 17, 2017, at 11:54, Hartmann, O.  wrote:
> 
> 12-CURRENT (FreeBSD 12.0-CURRENT #74 r312348: Tue Jan 17 19:54:58 CET
> 2017 am64) reports the wrong linkspeed on a dualport Intel i350 NIC:
> 
> igb0: flags=8843 metric 0 mtu
> 1500
> options=653dbb
> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xff00 broadcast
> 192.168.0.255 nd6 options=29
>media: Ethernet autoselect (100baseTX )
>status: active
> 
> The swith the NIC is connected to reports 1 GBit. I checked with two
> switches, FreeBSD reports bullshit on that subject.
> 
> I also realised severe problems of this Intel i350 dual NIC cards with
> FreeBSD (we use this NIC type as a standard and so we have plenty, all
> with the same issue). When the NIC negotiates its linkspeed, it very
> often fall back to 100 MBit. This behaviour is not predictable, but it
> occurs with a SoHo smart managed Netgear GS110TBv2 and some of our
> Cisco Catalyst switches at work (some 35XX and 29XX, I do not know the
> exact type).

Hi,
One of the workarounds for igb wasn't ported to the new driver--I remember 
an issue like this being solved sometime in the 2015-2016 timeframe (I'm 
leaning towards 2016).
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: recent change to vim defaults?

[Ngie Cooper]

> On Jan 15, 2017, at 08:03, Julian Elischer  wrote:
> 
> I noticed that suddenly vim is grabbing mouse movements, which makes life 
> really hard.
> 
> Was there a specific revision that brought in this change, and can it be 
> removed?

"set mouse=" will disable the feature you're describing.
-Ngie

PS I find the new feature incredibly annoying and disable it on all FreeBSD 
clients where I install vim.
___
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 #4653 - Failure

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 18:18, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD_i386 - Build #4653 - Failure:
> 
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/changes
> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/console
> 
> Change summaries:
> 
> 312104 by cem:
> Fix broken fstyp exfat testcase
> 
> Introduced in r312010.
> 
> It helps to read the documentation before trying to test something.
> 
> 312103 by cem:
> Revert r310994
> 
> Don't implement some terrible hack on a test by test basis.  The
> framework fix is straightforward and can be chased up in the original
> bug.
> 
> Reviewed by:  ngie ("be my guest")
> 
> 312102 by ngie:
> Note that sys/types.h is required on FreeBSD for kqueue(2), unlike NetBSD
> 
> MFC after:12 days
> X-MFC with:   r305358
> Sponsored by: Dell EMC Isilon

Broken by r312103.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 14:48, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:
> 
> 
>> On Jan 13, 2017, at 12:23, Eric Joyner <e...@freebsd.org> wrote:
>> 
>> ^ Message ^
>> 
>> It takes forever, but I keep on forgetting to time how long it takes, so I
>> don't know how long "forever" is.
> 
> Using -DNO_CLEAN on my 12.0-CURRENT / amd64 / 3GB RAM / 3 cores / VMware 
> Fusion + open-vmtools VM…
> - … buildworld with special baked WITHOUT/MK options in src.conf: 26 mins
> - …. buildkernel of GENERIC/GENERIC-NODEBUG with stripped src.conf and 
> MODULES_OVERRIDE: 14 minutes
> 
> Overall time: 40 minutes
> 
> Granted, I’m pretty up-to-date (just upgrading a few hundred revs at a time), 
> but a from-scratch build on more ample Sandybridge/Haswell hardware with SSDs 
> shouldn’t take any longer than 30 mins (if you optimize things heavily, it 
> can be less than that).
> 
> If you need a beefy box to play with for building en masse (since you’re a 
> FreeBSD dev), try the universe*.freebsd.org boxes.

Important note: unless I have a good reason to test out GENERIC, I always used 
GENERIC-NODEBUG, so needless to say witness and other debug bits don’t add time 
to my build.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 12:23, Eric Joyner  wrote:
> 
> ^ Message ^
> 
> It takes forever, but I keep on forgetting to time how long it takes, so I
> don't know how long "forever" is.

Using -DNO_CLEAN on my 12.0-CURRENT / amd64 / 3GB RAM / 3 cores / VMware Fusion 
+ open-vmtools VM…
- … buildworld with special baked WITHOUT/MK options in src.conf: 26 mins
- …. buildkernel of GENERIC/GENERIC-NODEBUG with stripped src.conf and 
MODULES_OVERRIDE: 14 minutes

Overall time: 40 minutes

Granted, I’m pretty up-to-date (just upgrading a few hundred revs at a time), 
but a from-scratch build on more ample Sandybridge/Haswell hardware with SSDs 
shouldn’t take any longer than 30 mins (if you optimize things heavily, it can 
be less than that).

If you need a beefy box to play with for building en masse (since you’re a 
FreeBSD dev), try the universe*.freebsd.org boxes.

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: powerpc.LINT* broken in netmap(4)

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 02:22, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> wrote:
> 
> Hi,
>   I spotted these compilation errors on universe12a.freebsd.org for both 
> powerpc.LINT and powerpc.LINT64:
> 
> cc1: warnings being treated as errors
> /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function 
> 'generic_set_tx_event':
> /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the 
> address of 'generic_mbuf_destructor' will always evaluate as 'true' 
> [-Waddress]
> --- netmap_generic.o ---
> *** [netmap_generic.o] Error code 1
> 
>   I haven’t yet dug into why this only surfaces on powerpc, yet…

(CC -powerpc; BCC +powerpc)
Hi,
sparc64 has the same issue as powerpc*, so I suspect that gcc is 
flagging this as an issue.
Thanks,
-Ngie

PS. Sidenote: why was the SET_MBUF_DESTRUCTOR macro added, but not used in 
nm_os_get_mbuf ?


signature.asc
Description: Message signed with OpenPGP using GPGMail

powerpc.LINT* broken in netmap(4)

[Ngie Cooper (yaneurabeya)]

Hi,
I spotted these compilation errors on universe12a.freebsd.org for both 
powerpc.LINT and powerpc.LINT64:

cc1: warnings being treated as errors
/scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function 
'generic_set_tx_event':
/scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the address 
of 'generic_mbuf_destructor' will always evaluate as 'true' [-Waddress]
--- netmap_generic.o ---
*** [netmap_generic.o] Error code 1

I haven’t yet dug into why this only surfaces on powerpc, yet…
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: vt(4) chops off the leftmost three columns

[Ngie Cooper (yaneurabeya)]

> On Jan 12, 2017, at 18:13, Ed Maste  wrote:
> 
> On 12 January 2017 at 18:50, Alan Somers  wrote:
>> I've seen three separate machines where FreeBSD11's vt(4) driver chops
>> off the leftmost three columns of the screen.  Rendering simply starts
>> at the beginning of the fourth column.  In all cases, setting
>> "kern.vty=sc" corrects the problem.
> 
> Or try setting hw.vga.textmode=1
> 
> Did you observe this with IPMI redirected video or an attached monitor
> (or a combination)?

I’ll have to double check, but I’m pretty sure I’ve seen this with my Haswell 
box (Escher) over VGA using my projector.
Thanks,
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: SVN r311568 breaks build

[Ngie Cooper (yaneurabeya)]

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

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: SVN r310931 Bad code

[Ngie Cooper (yaneurabeya)]

> On Dec 31, 2016, at 06:14, Michael Butler  wrote:
> 
> At line 1949 of head/contrib/bsnmp/lib/snmpclient.c, you changed ..
> 
> - if ((sc->chost = malloc(strlen(s) + 1)) == NULL) {
> + if ((sc->chost = strdup(strlen(s))) == NULL) {
> 
> This can't work as intended since strlen returns the length of the
> string not a pointer to it.
> 
> I expect this should be ..
> 
>   if ((sc->chost = strdup(s)) == NULL) {

Yeah… egg on my face... I fixed it in r310942.
Sorry for the breakage :/…
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r 310850: buildkernel failure: ip_carp.c:615:28: error: incomplete definition

[Ngie Cooper (yaneurabeya)]

> On Dec 30, 2016, at 12:07, O. Hartmann  wrote:
> 
> 
> [...]
> 
> ===> cas (all)
> --- all_subdir_carp ---
> --- ip_carp.o ---
> /usr/src/sys/modules/carp/../../netinet/ip_carp.c:615:28: error: incomplete 
> definition of
> type 'struct ip6_hdr' return (memcmp(, >ip6_src, sizeof(in6)) == 0);
>  ~~~^
> /usr/src/sys/netinet6/in6.h:662:8: note: forward declaration of 'struct 
> ip6_hdr'
> struct ip6_hdr;
>   ^
> --- all_subdir_cam ---
> Building 
> /usr/obj/usr/src/sys/WALHALL/modules/usr/src/sys/modules/cam/scsi_pass.o
> --- all_subdir_carp ---
> 1 error generated.
> *** [ip_carp.o] Error code 1

Should be addressed in r310864.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail