Re: build wirh GCC -- supported?

[Garrett Cooper]

> On Jan 16, 2016, at 03:27, Kostya Berger  wrote:
> 
> Hi, everyone.
> Is GCC supported for building CURRENT? And if so, how do I set it to be 
> default compiler?Thank you very much for the answer.

It depends on the architecture.

Please note that not everything will build, eg you might need to set 
WITHOUT_TESTS.

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: Installworld fails with TMPDIR pointing to NFS mounted directory

[Garrett Cooper]

> On Jan 12, 2016, at 11:21, Tom Vijlbrief  wrote:
> 
> 
> Op di 12 jan. 2016 om 18:08 schreef NGie Cooper :
>> 
>> > On Jan 12, 2016, at 08:42, Tom Vijlbrief  wrote:
>> >
>> > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not
>> > think it is raspberry related or even 11-CURRENT related.
>> >
>> > export TMPDIR=/media/usbdisk/tmp
>> >
>> > make installword MAKEOBJDIRPREFIX=/media/swan/obj
>> 
>> Hi Tom,
>> MAKEOBJDIRPREFIX should always be set via the environment, not the 
>> command line, e.g.
>> 
>> export MAKEOBJDIRPREFIX=/media/swan/obj
>> make installworld
>> 
>> Cheers,
>> -NGie
> 
> I think I actually did the export and not as I typed in my mail,
> the export is in my shell history :-)
> 
> I also added:
> 
> rpc_lockd_enable="YES"
> 
> to my /etc/rc.conf and rebooted (rpc.lockd is now running) as Bryan 
> suggested, but I don't think that it is needed if the only client accessing 
> the NFS tmp dir is the local client?
> 
> [root@rpibsd /media/swan/src]# env | grep swan
> TMPDIR=/media/swan/tmp
> PWD=/media/swan/src
> MAKEOBJDIRPREFIX=/media/swan/obj
> 
> make installworld DESTDIR=/d/root11
> 
> Same result:
> 
> ===> etc/sendmail (install)
> cd /media/swan/src/etc/../share/man; make makedb
> makewhatis /d/root11/usr/share/man
> makewhatis /d/root11/usr/share/openssl/man
> rm: /media/swan/tmp/install.sy3BjziY/locale/en_US.UTF-8: Directory not empty
> rm: /media/swan/tmp/install.sy3BjziY/locale: Directory not empty
> rm: /media/swan/tmp/install.sy3BjziY: Directory not empty
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /media/swan/src
> *** Error code 1
> 
> Stop.
> make: stopped in /media/swan/src
> [root@rpibsd /media/swan/src]# 

The NFS "directory not empty" issue has been a common annoyance for me for 
several years. It's not just you... It deserves a bug though.
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: clang/3.7.1/include/ does not exist?

[Garrett Cooper]

