Re: installworld woes

[Shawn Webb]

On May 28, 2016, at 8:29 PM, Alan Somers  wrote:
> 
> On Sat, May 28, 2016 at 6:26 PM, Shawn Webb  
> wrote:
>> On May 28, 2016, at 8:23 PM, Alan Somers  wrote:
>>> 
>>> On Sat, May 28, 2016 at 6:14 PM, Shawn Webb  
>>> wrote:
 I haven’t had the time to properly diagnose this one. But here’s a little 
 installworld bug I’ve run into. When performing the following, 
 installworld fails:
 
 1. Make sure /chroot doesn’t exist, if it does, then `rm -rf /chroot`
 2. mkdir /chroot
 3. cd /usr/src
 4. make installworld DESTDIR=/chroot
 
 I’m my case, the chroot is at /builds/updater/chroot. Below is a link to 
 the log of the error I’m getting. I’m using HardenedBSD’s source, the 
 hardened/current/master branch.
 
 Link to log: http://pastebin.com/titmiNCW 
 
 Thanks,
 
 Shawn Webb
 Cofounder and Security Engineer
 HardenedBSD
 
 GPG Key ID:  0x6A84658F52456EEE
 GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
 
>>> 
>>> Can you please send me your copy of etc/mtree/BSD.tests.dist?  And did
>>> you set anything like WITHOUT_TESTS=1 in /etc/src.conf?  Also, what
>>> exact revision of HardenedBSD are you using?
>>> 
>>> -Alan
>> 
>> Hey Alan,
>> 
>> Both make.conf and src.conf is empty. I’m at commit 
>> 41e51b23103daca5c5cdbfa894f1166d07f87c15 in the hardened/current/master 
>> branch. Here’s etc/mtree/BSD.tests.dist in my src tree: http://ix.io/MiS
>> 
>> Thanks,
>> 
>> Shawn Webb
>> Cofounder and Security Engineer
>> HardenedBSD
>> 
>> GPG Key ID:  0x6A84658F52456EEE
>> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
> 
> I'll fix it tonight after I get the kids into bed.  In the meantime,
> you can roll back to before this commit.
> https://github.com/HardenedBSD/hardenedBSD/commit/442baa51845cf38dbcfdc44bd8493defdaad630a
> 
> -Alan

No worries. No rush here. I appreciate the help! Can you add “Reported by: 
HardenedBSD” to the commit log?

Thanks,


Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: installworld woes

[Alan Somers]

On Sat, May 28, 2016 at 6:26 PM, Shawn Webb  wrote:
> On May 28, 2016, at 8:23 PM, Alan Somers  wrote:
>>
>> On Sat, May 28, 2016 at 6:14 PM, Shawn Webb  
>> wrote:
>>> I haven’t had the time to properly diagnose this one. But here’s a little 
>>> installworld bug I’ve run into. When performing the following, installworld 
>>> fails:
>>>
>>> 1. Make sure /chroot doesn’t exist, if it does, then `rm -rf /chroot`
>>> 2. mkdir /chroot
>>> 3. cd /usr/src
>>> 4. make installworld DESTDIR=/chroot
>>>
>>> I’m my case, the chroot is at /builds/updater/chroot. Below is a link to 
>>> the log of the error I’m getting. I’m using HardenedBSD’s source, the 
>>> hardened/current/master branch.
>>>
>>> Link to log: http://pastebin.com/titmiNCW 
>>>
>>> Thanks,
>>>
>>> Shawn Webb
>>> Cofounder and Security Engineer
>>> HardenedBSD
>>>
>>> GPG Key ID:  0x6A84658F52456EEE
>>> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>>>
>>
>> Can you please send me your copy of etc/mtree/BSD.tests.dist?  And did
>> you set anything like WITHOUT_TESTS=1 in /etc/src.conf?  Also, what
>> exact revision of HardenedBSD are you using?
>>
>> -Alan
>
> Hey Alan,
>
> Both make.conf and src.conf is empty. I’m at commit 
> 41e51b23103daca5c5cdbfa894f1166d07f87c15 in the hardened/current/master 
> branch. Here’s etc/mtree/BSD.tests.dist in my src tree: http://ix.io/MiS
>
> Thanks,
>
> Shawn Webb
> Cofounder and Security Engineer
> HardenedBSD
>
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

I'll fix it tonight after I get the kids into bed.  In the meantime,
you can roll back to before this commit.
https://github.com/HardenedBSD/hardenedBSD/commit/442baa51845cf38dbcfdc44bd8493defdaad630a

-Alan
___
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 woes

[Shawn Webb]

On May 28, 2016, at 8:23 PM, Alan Somers  wrote:
> 
> On Sat, May 28, 2016 at 6:14 PM, Shawn Webb  
> wrote:
>> I haven’t had the time to properly diagnose this one. But here’s a little 
>> installworld bug I’ve run into. When performing the following, installworld 
>> fails:
>> 
>> 1. Make sure /chroot doesn’t exist, if it does, then `rm -rf /chroot`
>> 2. mkdir /chroot
>> 3. cd /usr/src
>> 4. make installworld DESTDIR=/chroot
>> 
>> I’m my case, the chroot is at /builds/updater/chroot. Below is a link to the 
>> log of the error I’m getting. I’m using HardenedBSD’s source, the 
>> hardened/current/master branch.
>> 
>> Link to log: http://pastebin.com/titmiNCW 
>> 
>> Thanks,
>> 
>> Shawn Webb
>> Cofounder and Security Engineer
>> HardenedBSD
>> 
>> GPG Key ID:  0x6A84658F52456EEE
>> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>> 
> 
> Can you please send me your copy of etc/mtree/BSD.tests.dist?  And did
> you set anything like WITHOUT_TESTS=1 in /etc/src.conf?  Also, what
> exact revision of HardenedBSD are you using?
> 
> -Alan

Hey Alan,

Both make.conf and src.conf is empty. I’m at commit 
41e51b23103daca5c5cdbfa894f1166d07f87c15 in the hardened/current/master branch. 
Here’s etc/mtree/BSD.tests.dist in my src tree: http://ix.io/MiS

Thanks,

Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: installworld woes