> On Dec 29, 2015, at 13:20, Roger Marquis  wrote:
> 
> NGie Cooper wrote:
>>How are you executing buildworld? What?s your revision?
> 
> In the latest iteration:
> 
> uname -a
>   ... 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Thu Dec 17 18:26:58 PST 2015
> ...:/usr/obj/usr/src/sys/GENERIC amd64
> cd /usr/src
> rm -rf * .s* .a* ../obj/*
> svnlite co https://svn.freebsd.org/base/head ./
>  Checked out revision 292870.
> make cleanworld
> make buildworld -DNO_GAMES
> 
> Had been seeing the same results on multiple systems, with a couple of
> yesterday's and several previous revisions, but as of 292873 it does build
> again.

I don't use cleanworld. That might be a part of the problem. Is /usr/obj on 
tmpfs?
Thanks!
___
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: r292688: ix_txrx.c:812:4: error: use of undeclared identifier 'ip6';

[Garrett Cooper]

> On Dec 24, 2015, at 04:03, O. Hartmann  wrote:
> 
> Building kernel on r292688 fails with the error shown below:
> 
> [...]
> cc  -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror 
> -D_KERNEL
> -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
> -include /usr/obj/usr/src/sys/GATE/opt_global.h -I. -I/usr/src/sys -fno-common
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
> -I/usr/obj/usr/src/sys/GATE
> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
> -fdiagnostics-show-option
> -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function  
> -Wno-error-pointer-sign
> -Wno-error-shift-negative-value  -mno-aes -mno-avx  -std=iso9899:1999
> -c /usr/src/sys/modules/isci/../../dev/isci/scil/scif_sas_smp_remote_device.c 
> -o
> scif_sas_smp_remote_device.o --- all_subdir_iwnfw --- --- iwn5150fw.ko --- ld 
> -d
> -warn-common -r -d -o iwn5150fw.ko iwlwifi-5150-8.24.2.2.fw.fwo iwn5150fw.o :>
> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk iwn5150fw.ko  export_syms 
> | xargs -J%
> objcopy % iwn5150fw.ko --- all_subdir_ix --- --- ix_txrx.o
> --- /usr/src/sys/modules/ix/../../dev/ixgbe/ix_txrx.c:812:4: error: use of 
> undeclared
> identifier 'ip6'; did you mean 'ip'? ip6 = (struct ip6_hdr *)(l3d); ^~~
> ip /usr/src/sys/modules/ix/../../dev/ixgbe/ix_txrx.c:730:13: note: 'ip' 
> declared here
> struct ip *ip; ^ /usr/src/sys/modules/ix/../../dev/ixgbe/ix_txrx.c:812:8: 
> error:
> incompatible pointer types assigning to 'struct ip *' from 'struct ip6_hdr
> *' [-Werror,-Wincompatible-pointer-types] ip6 = (struct ip6_hdr *)(l3d); ^
> ~~~ 
> /usr/src/sys/modules/ix/../../dev/ixgbe/ix_txrx.c:814:14: error:
> use of undeclared identifier 'ip6' ipproto = ip6->ip6_nxt; ^ --- 
> all_subdir_isci ---

Hi!
I've CCed erj/sbruno..
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: Build from 9.3-RELEASE to 11.0-CURRENT fails for i386 (-Wsign-compare issues with gcc)

[Garrett Cooper]

> On Dec 22, 2015, at 08:23, John Baldwin  wrote:
> 
>> On Monday, December 21, 2015 11:01:36 AM John Baldwin wrote:
>>> On Saturday, December 19, 2015 01:05:36 PM NGie Cooper wrote:
>>> Hi John,
>>>I tried bootstrapping 9.3-RELEASE to 11.0-CURRENT with i386 and ran into 
>>> the -Wsign-compare issue below when running make libraries with buildworld, 
>>> because it’s building libkvm with gcc 4.2.1 :/… I’ve tried bootstrapping 
>>> with clang/clang37, but haven’t been able to yet. I’ll try installing 
>>> 10.2-RELEASE via freebsd-update so I can use clang instead of gcc.
>>> Thanks!
>>> -NGie
>> 
>> We don't actually support going from 9 to 11.  However, these constants
>> should probably be explicitly unsigned anyway.  I haven't tested this at
>> all, but something like this:
>> 
>> Index: head/lib/libkvm/kvm_i386.h
>> ===
>> --- head/lib/libkvm/kvm_i386.h  (revision 292553)
>> +++ head/lib/libkvm/kvm_i386.h  (working copy)
>> @@ -57,8 +57,8 @@
>> #defineI386_PG_PS  0x080
>> #defineI386_PG_FRAME_PAE   (0x000ff000ull)
>> #defineI386_PG_PS_FRAME_PAE(0x000fffe0ull)
>> -#defineI386_PG_FRAME   (0xf000)
>> -#defineI386_PG_PS_FRAME(0xffc0)
>> +#defineI386_PG_FRAME   (0xf000u)
>> +#defineI386_PG_PS_FRAME(0xffc0u)
>> 
>> #ifdef __i386__
>> _Static_assert(PAGE_SHIFT == I386_PAGE_SHIFT, "PAGE_SHIFT mismatch");
> 
> This passed a universe build on HEAD.  If you can test that it fixes the 9.3 
> -> 11.0
> bootstrap I will commit it.

I'll fire up a 9.3 VM and give it a shot.
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 .SUFFIXES bug?

[Garrett Cooper]

> On Dec 15, 2015, at 07:01, Carsten Kunze  wrote:
> 
> Hello,
> 
> current groff doesn't build on FreeBSD.  I had noticed the same issue some 
> months ago on NetBSD and cross checked on FreeBSD and it had worked on 
> FreeBSD.  There must have somethig changed since then.  How to reproduce:
> 
> When there is a file "test.1.man" and a makefile:
> 
> .SUFFIXES:
> .SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf 
> .xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp
> 
> .man:
>@echo Making $@ from $<
>rm -f $@
>@LC_ALL=C \
> sed -e "s|foo|bar|g" \
> $< >$@
> 
> "make test.1" results in "make: don't know how to make test.1. Stop".
> 
> When ".man" is put to the start of the list it works.  It also works when the 
> first .SUFFIXES line is removed.
> 
> The answer from NetBSD is that this is very likely a bug in make.  May this 
> also be the case for FreeBSD?

Hi Carsten,

Probably since both use bmake... (I saw you started the other thread on 
tech-userle...@netbsd.org).

Simon maintains bmake. I've CCed him for visibility.

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: Panic at shutdown

[Garrett Cooper]

> On Nov 28, 2015, at 12:32, Ranjan1018 . <21474...@gmail.com> wrote:
> 
> Hi,
> 
> sometimes I have the panic in the photo at shutdown:
> 
> http://imgur.com/mXrgFLp
> 
> Unfortunately this happens randomly.
> 
> I am running:
> 
> $ uname -a
> 
> FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r291160M: Sun Nov 22
> 17:10:38 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC  amd64

The panic is in the ZFS code.

Have you run memtest on the machine recently?
___
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: libXO-ification - Why - and is it a symptom of deeper issues?

[Garrett Cooper]

> On Nov 15, 2015, at 09:51, Andrey Chernov  wrote:
> 
>> On 15.11.2015 20:37, Adrian Chadd wrote:
>>> On 15 November 2015 at 09:10, Dan Partelly  wrote:
>>> Meaning, is that simple to push things in head , if somone does the work, 
>>> even with with no proper review of the problem at hand , and the proposed 
>>> solutions ?
>> 
>> Nope and yup. The juniper folk had a solution to a problem multiple
>> people had requested work on, and their proposal was by far the
>> furthest along code and use wise.
>> 
>> It's all fine and good making technical decisions based on drawings
>> and handwaving and philosophizing, but at some point someone has to do
>> the code. Juniper's libxo was the furthest along in implementation and
>> production.
> 
> It seems it is the only and final argument for libXO existence. I
> remember 2 or 3 discussions against libXO spontaneously happens in the
> FreeBSD lists, all ended with that, approximately: "we already have the
> code and you have just speculations". Alternative and more architecture
> clean ideas, like making standalone template-oriented parser probably
> based on liXO, are never seriously considered, because nobody will code
> it, not for other reasons.

We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't 
seems like the best idea in the world to me from a end-user sysadmin/developer 
perspective.

I could just as easily use standard tools like awk, grep, sed, and more 
advanced languages like perl or Python to parse output, and assuming output 
doesn't get a major rewrite, I'd just go with that method that's worked pretty 
well for me over the last 10 years of my career..

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: libXO-ification - Why - and is it a symptom of deeper issues?

[Garrett Cooper]

> On Nov 15, 2015, at 10:05, Allan Jude  wrote:
> 
>> On 2015-11-15 07:54, Dan Partelly wrote:
>> 
>> Hi all,
>> 
>> I was looking at the new facility of dumping JSON,XML from many utils in 
>> base and after some funny minutes, I couldn't stop ask myself “ Ok, this is 
>> funny , but why ? “ And I couldn't find a real answer. Ill outline what I 
>> think:
>> 
>> 
>> 1. Undoubtedly, it makes base code slightly harder to understand and 
>> maintain.
> 
> I am not sure that libxo actually makes the code any harder to
> understand and maintain. It might actually make it slightly better.
> 
> replacing:
> 
> printf("%s %s %d\n", foo, bar, number);
> 
> with:
> 
> xo_emit("{:foo/%s} {:bar/%s} {:number/%d}", foo, bar, number);
> 
> it not really hurting much.

That's by and large true, but there are other APIs that need to be called on 
exit (xo_finish?) and in other scenarios where flushing, etc is needed. If you 
don't do that, you don't get the output you expect (which broke uptime/w 
several months ago..).

Also, typos with the meta language into the xo_emit calls have bit is more than 
once ;(.
___
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: libXO-ification - Why - and is it a symptom of deeper issues?

[Garrett Cooper]

> On Nov 15, 2015, at 10:09, Allan Jude  wrote:

...

> The big difference is, a json parser isn't going to blow up if a new
> field gets added in the middle, and your awk/grep/sed script probably will.

That's a plus to those formats, yes, but if someone changes the field name 
(which can happen today, on a whim, and would go unnoticed for a while because 
no tests/spec), you'll run into a KeyError in Python or an equivalent error 
message in your language of choice.

Thanks,
___
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: Failing buildword due to execution permission (with fix)

[Garrett Cooper]

> On Nov 9, 2015, at 17:27, Bryan Drewery <bdrew...@freebsd.org> wrote:
> 
>> On 11/9/2015 5:17 PM, Garrett Cooper wrote:
>> 
>>> On Nov 9, 2015, at 16:13, Bryan Drewery <bdrew...@freebsd.org> wrote:
>> 
>> 
>> ...
>> 
>>> If this is a shell file then it is best to invoke it with 'sh' rather
>>> than a chmod/#!. The src checkout should be noexec-safe.
>> 
>> Right. I think it'd be a good idea for me to hunt down other issues though 
>> in the build by setting -o noexec.
>> 
>> 
>> The only thing that concerns me with doing that is that it could result in 
>> weirdness, e.g. The osreldate.h generation script in include/ .
> 
> It prepends 'sh'.
> 
> include/Makefile:MK_OSRELDATE_SH=   ${.CURDIR}/mk-osreldate.sh
> include/Makefile:   sh ${MK_OSRELDATE_SH}

Yeah... I forgot.

I wrote up that patch at iX, and it was iterated over a bit. I was just 
remembering what happens when you use ${SHELL} (hint: no bueno if your build is 
kicked off with a csh/non-POSIX sh..).

I'll do that soon-ish.

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 broken

[Garrett Cooper]

> On Nov 9, 2015, at 09:56, Ian Lepore  wrote:

...

>> I must perform a
>>  chflags -R noschg
>> on /usr/obj prior to blowing it away. Is it different for you,
>> or did you just omit that step?
> 
> In 19 years of using freebsd, I have never once needed to chflags on an
> obj directory.  Nothing in the build process sets any non-standard
> flags in the obj dirs, and a simple rm -rf will remove everything just
> fine (you would need to sudo the rm -rf if you built as root).

I used to have to do that in earlier/custom versions of 10.x.

Vanilla FreeBSD shouldn't be setting schg on files in MAKEOBJDIRPREFIX though, 
ever.

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: Failing buildword due to execution permission (with fix)

[Garrett Cooper]

> On Nov 9, 2015, at 13:35, José Pérez  wrote:
> 
> Hello,
> I have this buildwordl failure:
> 
> ===> libexec/rbootd (depend)
> --- depend_subdir_lib ---
> --- aton_ether_subr.c ---
> /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr 
> /usr/src/sys/net/if_ethersubr.c ato
> n_ether_subr.c
> sh: /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr: Permission 
> denied
> *** [aton_ether_subr.c] Error code 126
> 
> 
> I fixed with:
> chmod +x /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr
> 
> 
> This was from a fresh checkout of current on a new machine.
> 
> Is it me or shall I report a bug?

Please file a bug and assign it to me (ngie). Is the file system mounted with 
noexec?
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: Failing buildword due to execution permission (with fix)

[Garrett Cooper]

> On Nov 9, 2015, at 16:13, Bryan Drewery  wrote:


...

> If this is a shell file then it is best to invoke it with 'sh' rather
> than a chmod/#!. The src checkout should be noexec-safe.

Right. I think it'd be a good idea for me to hunt down other issues though in 
the build by setting -o noexec.


The only thing that concerns me with doing that is that it could result in 
weirdness, e.g. The osreldate.h generation script in include/ .

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: mtree patch for WITHOUT_LPR

[Garrett Cooper]

> On Nov 7, 2015, at 10:19, Dmitry Morozovsky  wrote:

...

> ===
> --- etc/mtree/BSD.lpr.dist(nonexistent)
> +++ etc/mtree/BSD.lpr.dist(working copy)
> @@ -0,0 +1,30 @@
> +# $FreeBSD$
> +#
> +# Please see the file src/etc/mtree/README before making changes to this 
> file.
> +#
> +
> +/set type=dir uname=root gname=wheel mode=0755
> +.
> +include
> +atf-c
> +..
> +atf-c++
> +..

This diff is incorrect.

There are a lot of other things that need to be fixed if we go down this path. 
Do you have a plan or idea of what all needs to be fixed?

Also, some things do this on purpose, e.g. the debug files.

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: FreeBSD_HEAD_sparc64 - Build #1311 - Still Failing

[Garrett Cooper]

> On Nov 7, 2015, at 06:18, Andriy Gapon  wrote:
> 
>> On 07/11/2015 10:00, jenkins-ad...@freebsd.org wrote:
>> In file included from 
>> /builds/FreeBSD_HEAD_sparc64/gnu/lib/libstdc++/../../../contrib/gcc/debug.c:19:
>> /builds/FreeBSD_HEAD_sparc64/gnu/lib/libstdc++/../../../contrib/gcc/system.h:418:
>>  error: conflicting types for 'strsignal'
>> /builds/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/FreeBSD_HEAD_sparc64/tmp/usr/include/string.h:115:
>>  error: previous declaration of 'strsignal' was here
> 
> Has this been fixed?

I don't think so..
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Unicode collation string and reworked locale definitions

[Garrett Cooper]

> On Nov 2, 2015, at 02:17, Baptiste Daroussin  wrote:
> 
>> On Mon, Nov 02, 2015 at 10:04:11AM +, David Chisnall wrote:
>>> On 1 Nov 2015, at 21:30, Baptiste Daroussin  wrote:
>>> 
>>> All issues reported has been fixed, except if more issues are reported, this
>>> will be merged into head next saturday: November 7th
>> 
>> That’s really excellent news!  Thanks for doing this.  Are there any good 
>> potential sources for the regex stuff?  I think std::regex in libc++ 
>> supports multibyte character sets, but is very full of templates and not 
>> very easy to translate into C.
> For te regex tools, it will be another step. I was planning to incorporate
> libtre + apple's patches like dragonfly did, it would need a lot of tests, but
> from my current testing performances are better than our current 
> implementation.
> And it makes libc's regrex passing way more entries in the AT regex test 
> suite
> 
> If anyone else want to work on bringing in that I would be very glad as I have
> already too much things in my plate :)

I was about to say... The regex tests on FreeBSD in tools/regression/lib/libc 
are quite broken ;(.. (Bug 191354). I'd like to fix/salvage those test cases if 
at all possible -- this might be a good motivator for that.
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: dtc(1): reproducible segmentation fault

[Garrett Cooper]

> On Oct 23, 2015, at 07:10, George Abdelmalik  
> wrote:
> 
> Hi,
> 
> With recent amd64 11.0-current system (as of earlier this week) I can 
> reproduciblycw
> get a SIGSEGV when running a command such as
> 
> $ dtc -o zb.dtb /usr/src/sys/boot/fdt/dts/arm/zedboard.dts
> Segmentation fault (core dumped)
> 
> I've investigated the issue and found that the problem is at line
> 241 of the /usr/src/usr.bin/dtc/input_buffer.cc where the call to
> mmap(2) fails. Snippet below:
> 
> 233 mmap_input_buffer::mmap_input_buffer(int fd) : input_buffer(0, 0)
> 234 {
> 235 struct stat sb;
> 236 if (fstat(fd, ))
> 237 {
> 238 perror("Failed to stat file");
> 239 }
> 240 size = sb.st_size;
> 241 buffer = (const char*)mmap(0, size, PROT_READ,
> 242 MAP_PREFAULT_READ, fd, 0);
> 243 if (buffer == 0)
> 244 {
> 245 perror("Failed to mmap file");
> 246 }
> 247 }
> 
> The code incorrectly tests againts 0 instead of MAP_FAILED for failure
> which is why the the perror message isn't seen at the terminal, the SIGSEGV
> happens later when an attempt to access the buffer array is made.
> 
> Also the final parts of truss output are:
> 
> ..
> ..
> getrusage(0,{ u=0.00,s=0.002578,in=2,out=0 }) = 0 (0x0)
> mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 
> 34384904192 (0x80180)
> openat(AT_FDCWD,"xxx.dtb",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3)
> getrusage(0,{ u=0.00,s=0.002697,in=2,out=0 }) = 0 (0x0)
> openat(AT_FDCWD,"/usr/src/sys/boot/fdt/dts/arm/zedboard.dts",O_RDONLY,00) = 4 
> (0x4)
> fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) = 0 (0x0)
> fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) = 0 (0x0)
> mmap(0x0,5360,PROT_READ,MAP_PREFAULT_READ,4,0x0) ERR#22 'Invalid argument'
> close(4) = 0 (0x0)
> SIGNAL 11 (SIGSEGV)
> process killed, signal = 11 (core dumped)
> 
> Any help debugging this futher would be much appreciated. I just can't 
> understand why
> the mmap in question would fail, and what's invalid about its arguments?

Hi George,
Could you please post the bug report (with your dts file) on 
bugs.freebsd.org and CC Ian Lepore and Warner Losh?
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 broken

[Garrett Cooper]

> On Oct 14, 2015, at 07:20, Shawn Webb  wrote:
> 
> I've now reproduced this same error on two boxes:
> 
> gencat: Unable to create a new zh_CN.GB2312: Permission denied
> --- zh_CN.GB2312 ---
> *** [zh_CN.GB2312] Error code 1
> 
> make[5]: stopped in /usr/src/usr.bin/vi/catalog
> 1 error

Jenkins agrees: https://jenkins.freebsd.org/job/FreeBSD_HEAD/3394/console
___
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-tests - Build #1497 - Still Unstable

[Garrett Cooper]

> On Sep 28, 2015, at 06:30, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD-tests - Build #1497 - Still Unstable:
> 
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1497/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1497/changes
> Full build log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1497/console
> 
> Change summaries:
> 
> No changes
> 
> 
> The failed test cases:
> 
> 1 tests failed.
> FAILED:  test-report.xml.
> 
> Error Message:

The kyua tests passed. It just ran into an LOR at the end that is probably 
causing issues or something..
___
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: em broken on current amd64

[Garrett Cooper]

> On Sep 5, 2015, at 08:50, Manfred Antar  wrote:
> 
> Recent changes to em have broken current on amd64.
> Booting kernel will hang when trying to load em0, then will continue booting 
> without the driver loading (No Network)
> This is on a HP SFF 8000 with em0 embedded on the motherboard.
> 
> boot messages:
> 
> em0:  port 0x3100-0x311f mem 
> 0xf310-0xf311,0xf3125000-0xf3125fff irq 19 at device 25.0 on pci0
> em0: attempting to allocate 1 MSI vectors (1 supported)
> em0: using IRQ 265 for MSI
> em0: Using an MSI interrupt
> em0: The EEPROM Checksum Is Not Valid
> device_attach: em0 attach returned 5

Tijl said the same. The offending commit's r287467.
Cheers,
___
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 changes to minibus on current amd64 breaks em0

[Garrett Cooper]

> On Sep 4, 2015, at 14:01, Manfred Antar  wrote:
> 
> Current from 9/4/2015 1:00pm PDT:
> Kenel hangs on boot at:
> 
> em0:  port 0x3100-0x311f mem 
> 0xf310-0xf311,0xf3125000-0xf3125fff irq 19 at device 25.0 on pci0
> em0: attempting to allocate 1 MSI vectors (1 supported)
> msi: routing MSI IRQ 265 to local APIC 0 vector 61
> em0: using IRQ 265 for MSI
> em0: Using an MSI interrupt

- What do you mean by minibus?
- what's the revision?
- could you do boot -v please?
___
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 on boot during scan with pmspcv

[Garrett Cooper]

> On Sep 1, 2015, at 13:30, Conrad Meyer  wrote:
> 
>> On Mon, Aug 31, 2015 at 6:20 PM, John Baldwin  wrote:
>> Probably pCardInfo is NULL.
>> 
>> Looking at the pms driver source is making my stomach churn, but I don't
>> see anything obvious.  The field is set during attach, so it shouldn't be
>> NULL when the intrhook runs.  Do you have any other storage devices on
>> this box?  If so, I would try to kldload the pms driver after you have
>> booted far enough to setup dumps (either that or setup remote kgdb).
> 
> In fact, I don't have any storage devices attached to the PMC
> controller on this box. So it's a pretty low priority for me other
> than not panicing. I've configured the BIOS to legacy boot and the
> issue no longer crops up.
> 
> I just wanted to register the stack and unpleasantness on -CURRENT@ in
> case someone else runs into it too and/or PMC is reading and can
> diagnose/fix it.

If you see something, bug it :)!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Garrett Cooper]

> On Aug 30, 2015, at 23:13, Andriy Gapon  wrote:
> 
> 
> I would appreciate any pointers at how to debug an ACPI suspend problem that 
> I have.
> 
> What I have so far.  The system hangs when I try to suspend it and it gets 
> reset
> by a watchdog.  Setting debug.acpi.suspend_bounce=1 does not make any
> difference, so the hang happens before the final sleep code is executed.  I
> think that the device suspend stage is executed, because disks get spun down 
> and
> video signals gets cut off.
> 
> I could enable / add some debug printfs, but I suppose that their output would
> get lost due to the above.  RAM content unfortunately does not survive across
> the resets.

When I last had to do this to figure out what magic formula was required to get 
my netbook working, I did something like this:

1. Stripped down the kernel to just the storage driver and core pieces.
2. Loaded all other modules after boot, if necessary.
3. Called zzz with the appropriate ACPI tunables/sysctls set.

That got me pointed in the right direction (IIRC it was psm at the time). What 
I did to get a real smoking gun was I put printf statements in subr_bus.c 
(IIRC) to track device quiescing at suspend and reawakening at resume.

There’s `options BUS_DEBUG` too, which may or may not help.

FWIW I found debug.acpi.suspend_bounce less useful, but it still exercised the 
quiesce->reawaken cycle, sorta.

There’s also `hw.acpi.reset_video` and `debug.acpi.resume_beep`.

You might need to hack /etc/rc.resume and /etc/rc.suspend, BTW, depending on 
what you discover (switching my vty was definitely required in order for X11 to 
come back in a sane manner at resume).

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: r287246: buildworld fails: ld: i386:x86-64 architecture of input file `/usr/obj/usr/src/sys/boot/i386/gptboot/../../libstand32/libstand.a(qdivrem.o)' is incompatible with i386 output

[Garrett Cooper]

Warner broke sys/boot somehow.. Jenkins concurs.



 On Aug 27, 2015, at 23:41, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
 Recent CURRENT sources fail to buildworld:
 
 [...]
 --- util.o ---
 cc  -DBOOTPROG=\gptboot\  -O1  -DGPT  -DUFS1_AND_UFS2  -DSIOPRT=0x3f8
 -DSIOFMT=0x3  -DSIOSPD=9600  -I/usr/src/sys/boot/i386/gptboot/../../common
 -I/usr/src/sys/boot/i386/gptboot/../common
 -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I.
 -I/usr/src/sys/boot/i386/gptboot/../boot2
 -I/usr/src/sys/boot/i386/gptboot/../../..  -Wall -Waggregate-return
 -Wbad-function-cast -Wcast-align  -Wmissing-declarations -Wmissing-prototypes
 -Wnested-externs  -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings
 -Winline -march=i386 -ffreestanding -mno-mmx -mno-sse -mno-avx -msoft-float
 -m32 -DNDEBUG -std=gnu99-Qunused-arguments
 -c /usr/src/sys/boot/i386/gptboot/../../common/util.c -o util.o --- gptldr.out
 --- ld -static -N --gc-sections -m elf_i386_fbsd -e start -Ttext 0x7c00 -o
 gptldr.out gptldr.o --- gptboot.out --- ld -static -N --gc-sections -m
 elf_i386_fbsd -Ttext 0x0 -o
 gptboot.out /usr/obj/usr/src/sys/boot/i386/gptboot/../btx/lib/crt0.o gptboot.o
 sio.o gpt.o crc32.o drv.o cons.o
 util.o /usr/obj/usr/src/sys/boot/i386/gptboot/../../libstand32/libstand.a ld:
 i386:x86-64 architecture of input file
 `/usr/obj/usr/src/sys/boot/i386/gptboot/../../libstand32/libstand.a(qdivrem.o)'
 is incompatible with i386 output *** [gptboot.out] Error code 1
 
 make[6]: stopped in /usr/src/sys/boot/i386/gptboot
 1 error
 
 make[6]: stopped in /usr/src/sys/boot/i386/gptboot
 *** [_sub.all] Error code 2
 ___
 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: Read-only /usr/obj/ no longer kosher?

[Garrett Cooper]

 On Aug 26, 2015, at 19:03, O'Connor, Daniel dar...@dons.net.au wrote:
 
 
 On 27 Aug 2015, at 08:25, Pawel Jakub Dawidek p...@freebsd.org wrote:
 On Tue, Aug 25, 2015 at 03:32:35PM -0700, NGie Cooper wrote:
 On Tue, Aug 25, 2015 at 3:21 PM, Xin Li delp...@delphij.net wrote:
 On 08/25/15 14:55, Pawel Jakub Dawidek wrote:
 Now that I think of it, it might have been that I did
 buildworld/buildkernel before -p1. Then freebsd-update updated
 newvers.sh and then I was trying to do installworld.
 
 Yes, I can now reproduce it with source updated to -p2.
 
 Yes, that's because freebsd-version.sh is generated from the files (but
 it's not clear to me whether if it's a bug or a feature that 'make
 install' checks if it's up-to-date and decides to regenerate it...).
 
 It's a quirk for sure. If you change the behavior, people will
 definitely complain as they will now need to go back and rebuild
 everything.
 
 What we have now is misleading. People should recompile. It is rather
 rare to see security advisory which bumps only patch level and something
 that doesn't require recompilation (eg. a shell script). Current
 behaviour would make people think they are running latest patch level
 because freebsd-version says so, eventhough they only did 'make
 installworld' without rebuilding affected binaries.
 
 So..
 How hard would it be to force CC/CXX to /usr/bin/false during installworld?

Trivial in FreeBSD. Just make it so in Makefile for the installworld target, 
add false to itools, and add appropriate special casing in bsd.compiler.mk.

Doing this just prevents recompiling though, so not pjd's case.

Also, this might break someone's random usecase where they need CC/CXX to do 
something meaningful at install time, however, the likelihood of it being 
correct is slim IMHO..
___
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: r286615: /usr/libexec/ftpd broken!

[Garrett Cooper]

 On Aug 18, 2015, at 09:05, Benjamin Kaduk ka...@mit.edu wrote:
 
 On Tue, 18 Aug 2015, Garrett Cooper wrote:
 
 
 On Aug 18, 2015, at 08:57, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 
 On Tue, Aug 18, 2015 at 11:38:47AM -0400, Benjamin Kaduk wrote:
 
 On Tue, 18 Aug 2015, Marcel Moolenaar wrote:
 
 On Aug 17, 2015, at 10:15 PM, O. Hartmann ohart...@zedat.fu-berlin.de 
 wrote:
 
 Port security/heimdal installs its own ftpd with its appropriate 
 manpages.
 
 Ugh :-(
 
 I would argue that heimdal should not be in the business of supplying an
 ftpd.  Kerberos-enabled ftp basically does not offer any advantages over
 scp.
 
 OPENSSH_NONE_CIPHER is OFF by default, i.e. ftp can give more speed.
 
 More pragmatically, there are less ssh clients (openssh or bust really),
 whereas there are more ftp clients (Firefox, Chrome, ftp(1), python,
 etc).
 
 I specifically said Kerberos-enabled ftp.  The things you listed do not
 appear to qualify.

Fair enough .
___
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: r286615: /usr/libexec/ftpd broken!

[Garrett Cooper]

 On Aug 18, 2015, at 08:57, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 
 On Tue, Aug 18, 2015 at 11:38:47AM -0400, Benjamin Kaduk wrote:
 
 On Tue, 18 Aug 2015, Marcel Moolenaar wrote:
 
 On Aug 17, 2015, at 10:15 PM, O. Hartmann ohart...@zedat.fu-berlin.de 
 wrote:
 
 Port security/heimdal installs its own ftpd with its appropriate manpages.
 
 Ugh :-(
 
 I would argue that heimdal should not be in the business of supplying an
 ftpd.  Kerberos-enabled ftp basically does not offer any advantages over
 scp.
 
 OPENSSH_NONE_CIPHER is OFF by default, i.e. ftp can give more speed.

More pragmatically, there are less ssh clients (openssh or bust really), 
whereas there are more ftp clients (Firefox, Chrome, ftp(1), python, 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: r286615: /usr/libexec/ftpd broken!

[Garrett Cooper]

 On Aug 11, 2015, at 06:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
 On Tue, 11 Aug 2015 14:05:36 +0200
 O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
 On Tue, 11 Aug 2015 13:18:14 +0200
 Ed Schouten e...@nuxi.nl wrote:
 
 Hi there,
 
 2015-08-11 10:44 GMT+02:00 O. Hartmann ohart...@zedat.fu-berlin.de:
 ftpd starts sometimes, sporadically, and dies somewhere in the process.
 Connections to the ftpd aren't possible. Sockstat doesn't even show up a
 TCP/IP socket (21, ftp/tcp) where the daemon is supposed to listen for
 incoming connection - I see only udp4 (connecting to
 local_unbound/127.0.0.1:53). This is strange ...
 
 That's annoying. We should fix that.
 
 I recently made some changes to shutdown(2), but a grep reveals that
 ftpd doesn't call that function anywhere. Phew! The last changes made
 to ftpd are related to libxo. Adding marcel@, just to be sure.
 
 In the meantime, could you maybe run truss(8) over ftpd and send us the
 output?
 
 Thanks,
 
 I found one of our boxes, running
 
 FreeBSD 11.0-CURRENT #0 r286562: Mon Aug 10 08:14:52 CEST 2015 amd64
 
 which runs ftpd without problems (started via service ftpd onestart):
 
 USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN
 ADDRESS root ftpd   23139 3  dgram  - /var/run/logpriv
 root ftpd   23139 5  tcp6   *:21  *:*
 root ftpd   23139 6  tcp4   *:21  *:*
 
 
 ... as expected ... and the daemon is running for several minutes for now ...
 
 I will update the system as well and then ... see ... ;-)
 
 Well, after the update to FreeBSD 11.0-CURRENT #1 r286625: Tue Aug 11 14:09:55
 CEST 2015  amd64, ftpd is still working! This box is the only one that does
 nameresolution via DNS (external), while all non-functional systems do not 
 have
 DNS resolution and work with local_unbound name resolving.

Something is indeed weird with DNS under some circumstances as of a few weeks 
ago. I'm trying to update my box and I'm seeing a ton of complaints about 
unbound handing back A records instead of  ones. My machine is on an IPv4 
NAT network, but I still find it odd how my last update a few weeks ago started 
causing this..
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[Garrett Cooper]

On Jul 8, 2015, at 2:53, Oliver Pinter oliver.pin...@hardenedbsd.org wrote:

 On 7/8/15, O'Connor, Daniel dar...@dons.net.au wrote:
 
 On 8 Jul 2015, at 08:11, Garrett Wollman woll...@hergotha.csail.mit.edu
 wrote:
 Perhaps the test was (erroneously) written to assume that
 gettimeofday() was a system call, and could therefore detect invalid
 pointers and return [EFAULT].  This has not been the case for some
 time.  (In HEAD, not since r237434, which is three years ago.)
 
 In defence of the test, the man page says it can return EFAULT.
 
 That's fine, but why changed the behaviour since 2015. May 27.? I have
 an older FreeBSD/HardenedBSD install, where this test passing. See
 some previous email in this thread.

Hmm… works for me at least (no non-upstreamed changes to the kernel/userland as 
far as I remember — just more tests and some related build stuff).
Cheers,
-NGie

$ uname -a
FreeBSD fuji-current-amd64.local 11.0-CURRENT FreeBSD 11.0-CURRENT #1 
r284769+70563d6(isilon-atf)-dirty: Thu Jul  2 13:19:45 PDT 2015 
ngie@fuji-current-amd64.local:/usr/obj/usr/src/sys/FUJI  amd64
$ cc -Wall -g -O0 -o busted_gettimeofday busted_gettimeofday.c
$ ./busted_gettimeofday
busted_gettimeofday: gettimeofday: Bad address
$ cc -Wall -g -o busted_gettimeofday busted_gettimeofday.c
$ ./busted_gettimeofday
busted_gettimeofday: gettimeofday: Bad address
$ cc -Wall -o busted_gettimeofday busted_gettimeofday.c
$ ./busted_gettimeofday
busted_gettimeofday: gettimeofday: Bad address


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[Garrett Cooper]

On Jul 8, 2015, at 12:17, Doug Rabson d...@rabson.org wrote:

 As far as I can tell, POSIX doesn't require either EFAULT or any other
 behaviour - the text in http://www.open-std.org/jtc1/sc22/open/n4217.pdf
 just says, No errors are defined. Our man page is wrong and any real
 program which relies on gettimeofday not faulting when given bad inputs is
 broken.

I would suggest the following:
1. Document behavior in NOTES about gettimeofday returning EFAULT with the 
specific scenarios kib mentioned, segfaulting otherwise (wordsmithing the 
actual info of course). Otherwise, it might confuse people who look at the 
manpage later.
2. I’ll add a `#ifdef __FreeBSD__` to the testcase which will then skip it, 
because it’s easier to do that then test undefined behavior that only makes 
sense on NetBSD.
Thanks!
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[Garrett Cooper]

 On Jul 7, 2015, at 15:00, Oliver Pinter oliver.pin...@hardenedbsd.org wrote:
 
 Hi all!
 
 We discovered that one of the kyua test failing from gettimeofday tests.
 The error is reproducible on recent snapshot from 11-CURRENT:
 ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso
 
 root@freebsd:~ # cat test-gtod.c
 #include sys/time.h
 #include stdio.h
 
 int
 main(int argc, char **argv)
 {
 
return (gettimeofday((void *)-1, NULL));
 }
 root@freebsd:~ # make test-gtod
 cc -O2 -pipetest-gtod.c  -o test-gtod
 root@freebsd:~ # uname -a
 FreeBSD freebsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r284969: Tue Jun
 30 22:05:35 UTC 2015
 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
 root@freebsd:~ # ./test-gtod
 Segmentation fault (core dumped)
 
 root@freebsd:~ # gdb ./test-gtod
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...(no debugging
 symbols found)...
 (gdb) r
 Starting program: /root/test-gtod
 (no debugging symbols found)...(no debugging symbols found)...
 Program received signal SIGSEGV, Segmentation fault.
 0x000800958fbd in bcopy () from /lib/libc.so.7
 (gdb) bt
 #0  0x000800958fbd in bcopy () from /lib/libc.so.7
 #1  0x559c1291 in ?? ()
 #2  0xf9fde38df0174b80 in ?? ()
 #3  0x in ?? ()
 #4  0x in ?? ()
 
 And this is the original kyua test:
 op@opn sys kyua test gettimeofday_test
 gettimeofday_test:gettimeofday_err  -  broken: Premature exit; test
 case received signal 11 (core dumped)  [0.987s]
 gettimeofday_test:gettimeofday_mono  -  passed  [0.014s]
 
 Results file id is usr_tests_lib_libc_sys.20150707-215959-750045
 Results saved to
 /usr/home/op/.kyua/store/results.usr_tests_lib_libc_sys.20150707-215959-750045.db
 
 1/2 passed (1 failed)
 op@opn sys pwd
 /usr/tests/lib/libc/sys

Please file a bug.

I have no idea where this broke because the Jenkins runs have been unreliable 
over the past few weeks ;(...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: panic: negative refcount after dhclient during boot

[Garrett Cooper]

On Jul 5, 2015, at 8:16, Rink Springer r...@freebsd.org wrote:

 Hi all,
 
 On my FreeBSD/mips machine (it's a RouterStation Pro), I get the
 following panic during boot:

…

 This reproduces 100%. I'm at:
 
 FreeBSD 11.0-CURRENT #0 r285099: Sun Jul  5 12:31:47 CEST 2015
 
 Let me know what I can do to help track this down; I only started
 getting the panic after 'gateway_enable=YES' in /etc/rc.conf
 
 The kernel has INVARIANTS but no WITNESS. Config available at
 http://rink.nu/tmp/FRINGE - boot log at http://rink.nu/tmp/fringe.txt

Please file a bug!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: powerpc and powerpc64 builds broken

[Garrett Cooper]

 On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:
 
 Both powerpc and powerpc64 builds are broken in the same way, in
 usr.bin/mkesdb.  It was working correctly as of just before BSDCan, I
 successfully built world and kernel on June 6.
 
 The error seen at this point is:
 
 cc  -O2 -pipe   -I/home/chmeee/freebsd/head/usr.bin/mkesdb
 -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
 -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
 -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
 -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
 -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
 -Wold-style-definition -Wno-pointer-sign
 -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
 -o mkesdb lex.o yacc.o
 /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
 undefined reference to symbol `_end' (try adding -lc)
 /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
 could not read symbols: Bad value
 
 I've seen this both locally on my G5, and on the Power8 in the FreeBSD 
 cluster.

- What does file say when you run it on libc.so.7?
- What's your current revision?
- Does it work when SRCCONF/__MAKECONF are set to /dev/null?

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

Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?

[Garrett Cooper]

On Jun 21, 2015, at 3:16, Trond Endrestøl trond.endres...@fagskolen.gjovik.no 
wrote:

 Hi,
 
 Am I the only one who fails to build recent base/head (r284673) on
 pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.

...

 CC=clang
 CXX=clang++
 CPP=clang-cpp

Hi Trond,
You need to remove these lines. They shouldn’t have been set before or 
after the commits from projects/bmake .
Thanks,


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: toolchain target

[Garrett Cooper]

On Jun 17, 2015, at 23:22, Andriy Gapon a...@freebsd.org wrote:

 On 18/06/2015 02:26, Simon J. Gerraty wrote:
 Andriy Gapon a...@freebsd.org wrote:
 Seems like there is some problem with 'toolchain' target in the latest 
 head.
 Output of running `make toolchain TARGET=i386` on amd64 system can be found
 here: http://dpaste.com/3RD3C4V
 
 
 AFAICS, it still worked as of r283188.
 
 There has been a clang update since then.
 
 I just did make -j12 toolchain TARGET=i386 ok
 do you have anything interesting in /etc/make.conf?
 
 Thank you for the hint -- __MAKE_CONF=/dev/null SRC_CONF=/dev/null fix the 
 problem.
 
 Now I am trying to figure out what the problem is.
 
 My make.conf:
 .if defined(CC)
 .if ${CC} == gcc
 CPUTYPE?=k8-sse3
 .else
 CPUTYPE?=amdfam10
 .endif
 .endif
 CFLAGS+= -O2 -fno-strict-aliasing -pipe
 CFLAGS+= -fno-omit-frame-pointer
 CXXFLAGS+= -O2 -fno-strict-aliasing -pipe
 
 And src.conf:
 WITH_DEBUG_FILES=yes
 WITH_CTF=yes
 WITHOUT_INET6=YES
 WITHOUT_PROFILE=YES
 WITHOUT_FORTRAN=YES
 WITHOUT_I4B=YES
 WITHOUT_IPFILTER=YES
 WITHOUT_ATM=YES
 WITHOUT_IPX=YES
 WITHOUT_LPR=yes
 WITHOUT_ZONEINFO=yes
 MALLOC_PRODUCTION=yes
 LOADER_BZIP2_SUPPORT=yes
 LOADER_FIREWIRE_SUPPORT=yes
 
 
 Looks like my rather innocent manipulations of CFLAGS could be causing the 
 problem.
 Without my make.conf:
 mkdep -f .depend -a
 -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/include
 -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
 -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support
  -I.
 -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
 -D__STDC_CONSTANT_MACROS
 -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd11.0\
 -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\
 -I/usr/obj/usr/devel/svn2/head/tmp/legacy/usr/include  -std=c++11
 -stdlib=libc++
 /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp
 ...
 
 With my make.conf:
 mkdep -f .depend -a  -std=c++11  -stdlib=libc++
 /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp
 ...
 
 All the preprocessor flags (-I, -D) are gone.

Oh really…? This is going to break a _lot_ of peoples’ custom make.confs :(...


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: make targets broken?

[Garrett Cooper]

 On Jun 16, 2015, at 05:20, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net 
 wrote:
 
 Hi,
 
 I am puzzled by this:
 
 head-scratch.svn]$ make targets
 `targets’ is up to date.

It probably needs to be marked .PHONY. check with sjg though...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Warning: HEAD with zfs is potentially broken

[Garrett Cooper]

 On Jun 15, 2015, at 09:17, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
 Am Mon, 15 Jun 2015 17:39:58 +0200
 Baptiste Daroussin b...@freebsd.org schrieb:
 
 On Mon, Jun 15, 2015 at 08:13:12AM -0700, Peter Wemm wrote:
 Beware, a recent change has moved zfs tools internal libraries to the wrong 
 location and this can cause machines to be unbootable.  /sbin/zfs uses the 
 libraries from /lib, which are now going stale and may have undefined 
 symbols.  
 installworld is incorrectly installing them in /usr/lib.  This happened 
 some 
 time in the last week or so.
 
 Be very careful over the next few days.  This can cause boot failures.
 
 Same goes for everything that was installed in /lib 
 
 I workarounded the issue with r284417. but given what now sys.mk does I 
 really
 fear way more fallouts.
 
 regards,
 Bapt
 
 Luckily, since r284336, buildworld doesn't work properly (in my case amd64) 
 anymore.
 Buildworld bails out on several weird mk messages ...

Depends on your build options. I didn't dare run install world yesterday, but 
building with buildworld worked just fine for me with my stripped down build 
options.

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

Re: Error building x11/nvidia-driver kernel module @r284408

[Garrett Cooper]

 On Jun 15, 2015, at 06:34, David Wolfskill da...@catwhisker.org wrote:
 
 Now that vanilla head @284408 builds ( boots):
 
 FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1751  
 r284408M/284408:1100077: Mon Jun 15 05:51:00 PDT 2015 
 r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64
 
 I find that for my laptop, I encounter an error while trying to build
 the x11/nvidia-driver kernel module (courtesy of /etc/src.conf:
 
 g1-254(11.0-C)[2] cat /etc/src.conf 
 KERNCONF=CANARY
 PORTS_MODULES=x11/nvidia-driver
 PORTS_MODULES+=multimedia/cuse4bsd-kmod
 PORTS_MODULES+=emulators/virtualbox-ose-kmod
 WITHOUT_DEBUG_FILES=1
 IWN_DEBUG=1
 IEEE80211_DEBUG=1
 g1-254(11.0-C)[3] 
 
 -- which has heretofore been working for my daily refreshes for years):
 
 ...
 objcopy --strip-debug --add-gnu-debuglink=kernel.symbols kernel.debug kernel
 --- all ---
 === Ports module x11/nvidia-driver (all)
 cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; 
 PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
   SRC_BASE=/usr/src  OSVERSION=1100077  
 WRKDIRPREFIX=/usr/obj/usr/src/sys/CANARY make -B clean all
 ...
 ===  Configuring for nvidia-driver-346.47
 ===  Building for nvidia-driver-346.47
 === src (all)
 make[6]: don't know how to make 
 /common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine.
  Stop
 
 make[6]: stopped in 
 /common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src
 .CURDIR='/common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src'
 .MAKE='/usr/bin/make'
 .OBJDIR='/common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src'
 .TARGETS='all'
 DESTDIR=''
 LD_LIBRARY_PATH=''
 MACHINE='amd64'
 MACHINE_ARCH='amd64'
 MAKEOBJDIRPREFIX='/usr/obj'
 MAKESYSPATH=''
 MAKE_VERSION='20150606'
 SRCTOP='/usr/src'
 OBJTOP=''
 .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/bsd.mkopt.mk 
 /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
 /etc/src.conf /usr/src/share/mk/bsd.cpu.mk Makefile 
 /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk 
 /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
 /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.opts.mk 
 /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
 /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.mk 
 /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk 
 /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
 /usr/src/sys/conf/kern.mk'
 .PATH='. 
 /common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src'
 *** Error code 2
 
 Stop.
 
 
 
 A full typescript of the svn update and build may be found at
 http://www.catwhisker.org/~david/FreeBSD/head/build_r284408.txt; it's
 about 51MB.
 
 Please note that the (similar) refreshes for stable/10 (@r284404)
 had no problems; I have typescripts of them accessible (but I haven't
 put'them up on the Web server, as they're pretty boring).
 
 Perhaps some changes need to be made for (some?) ports to adjust for
 recent make  mk changes in head?
 
 I note that in the stable/10 case, the 
 .../obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine
  file
 is a symlink to /usr/src/sys/amd64/include -- and that it doesn't
 exist in the i386 case (and that doesn't appear to be a problem).

Looks like fallout from projects/bmake. Please file a bug and CC sjg.

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

Re: geom classe's geom_*.so installed /usr/lib/ instead of /lib/geom (crochet build)

[Garrett Cooper]

On Jun 15, 2015, at 4:40, Andrey Fesenko f0and...@gmail.com wrote:

 Hello,
 I'm build CURENT (r284408) for arm with crochet.
 
 all geom lasse's geom_*.so installed /usr/lib/ instead of /lib/geom
 
 /usr/obj/_.installworld.armv6.log
 ...
 === sbin/geom/class/cache (install)
 install -s -o root -g wheel -m 444 geom_cache.so
 /usr/obj/_.mount.freebsd/usr/lib
 install -o root -g wheel -m 444 gcache.8.gz
 /usr/obj/_.mount.freebsd/usr/share/man/man8
 /sbin/gcache - /sbin/geom
 === sbin/geom/class/concat (install)
 install -s -o root -g wheel -m 444 geom_concat.so
 /usr/obj/_.mount.freebsd/usr/lib
 install -o root -g wheel -m 444 gconcat.8.gz
 /usr/obj/_.mount.freebsd/usr/share/man/man8
 ...
 
 after boot see
 root@r-pi:~ # gpart show
 gpart: Unknown command: show.
 usage: gpart help
   gpart list [-a] [name ...]
   gpart status [-ags] [name ...]
   gpart load [-v]
   gpart unload [-v]
 root@r-pi:~ # cp /usr/lib/geom_* /lib/geom/
 root@r-pi:~ # gpart show
 = 63  7698369  mmcsd0  MBR  (3.7G)
   6334776   1  !12  [active]  (17M)
34839  1918286   2  freebsd  (937M)
  1953125  5745307  - free -  (2.7G)
 
 =  0  1918286  mmcsd0s2  BSD  (937M)
0  105- free -  (53K)
  105  1918080 1  freebsd-ufs  (937M)
  1918185  101- free -  (51K)

More breakage from projects/bmake. This should be fixed in theory, but bapt/sjg 
can confirm if it’s fixed.
Cheers,


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CURRENT] r284404 buildworld failure due to CXXFLAGS+= -std=c++11 in /etc/src.conf

[Garrett Cooper]

 On Jun 15, 2015, at 06:35, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
 On Sun, 14 Jun 2015 23:17:59 -0700
 Garrett Cooper yaneurab...@gmail.com wrote:
 
 On Jun 14, 2015, at 23:15, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
 Recent source of CURRENT (r284404) fails to buildworld when option
 
 CXXFLAGS+= -std=c++11 in /etc/src.conf
 
 is given in /etc/src.conf. That issue was introduced around after
 r282336. Below, you'll se the src.conf I use. I also have the buildworl
 d failure with src.conf containing only the line CXXFLAGS as specified
 above.
 
 With r284336 and before, this issue wasn't present.
 
 *PLEASE* file a bug.
 
 ... I was wondering whether this issue affects only a small amount of people 
 or
 it is simply ignored by most ...?

It's broken and it's not being ignored...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #85 - Failure

[Garrett Cooper]

On Jun 15, 2015, at 1:27, Simon J. Gerraty s...@juniper.net wrote:

 Konstantin Belousov kostik...@gmail.com wrote:
 I see the same problem on the up-to-date stable/10 host, trying to build
 
 I'm building HEAD on stable/10, I just updated the tree and did a clean
 tree buildworld ok.
 
 HEAD.  This is completely unacceptable, we have documented and always
 supported just
  make buildworld buildkernel
 on latest stable to get buildable and bootable HEAD.
 
 I think that proposition became shaking as soon as the current options
 model was added to the build - any new option will break building
 unless you use the share/mk from head.
 
 Hmm ok I've introduced the concept of options being set during sys.mk
 which makes the above issue slightly worse.
 Craig as already committed a fix for src/Makefile,
 hmm I thought it had logic to switch to the tree's share/mk
 in which case the change to src/Makefile should be all that's needed.
 
 There is yet another issue with the build system, I have
  INSTALL+=-CS
 in make.conf for around 15 years.  Apparently it is broken now.
 
 Ah! make.conf is getting included earlier.
 So that {local,src}.sys.mk can be included earlier so that any of them
 can provide pointer to external toolchain before sys.mk sets CC etc.
 
 That sucks, though that implies you are getting sys.mk from src/ at
 least after the build gets going.
 
 The installkernel target results in
 ph/vjc (install)
 --- _kmodinstall ---
 CS -o root -g wheel -m 555   ng_vjc.ko 
 /usr/home/kostik/build/bsd/DEV/p/boot/kernel
 CS: not found
 etc.

This is going to break a whole lot of stuff — especially because I’ve 
discovered people either try and be overly clever with make, or like 
.include’ing things more than once :(.



signature.asc
Description: Message signed with OpenPGP using GPGMail

[HEADSUP] head after r284417 is broken; please be patient while it's fixed

[Garrett Cooper]

Jenkins emails will probably keep on informing everyone about how healthy 
things are in the meantime.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CURRENT] r284404 buildworld failure due to CXXFLAGS+= -std=c++11 in /etc/src.conf

[Garrett Cooper]

On Jun 14, 2015, at 23:15, O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 Recent source of CURRENT (r284404) fails to buildworld when option
 
 CXXFLAGS+= -std=c++11 in /etc/src.conf
 
 is given in /etc/src.conf. That issue was introduced around after
 r282336. Below, you'll se the src.conf I use. I also have the buildworl
 d failure with src.conf containing only the line CXXFLAGS as specified
 above.
 
 With r284336 and before, this issue wasn't present.

*PLEASE* file a bug.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #85 - Failure

[Garrett Cooper]

On Jun 14, 2015, at 14:18, Simon J. Gerraty s...@juniper.net wrote:

 Craig Rodrigues rodr...@crodrigues.org wrote:
 On Sun, Jun 14, 2015 at 8:09 AM, Adrian Chadd adr...@freebsd.org wrote:
 
+ make -j 4 CROSS_TOOLCHAIN=amd64-gcc buildworld
__MAKE_CONF=/builds/FreeBSD_HEAD_amd64_gcc4.9/make.conf
make: /builds/FreeBSD_HEAD_amd64_gcc4.9/Makefile line 102: Malformed
conditional (${MK_META_MODE} == yes)
 
 That would imply that src/share/mk isn't being used?
 
 I'm not sure when Warner changed the default MAKESYSPATH to be
 .../share/mk
 but that would be the right thing to do:

That’s only present on head.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #85 - Failure

[Garrett Cooper]

On Jun 14, 2015, at 14:28, Simon J. Gerraty s...@juniper.net wrote:

 Garrett Cooper yaneurab...@gmail.com wrote:
 
 On Jun 14, 2015, at 14:18, Simon J. Gerraty s...@juniper.net wrote:
 
 Craig Rodrigues rodr...@crodrigues.org wrote:
 On Sun, Jun 14, 2015 at 8:09 AM, Adrian Chadd adr...@freebsd.org wrote:
 
   + make -j 4 CROSS_TOOLCHAIN=amd64-gcc buildworld
   __MAKE_CONF=/builds/FreeBSD_HEAD_amd64_gcc4.9/make.conf
   make: /builds/FreeBSD_HEAD_amd64_gcc4.9/Makefile line 102: Malformed
   conditional (${MK_META_MODE} == yes)
 
 That would imply that src/share/mk isn't being used?
 
 I'm not sure when Warner changed the default MAKESYSPATH to be
 .../share/mk
 but that would be the right thing to do:
 
 That’s only present on head.
 
 The default? yes I think it went back and forth a bit.
 But you can use
 
 make -m .../share/mk
 
 on 10.0

Yes, however… the problem is that there’s a _huge_ discrepancy in build 
machinery between 10 and 11. Also, some of the changes were MFCed, but not 
before 10.1 was cut.

There are some other items that need to be MFCed as well, like r279247. That 
change needs to be run through make tinderbox though on ref10-amd64, and 
ideally on a 10.0-RELEASE/10.1-RELEASE image as the ref10 servers run 10-STABLE 
IIRC.

Thanks!




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: geli panics my system after suspend-resume: g_eli_orphan_spoil_assert() called for cd0.eli

[Garrett Cooper]

On Jun 13, 2015, at 7:10, José García Juanino jjuan...@gmail.com wrote:

 Hi FreeBSD current,
 
 I get a reproducible panic following these steps:
 
 1- Mount a geli encrypted DVD:
 
 # geli attach /dev/cd0
 Password:
 
 # mount -o ro /dev/cd0.eli /cdrom
 
 2- Do some work in the /cdrom filesystem.
 
 3- Close my laptop lid. The system suspends.
 
 4- Open again the lid a wait. The system resumes, but panics after a
 few seconds:
 
 panic: Function g_eli_orphan_spoil_assert() called for cd0.eli.
 
 After that, X windows session close and bt prompt shows in the
 console. I type dump and reboot.
 
 Download the full backtrace from http://pastebin.com/i82Zbt0A

File a bug! https://bugs.freebsd.org/bugzilla/enter_bug.cgi



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: how do I downgrade from 11-current to 10-stable

[Garrett Cooper]

On May 31, 2015, at 16:27, Matthew D. Fuller fulle...@over-yonder.net wrote:

 On Sun, May 31, 2015 at 04:20:42PM -0700 I heard the voice of
 Kevin Oberman, and lo! it spake thus:
 
 Unfortunately the list ends at 9.0. It would be nice if it could be
 updated. I might sift through SVN and see if I can put together a patch for
 10.2. It is quite likely that the version has not changed since 9.0.
 
 In -CURRENT, it has a line for version 7 in 10.0 added in r265950
 (apparently after the stable/10 branch point; the actual v7 support
 was a year before that), that was seemingly never MFC'd.

V7 support was never MFCed to stable/9. It’s in stable/10 and newer and was 
included in 10.0-RELEASE: 
https://svnweb.freebsd.org/base/release/10.0.0/sys/geom/eli/g_eli.h?r1=238115r2=238116;
 .
Cheers!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: how do I downgrade from 11-current to 10-stable

[Garrett Cooper]

On May 30, 2015, at 18:41, Erich Dollansky erichsfreebsdl...@alogt.com wrote:

 Hi,
 
 On Sat, 30 May 2015 05:52:56 -0400
 Aryeh Friedman aryeh.fried...@gmail.com wrote:
 
 My desktop machine is 11-current and I want to down grade it to
 10-stable how do I do this without needing a reinstall?
 
 
 I did this several times from sources. Be aware of one problem which
 could be fatal. If you created a encrypted partition with GELI and you
 downgrade, the older version might not be able to handle the encryption
 of the newer version. This is not mentioned in the documentation.
 
 There might be also a catch with the mix of kernel/world. To avoid
 problems there, I ran both the installation of kernel and the world in
 one go.

Anything that modifies on-disk metadata is a no-go for downgrades, which 
includes UFS and ZFS as well…
Cheers,
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Need help reducing compilation warnings in CURRENT

[Garrett Cooper]

On May 30, 2015, at 19:15, Craig Rodrigues rodr...@freebsd.org wrote:

 On Thu, May 28, 2015 at 9:49 AM, Konstantin Belousov kostik...@gmail.com
 wrote:
 
 On Wed, May 27, 2015 at 11:30:45PM -0700, Craig Rodrigues wrote:
 
 I take some time to do a pass over mine code or code I am somewhat
 knowledgable, to correct some 'assigned but not used variable' warnings.
 There might be even one real bug in SU code uncovered, but I am not
 sure yet.
 
 Please review at https://reviews.freebsd.org/D2665 .
 I do not have an intention of splitting this into individual changes.
 
 
 Thanks for committing these fixes.
 Jenkins detected this as fixing 42 warnings:
 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/34/warnings17Result/
 
 Every little bit helps!

The -Wstrict-aliasing warnings are particularly useful, considering clang still 
doesn’t support this detection…
Thanks :)!
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: cam(4) timeouts in bhyve/kyua runs up on Jenkins?

[Garrett Cooper]

On Apr 28, 2015, at 0:54, Alexander Motin m...@freebsd.org wrote:

 Hi.
 
 On 27.04.2015 21:17, Garrett Cooper wrote:
 On Apr 27, 2015, at 11:16, Garrett Cooper yaneurab...@gmail.com
 wrote:
 
 I was looking at the console log for the latest kyua run and I’ve
 noticed that it’s timing out a bit more [1] than it was
 previously [2]. I’ve seen some of your commits recently to cam(4)
 dealing with bhyve — has there been a performance regression
 there? Thanks! -NGie
 
 1.
 https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/940/console
 2.
 https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/console
 
 (Sorry for not being more explicit for the archives) These are the
 timeouts I’m referring to:
 
 ahcich0: is  cs  ss 1f00 rs 1f00 tfd 50
 serr  cmd 1000dc17 (ada0:ahcich0:0:0:0):
 WRITE_FPDMA_QUEUED. ACB: 61 08 a8 54 1e 40 00 00 00 00 00 00
 (ada0:ahcich0:0:0:0): CAM status: Command timeout
 (ada0:ahcich0:0:0:0): Retrying command
 
 Last time I was more working on bhyve host disk emulation, rather then
 on cam(4) running on guest. Considering that, what guest and what host
 versions are you running? Is there any other load on host except this VM
 that could cause I/O delays high enough to trigger timeouts? What are
 you using to back the virtual disk (file, zvol, ...)?

I have no idea what the Jenkins slaves are running in terms of 
configuration/version/etc. You’ll have to ask jenkins-admin@…
Thanks!
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Linuxulator: CRASH

[Garrett Cooper]

On May 25, 2015, at 13:41, Larry Rosenman l...@lerctr.org wrote:

 I have a boinc-client installation running World Community Grid science
 that's been working fine for months.
 
 Updated to current -HEAD, and now we crash the kernel if it's running.
 
 The backtrace points to the linuxulator.
 
 Ideas?
 
 
 borg.lerctr.org dumped core - see /var/crash/vmcore.17
 
 Mon May 25 15:38:26 CDT 2015
 
 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #45 r283537: Mon 
 May 25 15:10:23 CDT 2015 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER 
  amd64
 
 panic: page fault
 
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 
 Unread portion of the kernel message buffer:
 
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 3; apic id = 03
 fault virtual address = 0xfe2e7240
 fault code= supervisor read data, page not present
 instruction pointer   = 0x20:0x80e96273
 stack pointer = 0x28:0xfe2eb49c7600
 frame pointer = 0x28:0xfe2eb49c7610
 code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags  = interrupt enabled, resume, IOPL = 0
 current process   = 1128 (wcgrid_fahv_vina_pr)
 trap number   = 12
 panic: page fault
 cpuid = 3
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe2eb49c7150
 vpanic() at vpanic+0x189/frame 0xfe2eb49c71d0
 panic() at panic+0x43/frame 0xfe2eb49c7230
 trap_fatal() at trap_fatal+0x379/frame 0xfe2eb49c7290
 trap_pfault() at trap_pfault+0x22e/frame 0xfe2eb49c7330
 trap() at trap+0x4b5/frame 0xfe2eb49c7540
 calltrap() at calltrap+0x8/frame 0xfe2eb49c7540
 --- trap 0xc, rip = 0x80e96273, rsp = 0xfe2eb49c7600, rbp = 
 0xfe2eb49c7610 ---
 copystr() at copystr+0x13/frame 0xfe2eb49c7610
 namei() at namei+0xdb/frame 0xfe2eb49c76d0
 kern_execve() at kern_execve+0x24c/frame 0xfe2eb49c7a20
 linux_common_execve() at linux_common_execve+0x84/frame 0xfe2eb49c7a60
 linux_execve() at linux_execve+0xad/frame 0xfe2eb49c7ae0
 ia32_syscall() at ia32_syscall+0x288/frame 0xfe2eb49c7bf0
 Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe2eb49c7bf0
 --- syscall (0, Linux ELF32, linux_nosys), rip = 0x8048110, rsp = 0xcca4, 
 rbp = 0 ---
 Uptime: 1m33s
 Dumping 2647 out of 64457 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
 
 Reading symbols from /boot/kernel/linux.ko.symbols...done.
 Loaded symbols for /boot/kernel/linux.ko.symbols
 Reading symbols from /boot/kernel/linux_common.ko.symbols...done.
 Loaded symbols for /boot/kernel/linux_common.ko.symbols
 Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
 Loaded symbols for /boot/kernel/if_lagg.ko.symbols
 Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done.
 Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols
 Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done.
 Loaded symbols for /boot/kernel/snd_spicds.ko.symbols
 Reading symbols from /boot/kernel/coretemp.ko.symbols...done.
 Loaded symbols for /boot/kernel/coretemp.ko.symbols
 Reading symbols from /boot/kernel/ichsmb.ko.symbols...done.
 Loaded symbols for /boot/kernel/ichsmb.ko.symbols
 Reading symbols from /boot/kernel/smbus.ko.symbols...done.
 Loaded symbols for /boot/kernel/smbus.ko.symbols
 Reading symbols from /boot/kernel/ichwd.ko.symbols...done.
 Loaded symbols for /boot/kernel/ichwd.ko.symbols
 Reading symbols from /boot/kernel/cpuctl.ko.symbols...done.
 Loaded symbols for /boot/kernel/cpuctl.ko.symbols
 Reading symbols from /boot/kernel/crypto.ko.symbols...done.
 Loaded symbols for /boot/kernel/crypto.ko.symbols
 Reading symbols from /boot/kernel/cryptodev.ko.symbols...done.
 Loaded symbols for /boot/kernel/cryptodev.ko.symbols
 Reading symbols from /boot/kernel/dtraceall.ko.symbols...done.
 Loaded symbols for /boot/kernel/dtraceall.ko.symbols
 Reading symbols from /boot/kernel/profile.ko.symbols...done.
 Loaded symbols for /boot/kernel/profile.ko.symbols
 Reading symbols from /boot/kernel/dtrace.ko.symbols...done.
 Loaded symbols for /boot/kernel/dtrace.ko.symbols
 Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done.
 Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols
 Reading symbols from /boot/kernel/systrace.ko.symbols...done.
 Loaded symbols for /boot/kernel/systrace.ko.symbols
 Reading symbols from /boot/kernel/sdt.ko.symbols...done.
 Loaded symbols for /boot/kernel/sdt.ko.symbols
 Reading symbols from /boot/kernel/lockstat.ko.symbols...done.
 Loaded symbols for 

Re: Slow shutdown

[Garrett Cooper]

On May 24, 2015, at 6:33, Ranjan1018 . 21474...@gmail.com wrote:

 On my laptop running r283297, after the message “All buffers synced.” and
 before “Uptime: …..” it takes more than 55 seconds.

Not a lot of info here to diagnose your issue...
- What happens if you hit control-t, i.e. what wait channel does it print out?
- What filesystems do you have mounted (fuse, NFS, UFS, ZFS)?
- What’s your root media (SSDs, SATA/PATA hard drives, etc)?

Thanks..


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #18 - Failure

[Garrett Cooper]

On May 24, 2015, at 16:08, jenkins-ad...@freebsd.org wrote:

 FreeBSD_HEAD_amd64_gcc4.9 - Build #18 - Failure:
 
 Check console output at 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/18/ to view the 
 results.

The failure’s caused by bad arguments being passed to objcopy for generating 
the linux .vdso, and will affect all amd64/i386 builds. I have a patch I’m 
testing out that I’ll throw up on Phabricator soon for this issue.
Thanks,


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #18 - Failure

[Garrett Cooper]

On May 24, 2015, at 16:35, Garrett Cooper yaneurab...@gmail.com wrote:

 On May 24, 2015, at 16:08, jenkins-ad...@freebsd.org wrote:
 
 FreeBSD_HEAD_amd64_gcc4.9 - Build #18 - Failure:
 
 Check console output at 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/18/ to view the 
 results.
 
 The failure’s caused by bad arguments being passed to objcopy for generating 
 the linux .vdso, and will affect all amd64/i386 builds. I have a patch I’m 
 testing out that I’ll throw up on Phabricator soon for this issue.
 Thanks,

Here’s the review… https://reviews.freebsd.org/D2641
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: am335x-bone.dts not exist

[Garrett Cooper]

On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote:

 On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote:
 
 # uname -a
 FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat
 May 23 11:56:46 MSK 2015
 root@des.local:/usr/obj/usr/src/sys/GENERIC  amd64
 
 I'm build BEAGLEBONE with crochet.
 
 build error
 
 Mounting UFS partition 1 at /usr/obj/_.mount.freebsd
 Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone
 Error: beaglebone.dts:29.1-2 syntax error
 FATAL ERROR: Unable to parse input tree
 
 
 file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include
 am335x-bone.dts but this file not existence. Need use am335x-evm.dts
 or else?
 
 
 am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI)
 
 I guess crochet does not have this path as include path when compiling
 dts files.

Pardon me for being a bit daft potentially, but shouldn’t #include work for all 
dts files (look for #include in this doc: 
http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
 )?
Thanks!



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: libiconv: compile error with gcc-4.9

[Garrett Cooper]

On May 20, 2015, at 0:09, Adrian Chadd adr...@freebsd.org wrote:

 Hi,
 
 I have the following compile error with gcc-4.9. Is there an issue
 with the macro/inline, or is it just dead code?
 
 --- citrus_prop.So ---
 /usr/local/bin/mips-portbld-freebsd11.0-gcc -isystem
 /home/adrian/work/freebsd/head-embedded/obj-gcc/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include
 -L/home/adrian/work/freebsd/head-embedded/obj-gcc/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/lib
 --sysroot=/home/adrian/work/freebsd/head-embedded/obj-gcc/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp
 -B/usr/local/mips-freebsd/bin/ -fpic -DPIC  -O -pipe -G0 -march=mips32
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/include
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/../../include
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/mips -DNLS
 -DSOFTFLOAT -D__DBINTERFACE_PRIVATE
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/../../contrib/gdtoa
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/../../contrib/libc-vis
 -DINET6 
 -I/home/adrian/work/freebsd/head-embedded/obj-gcc/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/resolv
 -D_ACL_PRIVATE -DPOSIX_MISTAKE
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/../libmd
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/../../contrib/jemalloc/include
 -DMALLOC_PRODUCTION
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/../../contrib/tzcode/stdtime
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/stdtime
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/locale
 -DBROKEN_DES -DPORTMAP -DDES_BUILTIN
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/rpc
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/mips/softfloat
 -I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/softfloat
 -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99
 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
 -Wno-pointer-sign   -c
 /usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/iconv/citrus_prop.c
 -o citrus_prop.So
 /usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/iconv/citrus_prop.c:
 In function '_citrus_prop_read_chr':
 /usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/iconv/citrus_prop.c:112:16:
 error: variable 'neg' set but not used
 [-Werror=unused-but-set-variable]
  int base, ch, neg; \
^
 /usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/iconv/citrus_prop.c:142:1:
 note: in expansion of macro '_CITRUS_PROP_READ_INT'
 _CITRUS_PROP_READ_INT(chr, int)
 ^
 /usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/iconv/citrus_prop.c:
 In function '_citrus_prop_read_num':
 /usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/iconv/citrus_prop.c:112:16:
 error: variable 'neg' set but not used
 [-Werror=unused-but-set-variable]
  int base, ch, neg; \
^
 /usr/home/adrian/work/freebsd/head-embedded/src/lib/libc/iconv/citrus_prop.c:143:1:
 note: in expansion of macro '_CITRUS_PROP_READ_INT'
 _CITRUS_PROP_READ_INT(num, uint64_t)
 ^

If I remember correctly, we obtained libiconv from netbsd. If so, was this 
fixed already by upstream?
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [283136]: buildworld failure: usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lproc

[Garrett Cooper]

On May 20, 2015, at 5:49, David Wolfskill da...@catwhisker.org wrote:

 On Wed, May 20, 2015 at 06:50:24AM +0200, O. Hartmann wrote:
 Current sources (r283136) die on buildworld with the following error:
 
 [...]
 --- cddl/lib__L ---
 /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lproc
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 *** [libdtrace.so.2] Error code 1
 
 
 I was able to perform a source update from:
 
 FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #67  
 r283104M/283104:1100073: Tue May 19 05:02:57 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64
 
 to:
 
 FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #68  
 r283142M/283142:1100073: Wed May 20 05:02:58 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64
 
 without incident.
 
 Checking https://docs.freebsd.org/mail/current/svn-src-head.html,
 it looks as if r283139 is intended to address what you saw, and
 r283143  - 283145 are additional clean-up.

The build *should* be fixed (for now, until someone changes 
LIBADD/LDADD for these libraries ._. ...) in r283152. Just to be doubly/triply 
sure I’ve kicked off a clean tinderbox on ref11-amd64 (I kind of rushed through 
an amd64/sparc64 buildworld and verified a few things manually when I was 
fixing things up).
Thank you for the report,
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [283136]: buildworld failure: usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lproc

[Garrett Cooper]

On May 20, 2015, at 6:09, Garrett Cooper yaneurab...@gmail.com wrote:

 On May 20, 2015, at 5:49, David Wolfskill da...@catwhisker.org wrote:
 
 On Wed, May 20, 2015 at 06:50:24AM +0200, O. Hartmann wrote:
 Current sources (r283136) die on buildworld with the following error:
 
 [...]
 --- cddl/lib__L ---
 /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lproc
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 *** [libdtrace.so.2] Error code 1
 
 
 I was able to perform a source update from:
 
 FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #67  
 r283104M/283104:1100073: Tue May 19 05:02:57 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64
 
 to:
 
 FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #68  
 r283142M/283142:1100073: Wed May 20 05:02:58 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64
 
 without incident.
 
 Checking https://docs.freebsd.org/mail/current/svn-src-head.html,
 it looks as if r283139 is intended to address what you saw, and
 r283143  - 283145 are additional clean-up.
 
   The build *should* be fixed (for now, until someone changes 
 LIBADD/LDADD for these libraries ._. ...) in r283152. Just to be 
 doubly/triply sure I’ve kicked off a clean tinderbox on ref11-amd64 (I kind 
 of rushed through an amd64/sparc64 buildworld and verified a few things 
 manually when I was fixing things up).
 Thank you for the report,

And… I missed a spot. r283159 should be a stable spot to work off of. Again, 
sorry for the breakage (6am commits are.. fun).
Thanks...



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: mergemaster failing with read-only /usr/src

[Garrett Cooper]

On May 4, 2015, at 7:05, John Baldwin j...@freebsd.org wrote:

 /etc is quite special as it isn't installed during installworld, only for
 distribution.  The tests should probably be part of installworld, so please
 move it.

Fixed in r283056 — pending MFC to stable/10. Thanks for the report!
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: UEFI, loader and keyboard problems

[Garrett Cooper]

On May 16, 2015, at 14:47, Allan Jude allanj...@freebsd.org wrote:

 On 2015-05-16 17:27, Dimitry Andric wrote:
 On 16 May 2015, at 18:50, Roman Bogorodskiy no...@freebsd.org wrote:
 
 I'm running -CURRENT amd64
 
 and have weird problems with keyboard in loader. Specifically, some char
 keys produce numbers. For example:
 
 boot -- b66t
 
 The problem appears to be with the right side of the query layout.
 
 'y' is still 'y', but 'u' becomes '4', 'i' becomes '5', etc. The same
 for the second row, 'h' is still 'h', but 'j' is '1' etc.
 
 Is this maybe some weird keyboard in combination with NUM LOCK on?
 
 -Dimitry
 
 
 That is a good insight, I know a lot of laptops have a 'numpad' feature
 where the keys on the right side of the keyboard can provide the
 functionality of the numpad when numlock is on or when a function modify
 key is depressed.

It also depends on the keyboard itself. US keyboards are fairly 
straightforward, but other ones are a bit more complex, e.g. Japanese keyboards.
Thanks!
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Increase BUFSIZ to 8192

[Garrett Cooper]

On May 14, 2015, at 1:06, Poul-Henning Kamp p...@phk.freebsd.dk wrote:

 
 In message 20150514075316.gy37...@funkthat.com, John-Mark Gurney writes:
 Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
 
 In message 20150514072155.gt37...@funkthat.com, John-Mark Gurney writes:
 
 Since you apprently missed my original reply, I said that we shouldn't
 abuse BUFSIZ for this work, and that it should be changed in mdXhl.c...
 
 Say what ?
 
 BUFSIZ is used entirely appropriately in MDXFileChunk():  For reading
 a file into an algorithm.
 
 In fact, posix-2008 references LINE_MAX because:
 
 MDXFileChunk() does not read lines, it reads an entire file.

Being pedantic, technically it’s a portion of a file, which can be the whole 
thing, and it reads it in “sizeof(buffer)” chunks (of which buffer is 
“hardcoded to BUFSIZ right now).
Cheers!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [RFC] Replace gnu groff in base by heirloom doctools

[Garrett Cooper]

On May 13, 2015, at 17:02, Baptiste Daroussin b...@freebsd.org wrote:

 Hi,
 
 I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirloom
 doctools.

…

Hi Bapt,
Do you have a list of items that require doctools [if groff isn’t 
present]?
Thanks!
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Increase BUFSIZ to 8192

[Garrett Cooper]

On May 14, 2015, at 1:01, Poul-Henning Kamp p...@phk.freebsd.dk wrote:

 
 In message 1431542835.1221.30.ca...@freebsd.org, Ian Lepore writes:
 On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
 
 As I've already pointed out, BUFSIZ appears in the
 base code over 2000 times.  Where is the analysis of the impact an 8x
 change is going to have on all those uses?
 
 Not to pick on Ian in particular, but I'm going to call bike-shed
 on this discussion now.
 
 Please just make it 4K on 32bit archs and 16K on 64 bit archs, and
 get on with your lives.
 
 If experience in -current (that's why developers run current, right ?!)
 documents that this was the wrong decision, we can revisit it.
 
 Until then:  Shut up and code.

Baptiste’s recommendation was related to md5 performance, so it might be that 
(as you pointed out with MDXFileChunk), things might be less performant in the 
application than they could be — but that’s an application bug (only helped by 
scaling issues with FreeBSD, potentially). Until performance has been 
characterized on 32-bit vs 64-bit architectures, blanket changing a value 
doesn’t make sense.

I think that changing buffers sized at BUFSIZ for md5/libmd5 probably makes a 
lot more sense as that change is isolated and the end result could be easily 
micro benchmarked. If/when we have an overall characterization we can look at 
increasing the value across the board.

Thanks!
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Race VT+X11 on -current

[Garrett Cooper]

 On May 7, 2015, at 21:34, Hans Petter Selasky h...@selasky.org wrote:
 
 Hi,
 
 I have a fix, attached.
 
 I'll just throw this in if nobody objects. Seems like a trivial issue:
 
 Prevent switching to NULL or own window in the vt_proc_window_switch
 function. This fixes an issue where X11 keyboard input can appear
 stuck. The cause of the problem is a duplicate TTY device window
 switch IOCTL during boot, which leaves the vt_switch_timer running,
 because the current window is already selected. While at it factor out
 some NULL checks.
 
 PR:200032
 Reported by:multiple people
 MFC after:1 week

Hi Hans,
Can you please toss that up on phabricator?
Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Race VT+X11 on -current

[Garrett Cooper]

 On May 7, 2015, at 09:43, Kevin Oberman rkober...@gmail.com wrote:
 
 On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky h...@selasky.org wrote:
 
 Hi,
 
 Sometimes when logging into X11 the keyboard input is not working.
 Pressing ALT+F9 makes it work. Any idea where the race is?
 
 --HPS
 
 Actually, I have found that switching to ANY other terminal (e.g. ALT-F2)
 and back to vty1 does the job.
 
 I must admit that this is a pretty minor annoyance, so I never got around
 to reporting it. Still, any bug report should show that it impacts multiple
 users.

Speaking of which, please file a bug for this issue so it doesn't get lost!
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Build failed in Jenkins: FreeBSD_HEAD #2725

[Garrett Cooper]

On May 4, 2015, at 10:38, Cy Schubert cy.schub...@komquats.com wrote:

 I think jenkins copy of head still contains ntp_parser.y. I see no issue
 here.
 
 Cy Schubert
 cy.schub...@cschubert.com
 
 You need to do a better job at figuring out why you broke things.
 This is not the first time you've broken things with an ntp import.

I don’t see that file either…

$ ls contrib/ntp/ntpd/ntp_parser.y
ls: contrib/ntp/ntpd/ntp_parser.y: No such file or directory
$ svnversion
282423M
$ svn status | grep -v \?
M   Makefile

Thanks,
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Build failed in Jenkins: FreeBSD_HEAD #2725

[Garrett Cooper]

On May 4, 2015, at 10:46, Garrett Cooper yaneurab...@gmail.com wrote:

 
 On May 4, 2015, at 10:38, Cy Schubert cy.schub...@komquats.com wrote:
 
 I think jenkins copy of head still contains ntp_parser.y. I see no issue
 here.
 
 Cy Schubert
 cy.schub...@cschubert.com
 
 You need to do a better job at figuring out why you broke things.
 This is not the first time you've broken things with an ntp import.
 
 I don’t see that file either…
 
 $ ls contrib/ntp/ntpd/ntp_parser.y
 ls: contrib/ntp/ntpd/ntp_parser.y: No such file or directory
 $ svnversion
 282423M
 $ svn status | grep -v \?
 M   Makefile
 
 Thanks,
 -NGie

That being said, I’m not sure if checking in bison-processed source was the 
wisest thing in the world (contrib/ntp/ntpd/ntp_parser.c).
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: mergemaster failing with read-only /usr/src

[Garrett Cooper]

On May 3, 2015, at 8:55, Wolfgang Zenker wolfg...@lyxys.ka.sub.org wrote:

 * Jilles Tjoelker jil...@stack.nl [150503 14:53]:
 On Sun, May 03, 2015 at 02:03:49PM +0200, Wolfgang Zenker wrote:
 I'm trying to update this system:
 FreeBSD pomona 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Mon Apr 13 03:48:04 
 CEST 2015 wolfgang@pomona:/usr/obj/usr/src/sys/UBQTERL mips
 
 Source for that was probably from about April 11th. I sucessfully built
 world and kernel, ran mergemaster -p and make installworld on rev 282299
 but then mergemaster fails with:
 
 # mergemaster -iFU
 
 *** Creating the temporary root environment in /var/tmp/temproot
 *** /var/tmp/temproot ready for use
 *** Creating and populating directory structure in /var/tmp/temproot
 
 /bin/sh: cannot create routing_test.tmp: Read-only file system
 
  *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to
  the temproot environment
 
 Filesystems are mounted like this:
 # mount
 /dev/da0s2a on / (ufs, local, noatime)
 devfs on /dev (devfs, local, multilabel)
 /dev/da0s1 on /boot (msdosfs, local)
 vulcan.lyx:/usr/src11 on /usr/src (nfs, read-only)
 vulcan.lyx:/var/obj/11/mips64 on /usr/obj (nfs)
 
 This used to work before. Any ideas, any further info I could provide?
 
 This broke after a test was added for etc/rc.d/. Without special code,
 this causes these tests to be built and installed as part of
 mergemaster/etcmerge, like other parts of etc.
 
 As a workaround you can do:
  echo make -C etc obj all | make buildenv
 on the build machine after make buildworld. Then mergemaster will work,
 even with a read-only /usr/obj.
 
 Well, I do build on that machine directly, and /usr/obj is mounted r/w,
 only /usr/src is a read-only mount. Trying the workaround on the machine
 istself does not help, unfortunately: while the make buildenv does
 work without a problem, mergemaster still fails in the same way.

I was going to move it to etc/tests soon since it wasn’t really testing 
/etc/rc.d/, but it makes more sense (with the issue above), just to create 
.../tests/etc, and move things there. I wish etc/ wasn’t such a special 
butterfly...


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Head buildworld @282213 fails; suspect r282211

[Garrett Cooper]

On Apr 29, 2015, at 8:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 Am Wed, 29 Apr 2015 05:47:18 -0700
 David Wolfskill da...@catwhisker.org schrieb:
 
 Running:
 
 FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46
 r282133M/282133:1100070: Tue Apr 28 05:39:53 PDT 2015
 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64
 
 After updating sources to r282213, buildworld fails:
 
 ...
 stage 4.4: building everything
 ...
 --- tests.all__D ---
 /usr/src/tests/sys/aio/aio_test.c:207:2: error: implicit declaration of 
 function
 'atf_skip' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
 ATF_REQUIRE_KERNEL_MODULE(aio); ^
 /usr/src/tests/freebsd_test_suite/macros.h:43:3: note: expanded from macro
 'ATF_REQUIRE_KERNEL_MODULE' atf_skip(module %s could not be resolved: %s,  
\
^
 1 error generated.
 *** [aio_test.o] Error code 1
 
 make[6]: stopped in /usr/src/tests/sys/aio
 
 ...
 --- tests.all__D ---
 /usr/src/tests/sys/aio/aio_test.c:207:2: error: implicit declaration of 
 function
 'atf_skip' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
 ATF_REQUIRE_KERNEL_MODULE(aio); ^
 /usr/src/tests/freebsd_test_suite/macros.h:43:3: note: expanded from macro
 'ATF_REQUIRE_KERNEL_MODULE' atf_skip(module %s could not be resolved: %s,  
\
^
 1 error generated.
 *** [aio_test.o] Error code 1
 
 make[6]: stopped in /usr/src/tests/sys/aio
 
 
 src.conf is:
 g1-254(11.0-C)[3] cat /etc/src.conf
 KERNCONF=CANARY
 PORTS_MODULES=x11/nvidia-driver
 PORTS_MODULES+=multimedia/cuse4bsd-kmod
 PORTS_MODULES+=emulators/virtualbox-ose-kmod
 WITHOUT_DEBUG_FILES=1
 IWN_DEBUG=1
 IEEE80211_DEBUG=1
 g1-254(11.0-C)[4]
 
 and make.conf:
 
 g1-254(11.0-C)[4] cat /etc/make.conf
 # CFLAGS+=  -g
 SENDMAIL_MC=/etc/mail/laptop.mc
 NET_SNMP_SYS_CONTACT=da...@catwhisker.org
 NET_SNMP_SYS_LOCATION=variable
 NET_SNMP_LOGFILE=/var/log/snmpd.log
 NET_SNMP_PERSISTENTDIR=/var/net-snmp
 WITH_BSD_JDK=TRUE
 FORCE_PKG_REGISTER= NO
 # For mplayer
 WITHOUT_RUNTIME_CPUDETECTION=   YES
 OPTIONS_SET=OPTIMIZED_CFLAGS
 WITHOUT_CJK=YES
 NO_SUID_XSERVER=YES
 INSTALL_AS_NCFTP=yes
 g1-254(11.0-C)[5]
 
 Peace,
 david
 
 Here the same with r282221.

Fixed in r282244 — sorry for the breakage :(.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #983

[Garrett Cooper]

I'll fix these tonight. Forgot to add appropriate modfind calls to these 
testcases, and GENERIC doesn't appear to have mqueuefs or aio built into it... 
Interesting data points.

 On Apr 27, 2015, at 11:27, jenkins-ad...@freebsd.org wrote:
 
 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: cam(4) timeouts in bhyve/kyua runs up on Jenkins?

[Garrett Cooper]

On Apr 27, 2015, at 11:16, Garrett Cooper yaneurab...@gmail.com wrote:

 Hi mav!
   I was looking at the console log for the latest kyua run and I’ve 
 noticed that it’s timing out a bit more [1] than it was previously [2]. I’ve 
 seen some of your commits recently to cam(4) dealing with bhyve — has there 
 been a performance regression there?
 Thanks!
 -NGie
 
 1. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/940/console
 2. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/console

(Sorry for not being more explicit for the archives)
These are the timeouts I’m referring to:

ahcich0: is  cs  ss 1f00 rs 1f00 tfd 50 serr  
cmd 1000dc17
(ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 a8 54 1e 40 00 00 00 00 00 
00
(ada0:ahcich0:0:0:0): CAM status: Command timeout
(ada0:ahcich0:0:0:0): Retrying command


signature.asc
Description: Message signed with OpenPGP using GPGMail

cam(4) timeouts in bhyve/kyua runs up on Jenkins?

[Garrett Cooper]

Hi mav!
I was looking at the console log for the latest kyua run and I’ve 
noticed that it’s timing out a bit more [1] than it was previously [2]. I’ve 
seen some of your commits recently to cam(4) dealing with bhyve — has there 
been a performance regression there?
Thanks!
-NGie

1. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/940/console
2. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/console


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Newer yacc needed for building world

[Garrett Cooper]

On Apr 24, 2015, at 2:59, Garrett Cooper yaneurab...@gmail.com wrote:

 On Apr 23, 2015, at 2:05, Willem Jan Withagen w...@digiware.nl wrote:
 
 On 22/04/2015 23:37, Ed Maste wrote:
 On 22 April 2015 at 15:55, Willem Jan Withagen w...@digiware.nl wrote:
 
 Yes:
 https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html
 
 
 But this is not enough to make yacc part of the build tools??
 
 yacc is unconditionally built during bootstrap-tools as of r281615.
 What SVN rev is your tree?
 
 
 # svn info
 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/stable/10
 Relative URL: ^/stable/10
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 281853
 Node Kind: directory
 Schedule: normal
 Last Changed Author: kib
 Last Changed Rev: 281849
 Last Changed Date: 2015-04-22 12:59:05 +0200 (Wed, 22 Apr 2015)
 
 Then I removed /usr/obj/* to get a fresh start.
 Removing yacc just gets me into trouble even earlier:
 
 # make -j 32 buildworld
 .
 .
 .
 --- _bootstrap-tools-usr.bin/compile_et ---
 --- parse.c ---
 yacc -d -o parse.c /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y
 yacc: not found
 --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree ---
 /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree created for
 /usr/src/usr.sbin/bsnmpd/gensnmptree
 --- _bootstrap-tools-usr.bin/compile_et ---
 *** [parse.c] Error code 127
 
 So I have relatively little further to test.
 Perhaps the '-j 32' was a bit aggressive, but it gets fast where the
 error is.
 
   Well, that’s amusing :(. You found a new race that wasn’t present 
 before my changes to parallelize bootstrap-tools (kerberos comes before yacc 
 in bootstrap-tools). Do you have yacc installed on your machine?
   Please try out this patch.
 Thanks!
 -NGie
 
 $ svn diff Makefile.inc1 
 Index: Makefile.inc1
 ===
 --- Makefile.inc1   (revision 281823)
 +++ Makefile.inc1   (working copy)
 @@ -1358,6 +1358,8 @@
usr.bin/compile_et
 
 .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g}
 +
 +${_bt}-usr.bin/compile_et: ${_bt}-usr.bin/yacc
 .endif
 
 bootstrap-tools: .PHONY

It’ll also need lex too. This should be a bit more comprehensive:

Index: Makefile.inc1
===
--- Makefile.inc1   (revision 281823)
+++ Makefile.inc1   (working copy)
@@ -1358,6 +1358,8 @@
usr.bin/compile_et
 
 .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g}
+
+${_bt}-usr.bin/compile_et: ${_bt}$-usr.bin/lex ${_bt}-usr.bin/yacc
 .endif
 
 bootstrap-tools: .PHONY


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: readdir/telldir/seekdir problem (i think)

[Garrett Cooper]

On Apr 24, 2015, at 3:42, Julian Elischer jul...@freebsd.org wrote:

 here's an interesting datapoint.  If the test program is run on kFreeBSD 
 using glibc, it runs without flaw.
 
 OS-X  (bsd derived libc) HFS+ fails
 FreeBSD libc (UFS) fails
 FreeBSD libc (ZFS) fails
 FreeBSD glibc  succceeds
 Centos 6.5 glibc succeeds
 
 some NFS tests would be nice to do too I guess...
 glibc authors seem to have done something right.. it even copes with FreeBSD 
 kernel..

Hi Julian,
What version of FreeBSD are you running (uname -a) / coming up with the 
above results on? I’m asking because IIRC there was an issue that pho@ brought 
up with readdir/telldir/etc that was fixed on CURRENT in the past 1-2 years for 
us, that might be affecting you.
Cheers,
-NGie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Newer yacc needed for building world

[Garrett Cooper]

On Apr 23, 2015, at 2:05, Willem Jan Withagen w...@digiware.nl wrote:

 On 22/04/2015 23:37, Ed Maste wrote:
 On 22 April 2015 at 15:55, Willem Jan Withagen w...@digiware.nl wrote:
 
 Yes:
 https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html
 
 
 But this is not enough to make yacc part of the build tools??
 
 yacc is unconditionally built during bootstrap-tools as of r281615.
 What SVN rev is your tree?
 
 
 # svn info
 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/stable/10
 Relative URL: ^/stable/10
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 281853
 Node Kind: directory
 Schedule: normal
 Last Changed Author: kib
 Last Changed Rev: 281849
 Last Changed Date: 2015-04-22 12:59:05 +0200 (Wed, 22 Apr 2015)
 
 Then I removed /usr/obj/* to get a fresh start.
 Removing yacc just gets me into trouble even earlier:
 
 # make -j 32 buildworld
 .
 .
 .
 --- _bootstrap-tools-usr.bin/compile_et ---
 --- parse.c ---
 yacc -d -o parse.c /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y
 yacc: not found
 --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree ---
 /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree created for
 /usr/src/usr.sbin/bsnmpd/gensnmptree
 --- _bootstrap-tools-usr.bin/compile_et ---
 *** [parse.c] Error code 127
 
 So I have relatively little further to test.
 Perhaps the '-j 32' was a bit aggressive, but it gets fast where the
 error is.

Well, that’s amusing :(. You found a new race that wasn’t present 
before my changes to parallelize bootstrap-tools (kerberos comes before yacc in 
bootstrap-tools). Do you have yacc installed on your machine?
Please try out this patch.
Thanks!
-NGie

$ svn diff Makefile.inc1 
Index: Makefile.inc1
===
--- Makefile.inc1   (revision 281823)
+++ Makefile.inc1   (working copy)
@@ -1358,6 +1358,8 @@
usr.bin/compile_et
 
 .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g}
+
+${_bt}-usr.bin/compile_et: ${_bt}-usr.bin/yacc
 .endif
 
 bootstrap-tools: .PHONY


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Newer yacc needed for building world

[Garrett Cooper]

On Apr 24, 2015, at 3:03, Garrett Cooper yaneurab...@gmail.com wrote:

 On Apr 24, 2015, at 2:59, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On Apr 23, 2015, at 2:05, Willem Jan Withagen w...@digiware.nl wrote:
 
 On 22/04/2015 23:37, Ed Maste wrote:
 On 22 April 2015 at 15:55, Willem Jan Withagen w...@digiware.nl wrote:
 
 Yes:
 https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html
 
 
 But this is not enough to make yacc part of the build tools??
 
 yacc is unconditionally built during bootstrap-tools as of r281615.
 What SVN rev is your tree?
 
 
 # svn info
 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/stable/10
 Relative URL: ^/stable/10
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 281853
 Node Kind: directory
 Schedule: normal
 Last Changed Author: kib
 Last Changed Rev: 281849
 Last Changed Date: 2015-04-22 12:59:05 +0200 (Wed, 22 Apr 2015)
 
 Then I removed /usr/obj/* to get a fresh start.
 Removing yacc just gets me into trouble even earlier:
 
 # make -j 32 buildworld
 .
 .
 .
 --- _bootstrap-tools-usr.bin/compile_et ---
 --- parse.c ---
 yacc -d -o parse.c /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y
 yacc: not found
 --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree ---
 /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree created for
 /usr/src/usr.sbin/bsnmpd/gensnmptree
 --- _bootstrap-tools-usr.bin/compile_et ---
 *** [parse.c] Error code 127
 
 So I have relatively little further to test.
 Perhaps the '-j 32' was a bit aggressive, but it gets fast where the
 error is.
 
  Well, that’s amusing :(. You found a new race that wasn’t present 
 before my changes to parallelize bootstrap-tools (kerberos comes before yacc 
 in bootstrap-tools). Do you have yacc installed on your machine?
  Please try out this patch.
 Thanks!
 -NGie
 
 $ svn diff Makefile.inc1 
 Index: Makefile.inc1
 ===
 --- Makefile.inc1   (revision 281823)
 +++ Makefile.inc1   (working copy)
 @@ -1358,6 +1358,8 @@
   usr.bin/compile_et
 
 .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g}
 +
 +${_bt}-usr.bin/compile_et: ${_bt}-usr.bin/yacc
 .endif
 
 bootstrap-tools: .PHONY
 
 It’ll also need lex too. This should be a bit more comprehensive:
 
 Index: Makefile.inc1
 ===
 --- Makefile.inc1   (revision 281823)
 +++ Makefile.inc1   (working copy)
 @@ -1358,6 +1358,8 @@
usr.bin/compile_et
 
 .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g}
 +
 +${_bt}-usr.bin/compile_et: ${_bt}$-usr.bin/lex ${_bt}-usr.bin/yacc
 .endif
 
 bootstrap-tools: .PHONY

I’ll work out the finally kinks with how to spell lex and yacc…

This is part of the reason why I think BOOTSTRAPPING needs to be kicked to the 
curb and everything needs to be built in parallel, but enough people haven’t 
complained about built failures, so the optimization remains..


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Error in parallel building

[Garrett Cooper]

On Apr 21, 2015, at 3:00, Willem Jan Withagen w...@digiware.nl wrote:

 Hi,
 
 With a freshly fetched HEAD, and 'make -j 8 buildworld'  I get:
 
 
 --- _bootstrap-tools-kerberos5/lib/libvers ---
 --- roken.h ---
 make-roken  roken.h
 make-roken: not found
 --- _bootstrap-tools-kerberos5/tools/make-roken ---
 --- make-roken.c ---
 awk -f 
 /usr/srcs/head/kerberos5/tools/make-roken/../../../crypto/heimdal/lib/roken/roken.awk
  
 /usr/srcs/head/kerberos5/tools/make-roken/../../../crypto/heimdal/lib/roken/roken.h.in
   make-roken.c
 --- _bootstrap-tools-kerberos5/lib/libvers ---
 *** [roken.h] Error code 127
 
 make[3]: stopped in /usr/srcs/head/kerberos5/lib/libvers
 1 error

I’m really sorry for not catching this sooner :(… I missed the part about 
MAKE_ROKEN in libvers.

All of kerberos5 built during bootstrap-tools is basically serialized in an 
implicit manner, so I’ve committed the following item to resolve the build 
issue you’ve noted.

Thank you for the feedback,
-NGie


r281823 | ngie | 2015-04-21 03:17:25 -0700 (Tue, 21 Apr 2015) | 9 lines

Serialize all of _kerberos5_bootstrap_tools to avoid build failures involving
make bootstrap-tools

On the plus side, this also greatly reduces complexity

MFC after: 1 week
Pointyhat to: ngie
Reported by: Willem Jan Withagen w...@digiware.nl


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Error in parallel building

[Garrett Cooper]

On Apr 21, 2015, at 3:20, Willem Jan Withagen w...@digiware.nl wrote:

 Long time that I saw a pointy hat coming by :)
 Usually I'm the one on the receiving end.

Happens :) (especially when I’m not as careful/pedantic as I can be 
sometimes..).
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Build failed in Jenkins: FreeBSD_HEAD #2663

[Garrett Cooper]

 On Apr 18, 2015, at 15:56, jenkins-ad...@freebsd.org wrote:


 === lib/libpmc (all)
 --- libpmc.So ---
 cc  -fpic -DPIC  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers 
 -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
 -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
 -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
 -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int 
 -Wno-unused-const-variable -Qunused-arguments -c 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c -o 
 libpmc.So
 --- pmclog.So ---
 cc  -fpic -DPIC  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers 
 -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
 -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
 -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
 -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int 
 -Wno-unused-const-variable -Qunused-arguments -c 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/pmclog.c -o 
 pmclog.So
 --- libpmc.So ---
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:302:1: 
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean 
 'PMC_CLASS_P5'?
 PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500, PMC_CLASS_TSC);
 ^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:273:3: 
 note: expanded from macro 'PMC_MDEP_TABLE'
PMC_CLASS_##C, __VA_ARGS__  \
^
 scratch space:64:1: note: expanded from here
 PMC_CLASS_E500
 ^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
  note: 'PMC_CLASS_P5' declared here
__PMC_CLASSES()
^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
  note: expanded from macro '__PMC_CLASSES'
__PMC_CLASS(P5) /* Intel Pentium counters */\
^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
  note: expanded from macro '__PMC_CLASS'
 #define __PMC_CLASS(N)  PMC_CLASS_##N ,
^
 scratch space:46:1: note: expanded from here
 PMC_CLASS_P5
 ^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:302:44: 
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean 
 'PMC_CLASS_P5'?
 PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500, PMC_CLASS_TSC);
   ^~
   PMC_CLASS_P5
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:273:18: 
 note: expanded from macro 'PMC_MDEP_TABLE'
PMC_CLASS_##C, __VA_ARGS__  \
   ^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
  note: 'PMC_CLASS_P5' declared here
__PMC_CLASSES()
^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
  note: expanded from macro '__PMC_CLASSES'
__PMC_CLASS(P5) /* Intel Pentium counters */\
^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
  note: expanded from macro '__PMC_CLASS'
 #define __PMC_CLASS(N)  PMC_CLASS_##N ,
^
 scratch space:46:1: note: expanded from here
 PMC_CLASS_P5
 ^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:2961:7: 
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean 
 'PMC_CLASS_P5'?
case PMC_CLASS_E500:
 ^~
 PMC_CLASS_P5
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
  note: 'PMC_CLASS_P5' declared here
__PMC_CLASSES()
^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
  note: expanded from macro '__PMC_CLASSES'
__PMC_CLASS(P5) /* Intel Pentium counters */\
^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
  note: expanded from macro '__PMC_CLASS'
 #define __PMC_CLASS(N)  PMC_CLASS_##N ,