[Alan Somers]

On Sat, May 28, 2016 at 6:14 PM, Shawn Webb  wrote:
> I haven’t had the time to properly diagnose this one. But here’s a little 
> installworld bug I’ve run into. When performing the following, installworld 
> fails:
>
> 1. Make sure /chroot doesn’t exist, if it does, then `rm -rf /chroot`
> 2. mkdir /chroot
> 3. cd /usr/src
> 4. make installworld DESTDIR=/chroot
>
> I’m my case, the chroot is at /builds/updater/chroot. Below is a link to the 
> log of the error I’m getting. I’m using HardenedBSD’s source, the 
> hardened/current/master branch.
>
> Link to log: http://pastebin.com/titmiNCW 
>
> Thanks,
>
> Shawn Webb
> Cofounder and Security Engineer
> HardenedBSD
>
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>

Can you please send me your copy of etc/mtree/BSD.tests.dist?  And did
you set anything like WITHOUT_TESTS=1 in /etc/src.conf?  Also, what
exact revision of HardenedBSD are you using?

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

installworld woes

[Shawn Webb]

I haven’t had the time to properly diagnose this one. But here’s a little 
installworld bug I’ve run into. When performing the following, installworld 
fails:

1. Make sure /chroot doesn’t exist, if it does, then `rm -rf /chroot`
2. mkdir /chroot
3. cd /usr/src
4. make installworld DESTDIR=/chroot

I’m my case, the chroot is at /builds/updater/chroot. Below is a link to the 
log of the error I’m getting. I’m using HardenedBSD’s source, the 
hardened/current/master branch.

Link to log: http://pastebin.com/titmiNCW 

Thanks,

Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal;

[Alan Somers]

On Sat, May 28, 2016 at 4:26 PM, Bryan Drewery  wrote:
> On 5/28/16 3:07 PM, O. Hartmann wrote:
>> CXXFLAGS+=  -std=c++11
>>
>>
>> As it has been earlier stated, there is no -std=c++11 visible in the cc 
>> options, only
>> -std=gnu99.
>
> I'm confused why -std=c++11 *doesn't* show now.  Whatever though, the
> problem is reproducible with GCC toolchains which always get -std=c++11
> added in.
>
> I'm committing a fix.
>
> --
> Regards,
> Bryan Drewery

It didn't show only because ohartman pasted the wrong context in his
original email.  He pasted the compile command for a .c file, followed
the the error message from a .cc file.  Thanks for fixing it, Bryan.

-Alan
___
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: r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal;

[Bryan Drewery]

On 5/28/16 3:07 PM, O. Hartmann wrote:
> CXXFLAGS+=  -std=c++11
> 
> 
> As it has been earlier stated, there is no -std=c++11 visible in the cc 
> options, only
> -std=gnu99.

I'm confused why -std=c++11 *doesn't* show now.  Whatever though, the
problem is reproducible with GCC toolchains which always get -std=c++11
added in.

I'm committing a fix.

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

Re: r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal;

[O. Hartmann]

Am Sat, 28 May 2016 15:20:15 -0600
Alan Somers  schrieb:

> On Sat, May 28, 2016 at 3:04 PM, O. Hartmann
>  wrote:
> > Recent CURRENT r300912 fails to buildworld with the error shown below:
> >
> > [...]
> > cc   -O2 -pipe -O3 -O3 -pipe -march=native  -DNDEBUG -MD  
> > -MF.depend.alias_skinny.o
> > -MTalias_skinny.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
> > -Wno-unused-const-variable
> > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
> > -Wno-switch
> > -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  
> > -Qunused-arguments
> > -c 
> > /usr/src/lib/libalias/modules/skinny/../../../../sys/netinet/libalias/alias_skinny.c
> > -o alias_skinny.o --- all_subdir_lib/libdevdctl --- --- event.So
> > --- /usr/src/lib/libdevdctl/event.cc:438:45: error: invalid suffix on 
> > literal; C++11
> > requires a space between literal and identifier 
> > [-Wreserved-user-defined-literal]
> > snprintf(timebuf, bufsize, " timestamp=%"PRId64,  
> 
> Those aren't the usual CFLAGS.  What are your environment, compiler,
> and target architecture?

Compiler is CLANG/LLVM, target arch is amd64, in that case, an oldish 
IvyBridge, but it
fails the same way on Haswell as well. 64bit.

For buildworld, I use in /etc/src.conf this since an eternity (measured in the 
metrik of
11-CURRENT):

CPUTYPE?=   native
#
CFLAGS+=-O3 -pipe
# for the kernel
COPTFLAGS+= -O3 -pipe
#
CXXFLAGS+=  -std=c++11


As it has been earlier stated, there is no -std=c++11 visible in the cc 
options, only
-std=gnu99.

The compiler gives the right suggestion itself, but someone should fix and 
commit ...

Regards,

Oliver


pgpawNd2T6M9k.pgp
Description: OpenPGP digital signature

Re: r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal;

[Bryan Drewery]

On 5/28/16 2:43 PM, Dimitry Andric wrote:
> On 28 May 2016, at 23:20, Alan Somers  wrote:
>>
>> On Sat, May 28, 2016 at 3:04 PM, O. Hartmann
>>  wrote:
>>> Recent CURRENT r300912 fails to buildworld with the error shown below:
>>>
>>> [...]
>>> cc   -O2 -pipe -O3 -O3 -pipe -march=native  -DNDEBUG -MD  
>>> -MF.depend.alias_skinny.o
>>> -MTalias_skinny.o -std=gnu99 -fstack-protector-strong -Wsystem-headers 
>>> -Wno-pointer-sign

I only see std=gnu99 here ^^ and no std=c++11.

>>> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
>>> -Wno-tautological-compare
>>> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
>>> -Wno-enum-conversion
>>> -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
>>> -Wno-knr-promoted-parameter
>>> -Wno-parentheses  -Qunused-arguments
>>> -c 
>>> /usr/src/lib/libalias/modules/skinny/../../../../sys/netinet/libalias/alias_skinny.c
>>> -o alias_skinny.o --- all_subdir_lib/libdevdctl --- --- event.So
>>> --- /usr/src/lib/libdevdctl/event.cc:438:45: error: invalid suffix on 
>>> literal; C++11
>>> requires a space between literal and identifier 
>>> [-Wreserved-user-defined-literal]
>>> snprintf(timebuf, bufsize, " timestamp=%"PRId64,
>>
>> Those aren't the usual CFLAGS.  What are your environment, compiler,
>> and target architecture?
> 
> There seems to be something that is adding -std=c++11 unconditionally to
> the CXXFLAGS for a C++ library.  I'm adding Bryan on CC, who may know
> how this comes to pass.
> 
> That said, putting a space between the double quote and PRId64
> identifier would be handy in any case.
> 
> -Dimitry
> 


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

Re: r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal;

[Dimitry Andric]

On 28 May 2016, at 23:20, Alan Somers  wrote:
> 
> On Sat, May 28, 2016 at 3:04 PM, O. Hartmann
>  wrote:
>> Recent CURRENT r300912 fails to buildworld with the error shown below:
>> 
>> [...]
>> cc   -O2 -pipe -O3 -O3 -pipe -march=native  -DNDEBUG -MD  
>> -MF.depend.alias_skinny.o
>> -MTalias_skinny.o -std=gnu99 -fstack-protector-strong -Wsystem-headers 
>> -Wno-pointer-sign
>> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
>> -Wno-tautological-compare
>> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
>> -Wno-enum-conversion
>> -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
>> -Wno-knr-promoted-parameter
>> -Wno-parentheses  -Qunused-arguments
>> -c 
>> /usr/src/lib/libalias/modules/skinny/../../../../sys/netinet/libalias/alias_skinny.c
>> -o alias_skinny.o --- all_subdir_lib/libdevdctl --- --- event.So
>> --- /usr/src/lib/libdevdctl/event.cc:438:45: error: invalid suffix on 
>> literal; C++11
>> requires a space between literal and identifier 
>> [-Wreserved-user-defined-literal]
>> snprintf(timebuf, bufsize, " timestamp=%"PRId64,
> 
> Those aren't the usual CFLAGS.  What are your environment, compiler,
> and target architecture?

There seems to be something that is adding -std=c++11 unconditionally to
the CXXFLAGS for a C++ library.  I'm adding Bryan on CC, who may know
how this comes to pass.

That said, putting a space between the double quote and PRId64
identifier would be handy in any case.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Mark Millard]

On 2016-May-28, at 12:03 PM, Adrian Chadd  wrote:

> [snip]
> 
> hi,
> 
> please don't patch the ports compiler assumptions about things like
> this. We should be targeting external toolchains on OSes (eg macosx)
> where it may already generate freebsd binaries and as such we should
> be calling the compiler/linker with all the flags it needs.
> 
> Having a patched compiler default for mips made things way, way harder
> than it needed to be.
> 
> 
> 
> -adrian

Are there specific technical examples of specific lessons learned from the 
"patched compiler default for mips" context?

Is there an intent to use /usr/src/. . . materials for buildworld/buildkernel 
and the like from a non-FreeBSD context? Are there examples?

Currently I'm just providing evidence that some FreeBSD committers have 
requested. I'm not a committer for FreeBSD or for upstream and will not be 
making any FreeBSD system or ports changes outside my personal context. I'm no 
direct risk to FreeBSD. So your note is more for the folks having me cross 
check xtoolchain and related behavior than for me.


Notes on my context. . . (stop reading if you do not care)

Unfortunately powerpc64 and powerpc still can not be clang based overall for 
buildworld/buildkernel.

I will say that in my use of devel/powerpc64-xtoolchain-gcc (and so 
devel/powerpc64-gcc ) to have a libc++ based FreeBSD on powerpc64 I've always 
had to have some form of work around to avoid /usr/local/include causing 
buildworld failures from use of the wrong files for buildworld purposes. I have 
either:

A) temporarily renamed files below /usr/local/include/ to avoid them being used 
(or otherwise blocked /usr/local/include access)

or

B) used C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to cause the C/C++ compiles to 
look below /usr/include/ before looking below /usr/local/include/ . (I've also 
experimented with extra -I's and the like.)

So far I've not used devel/powerpc64-gcc to build ports under FreeBSD. So far 
I've only built ports from a self-hosted context (no cross-built ports). So I 
tend to use something like lang/gcc49 to build ports. I'm not likely to adopt a 
technique for building the likes of lang/gcc49 that messes up using it to build 
ports.

I normally self-host buildworld/buildkernel on a powerpc64 FreeBSD context, an 
odd use of devel/powerpc64-gcc . But I have at times also cross-built from an 
amd64 FreeBSD context and it also can have the "wrong files for buildworld" 
problem for /usr/local/include/ in FreeBSD.

I've never tried buildworld/buildkernel from a non-FreeBSD context and so have 
never built devel/powerpc64-gcc or anything like its configuration outside 
FreeBSD.

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

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

Re: r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal;

[Alan Somers]

On Sat, May 28, 2016 at 3:04 PM, O. Hartmann
 wrote:
> Recent CURRENT r300912 fails to buildworld with the error shown below:
>
> [...]
> cc   -O2 -pipe -O3 -O3 -pipe -march=native  -DNDEBUG -MD  
> -MF.depend.alias_skinny.o
> -MTalias_skinny.o -std=gnu99 -fstack-protector-strong -Wsystem-headers 
> -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
> -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-enum-conversion
> -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
> -Wno-knr-promoted-parameter
> -Wno-parentheses  -Qunused-arguments
> -c 
> /usr/src/lib/libalias/modules/skinny/../../../../sys/netinet/libalias/alias_skinny.c
> -o alias_skinny.o --- all_subdir_lib/libdevdctl --- --- event.So
> --- /usr/src/lib/libdevdctl/event.cc:438:45: error: invalid suffix on 
> literal; C++11
> requires a space between literal and identifier 
> [-Wreserved-user-defined-literal]
> snprintf(timebuf, bufsize, " timestamp=%"PRId64,

Those aren't the usual CFLAGS.  What are your environment, compiler,
and target architecture?
___
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: r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal;

[Dimitry Andric]

On 28 May 2016, at 23:04, O. Hartmann  wrote:
> Recent CURRENT r300912 fails to buildworld with the error shown below:
> 
> [...]
> cc   -O2 -pipe -O3 -O3 -pipe -march=native  -DNDEBUG -MD  
> -MF.depend.alias_skinny.o
> -MTalias_skinny.o -std=gnu99 -fstack-protector-strong -Wsystem-headers 
> -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
> -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-enum-conversion
> -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
> -Wno-knr-promoted-parameter
> -Wno-parentheses  -Qunused-arguments
> -c 
> /usr/src/lib/libalias/modules/skinny/../../../../sys/netinet/libalias/alias_skinny.c
> -o alias_skinny.o --- all_subdir_lib/libdevdctl --- --- event.So
> --- /usr/src/lib/libdevdctl/event.cc:438:45: error: invalid suffix on 
> literal; C++11
> requires a space between literal and identifier 
> [-Wreserved-user-defined-literal]
> snprintf(timebuf, bufsize, " timestamp=%"PRId64,

If you are compiling with CXXFLAGS having -std=c++11, please turn that
off to work around this.  At some point there should be space inserted
between the double quote and the PRId64, that should fix it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

r300912: compile failure in world: event.cc:438:45: error: invalid suffix on literal;

[O. Hartmann]

Recent CURRENT r300912 fails to buildworld with the error shown below:

[...]
cc   -O2 -pipe -O3 -O3 -pipe -march=native  -DNDEBUG -MD  
-MF.depend.alias_skinny.o
-MTalias_skinny.o -std=gnu99 -fstack-protector-strong -Wsystem-headers 
-Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter
-Wno-parentheses  -Qunused-arguments
-c 
/usr/src/lib/libalias/modules/skinny/../../../../sys/netinet/libalias/alias_skinny.c
-o alias_skinny.o --- all_subdir_lib/libdevdctl --- --- event.So
--- /usr/src/lib/libdevdctl/event.cc:438:45: error: invalid suffix on literal; 
C++11
requires a space between literal and identifier 
[-Wreserved-user-defined-literal]
snprintf(timebuf, bufsize, " timestamp=%"PRId64,


pgp7mtovzwn2z.pgp
Description: OpenPGP digital signature

Re: WITNESS messages on 11

[mokhi]

I'm not sure, but maybe this is related to [1].
FWIW, according to [2], LORs of witness means deadlock could be
happened in that situation (if it's not a false positive), not
necessarily an accurate deadlock happening IMO :)

I hope it helps :)

[1]http://lists.freebsd.org/pipermail/freebsd-current/2016-May/061195.html
[2]https://www.freebsd.org/doc/faq/troubleshoot.html#idp63374416

Best Regards, Mokhi.
___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Adrian Chadd]

[snip]

hi,

please don't patch the ports compiler assumptions about things like
this. We should be targeting external toolchains on OSes (eg macosx)
where it may already generate freebsd binaries and as such we should
be calling the compiler/linker with all the flags it needs.

Having a patched compiler default for mips made things way, way harder
than it needed to be.



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

WITNESS messages on 11

[Yuri]

I saw this every time I tried to install 11 from the VM image recently.


While copying over the ports tree with the command "nc   | tar 
xzf -" I get the messages, see below.



Yuri


lock order reversal:
 1st 0xfe003ca55570 bufwait (bufwait) @ 
/usr/src/sys/kern/vfs_bio.c:3512
 2nd 0xf80003db6a00 dirhash (dirhash) @ 
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281

stack backtrace:
#0 0x80a981b0 at witness_debugger+0x70
#1 0x80a980a4 at witness_checkorder+0xe54
#2 0x80a429a2 at _sx_xlock+0x72
#3 0x80cf32dd at ufsdirhash_add+0x3d
#4 0x80cf60ba at ufs_direnter+0x4da
#5 0x80cfe6b9 at ufs_mkdir+0x8a9
#6 0x80ff7f47 at VOP_MKDIR_APV+0xf7
#7 0x80b05c88 at kern_mkdirat+0x208
#8 0x80e9cc1b at amd64_syscall+0x2db
#9 0x80e7cbdb at Xfast_syscall+0xfb
lock order reversal:
 1st 0xf800388ed5f0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:894
 2nd 0xfe003cb6ccb0 bufwait (bufwait) @ 
/usr/src/sys/ufs/ffs/ffs_vnops.c:263

 3rd 0xf8003b40b7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
stack backtrace:
#0 0x80a981b0 at witness_debugger+0x70
#1 0x80a980a4 at witness_checkorder+0xe54
#2 0x80a12b06 at __lockmgr_args+0x4d6
#3 0x80cedf46 at ffs_lock+0xa6
#4 0x80ff88f0 at VOP_LOCK1_APV+0x100
#5 0x80b0880a at _vn_lock+0x9a
#6 0x80af8c63 at vget+0x63
#7 0x80aeb52c at vfs_hash_get+0xcc
#8 0x80ce95a0 at ffs_vgetf+0x40
#9 0x80ce0e91 at softdep_sync_buf+0xb51
#10 0x80ceeb36 at ffs_syncvnode+0x256
#11 0x80cedde0 at ffs_fsync+0x20
#12 0x80ff79b7 at VOP_FSYNC_APV+0xf7
#13 0x80ada695 at bufsync+0x35
#14 0x80af6d12 at bufobj_invalbuf+0xa2
#15 0x80af9f4e at vgonel+0x15e
#16 0x80afce37 at vnlru_proc+0x577
#17 0x809fd8c4 at fork_exit+0x84

___
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 update day 2

[Matthew Macy]

  On Sat, 28 May 2016 06:07:40 -0700 Eric McCorkle  
wrote  
 > Ok, 
 >  
 > When I load the module, it the screen blanks for a second as it does when 
 > switching framebuffer drivers.  However, it looks like this fails, as the 
 > last kernel message is 
 >  
 > *ERROR*: switching to FCLK failed 

There are two places in the code in intel_display.c where that error is 
reported. Both look like this:


if (wait_for_atomic_us(I915_READ(LCPLL_CTL) &
   LCPLL_CD_SOURCE_FCLK_DONE, 1))
DRM_ERROR("Switching to FCLK failed\n");

The last argument is effectively the number of times DELAY(1) is called. Could 
you try changing the 1 in those calls to 10?

Thanks.
-M


 >  
 > Not sure how I can get more detailed information. 
 >  
 > > On May 26, 2016, at 19:08, Eric McCorkle  wrote: 
 > >  
 > > Letting you know, I had an error in detection.  I'm trying to get a change 
 > > done before code slush, but I will circle back and provide a detailed 
 > > report  
 > >  
 > >> On May 23, 2016 4:12:52 AM EDT, Matthew Macy  wrote: 
 > >>  
 > >> The highlights for today are the following: 
 > >>  
 > >> Bug fixes: 
 > >> - Will Andrews fixed attach for some laptops (such as the Carbon X1). 
 > >> The Carbon X1 has a quirky BIOS that doesn't allow the OS to 
 > >> enumerate the GPU's interrupt. 
 > >> - Will Andrews identified a conditionally uninitialized return in 
 > >> idr_find that could lead to a panic in some cases. 
 > >> - Fixed a panic in mtrr_del frequently seen when attach failed. 
 > >> - Sleep/wakeups with interrupts are largely implemented correctly 
 > >> now. Previously a polling 10ms sleep was used. I'm still 
 > >> concerned that the code really needs to be level-triggered. 
 > >>  
 > >> Cleanups: 
 > >> - Logging is now enabled for the first 10s after attach unless 
 > >> dev.drm.drm_debug_keep=1. 
 > >> - Unimplemented warnings are off by default. 
 > >>  
 > >> As of this moment the latest USB image is: 
 > >> http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz 
 > >>  
 > >> The USB image now has sync disabled on var. This should improve 
 > >> responsiveness for most people with slow USB pen drives. If 
 > >> you're having issues that require retaining logs you'll need 
 > >> to "zfs set sync=enabled zrootusb/var". 
 > >>  
 > >> The USB image now includes kde4 and xfce. It is also much larger, for  
 > >> this iteration you will need a 16GB USB key. The next one will probably 
 > >> not be quite so large. If size is a common problem let me know. It's  
 > >> difficult to buy a USB key that is less than 16GB today. 
 > >>  
 > >> joeuser's .xinitrc is configured to start xfce with  startx. To start 
 > >> kde  
 > >> run: service kdm4 onestart. 
 > >>  
 > >> Note that the image name has changed. The most recent should be 
 > >> self-evident in: http://www.bsddesktop.com/images  
 > >>  
 > >> Helpful hint: use a 1MB blocksize for dd and run gpart recover 
 > >> to fix label warnings. Assuming your USB pen drive shows up as 
 > >> /dev/da0 and cftdisk image is the one I just posted: 
 > >>  
 > >> unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img 
 > >> of=/dev/da0 bs=1M; gpart recover da0 
 > >>  
 > >> And as a reminder, if you're having problems with X on the USB 
 > >> key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf 
 > >> somewhere else on your file system. 
 > >>  
 > >> If using the github repo, make sure you're using the drm-next-4.6 
 > >> branch. 
 > >>  
 > >> Cheers. 
 > >>  
 > >> -M 
 > >>  
 > >> ___ 
 > >> freebsd-...@freebsd.org mailing list 
 > >> https://lists.freebsd.org/mailman/listinfo/freebsd-x11 
 > >> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" 
 > >  
 > > --  
 > > Sent from my Android device with K-9 Mail. Please excuse my brevity. 
 > > ___ 
 > > freebsd-...@freebsd.org mailing list 
 > > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 
 > > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" 
 > ___ 
 > freebsd-current@freebsd.org mailing list 
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
 > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" 
 > 

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

Re: panic: DI already started in pmap_delayed_invl_started

[Ryan Stone]

Whoops.  I just reported the uname output without giving any thought as to
whether it made any sense.  I don't have r300863, so I'll update and
hopefully that fixes it.  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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Mark Millard]

[Top post of failure to get rid of /usr/local/include from devel/powerpc64-gcc 
search list.]

I have tried:

> # svnlite diff /usr/ports/devel/powerpc64-gcc/
> Index: /usr/ports/devel/powerpc64-gcc/Makefile
> ===
> --- /usr/ports/devel/powerpc64-gcc/Makefile   (revision 415874)
> +++ /usr/ports/devel/powerpc64-gcc/Makefile   (working copy)
> @@ -43,6 +43,7 @@
>  CONFIGURE_ARGS+=--target=${GCC_TARGET} --disable-nls 
> --enable-languages=c,c++ \
>   --without-headers \
>   --with-gmp=${LOCALBASE} \
> + 
> --with-local-prefix=${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION} \
>   --with-pkgversion="FreeBSD Ports Collection for 
> ${PKGNAMEPREFIX:C/-//g}" \
>   --with-system-zlib \
>   --with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \

which when rebuilt in a powerpc64 context shows up with:

--with-local-prefix=/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0

in the "Configured with" (from using -v):

> Target: powerpc64-portbld-freebsd11.0
> Configured with: 
> /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure 
> --target=powerpc64-portbld-freebsd11.0 --disable-nls --enable-languages=c,c++ 
> --without-headers --with-gmp=/usr/local 
> --with-local-prefix=/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0 
> --with-pkgversion='FreeBSD Ports Collection for powerpc64' --with-system-zlib 
> --with-as=/usr/local/bin/powerpc64-freebsd-as 
> --with-ld=/usr/local/bin/powerpc64-freebsd-ld --prefix=/usr/local 
> --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/ 
> --build=powerpc64-portbld-freebsd11.0

But /usr/local/include still shows up in the search list, for example:

> ignoring nonexistent directory 
> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include"
> ignoring duplicate directory 
> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/src/lib/msun/powerpc
>  /usr/src/lib/msun/src
>  /usr/src/lib/libc/include
>  /usr/src/lib/libc/powerpc
>  /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include
>  /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include
>  /usr/local/include
>  /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed
> End of search list.

[Despite some prior mis-wording in other messages: The line match for 
--with-local-prefix= 's value with "/include" appended matches the line prior 
to /usr/local/include in the search list, not the following line.]

So far I'm unsuccessful at avoiding /usr/local/include being in the search 
list. I'm still at the stage of C_INCLUDE_PAPTH and CPLUS_INCLUDE_PATH being 
the best means that I've found to force /usr/include based paths to win when 
there are conflicts in /usr/local/include from ports that have been built.


So far I'm only doing the experiment with devel/powerpc64-gcc (used as the 
so-called "cross compiler" in my powerpc64 self-hosted context), not with the 
lang/gcc49 that I use as the system compiler. For lang/gcc49 I'm still using 
C_INCLUDE_PAPTH and CPLUS_INCLUDE_PATH to avoid /usr/local/include based paths 
from finding files. In part this is because I expect port building problems if 
I use lang/gcc49 to build ports without lang/gcc49 having /usr/local/include 
implicitly. I do not use devel/powerpc64-gcc to build ports.

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

On 2016-May-28, at 2:24 AM, Mark Millard  wrote:

> --with-local-prefix=/usr was insufficient to avoid /usr/local/include in the 
> search list in powerpc64-gcc:
> 
>> ignoring duplicate directory 
>> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include"
>> ignoring nonexistent directory 
>> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include"
>> ignoring duplicate directory 
>> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/src/gnu/lib/libssp/libssp_nonshared/..
>> /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp
>> /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include
>> /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include
>> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include
>> /usr/local/include
>> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed
>> End of search list.
> 
> Which came from (which shows the --with-local-prefix=/usr use):
> 
>> Configured with: 
>> /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure 
>> 

Re: panic: DI already started in pmap_delayed_invl_started

[Konstantin Belousov]

On Sat, May 28, 2016 at 11:29:28AM -0400, Ryan Stone wrote:
> I updated my system to r254461 on Thursday, and got this panic overnight.
> I have a full core and debug symbols if anybody wants me to look at
> something.
> 
> panic: DI already started

I suspect there is some typo in the revision number to which you updated.
Do you have r300863 in your sources ?  If not, ensure that you updated
up to that rev.

If r300863 still demonstrates the problem, I will ask for more specific
information.
___
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"

panic: DI already started in pmap_delayed_invl_started

[Ryan Stone]

I updated my system to r254461 on Thursday, and got this panic overnight.
I have a full core and debug symbols if anybody wants me to look at
something.

panic: DI already started
cpuid = 10
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1838bbc380
vpanic() at vpanic+0x182/frame 0xfe1838bbc400
kassert_panic() at kassert_panic+0x126/frame 0xfe1838bbc470
pmap_delayed_invl_started() at pmap_delayed_invl_started+0xe1/frame
0xfe1838bbc490
pmap_advise() at pmap_advise+0x31/frame 0xfe1838bbc540
vm_fault_dontneed() at vm_fault_dontneed+0x12f/frame 0xfe1838bbc590
vm_fault_hold() at vm_fault_hold+0x919/frame 0xfe1838bbc6a0
vm_fault() at vm_fault+0x78/frame 0xfe1838bbc6e0
vm_run() at vm_run+0x5b5/frame 0xfe1838bbc880
vmmdev_ioctl() at vmmdev_ioctl+0x8c2/frame 0xfe1838bbc940
devfs_ioctl_f() at devfs_ioctl_f+0x156/frame 0xfe1838bbc9a0
kern_ioctl() at kern_ioctl+0x246/frame 0xfe1838bbca00
sys_ioctl() at sys_ioctl+0x171/frame 0xfe1838bbcae0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe1838bbcbf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1838bbcbf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800ff60fa, rsp =
0x7fffdedf4e28, rbp = 0x7fffdedf4ee0 ---
___
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 update day 2

[Eric McCorkle]

Ok,

When I load the module, it the screen blanks for a second as it does when 
switching framebuffer drivers.  However, it looks like this fails, as the last 
kernel message is

*ERROR*: switching to FCLK failed

Not sure how I can get more detailed information.

> On May 26, 2016, at 19:08, Eric McCorkle  wrote:
> 
> Letting you know, I had an error in detection.  I'm trying to get a change 
> done before code slush, but I will circle back and provide a detailed report 
> 
>> On May 23, 2016 4:12:52 AM EDT, Matthew Macy  wrote:
>> 
>> The highlights for today are the following:
>> 
>> Bug fixes:
>> - Will Andrews fixed attach for some laptops (such as the Carbon X1).
>> The Carbon X1 has a quirky BIOS that doesn't allow the OS to
>> enumerate the GPU's interrupt.
>> - Will Andrews identified a conditionally uninitialized return in
>> idr_find that could lead to a panic in some cases.
>> - Fixed a panic in mtrr_del frequently seen when attach failed.
>> - Sleep/wakeups with interrupts are largely implemented correctly
>> now. Previously a polling 10ms sleep was used. I'm still
>> concerned that the code really needs to be level-triggered.
>> 
>> Cleanups:
>> - Logging is now enabled for the first 10s after attach unless
>> dev.drm.drm_debug_keep=1.
>> - Unimplemented warnings are off by default.
>> 
>> As of this moment the latest USB image is:
>> http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz
>> 
>> The USB image now has sync disabled on var. This should improve
>> responsiveness for most people with slow USB pen drives. If
>> you're having issues that require retaining logs you'll need
>> to "zfs set sync=enabled zrootusb/var".
>> 
>> The USB image now includes kde4 and xfce. It is also much larger, for 
>> this iteration you will need a 16GB USB key. The next one will probably
>> not be quite so large. If size is a common problem let me know. It's 
>> difficult to buy a USB key that is less than 16GB today.
>> 
>> joeuser's .xinitrc is configured to start xfce with  startx. To start
>> kde 
>> run: service kdm4 onestart.
>> 
>> Note that the image name has changed. The most recent should be
>> self-evident in: http://www.bsddesktop.com/images 
>> 
>> Helpful hint: use a 1MB blocksize for dd and run gpart recover
>> to fix label warnings. Assuming your USB pen drive shows up as
>> /dev/da0 and cftdisk image is the one I just posted:
>> 
>> unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img
>> of=/dev/da0 bs=1M; gpart recover da0
>> 
>> And as a reminder, if you're having problems with X on the USB
>> key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf
>> somewhere else on your file system.
>> 
>> If using the github repo, make sure you're using the drm-next-4.6
>> branch.
>> 
>> Cheers.
>> 
>> -M
>> 
>> ___
>> freebsd-...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-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: EARLY_AP_STARTUP hangs during boot

[Gary Jennejohn]

On Fri, 27 May 2016 09:50:05 +0200
Gary Jennejohn  wrote:

> On Thu, 26 May 2016 16:54:35 -0700
> John Baldwin  wrote:
> 
> > On Tuesday, May 17, 2016 06:47:41 PM Gary Jennejohn wrote:  
> > > On Mon, 16 May 2016 10:54:19 -0700
> > > John Baldwin  wrote:
> > > 
> > > > On Monday, May 16, 2016 12:22:42 PM Gary Jennejohn wrote:
> > > > > I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't
> > > > > break into DDB.
> > > > > 
> > > > > I did a verbose boot and the last lines I see are related to routing
> > > > > MSI-X to various local APIC vectors.  I copied the last few lines and
> > > > > they look like this:
> > > > > 
> > > > > msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
> > > > > msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
> > > > > msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
> > > > > msi: routing MSI-X IRQ 256 to local APIC 0 vector 49
> > >  ^^^ Assigning
> > > > > 
> > > > > I tried disabling msi and msix in /boot/loader.conf, but the settings
> > > > > were ignored (probabaly too early).  
> > > > 
> > > > No, those settings are not too early.  However, the routing to different
> > > > CPUs now happens earlier than it used to.  What is the line before the
> > > > MSI lines?  You can take a picture with your phone/camera if that's 
> > > > simplest.
> > > > 
> > > 
> > > Here a few lines before the MSI routing happens:
> > > 
> > > hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 
> > > on acpi0
> > > hpet0: vendor 0x4353, rev 0x1, 14318180 Hz, 3 timers, legacy route
> > > hpet0: t0 : irqs 0x00c0ff (0), MSI, periodic
> > > hpet0: t1 : irqs 0x00c0ff (0), MSI, periodic
> > > hpet0: t2 : irqs 0x00c0ff (0), MSI, periodic
> > > Timecounter "HPET" frequency 14318180 Hz quality 950
> > 
> > The assigning message means it is in the loop using
> > bus_bind_intr() to setup per-CPU timers.  Can you please try
> > setting 'hint.hpet.0.per_cpu=0' at the loader prompt to see if
> > disabling the use of per-CPU timers allows you to boot?
> >   
> 
> Something has changed since the last time I generated a kernel with
> this option.
> 
> Now I get a NULL-pointer dereference in the kernel, doesn't matter
> whether I set the hint or not.
> 

OK, now that the startup has been fixed, I tried setting the hint at
the loader prompt, but the kenel hangs in exactly the same place as
before.  I actually booted twice to make certain I hadn't made a
typo when setting the hint.

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

FreeBSD_HEAD_amd64_gcc - Build #1267 - Still Failing

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc - Build #1267 - Still Failing:

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

Change summaries:

300901 by bz:
In if_attachdomain1() there does not seem to be any reason
to use TRYLOCK rather than just acquire the lock, so just do that.

Reviewed by:markj
Obtained from:  projects/vnet
MFC after:  2 weeks
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D6578

300896 by adrian:
[ath] add WB335 btcoex for initial testing.

This is like the WB222 coexistence (ie, "MCI", a message bus inside the
chip), and it's currently a cut/paste so I can start using it to flesh
out the differences with WB222.

It doesn't completely /do/ bluetooth coexistence, because it turns out
I need to add some contigmalloc'ed buffers to the btcoex path for this
type of hardware.  I'm putting this work in the "people would like
to see functioning-ish btcoex before FreeBSD-11" bucket because I see
this as "broken".

Tested:

* QCA9535 (WB335) NIC, BT + 2GHz STA

300895 by np:
cxgbe/t4_tom: Exempt RDMA connections from a TCP sanity test for now, to
avoid panicking debug kernels.

t4_tom does not keep track of a connection once it switches to ULP mode
iWARP.  If the connection falls out of ULP mode the driver/hardware seq#
etc. are out of sync.  A better fix would be to figure out what the
current seq# are, update the driver's state, and perform all sanity
checks as usual.

300894 by gonzo:
Add gpiokeys to the list of GPIO modules built only if FDT is enabled

300893 by bdrewery:
Don't truncate existing error when writing the log.

Suggested by:   markj
MFC after:  2 weeks
Sponsored by:   EMC / Isilon Storage Division

300892 by bdrewery:
Rename function to be less generic.

MFC after:  2 weeks
Sponsored by:   EMC / Isilon Storage Division

300891 by bdrewery:
Write to the log using the tracer's credentials.

MFC after:  2 weeks
Sponsored by:   EMC / Isilon Storage Division

300890 by bdrewery:
exec: Cease tracing if credentials will change with the new image.

This also prevents tracing to a P_INEXEC process since it could race
with other processes attaching to it in filemon_event_process_exec() due
to the filemon_get_proc() race of incrementing ref and then locking the
filemon.  With the no-P_INEXEC invariant in place the p_filemon may only
be the same or NULL when trying to drop it in
filemon_event_process_exec().

MFC after:  2 weeks
Sponsored by:   EMC / Isilon Storage Division
Differential Revision:  https://reviews.freebsd.org/D6545

300889 by jhb:
Fix taskqueue groups to work with EARLY_AP_STARTUP.

In the EARLY_AP_STARTUP case the APs are already running when a taskqgroup
is created, so adjust the group at the same time it is created.

Sponsored by:   Netflix

300888 by np:
iw_cxgbe: Plug a lock leak in process_mpa_request().

If the parent is DEAD or connect_request_upcall() fails, the parent
mutex is left locked.  This leads to a hang when process_mpa_request()
is called again for another child of the listening endpoint.

Submitted by:   Krishnamraju Eraparaju @ Chelsio
Obtained from:  upstream iw_cxgb4
Sponsored by:   Chelsio Communications

300886 by bdrewery:
Move external GCC compiler hacks to bsd.sys.mk.

This allows respecting -nostdinc, -nostdinc++ and -nostdlib before
making the decision to add in -isystem, etc.  The -isystem flags
are problematic for building lib/libc++ and lib/libcxxrt which wants
to only use its own headers.

More information the need of these flags can be found at
https://gcc.gnu.org/ml/gcc/2016-03/msg00219.html

This also reverts r300873.

Sponsored by:   EMC / Isilon Storage Division

300885 by bdrewery:
Libcompat: Only pass -isystem =/usr/include for external GCC.

This is the same as the main build logic.  GCC with a cross-compiler
requires using -isystem to =/usr/include to get the search order
correct.

Reported by:dim, asomers
Sponsored by:   EMC / Isilon Storage Division

300884 by ngie:
Fix up r300870

The sys/types.h fix I proposed was only tested with zfs(4), not with
libzpool, which is where the build failure actually existed

Remove vm/vm_pageout.h from arc.c and zfs_vnops.c because they're both
unneeded

MFC after: 1 week
X-MFC with: r300865, r300870
In collaboration with: kib
Submitted by: alc
Sponsored by: EMC / Isilon Storage Division

300883 by asomers:
Fix typo from r300880

Reported by:rpokala
MFC after:  Never
Sponsored by:   Spectra Logic Corp

300882 by asomers:
Always create loopback routes on every fib

Always create loopback routes on every fib, for both IPv4 and IPv6

etc/rc.d/routing
Create loopback IPv4 and IPv6 routes on every fib at boot. Revert
278302; now that all FIBs have IPv6 loopback routes, the
"route add 

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Mark Millard]