^
 scratch space:46:1: note: expanded from here
 PMC_CLASS_P5
 ^
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:2961:7: 
 error: duplicate case value 'PMC_CLASS_P5'
case PMC_CLASS_E500:
 ^
 

Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #928

[Garrett Cooper]

On Apr 13, 2015, at 11:07, jenkins-ad...@freebsd.org wrote:

 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/928/

…

 kyua report --verbose --results-filter passed,skipped,xfail,broken,failed  
 --output test-report.txt
 kyua: E: Load of 'Kyuafile' failed: Failed to load Lua file 'Kyuafile': 
 Kyuafile:49: Load of 'lib/Kyuafile' failed: Failed to load Lua file 
 'lib/Kyuafile': lib/Kyuafile:49: Load of 'lib/libthr/Kyuafile' failed: Failed 
 to load Lua file 'lib/libthr/Kyuafile': lib/libthr/Kyuafile:26: Non-existent 
 test program 'lib/libthr/atexit_test'.
 kyuatestprompt # kyua report-junit --output=test-report.xml
 kyua report --verbose --results-filter passed,skipped,xfail,bro ken,failed  
 --output test-report.txt
 
 kyua: E: No previous results file found for test suite usr_tests.
 kyuatestprompt # kyua report-junit --output=test-report.xmlshutdown -p now
 
 
 kyua: E: No previous results file found for test suite usr_tests.
 kyuatestprompt # shutdown -p now
 
 Shutdown NOW!
 shutdown: [pid 664]
 kyuatestprompt #  
   

...

 Waiting (max 60 seconds) for system process `vnlru' to stop...done
 Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
 Waiting (max 60 seconds) for system process `syncer' to stop...
 Syncing disks, vnodes remaining...0 0 done
 All buffers synced.
 lock order reversal:
 1st 0xf800062d2068 ufs (ufs) @ 
 /builds/FreeBSD_HEAD/sys/kern/vfs_mount.c:1229
 2nd 0xf800061a15f0 devfs (devfs) @ 
 /builds/FreeBSD_HEAD/sys/kern/vfs_subr.c:2176
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007bdea650
 witness_checkorder() at witness_checkorder+0xe26/frame 0xfe007bdea6e0
 __lockmgr_args() at __lockmgr_args+0xa5c/frame 0xfe007bdea810
 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe007bdea830
 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe007bdea860
 _vn_lock() at _vn_lock+0x9a/frame 0xfe007bdea8d0
 vget() at vget+0x67/frame 0xfe007bdea910
 devfs_allocv() at devfs_allocv+0xfd/frame 0xfe007bdea960
 devfs_root() at devfs_root+0x43/frame 0xfe007bdea990
 dounmount() at dounmount+0x342/frame 0xfe007bdeaa10
 vfs_unmountall() at vfs_unmountall+0x61/frame 0xfe007bdeaa40
 kern_reboot() at kern_reboot+0x4f6/frame 0xfe007bdeaac0
 sys_reboot() at sys_reboot+0x58/frame 0xfe007bdeaae0
 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe007bdeabf0
 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe007bdeabf0
 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40fabc, rsp = 
 0x7fffe718, rbp = 0x7fffe810 ---
 Uptime: 16s
 acpi0: Powering system off
 + sudo python /vm/freebsd-ci/scripts/test/extract-test-logs.py -f 
 /vm/freebsd-ci/scripts/test/config/config.json
 cp: /tmp/tmp8uNnu_/usr/tests/*.xml: No such file or directory
 mdconfig -a -u 99 -t vnode -f 
 /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img
 umount /tmp/tmp8uNnu_
 mdconfig -d -u 99
 Recording test results
 ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to 
 exception
 hudson.AbortException: Test reports were found but none of them are new. Did 
 tests run? 
 For example, 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/ws/test-report.xml is 
 10 days old
 
   at hudson.tasks.junit.TestResult.parse(TestResult.java:178)
   at hudson.tasks.junit.TestResult.parse(TestResult.java:146)
   at hudson.tasks.junit.TestResult.init(TestResult.java:122)
   at 
 hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119)
   at 
 hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:93)
   at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688)
   at hudson.remoting.UserRequest.perform(UserRequest.java:121)
   at hudson.remoting.UserRequest.perform(UserRequest.java:49)
   at hudson.remoting.Request$2.run(Request.java:325)
   at 
 hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:745)
   at ..remote call to havoc.ysv.freebsd.org(Native Method)
   at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1360)
   at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
   at hudson.remoting.Channel.call(Channel.java:753)
   at hudson.FilePath.act(FilePath.java:978)
   at hudson.FilePath.act(FilePath.java:967)
   at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90)
   at 
 hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120)
   at 
 

Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i

[Garrett Cooper]

On Apr 8, 2015, at 1:47, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote:

 On Wed, Apr 8, 2015 at 1:08 AM, Garrett Cooper yaneurab...@gmail.com wrote:
 On Apr 8, 2015, at 0:49, Garrett Cooper yaneurab...@gmail.com wrote:
 
  On Apr 7, 2015, at 19:35, Konstantin Belousov kostik...@gmail.com wrote:
 
  On Tue, Apr 07, 2015 at 12:04:44PM -0700, Garrett Cooper wrote:
  Hi,
  I just tried to upgrade my system from a Nehalem style era 
  CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style 
  CPU/motherboard (an E-series Haswell/Z97 motherboard), and I?ve run into 
  some fun issues with my LSI 9240-4i controller. In particular, it?s 
  timing out because of issues noted similar to here: 
  https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html
   . I?ve done the following so far to try and diagnose the issue:
  - Upgraded the firmware on the card and in the BIOS
  - Tweaked with the PCI-E settings (2.0/3.0; disabled power savings 
  mode in the BIOS; etc)
  - Turned off 4GB ?remapping? on the PCM.
  - Booted USB key fob-based images running: 9.3-RELEASE, 10.1-RELEASE, 
  10-STABLE, 11-CURRENT
  - Booted my original drive running 9.3-RELEASE
  - Booted with hw.mfi.msi=0 set in loader.
  - Booted with boot -v.
  One more thing to try, is to put the card into PCIe slot handled by the
  south bridge instead of the CPU slot.
 
  I have two Drake Skinnies card which I cannot use, since all my machines
  are desktop class, and the only available PCIe 8x+ slots are connected
  to CPU.  I was never able to get a satisfactory explanation why the
  thing does not like CPU' PCIe.
 
  Northbridge, Southbridge, didn’t seem to matter :/… I’ve tried all 3 PCI-E 
  slots to no avail.
 
  One thing that I’m thinking might be a problem is the fact that it’s 
  sharing resources between the onboard graphics and the storage controller, 
  and plus the other two slots were supposedly dedicated for storage purposes 
  or some such (NVME, etc).
 
  Guess I’ll try neutering the onboard GPU and see what happens...
 
 Nope. Still timing out with onboard GPU off… I give up with this 
 motherboard...
 
 
 
 If your motherboard is not listed in the following lists as suitable for 
 Linux , it may cause problems under Unix like operating systems :
 
 
 
 http://www.asus.com/Static_WebPage/OS_Compatibility/
 http://www.asus.com/websites/global/aboutASUS/OS/Linux1410.pdf
 http://www.asus.com/Static_WebPage/Server/

It booted both FreeBSD/Linux without my controller — the hardware compatibility 
with it just sucks.

Email back from ASUS, “it’s not in our compatibility list. Use another card”. 
Uh, yeah… right. Not going to dump another $300 in an LSI card and redo my 
RAID. Guess I’ll purchase another motherboard.

Thank you for the input everyone. I’ll leave a helpful review on Newegg so 
others don’t stumble on this either.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i

[Garrett Cooper]

On Apr 7, 2015, at 19:35, Konstantin Belousov kostik...@gmail.com wrote:

 On Tue, Apr 07, 2015 at 12:04:44PM -0700, Garrett Cooper wrote:
 Hi,
  I just tried to upgrade my system from a Nehalem style era 
 CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style CPU/motherboard 
 (an E-series Haswell/Z97 motherboard), and I?ve run into some fun issues 
 with my LSI 9240-4i controller. In particular, it?s timing out because of 
 issues noted similar to here: 
 https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html 
 . I?ve done the following so far to try and diagnose the issue:
  - Upgraded the firmware on the card and in the BIOS
  - Tweaked with the PCI-E settings (2.0/3.0; disabled power savings mode 
 in the BIOS; etc)
  - Turned off 4GB ?remapping? on the PCM.
  - Booted USB key fob-based images running: 9.3-RELEASE, 10.1-RELEASE, 
 10-STABLE, 11-CURRENT
  - Booted my original drive running 9.3-RELEASE
  - Booted with hw.mfi.msi=0 set in loader.
  - Booted with boot -v.
 One more thing to try, is to put the card into PCIe slot handled by the
 south bridge instead of the CPU slot.
 
 I have two Drake Skinnies card which I cannot use, since all my machines
 are desktop class, and the only available PCIe 8x+ slots are connected
 to CPU.  I was never able to get a satisfactory explanation why the
 thing does not like CPU' PCIe.

Northbridge, Southbridge, didn’t seem to matter :/… I’ve tried all 3 PCI-E 
slots to no avail.

One thing that I’m thinking might be a problem is the fact that it’s sharing 
resources between the onboard graphics and the storage controller, and plus the 
other two slots were supposedly dedicated for storage purposes or some such 
(NVME, etc).

Guess I’ll try neutering the onboard GPU and see what happens...


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i

[Garrett Cooper]

On Apr 7, 2015, at 12:04, Garrett Cooper yaneurab...@gmail.com wrote:

 Hi,
   I just tried to upgrade my system from a Nehalem style era 
 CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style CPU/motherboard 
 (an E-series Haswell/Z97 motherboard), and I’ve run into some fun issues with 
 my LSI 9240-4i controller. In particular, it’s timing out because of issues 
 noted similar to here: 
 https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html . 
 I’ve done the following so far to try and diagnose the issue:
   - Upgraded the firmware on the card and in the BIOS
   - Tweaked with the PCI-E settings (2.0/3.0; disabled power savings mode 
 in the BIOS; etc)
   - Turned off 4GB “remapping” on the PCM.
   - Booted USB key fob-based images running: 9.3-RELEASE, 10.1-RELEASE, 
 10-STABLE, 11-CURRENT
   - Booted my original drive running 9.3-RELEASE
   - Booted with hw.mfi.msi=0 set in loader.
   - Booted with boot -v.
   Every time I run into MFI send command timeouts that eventually turn 
 into 
   Here’s the message I got (transcribed) with 11-CURRENT with boot -v:
 
 mfi0: Drake Skinny port 0xe000-0xe0ff mem 0xdfc6-0x…. on pci2
 mfi0: attempting to allocate 1 MSI vectors (1 supported)
 pci: routing MSI IRQ 264 to local APIC 0 vector 59
 mfi0: using IRQ 264 for MSI
 mfi0: using MSI
 mfi0: Megaraid SAS driver Ver 4.23
 mfi0: Frame 0xfe07f719f280 timed out command 0x101
 Error 60 in callback from mfi_send_frame
 
   The complete screenshot for that timeout can be found here: 
 https://people.freebsd.org/~ngie/mfi-timeout-boot-verbose.jpg
   What I haven’t done yet:
   - Exporting the volume with the old motherboard and importing it with 
 the new motherboard (I need to do some reading before I do this though 
 because I don’t want to toast my data by accident :(…).
   - Booted either Linux or Windows to make sure the controller works with 
 the motherboard

CentOS 7.1 release is no bueno either with similar errors. So it’s most likely 
a hardware compatibility issue.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i

[Garrett Cooper]

On Apr 8, 2015, at 0:49, Garrett Cooper yaneurab...@gmail.com wrote:

 On Apr 7, 2015, at 19:35, Konstantin Belousov kostik...@gmail.com wrote:
 
 On Tue, Apr 07, 2015 at 12:04:44PM -0700, Garrett Cooper wrote:
 Hi,
 I just tried to upgrade my system from a Nehalem style era 
 CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style CPU/motherboard 
 (an E-series Haswell/Z97 motherboard), and I?ve run into some fun issues 
 with my LSI 9240-4i controller. In particular, it?s timing out because of 
 issues noted similar to here: 
 https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html 
 . I?ve done the following so far to try and diagnose the issue:
 - Upgraded the firmware on the card and in the BIOS
 - Tweaked with the PCI-E settings (2.0/3.0; disabled power savings mode 
 in the BIOS; etc)
 - Turned off 4GB ?remapping? on the PCM.
 - Booted USB key fob-based images running: 9.3-RELEASE, 10.1-RELEASE, 
 10-STABLE, 11-CURRENT
 - Booted my original drive running 9.3-RELEASE
 - Booted with hw.mfi.msi=0 set in loader.
 - Booted with boot -v.
 One more thing to try, is to put the card into PCIe slot handled by the
 south bridge instead of the CPU slot.
 
 I have two Drake Skinnies card which I cannot use, since all my machines
 are desktop class, and the only available PCIe 8x+ slots are connected
 to CPU.  I was never able to get a satisfactory explanation why the
 thing does not like CPU' PCIe.
 
 Northbridge, Southbridge, didn’t seem to matter :/… I’ve tried all 3 PCI-E 
 slots to no avail.
 
 One thing that I’m thinking might be a problem is the fact that it’s sharing 
 resources between the onboard graphics and the storage controller, and plus 
 the other two slots were supposedly dedicated for storage purposes or some 
 such (NVME, etc).
 
 Guess I’ll try neutering the onboard GPU and see what happens...

Nope. Still timing out with onboard GPU off… I give up with this motherboard...


signature.asc
Description: Message signed with OpenPGP using GPGMail

mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i

[Garrett Cooper]

Hi,
I just tried to upgrade my system from a Nehalem style era 
CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style CPU/motherboard (an 
E-series Haswell/Z97 motherboard), and I’ve run into some fun issues with my 
LSI 9240-4i controller. In particular, it’s timing out because of issues noted 
similar to here: 
https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html . 
I’ve done the following so far to try and diagnose the issue:
- Upgraded the firmware on the card and in the BIOS
- Tweaked with the PCI-E settings (2.0/3.0; disabled power savings mode 
in the BIOS; etc)
- Turned off 4GB “remapping” on the PCM.
- Booted USB key fob-based images running: 9.3-RELEASE, 10.1-RELEASE, 
10-STABLE, 11-CURRENT
- Booted my original drive running 9.3-RELEASE
- Booted with hw.mfi.msi=0 set in loader.
- Booted with boot -v.
Every time I run into MFI send command timeouts that eventually turn 
into 
Here’s the message I got (transcribed) with 11-CURRENT with boot -v:

mfi0: Drake Skinny port 0xe000-0xe0ff mem 0xdfc6-0x…. on pci2
mfi0: attempting to allocate 1 MSI vectors (1 supported)
pci: routing MSI IRQ 264 to local APIC 0 vector 59
mfi0: using IRQ 264 for MSI
mfi0: using MSI
mfi0: Megaraid SAS driver Ver 4.23
mfi0: Frame 0xfe07f719f280 timed out command 0x101
Error 60 in callback from mfi_send_frame

The complete screenshot for that timeout can be found here: 
https://people.freebsd.org/~ngie/mfi-timeout-boot-verbose.jpg
What I haven’t done yet:
- Exporting the volume with the old motherboard and importing it with 
the new motherboard (I need to do some reading before I do this though because 
I don’t want to toast my data by accident :(…).
- Booted either Linux or Windows to make sure the controller works with 
the motherboard
- Tried clearing events with the controller
Does anyone have any thoughts or hints on this issue?
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT

[Garrett Cooper]

 On Mar 30, 2015, at 10:38, bsdml pietro.bs...@gmail.com wrote:
 
 Hey wolfgang,
 
 thanks for getting back to me. Adding hint.ata.1.disabled=1 in 
 /boot/device.hints indeed did the trick and allowed me to boot both 10.1 and 
 11-CURRENT, however this workaround has temporary solved my problem but 
 brings up to another headache. I have planned to get a bay caddy and swap the 
 cdrom drive with a 7.200 rpm SATA hdd, but doing this way disabling the 
 second SATA channel I will be unable to achieve such a thing.
 
 Is there a chance that the bay caddy ATA will work without the need to 
 disable the second ATA channel?

Has a bug been filed for this issue?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Garrett Cooper]

On Mar 22, 2015, at 14:36, Dimitry Andric d...@freebsd.org wrote:

 On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
 
 Ah right, that was on i386, on amd64 it does result in -2^63.  It is indeed 
 caused by reliance on signed integer wrapping.
 
 This diff should fix it, without rewriting the utility:
 
 Index: bin/expr/Makefile
 ===
 --- bin/expr/Makefile   (revision 280156)
 +++ bin/expr/Makefile   (working copy)
 @@ -6,6 +6,9 @@ PROG=   expr
 SRCS=  expr.y
 YFLAGS=
 
 +# expr relies on signed integer wrapping
 +CFLAGS+= -fwrapv
 +
 NO_WMISSING_VARIABLE_DECLARATIONS=
 
 .if ${MK_TESTS} != no
 
 
 Well, another alternative is to patch expr.y:
 
 Index: expr.y
 ===
 --- expr.y  (revision 280353)
 +++ expr.y  (working copy)
 @@ -393,7 +393,7 @@
 }
 
 void
 -assert_plus(intmax_t a, intmax_t b, intmax_t r)
 +assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
 {
/*
 * sum of two positive numbers must be positive,
 @@ -420,7 +420,7 @@
 }
 
 void
 -assert_minus(intmax_t a, intmax_t b, intmax_t r)
 +assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
 {
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN  a  0)
 
 
 There were already some patches previously done to this
 file to add volatile, so maybe this would be OK to do.
 
 What do you think?
 
 Volatile is not the solution, it is completely orthogonal.  The correct
 way would be to use unsigned integers, for which wrapping is defined,
 then convert those back and forth when presenting the results to the
 user.

Before doing that — what changed in the past week that changed the behavior of 
expr?
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Garrett Cooper]

On Mar 22, 2015, at 14:02, Craig Rodrigues rodr...@freebsd.org wrote:

 On Sun, Mar 22, 2015 at 11:26 AM, jenkins-ad...@freebsd.org wrote:
 
 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/867/
 
 
 Can someone with toolchain expertise look at this?
 After the clang 3.6.1 import, /bin/expr behaves differently.
 
 With clang 3.5.0:
 
 # expr 4611686018427387904 + 4611686018427387904
 expr: overflow
 
 With clang 3.6.1:
 
 # expr 4611686018427387904 + 4611686018427387904
 -9223372036854775808

I suspect -fwrapv is at fault, but I need to do some digging first..
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Garrett Cooper]

On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote:

...

 OK, converting expr.y to use unsigned integers would require a bit of work.
 
 Can you commit your patch to the Makefile?  It fixes the problem for now.

+1

I’d still like to know why clang 3.5 doesn’t have this behavior though — there 
might be other potential issues lurking around that need to be solved (either 
here, in ports, or both).

Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: What's the official method to test the build now?

[Garrett Cooper]

On Mar 21, 2015, at 5:32, Ryan Stone ryst...@gmail.com wrote:

 I still see the compile errors that I reported here:
 
 https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054803.html
 
 It affects these builds:
 
 sparc64 LINT kernel failed, check _.sparc64.LINT for details
 powerpc LINT kernel failed, check _.powerpc.LINT for details
 powerpc LINT64 kernel failed, check _.powerpc.LINT64 for details
 i386 LINT-NOINET kernel failed, check _.i386.LINT-NOINET for details
 i386 LINT-NOINET6 kernel failed, check _.i386.LINT-NOINET6 for details
 i386 LINT kernel failed, check _.i386.LINT for details
 i386 LINT-NOIP kernel failed, check _.i386.LINT-NOIP for details
 i386 LINT-VIMAGE kernel failed, check _.i386.LINT-VIMAGE for details

The only issues I ran into were with ixl(4) on powerpc* using 
ref10-amd64.freebsd.org: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198805 . I think the other 
issues have been solved.
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Garrett Cooper]

On Mar 22, 2015, at 15:09, Dimitry Andric d...@freebsd.org wrote:

 On 22 Mar 2015, at 23:04, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote:
 
 ...
 
 OK, converting expr.y to use unsigned integers would require a bit of work.
 
 Can you commit your patch to the Makefile?  It fixes the problem for now.
 
 +1
 
 I’d still like to know why clang 3.5 doesn’t have this behavior though — 
 there might be other potential issues lurking around that need to be solved 
 (either here, in ports, or both).
 
 Because this version optimizes better around undefined behavior.  There
 are most likely many issues lurking around, and most certainly in ports.
 
 I would recommend using UBSan to tackle this kind of thing.

I hope this got a ports tinderbox run first… Adding UBSan to tinderbox runs for 
toolchain upgrades [in the future] might be a good idea.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: What's the official method to test the build now?

[Garrett Cooper]

 On Mar 21, 2015, at 06:35, Ian Lepore i...@freebsd.org wrote:
 
 On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote:
 make tinderbox has been broken for weeks, so I presume it's not what I'm
 supposed to be using to test my commits anymore.  What's the officially
 supported make target that I'm supposed to use?
 
 I use make universe, sometimes with the -DMAKE_JUST_KERNELS option.

make universe doesn't error out; make tinderbox does however.

 But the LINT kernels for x86 and sparc have been broken since January.

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

Re: What's the official method to test the build now?

[Garrett Cooper]

On Mar 21, 2015, at 12:37, Dimitry Andric d...@freebsd.org wrote:

 On 21 Mar 2015, at 17:25, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On Mar 21, 2015, at 06:35, Ian Lepore i...@freebsd.org wrote:
 
 On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote:
 make tinderbox has been broken for weeks, so I presume it's not what I'm
 supposed to be using to test my commits anymore.  What's the officially
 supported make target that I'm supposed to use?
 
 I use make universe, sometimes with the -DMAKE_JUST_KERNELS option.
 
 make universe doesn't error out; make tinderbox does however.
 
 But the LINT kernels for x86 and sparc have been broken since January.
 
 So what's the effective difference between universe and tinderbox then?
 I've built quite a number of universes recently, and I while I did get a
 few errors, they were usually fixed quite quickly.
 
 Also, universe generates LINT kernel configurations, and builds them.  I
 didn't see errors there either...  Does tinderbox generate LINT configs
 differently, somehow?

universe gets called by tinderbox. From Makefile:

  6 # universe- *Really* build *everything* (buildworld and
  7 #   all kernels on all architectures).
  8 # tinderbox   - Same as universe, but presents a list of failed 
build
  9 #   targets and exits with an error if there were any.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #853

[Garrett Cooper]

On Mar 17, 2015, at 1:46, jenkins-ad...@freebsd.org wrote:

 See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/

…

 lib/libc/sys/clock_gettime_test:clock_gettime_real  -  panic: wrote past end 
 of sbuf (0 = 0)
 cpuid = 0
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe009748b760
 vpanic() at vpanic+0x189/frame 0xfe009748b7e0
 kassert_panic() at kassert_panic+0x132/frame 0xfe009748b850
 sbuf_set_drain() at sbuf_set_drain+0x28/frame 0xfe009748b880
 sbuf_new_for_sysctl() at sbuf_new_for_sysctl+0x29/frame 0xfe009748b8a0
 sysctl_kern_timecounter_choice() at sysctl_kern_timecounter_choice+0x18/frame 
 0xfe009748b900
 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x94/frame 
 0xfe009748b940
 sysctl_root() at sysctl_root+0x188/frame 0xfe009748b990
 userland_sysctl() at userland_sysctl+0x192/frame 0xfe009748ba30
 sys___sysctl() at sys___sysctl+0x74/frame 0xfe009748bae0
 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe009748bbf0
 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe009748bbf0
 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x800b77b0a, rsp = 
 0x7fffa938, rbp = 0x7fffa970 ---
 KDB: enter: panic
 [ thread pid 4557 tid 100062 ]
 Stopped at  kdb_enter+0x3e: movq$0,kdb_why
 db Slave went offline during the build
 ERROR: Connection was broken: java.io.IOException: Unexpected reader 
 termination
   at 
 hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:76)
 Caused by: java.lang.OutOfMemoryError: PermGen space
   at java.lang.Class.getDeclaredConstructors0(Native Method)
   at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
   at java.lang.Class.getConstructor0(Class.java:2885)
   at java.lang.Class.newInstance(Class.java:350)
   at 
 sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
   at 
 sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
 sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395)
   at 
 sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:113)
   at 
 sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:331)
   at 
 java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1376)
   at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:72)
   at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:493)
   at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:468)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.io.ObjectStreamClass.init(ObjectStreamClass.java:468)
   at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:365)
   at java.io.ObjectStreamClass.initProxy(ObjectStreamClass.java:562)
   at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1575)
   at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
   at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
   at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
   at hudson.remoting.Command.readFrom(Command.java:92)
   at 
 hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
   at 
 hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
 
 Build step 'Execute shell' marked build as failure
 ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to 
 exception
 hudson.AbortException: no workspace for FreeBSD_HEAD-tests2 #853
   at 
 hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:72)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
   at 
 hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761)
   at 
 hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721)
   at hudson.model.Build$BuildExecution.post2(Build.java:183)
   at 
 hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670)
   at hudson.model.Run.execute(Run.java:1742)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
   at hudson.model.ResourceController.execute(ResourceController.java:89)
   at 

Re: sbuf-related panic

[Garrett Cooper]

 On Mar 16, 2015, at 14:03, Shawn Webb shawn.w...@hardenedbsd.org wrote:
 
 On amd64, doing a Poudriere run. On r280133:
 
 (kgdb) bt
 #0  doadump (textdump=Unhandled dwarf expression opcode 0x93
 ) at pcpu.h:219
 #1  0x809726a5 in kern_reboot (howto=Unhandled dwarf expression 
 opcode 0x93
 ) at /usr/src/sys/kern/kern_shutdown.c:448
 #2  0x80972c98 in vpanic (fmt=value optimized out, ap=value 
 optimized out) at /usr/src/sys/kern/kern_shutdown.c:747
 #3  0x80972ac2 in kassert_panic (fmt=value optimized out) at 
 /usr/src/sys/kern/kern_shutdown.c:635
 #4  0x809bd5bd in sbuf_delete (s=0xfe085d468750) at 
 /usr/src/sys/kern/subr_sbuf.c:103
 #5  0x809669dd in sysctl_kern_proc_args (oidp=value optimized out, 
 arg1=value optimized out, arg2=value optimized out, 
 req=0xfe085d468868) at /usr/src/sys/kern/kern_proc.c:1858
 #6  0x8097e7b4 in sysctl_root_handler_locked (oid=0x81533738, 
 arg1=0xfe085d46893c, arg2=1, req=0xfe085d468868) at 
 /usr/src/sys/kern/kern_sysctl.c:183
 #7  0x8097e038 in sysctl_root (arg1=value optimized out, 
 arg2=value optimized out) at /usr/src/sys/kern/kern_sysctl.c:1660
 #8  0x8097e5b2 in userland_sysctl (td=value optimized out, 
 name=0xfe085d468930, namelen=value optimized out, old=value optimized 
 out, oldlenp=value optimized out, inkernel=value optimized out, 
new=value optimized out, newlen=value optimized out, retval=value 
 optimized out, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1764
 #9  0x8097e3e4 in sys___sysctl (td=0xf802521324b0, 
 uap=0xfe085d468a40) at /usr/src/sys/kern/kern_sysctl.c:1690
 #10 0x80da1bca in amd64_syscall (td=0xf802521324b0, traced=0) at 
 subr_syscall.c:133
 #11 0x80d7f3cb in Xfast_syscall () at 
 /usr/src/sys/amd64/amd64/exception.S:395
 #12 0x02759e502b7a in ?? ()

Ian's working on a few issues that have been reported to him by jhb, kib, and a 
few others.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Build failed in Jenkins: Build-UFS-image #1334

[Garrett Cooper]

Hi Craig!

 On Mar 12, 2015, at 08:17, jenkins-ad...@freebsd.org wrote:
 
 See https://jenkins.freebsd.org/job/Build-UFS-image/1334/

...

 echo /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/boot/amd64/boot1.efi
 /builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/boot/amd64/boot1.efi
 uudecode /builds/FreeBSD_HEAD/sys/boot/amd64/boot1.efi/fat.tmpl.bz2.uu
 make[7]: exec(uudecode) failed (No such file or directory)
 *** Error code 1

I've seen this error more than once, so there's probably a race condition 
somewhere in the Makefiles where it's trying to rebuild the file because one of 
the dependencies changed, or there's a race with how it's building images that 
needs to be fixed. I haven't filed a bug for this yet.

I'm on vacation right now. I'll take a look at it when I get back if it's still 
unresolved.

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

Re: Massive libxo-zation that breaks everything

[Garrett Cooper]

On Mar 1, 2015, at 5:33, Sulev-Madis Silber (ketas) madis...@hot.ee wrote:

 Hello.
 
 First, I would be happy to have JSON and XML output about filesystems,
 users, routes... but I don't like how it makes code of df, w, netstat
 hard to read/maintain and often broken.
 
 I don't think it would be good to continue with this. Maybe the effort
 should be put to creating new layer/library and then something on top of
 it that actually outputs JSON and XML.
 
 Or, if that's too difficult... maybe just regular df/w/netstat could be
 copied to somewhere else and made code libxo-output-only. And original
 df/w/netstat changes reverted and left alone.
 
 Then, maybe later, df/w/netstat/... could be updated to this new
 layer/library. Or maybe this should be just left as it is.
 
 That would mean having two netstat's in system, which could be both good
 (separation) and bad (maintaining).
 
 Just some ideas... I don't know how to solve this issue fully. I'm also
 not likely the one who would write code for all this. Hell, those aren't
 even all my ideas here. I just worry that system drop-in xo-zation is
 bad for overall health of base.
 
 Oh and, it makes rescue larger and more complex, too? On that, there was
 suggestion to maybe create separate first aid kit and emergency room
 types of system rescue utils/methods.

Hi Sulev,
Could you please cite instances where things were broken with 
converting utilities (netstat seems to be a sticking point — do you have data 
to support this?) over to libxo? The big problem (I think) is lack of tests 
with these utilities to ensure that output doesn’t break unknowingly.
I definitely see the wisdom in having /rescue be de-libxoified. It 
seems to go against the purpose of having a small “rescue image” binary — 
whereas the bsdxml integration into geom(3)/geom(4) is a necessary evil.
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: atkbd.c not compiling?

[Garrett Cooper]

On Feb 28, 2015, at 14:15, Garrett Cooper yaneurab...@gmail.com wrote:

 On Feb 28, 2015, at 13:56, Ryan Stone ryst...@gmail.com wrote:
 
 On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper yaneurab...@gmail.com 
 wrote:
 I’m not sure about key_map — are you building with syscons or vt?
 
 I have no idea.  I'm just running make tinderbox.  So far
 _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed,
 among others.
 
 i386.LINT and sparc64.LINK have both device sc and device vt from
 what I can see
 
 I think I figured it out. Is it because MK_VT != “no” and MK_LEGACY_CONSOLE 
 == “no”?

… or because MK_SYSCONS == no?


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: atkbd.c not compiling?

[Garrett Cooper]

On Feb 28, 2015, at 13:56, Ryan Stone ryst...@gmail.com wrote:

 On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper yaneurab...@gmail.com wrote:
 I’m not sure about key_map — are you building with syscons or vt?
 
 I have no idea.  I'm just running make tinderbox.  So far
 _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed,
 among others.
 
 i386.LINT and sparc64.LINK have both device sc and device vt from
 what I can see

It looks like a few keyboard drivers would be broken. Might be related to 
[AT]KBD_DFLT_KEYMAP...

From sys/dev/kbd/kbdtables.h :

 31 #ifndef KBD_DFLT_KEYMAP
 32 
 33 /* US iso8859 */
 34 #define ISO_ACCENTCHARS
 35 /*
 36  * Automatically generated from /usr/share/syscons/keymaps/us.iso.kbd.
 37  * DO NOT EDIT!
 38  */
 39 static keymap_t key_map = { 0x6d, {

From sys/dev/atkbd/atkbd.c:

 265 /* the initial key map, accent map and fkey strings */
 266 #ifdef ATKBD_DFLT_KEYMAP
 267 #define KBD_DFLT_KEYMAP
 268 #include atkbdmap.h
 269 #endif
 270 #include dev/kbd/kbdtables.h


signature.asc
Description: Message signed with OpenPGP using GPGMail