--with-local-prefix=/usr was insufficient to avoid /usr/local/include in the 
search list in powerpc64-gcc:

> ignoring duplicate directory 
> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include"
> ignoring duplicate directory 
> "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/src/gnu/lib/libssp/libssp_nonshared/..
>  /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp
>  /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include
>  /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include
>  /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include
>  /usr/local/include
>  /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed
> End of search list.

Which came from (which shows the --with-local-prefix=/usr use):

> Configured with: 
> /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure 
> --target=powerpc64-portbld-freebsd11.0 --disable-nls --enable-languages=c,c++ 
> --without-headers --with-gmp=/usr/local --with-local-prefix=/usr 
> --with-pkgversion='FreeBSD Ports Collection for powerpc64' --with-system-zlib 
> --with-as=/usr/local/bin/powerpc64-freebsd-as 
> --with-ld=/usr/local/bin/powerpc64-freebsd-ld --prefix=/usr/local 
> --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/ 
> --build=powerpc64-portbld-freebsd11.0

In Makefile terms:

> # svnlite diff /usr/ports/devel/powerpc64-gcc/Makefile 
> Index: /usr/ports/devel/powerpc64-gcc/Makefile
> ===
> --- /usr/ports/devel/powerpc64-gcc/Makefile   (revision 415874)
> +++ /usr/ports/devel/powerpc64-gcc/Makefile   (working copy)
> @@ -43,6 +43,7 @@
>  CONFIGURE_ARGS+=--target=${GCC_TARGET} --disable-nls 
> --enable-languages=c,c++ \
>   --without-headers \
>   --with-gmp=${LOCALBASE} \
> + --with-local-prefix=/usr \
>   --with-pkgversion="FreeBSD Ports Collection for 
> ${PKGNAMEPREFIX:C/-//g}" \
>   --with-system-zlib \
>   --with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \


Note: "Specifying --prefix has no effect on which directory GCC searches for 
local header files".

Some interesting wording is: "The same value can be used for both 
--with-local-prefix and --prefix provided it is not /usr" and "This can be used 
to avoid the default search of /usr/local/include". Also: "The purpose of 
--prefix is to specify where to install GCC" and "The local header files in 
/usr/local/include—if you put any in that directory—are not part of GCC".

My overall interpretation of that is that in my context:

--with-local-prefix=/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0

a.k.a.:

--with-local-prefix=${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION}

would make for a redundant overall search path without changing the ordering.

I have not figured out why /usr/local/include continued to show up and 
/usr/include did not. I wonder if they have special logic for if /usr is 
assigned and so force back there specified default.

I'll try rebuilding devel/powerpc64-gcc again based on:

--with-local-prefix=${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION}



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

On 2016-May-27, at 7:35 PM, Mark Millard  wrote:

> On 2016-May-27, at 7:04 PM, Mark Millard  wrote:
> 
>> FYI. . .
>> 
>> I expect that building gcc49 with:
>> 
>> +--with-local-prefix=/usr \
>> 
>> will help with system build activities via gcc49/g++49 by avoiding 
>> /usr/local/include interfering.
>> 
>> But I also expect that various port builds based on that same gcc49/g++49 
>> will have problems from not explicitly forcing /usr/local/include to be 
>> looked at when appropriate/required --unless something else is in place to 
>> do that separately. I expect some implicit /usr/local/include references to 
>> the likes of some of the below list:
>> 
>>> # diff -qr /usr/include/ /usr/local/include/ | grep /local/ | more
>>> Only in /usr/local/include/: apr-1
>>> Files /usr/include/atf-c/defs.h and /usr/local/include/atf-c/defs.h differ
>>> Only in /usr/local/include/: autosprintf.h
>>> Only in /usr/local/include/: bfd.h
>>> Only in /usr/local/include/: bfdlink.h
>>> Only in /usr/local/include/: boost
>>> Only in /usr/local/include/: curl
>>> Only in /usr/local/include/: db5
>>> Only in /usr/local/include/: dis-asm.h
>>> Files /usr/include/dwarf.h and /usr/local/include/dwarf.h differ
>>> Only in /usr/local/include/: editline
>>> Only in /usr/local/include/: expat.h
>>> Only in /usr/local/include/: expat_config.h
>>> Only in /usr/local/include/: expat_external.h
>>> Only in /usr/local/include/: ffi.h
>>> Only in /usr/local/include/: ffitarget.h