Re: truss -f timeout 2 sleep 10 causes breakage

[Konstantin Belousov]

On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.
> 
> Mere "timeout 2 sleep 10" correctly times out.
> 
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep and the entire thing refuses to exit, truss has to be killed off
> with SIGKILL.
The issue is because debugger can stop the debuggee, which makes the
single threading never succeed.  Supposed fix is in
https://reviews.freebsd.org/D44523
the cost is that in principle, the debuggee now can try to break out of
the reaper kill hammer, with the help of debugger.  But this setup is
arguably too convoluted: you either control the process with reaper, or
with debugger.

> 
> Here is the best part: after doing the above, going back to mere
> "timeout 2 sleep 10" (without truss!) no longer works -- timeout gets
> stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig
> _sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl
> amd64_syscall fast_syscall_common
This is because the threaded workqueue thread is stuck waiting for
single-threading of the victim.

> 
> It does react to -9 though.
Not the workqueue, which is the problem.

Re: truss -f timeout 2 sleep 10 causes breakage

[Dag-Erling Smørgrav]

Mateusz Guzik  writes:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.

Confirmed on 14.0-RELEASE-p5.

> Mere "timeout 2 sleep 10" correctly times out.
>
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep

This is sort of expected as truss(1) uses ptrace(2) which breaks the
parent-child relationship, so you should never use `truss -f` with a
command that expects to control its children.

> and the entire thing refuses to exit, truss has to be killed off
> with SIGKILL.

This, however, is not expected.

> Here is the best part: after doing the above, going back to mere
> "timeout 2 sleep 10" (without truss!) no longer works

Neither is this.

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org

truss -f timeout 2 sleep 10 causes breakage

[Mateusz Guzik]

Top of main, but I reproduced it on stable/14-e64d827d3 as well.

Mere "timeout 2 sleep 10" correctly times out.

Running "truss -f timeout 2 sleep 10" prevents timeout from killing
sleep and the entire thing refuses to exit, truss has to be killed off
with SIGKILL.

Here is the best part: after doing the above, going back to mere
"timeout 2 sleep 10" (without truss!) no longer works -- timeout gets
stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig
_sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl
amd64_syscall fast_syscall_common

It does react to -9 though.

-- 
Mateusz Guzik 

Re: Build breakage with WITH_BEARSSL=1

[Gordon Bergling]

Hello Mina,

thanks for the PR, I can confirm that this bugfix is working.

@Warner, could you commit it?

I think creating a differential for the small change isn't neccessary.

--Gordon

On Thu, Feb 23, 2023 at 10:05:25AM +, Mina Galić wrote:
> taking Simon off the list, cuz his auto - reply indicates he's very busy.
> 
> Either way, t should do it: https://github.com/freebsd/freebsd-src/pull/657
> 
> Mina Galić
> 
> Try PkgBase: https://alpha.pkgbase.live/
> 
>  Original Message 
> On 23 Feb 2023, 09:57, Mina Galić wrote:
> 
> > given that this isn't contrib code, we can just fix it in our tree:
> >
> > https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52
> >
> > Mina Galić
> >
> > Try PkgBase: https://alpha.pkgbase.live/
> >
> >  Original Message 
> > On 23 Feb 2023, 09:27, Gordon Bergling wrote:
> >
> >> Hi Simon, On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty 
> >> wrote: > This has been fixed upstream, I'll look at importing an update. 
> >> Thanks for merging the upstream fix. BearSSL is now compiling, but I get a 
> >> different error now while building veriexec. 
> >> /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function 
> >> declaration without a prototype is deprecated in all versio ns of C 
> >> [-Werror,-Wstrict-prototypes] veriexec_usage() ^ void This looks to me, 
> >> that the Makefile of veriexec should be updated as well. --Gordon

-- 

Re: Build breakage with WITH_BEARSSL=1

[Mina Galić]

taking Simon off the list, cuz his auto - reply indicates he's very busy.

Either way, t should do it: https://github.com/freebsd/freebsd-src/pull/657

Mina Galić

Try PkgBase: https://alpha.pkgbase.live/

 Original Message 
On 23 Feb 2023, 09:57, Mina Galić wrote:

> given that this isn't contrib code, we can just fix it in our tree:
>
> https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52
>
> Mina Galić
>
> Try PkgBase: https://alpha.pkgbase.live/
>
>  Original Message 
> On 23 Feb 2023, 09:27, Gordon Bergling wrote:
>
>> Hi Simon, On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote: 
>> > This has been fixed upstream, I'll look at importing an update. Thanks for 
>> merging the upstream fix. BearSSL is now compiling, but I get a different 
>> error now while building veriexec. 
>> /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function 
>> declaration without a prototype is deprecated in all versio ns of C 
>> [-Werror,-Wstrict-prototypes] veriexec_usage() ^ void This looks to me, that 
>> the Makefile of veriexec should be updated as well. --Gordon

Re: Build breakage with WITH_BEARSSL=1

[Mina Galić]

given that this isn't contrib code, we can just fix it in our tree:

https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52

Mina Galić

Try PkgBase: https://alpha.pkgbase.live/

 Original Message 
On 23 Feb 2023, 09:27, Gordon Bergling wrote:

> Hi Simon, On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote: > 
> This has been fixed upstream, I'll look at importing an update. Thanks for 
> merging the upstream fix. BearSSL is now compiling, but I get a different 
> error now while building veriexec. 
> /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function declaration 
> without a prototype is deprecated in all versio ns of C 
> [-Werror,-Wstrict-prototypes] veriexec_usage() ^ void This looks to me, that 
> the Makefile of veriexec should be updated as well. --Gordon

Re: Build breakage with WITH_BEARSSL=1

[Gordon Bergling]

Hi Simon,

On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote:
> This has been fixed upstream, I'll look at importing an update.

Thanks for merging the upstream fix. BearSSL is now compiling, but I get a
different error now while building veriexec.

  /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function declaration 
without a prototype is deprecated in all versio  ns of C 
[-Werror,-Wstrict-prototypes]
  veriexec_usage()
^
 void

This looks to me, that the Makefile of veriexec should be updated as well.

--Gordon


signature.asc
Description: PGP signature

Re: Build breakage with WITH_BEARSSL=1

[Simon J. Gerraty]

This has been fixed upstream, I'll look at importing an update.

Re: Build breakage with WITH_BEARSSL=1

[Warner Losh]

On Thu, Feb 16, 2023 at 12:57 AM Gordon Bergling  wrote:

> Hi Warner,
>
> On Wed, Feb 15, 2023 at 10:07:08AM -0700, Warner Losh wrote:
> > On Sun, Feb 12, 2023, 3:18 PM Warner Losh  wrote:
> > > On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling 
> wrote:
> > >
> > >> Hi,
> > >>
> > >> I am currently seeing a build breakage when building -CURRENT with
> > >> WITH_BEARSSL=1.
> > >>
> > >> The error is the following
> > >>
> > >>   make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line
> 109:
> > >> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem
> t*.asc 2>
> > >> /dev/null" returned non-zero status
> > >>   /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22:
> error:
> > >> a function declaration without a prototype is deprecat  ed in all
> versions
> > >> of C [-Werror,-Wstrict-prototypes]
> > >>   br_rsa_i62_keygen_get()
> > >>^
> > >> void
> > >>   1 error generated.
> > >>   --- rsa_i62_keygen.pico ---
> > >>
> > >>
> > >> When disabling BEARSSL in the src.conf the build succeeds as usual.
> > >>
> > >> Has anyone also seen this build error. Sources are very recent and the
> > >> src.conf is the following:
> > >>
> > >> WITH_EXTRA_TCP_STACKS=1
> > >> #WITH_BEARSSL=1
> > >> WITH_PIE=1
> > >> WITH_RETPOLINE=1
> > >> WITH_INIT_ALL_ZERO=1
> > >> WITH_OPENSSL_KTLS=1
> > >> WITHOUT_CLEAN=1
> > >>
> > >> Any help is very appreciated.
> > >>
> > >>
> > > What does the following do for you? It's a cut and pasted patch, but it
> > > should be clear enough what to do if the mailer mangles it.
> > >
> > > diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
> > > index dd0e242c8ef0..2af4864d8441 100644
> > > --- a/lib/libbearssl/Makefile.inc
> > > +++ b/lib/libbearssl/Makefile.inc
> > > @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
> > >  BEARSSL_SRC= ${BEARSSL}/src
> > >
> > >  CFLAGS+= -I${BEARSSL}/inc
> > > -
> > > +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
> > >
> >
> > I went ahead and committed this. Please let me know if the problem
> persists.
>
> Sorry for the late reply. I just tried a fresh build and it still fails
> with
>
> [..]/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a function
> declaration without a prototype is deprecated in all versions of C
> [-Werror,-Wstrict-prototypes]
>   br_rsa_i62_keygen_get()
>
> Did you see any other possibilty to fix this?
>

Oh, maybe add -Wno-strict-prototypes to where I added
NO_WDEPRECATED_NON_PROTOTYPES?

Warner

Re: Build breakage with WITH_BEARSSL=1

[Simon J. Gerraty]

Stephane Rochoy  wrote:
> It may be worth contacting BearSSL's maintainer directly: Thomas
> Pornin . The guy was very responsive and helpful
> back in 2020 :)

Indeed.

Re: Build breakage with WITH_BEARSSL=1

[Simon J. Gerraty]

Warner Losh  wrote:
> Would be nice if we could get upstream to actually fix this, but i don't even 
> know how to submit bugs there…
> 
> Agreed. I didn't recall off of the top of my head, so I did the quick bandaid.

I can reach out to the author, I don't know that he has a bug tracker.

What is the problem?  lack of prototype declarations?

Re: Build breakage with WITH_BEARSSL=1

[Mina Galić]

--- Original Message ---
On Thursday, February 16th, 2023 at 08:30, Stephane Rochoy 
 wrote:


> Warner Losh i...@bsdimp.com writes:
> 
> > On Wed, Feb 15, 2023, 1:09 PM Mina Galić free...@igalic.co
> > wrote:
> > 
> > > Would be nice if we could get upstream to actually fix this,
> > > but i don't even know how to submit bugs there…
> > 
> > Agreed. I didn't recall off of the top of my head, so I did the
> > quick bandaid.
> 
> 
> Hi,
> 
> It may be worth contacting BearSSL's maintainer directly: Thomas
> Pornin por...@bolet.org. The guy was very responsive and helpful
> 
> back in 2020 :)
> 
> Regards,
> --
> Stéphane Rochoy
> O: Stormshield

after re-reading https://bearssl.org/contrib.html
that's exactly what it says to do:

"Suggestions, comments, patches and other contributions are welcome. They 
should simply be sent to me (por...@bolet.org) by email."

(reading is hard)

Re: Build breakage with WITH_BEARSSL=1

[Stephane Rochoy]

Warner Losh  writes:


On Wed, Feb 15, 2023, 1:09 PM Mina Galić 
wrote:


Would be nice if we could get upstream to actually fix this,
but i don't even know how to submit bugs there…



Agreed. I didn't recall off of the top of my head, so I did the
quick bandaid.


Hi,

It may be worth contacting BearSSL's maintainer directly: Thomas
Pornin . The guy was very responsive and helpful
back in 2020 :)

Regards,
--
Stéphane Rochoy
O: Stormshield

Re: Build breakage with WITH_BEARSSL=1

[Gordon Bergling]

Hi Warner,

On Wed, Feb 15, 2023 at 10:07:08AM -0700, Warner Losh wrote:
> On Sun, Feb 12, 2023, 3:18 PM Warner Losh  wrote:
> > On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling  wrote:
> >
> >> Hi,
> >>
> >> I am currently seeing a build breakage when building -CURRENT with
> >> WITH_BEARSSL=1.
> >>
> >> The error is the following
> >>
> >>   make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
> >> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem t*.asc 2>
> >> /dev/null" returned non-zero status
> >>   /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error:
> >> a function declaration without a prototype is deprecat  ed in all versions
> >> of C [-Werror,-Wstrict-prototypes]
> >>   br_rsa_i62_keygen_get()
> >>^
> >> void
> >>   1 error generated.
> >>   --- rsa_i62_keygen.pico ---
> >>
> >>
> >> When disabling BEARSSL in the src.conf the build succeeds as usual.
> >>
> >> Has anyone also seen this build error. Sources are very recent and the
> >> src.conf is the following:
> >>
> >> WITH_EXTRA_TCP_STACKS=1
> >> #WITH_BEARSSL=1
> >> WITH_PIE=1
> >> WITH_RETPOLINE=1
> >> WITH_INIT_ALL_ZERO=1
> >> WITH_OPENSSL_KTLS=1
> >> WITHOUT_CLEAN=1
> >>
> >> Any help is very appreciated.
> >>
> >>
> > What does the following do for you? It's a cut and pasted patch, but it
> > should be clear enough what to do if the mailer mangles it.
> >
> > diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
> > index dd0e242c8ef0..2af4864d8441 100644
> > --- a/lib/libbearssl/Makefile.inc
> > +++ b/lib/libbearssl/Makefile.inc
> > @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
> >  BEARSSL_SRC= ${BEARSSL}/src
> >
> >  CFLAGS+= -I${BEARSSL}/inc
> > -
> > +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
> >
> 
> I went ahead and committed this. Please let me know if the problem persists.

Sorry for the late reply. I just tried a fresh build and it still fails with

[..]/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a function
declaration without a prototype is deprecated in all versions of C 
[-Werror,-Wstrict-prototypes]
  br_rsa_i62_keygen_get()

Did you see any other possibilty to fix this?

--Gordon


signature.asc
Description: PGP signature

Re: Build breakage with WITH_BEARSSL=1

[Warner Losh]

On Wed, Feb 15, 2023, 1:09 PM Mina Galić  wrote:

> Would be nice if we could get upstream to actually fix this, but i don't
> even know how to submit bugs there…
>

Agreed. I didn't recall off of the top of my head, so I did the quick
bandaid.

Warner


Mina Galić
>
> Try PkgBase: https://alpha.pkgbase.live/
>
>
>
>
>
>
>  Original Message 
> On 15 Feb 2023, 17:07, Warner Losh < i...@bsdimp.com> wrote:
>
>
>
>
> On Sun, Feb 12, 2023, 3:18 PM Warner Losh  wrote:
>
>>
>>
>> On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling  wrote:
>>
>>> Hi,
>>>
>>> I am currently seeing a build breakage when building -CURRENT with
>>> WITH_BEARSSL=1.
>>>
>>> The error is the following
>>>
>>>   make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
>>> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem t*.asc 2>
>>> /dev/null" returned non-zero status
>>>   /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error:
>>> a function declaration without a prototype is deprecat  ed in all versions
>>> of C [-Werror,-Wstrict-prototypes]
>>>   br_rsa_i62_keygen_get()
>>>^
>>> void
>>>   1 error generated.
>>>   --- rsa_i62_keygen.pico ---
>>>
>>>
>>> When disabling BEARSSL in the src.conf the build succeeds as usual.
>>>
>>> Has anyone also seen this build error. Sources are very recent and the
>>> src.conf is the following:
>>>
>>> WITH_EXTRA_TCP_STACKS=1
>>> #WITH_BEARSSL=1
>>> WITH_PIE=1
>>> WITH_RETPOLINE=1
>>> WITH_INIT_ALL_ZERO=1
>>> WITH_OPENSSL_KTLS=1
>>> WITHOUT_CLEAN=1
>>>
>>> Any help is very appreciated.
>>>
>>>
>> What does the following do for you? It's a cut and pasted patch, but it
>> should be clear enough what to do if the mailer mangles it.
>>
>> diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
>> index dd0e242c8ef0..2af4864d8441 100644
>> --- a/lib/libbearssl/Makefile.inc
>> +++ b/lib/libbearssl/Makefile.inc
>> @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
>>  BEARSSL_SRC= ${BEARSSL}/src
>>
>>  CFLAGS+= -I${BEARSSL}/inc
>> -
>> +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
>>
>
> I went ahead and committed this. Please let me know if the problem
> persists.
>
> Warner
>
>>

Re: Build breakage with WITH_BEARSSL=1

[Mina Galić]

Would be nice if we could get upstream to actually fix this, but i don't even 
know how to submit bugs there…

Mina Galić

Try PkgBase: https://alpha.pkgbase.live/

 Original Message 
On 15 Feb 2023, 17:07, Warner Losh wrote:

> On Sun, Feb 12, 2023, 3:18 PM Warner Losh  wrote:
>
>> On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling  wrote:
>>
>>> Hi,
>>>
>>> I am currently seeing a build breakage when building -CURRENT with 
>>> WITH_BEARSSL=1.
>>>
>>> The error is the following
>>>
>>> make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109: 
>>> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls' -1 *.pem t*.asc 2> 
>>> /dev/null" returned non-zero status
>>> /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a 
>>> function declaration without a prototype is deprecat ed in all versions of 
>>> C [-Werror,-Wstrict-prototypes]
>>> br_rsa_i62_keygen_get()
>>> ^
>>> void
>>> 1 error generated.
>>> --- rsa_i62_keygen.pico ---
>>>
>>> When disabling BEARSSL in the src.conf the build succeeds as usual.
>>>
>>> Has anyone also seen this build error. Sources are very recent and the
>>> src.conf is the following:
>>>
>>> WITH_EXTRA_TCP_STACKS=1
>>> #WITH_BEARSSL=1
>>> WITH_PIE=1
>>> WITH_RETPOLINE=1
>>> WITH_INIT_ALL_ZERO=1
>>> WITH_OPENSSL_KTLS=1
>>> WITHOUT_CLEAN=1
>>>
>>> Any help is very appreciated.
>>
>> What does the following do for you? It's a cut and pasted patch, but it 
>> should be clear enough what to do if the mailer mangles it.
>>
>> diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
>> index dd0e242c8ef0..2af4864d8441 100644
>> --- a/lib/libbearssl/Makefile.inc
>> +++ b/lib/libbearssl/Makefile.inc
>> @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
>> BEARSSL_SRC= ${BEARSSL}/src
>>
>> CFLAGS+= -I${BEARSSL}/inc
>> -
>> +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
>
> I went ahead and committed this. Please let me know if the problem persists.
>
> Warner
>
>>

Re: Build breakage with WITH_BEARSSL=1

[Warner Losh]

On Sun, Feb 12, 2023, 3:18 PM Warner Losh  wrote:

>
>
> On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling  wrote:
>
>> Hi,
>>
>> I am currently seeing a build breakage when building -CURRENT with
>> WITH_BEARSSL=1.
>>
>> The error is the following
>>
>>   make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
>> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem t*.asc 2>
>> /dev/null" returned non-zero status
>>   /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error:
>> a function declaration without a prototype is deprecat  ed in all versions
>> of C [-Werror,-Wstrict-prototypes]
>>   br_rsa_i62_keygen_get()
>>^
>> void
>>   1 error generated.
>>   --- rsa_i62_keygen.pico ---
>>
>>
>> When disabling BEARSSL in the src.conf the build succeeds as usual.
>>
>> Has anyone also seen this build error. Sources are very recent and the
>> src.conf is the following:
>>
>> WITH_EXTRA_TCP_STACKS=1
>> #WITH_BEARSSL=1
>> WITH_PIE=1
>> WITH_RETPOLINE=1
>> WITH_INIT_ALL_ZERO=1
>> WITH_OPENSSL_KTLS=1
>> WITHOUT_CLEAN=1
>>
>> Any help is very appreciated.
>>
>>
> What does the following do for you? It's a cut and pasted patch, but it
> should be clear enough what to do if the mailer mangles it.
>
> diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
> index dd0e242c8ef0..2af4864d8441 100644
> --- a/lib/libbearssl/Makefile.inc
> +++ b/lib/libbearssl/Makefile.inc
> @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
>  BEARSSL_SRC= ${BEARSSL}/src
>
>  CFLAGS+= -I${BEARSSL}/inc
> -
> +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
>

I went ahead and committed this. Please let me know if the problem persists.

Warner

>

Re: Build breakage with WITH_BEARSSL=1

[Warner Losh]

On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling  wrote:

> Hi,
>
> I am currently seeing a build breakage when building -CURRENT with
> WITH_BEARSSL=1.
>
> The error is the following
>
>   make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem t*.asc 2>
> /dev/null" returned non-zero status
>   /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a
> function declaration without a prototype is deprecat  ed in all versions of
> C [-Werror,-Wstrict-prototypes]
>   br_rsa_i62_keygen_get()
>^
> void
>   1 error generated.
>   --- rsa_i62_keygen.pico ---
>
>
> When disabling BEARSSL in the src.conf the build succeeds as usual.
>
> Has anyone also seen this build error. Sources are very recent and the
> src.conf is the following:
>
> WITH_EXTRA_TCP_STACKS=1
> #WITH_BEARSSL=1
> WITH_PIE=1
> WITH_RETPOLINE=1
> WITH_INIT_ALL_ZERO=1
> WITH_OPENSSL_KTLS=1
> WITHOUT_CLEAN=1
>
> Any help is very appreciated.
>
>
What does the following do for you? It's a cut and pasted patch, but it
should be clear enough what to do if the mailer mangles it.

diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
index dd0e242c8ef0..2af4864d8441 100644
--- a/lib/libbearssl/Makefile.inc
+++ b/lib/libbearssl/Makefile.inc
@@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
 BEARSSL_SRC= ${BEARSSL}/src

 CFLAGS+= -I${BEARSSL}/inc
-
+CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}

Warner

Re: Build breakage with WITH_BEARSSL=1

[Gary Jennejohn]

On Sun, 12 Feb 2023 11:54:47 +0100
Gordon Bergling  wrote:

> Hi,
>
> I am currently seeing a build breakage when building -CURRENT with 
> WITH_BEARSSL=1.
>
> The error is the following
>
>   make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109: 
> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem t*.asc 2> 
> /dev/null" returned non-zero status
>   /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a 
> function declaration without a prototype is deprecat  ed in all versions of C 
> [-Werror,-Wstrict-prototypes]
>   br_rsa_i62_keygen_get()
>^
> void
>   1 error generated.
>   --- rsa_i62_keygen.pico ---
>
>
> When disabling BEARSSL in the src.conf the build succeeds as usual.
>
> Has anyone also seen this build error. Sources are very recent and the
> src.conf is the following:
>
> WITH_EXTRA_TCP_STACKS=1
> #WITH_BEARSSL=1
> WITH_PIE=1
> WITH_RETPOLINE=1
> WITH_INIT_ALL_ZERO=1
> WITH_OPENSSL_KTLS=1
> WITHOUT_CLEAN=1
>
> Any help is very appreciated.
>

The current clang wants to see  br_rsa_i62_keygen_get(void), that's
why void was emitted.  The other routine in this file has the same
error.  Could be that this code has this problem in many places.

There might a flag which one could pass to clang so that it would not
choke on such an error, but I don't know clang well enough to figure
that out.  Maybe someone in the know could supply that info.

--
Gary Jennejohn

Build breakage with WITH_BEARSSL=1

[Gordon Bergling]

Hi,

I am currently seeing a build breakage when building -CURRENT with 
WITH_BEARSSL=1.

The error is the following

  make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109: 
warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem t*.asc 2> 
/dev/null" returned non-zero status
  /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a 
function declaration without a prototype is deprecat  ed in all versions of C 
[-Werror,-Wstrict-prototypes]
  br_rsa_i62_keygen_get()
   ^
void
  1 error generated.
  --- rsa_i62_keygen.pico ---


When disabling BEARSSL in the src.conf the build succeeds as usual.

Has anyone also seen this build error. Sources are very recent and the
src.conf is the following:

WITH_EXTRA_TCP_STACKS=1
#WITH_BEARSSL=1
WITH_PIE=1
WITH_RETPOLINE=1
WITH_INIT_ALL_ZERO=1
WITH_OPENSSL_KTLS=1
WITHOUT_CLEAN=1

Any help is very appreciated.

--Gordon

Re: vfs_mouse.c breakage?

[Pete Wright]

On 6/1/20 5:10 PM, Rick Macklem wrote:

It also needed .
It is ancient code (that started out in SunOS. if I recall correctly), where 
they
used things like "bool_t" and set them with TRUE/FALSE (upper case).

Unfortunately, those includes love to include other includes...

Anyhow, I think it is fixed now, rick


I can confirm on my end as well - thanks Rick!

-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: vfs_mouse.c breakage?

[Rick Macklem]

It also needed .
It is ancient code (that started out in SunOS. if I recall correctly), where 
they
used things like "bool_t" and set them with TRUE/FALSE (upper case).

Unfortunately, those includes love to include other includes...

Anyhow, I think it is fixed now, rick


From: Pete Wright 
Sent: Monday, June 1, 2020 8:05 PM
To: Rick Macklem; FreeBSD Current
Subject: Re: vfs_mouse.c breakage?

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca



On 6/1/20 2:50 PM, Rick Macklem wrote:
> Pete Wright wrote:
>> Subject: vfs_mouse.c breakage?
> Not sure if the vfs mouse is broken (sorry, I couldn't resist), but...

hah nice - dyslexia + poor eyesight are not good bedfellows :^)
>
> I think it needs a:
> #include 
>
> but it will take a little while for me to test this.
>
> Thanks for reporting it, rick

no prob - adding that include thew some more errors

$ git diff
diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index 03f95b2845f9..4282b1938095 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
@@ -39,6 +39,7 @@
  #include 
  __FBSDID("$FreeBSD$");

+#include 
  #include 
  #include 
  #include 


here's a snippet of the exception:
--- vfs_mount.o ---
In file included from /usr/home/pete/git/freebsd/sys/kern/vfs_mount.c:42:
In file included from /usr/home/pete/git/freebsd/sys/rpc/auth.h:50:
/usr/home/pete/git/freebsd/sys/rpc/xdr.h:105:3: error: type name
requires a specifier or qualifier
 bool_t  (*x_getlong)(struct XDR *, long *);


I'll sit tight for now - thanks for checking it out!

-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: vfs_mouse.c breakage?

[Pete Wright]

On 6/1/20 2:50 PM, Rick Macklem wrote:

Pete Wright wrote:

Subject: vfs_mouse.c breakage?

Not sure if the vfs mouse is broken (sorry, I couldn't resist), but...


hah nice - dyslexia + poor eyesight are not good bedfellows :^)


I think it needs a:
#include 

but it will take a little while for me to test this.

Thanks for reporting it, rick


no prob - adding that include thew some more errors

$ git diff
diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index 03f95b2845f9..4282b1938095 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
@@ -39,6 +39,7 @@
 #include 
 __FBSDID("$FreeBSD$");

+#include 
 #include 
 #include 
 #include 


here's a snippet of the exception:
--- vfs_mount.o ---
In file included from /usr/home/pete/git/freebsd/sys/kern/vfs_mount.c:42:
In file included from /usr/home/pete/git/freebsd/sys/rpc/auth.h:50:
/usr/home/pete/git/freebsd/sys/rpc/xdr.h:105:3: error: type name 
requires a specifier or qualifier

    bool_t  (*x_getlong)(struct XDR *, long *);


I'll sit tight for now - thanks for checking it out!

-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: vfs_mouse.c breakage?

[Rick Macklem]

Pete Wright wrote:
>Subject: vfs_mouse.c breakage?
Not sure if the vfs mouse is broken (sorry, I couldn't resist), but...

I think it needs a:
#include 

but it will take a little while for me to test this.

Thanks for reporting it, rick

>hello - i am having issues building CURRENT after this was applied:
>--- vfs_mount.o ---
>/usr/home/pete/git/freebsd/sys/kern/vfs_mount.c:2360:27: error: use of
>undeclared identifier 'AUTH_SYS'
> exp->ex_secflavors[0] = AUTH_SYS;
> ^
>1 error generated.
>*** [vfs_mount.o] Error code 1
>
>
>was curious if others are seeing this?
>
>cheers,
>-pete
>
>--
>Pete Wright
>p...@nomadlogic.org
>@nomadlogicLA
___
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"

vfs_mouse.c breakage?

[Pete Wright]

hello - i am having issues building CURRENT after this was applied:
https://reviews.freebsd.org/D25045
https://svnweb.freebsd.org/base?view=revision=361699


--- vfs_mount.o ---
/usr/home/pete/git/freebsd/sys/kern/vfs_mount.c:2360:27: error: use of 
undeclared identifier 'AUTH_SYS'

    exp->ex_secflavors[0] = AUTH_SYS;
    ^
1 error generated.
*** [vfs_mount.o] Error code 1


was curious if others are seeing this?

cheers,
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: [HEADS UP] EPOCH breakage in [USB/PCI] network drivers after r357004

[Hans Petter Selasky]

Hi,

The USB WLAN drivers are now fixed, but there are some more to go, and 
Gleb has put up a patch for review:


https://reviews.freebsd.org/D23408

After those drivers have been resolved I will rebase:

https://reviews.freebsd.org/D23348

Which then will contain a list of remaining network driver EPOCH issues.

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

[HEADS UP] EPOCH breakage in [USB/PCI] network drivers after r357004

[Hans Petter Selasky]

Hi,

Currently 8 of 10 USB WLAN drivers are broken and multiple PCI ones too. 
I have some patches, which I would like to have more attention that try 
to address these issues. The patches are currently being worked on.


1) https://reviews.freebsd.org/D23348
2) https://reviews.freebsd.org/D23347

If you have some comments please sign up!

I hope all issues will be addressed by end of week.

--HPS


___
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: breakage at usr.sbin/jail/Makefile

[Dennis Clarke]

On 11/21/19 11:33 AM, Ed Maste wrote:

On Wed, 20 Nov 2019 at 23:19, Pete Wright  wrote:


the issue seems to be on my amd64 system ${LINKER_TYPE} is not defined.
i was contemplating suggesting updating the .if clause in the Makefile
like so:

.if defined($LINKER_TYPE}) && ${LINKER_TYPE} == "bfd" && ${MACHINE} ==
"riscv"


Yes, this is the approach I went with - Cirrus-CI started building my
proposed change last night but it wasn't finished before I was. When I
checked this morning it confirmed the fix works. In any case the best
fix here will be to resolve the underlying RISC-V binutils issue and
revert all of the workarounds.

Note that FreeBSD's CI did not catch this issue because it builds with
-DNO_CLEAN. I also build locally with -DNO_CLEAN and wouldn't have
seen it either. In my opinion we ought to just remove the not-NO_CLEAN
case from buildworld/buildkernel.


I generally look at the CI traffic to get a feel for what I *should* be
seeing and thus I was baffled when my cross compile was blowing up on
exactly this issue.

Really I want to debug :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242067

wherein printf seems to get down to _ldtoa.c and then confusion sets in
over the in memory data for fp128 little endian data but that is another
story. I can't get very far without some basic tools and at the moment
the CI builds are not very useful as they barely have anything for tools
in /bin or anywhere else. Not even ed? Really?

In any case I did look at the RISC-V projects GNU Toolchain and I did go
with a build of the latest from :

https://github.com/riscv/riscv-gnu-toolchain

and that did work well for a buildworld a few days ago. The buildkernel
fails. So I start over as if I am fishing for code in a fast flowing
stream of water where I never know what works and what doesn't the next
moment.  Why?  Because the CI builds were not failing. Sometimes I get
lucky. With r354874 and the new GNU Toolchain cross tools I get a clean
buildworld and then the kernel fails.

So today I will start over from scratch but I will use the GNU Toolchain
from RISC-V upstream project thus :

vesta#
vesta# uname -apKU
FreeBSD vesta 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64 
amd64 1201000 1201000

vesta# /opt/rv64/tools/bin/riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

vesta#

So I will try again today and report back.




--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional











___
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: breakage at usr.sbin/jail/Makefile

[Ed Maste]

On Wed, 20 Nov 2019 at 23:19, Pete Wright  wrote:
>
> the issue seems to be on my amd64 system ${LINKER_TYPE} is not defined.
> i was contemplating suggesting updating the .if clause in the Makefile
> like so:
>
> .if defined($LINKER_TYPE}) && ${LINKER_TYPE} == "bfd" && ${MACHINE} ==
> "riscv"

Yes, this is the approach I went with - Cirrus-CI started building my
proposed change last night but it wasn't finished before I was. When I
checked this morning it confirmed the fix works. In any case the best
fix here will be to resolve the underlying RISC-V binutils issue and
revert all of the workarounds.

Note that FreeBSD's CI did not catch this issue because it builds with
-DNO_CLEAN. I also build locally with -DNO_CLEAN and wouldn't have
seen it either. In my opinion we ought to just remove the not-NO_CLEAN
case from buildworld/buildkernel.
___
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: breakage at usr.sbin/jail/Makefile

[Glen Barber]

On Wed, Nov 20, 2019 at 08:18:52PM -0800, Pete Wright wrote:
> 
> 
> On 11/20/19 8:13 PM, Glen Barber wrote:
> > On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:
> > > Hello,
> > > looks like some of the recent commits to usr.sbin/jail/Makefile has broken
> > > CURRENT.  I am getting this error when attempting a buildworld:
> > > 
> > > ===> usr.sbin/jail (cleandir)
> > > make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21:
> > > Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
> > > make[4]: Fatal errors encountered -- cannot continue
> > > make[4]: stopped in /usr/home/pete/git/freebsd/usr.sbin/jail
> > > *** [cleandir_subdir_usr.sbin/jail] Error code 1
> > > 
> > > 
> > > here's the code in question:
> > >   18 # workaround for GNU ld (GNU Binutils) 2.33.1:
> > >   19 #   relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
> > >   20 # https://bugs.freebsd.org/242109
> > >   21 .if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
> > >   22 CFLAGS+=-Wl,--no-relax
> > >   23 .endif
> > > 
> > > 
> > > looks like Ed Maste caught this already in the
> > > https://bugs.freebsd.org/242109 but wanted to flag it here as well in case
> > > anyone else runs into this in the hopes it saves some debugging time :)
> > > 
> > Reverted out of frustration in r354935.
> 
> thanks!
> 
> the issue seems to be on my amd64 system ${LINKER_TYPE} is not defined.  i was
> contemplating suggesting updating the .if clause in the Makefile like so:
> 
> .if defined($LINKER_TYPE}) && ${LINKER_TYPE} == "bfd" && ${MACHINE} ==
> "riscv"
> 
> 
> it allows things to compile on my end, but i'm not sure this is best way to
> resolve this issue.
> 

Not necessarily, there were followups to the original commit that leaned
in different directions.  But, nonetheless, I reverted the offending
commits because allowing head to be broken for hours is absurd, and
I personally do not tolerate it when I can resolve it.

Glen



signature.asc
Description: PGP signature

Re: breakage at usr.sbin/jail/Makefile

[Pete Wright]

On 11/20/19 8:13 PM, Glen Barber wrote:

On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:

Hello,
looks like some of the recent commits to usr.sbin/jail/Makefile has broken
CURRENT.  I am getting this error when attempting a buildworld:

===> usr.sbin/jail (cleandir)
make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21:
Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /usr/home/pete/git/freebsd/usr.sbin/jail
*** [cleandir_subdir_usr.sbin/jail] Error code 1


here's the code in question:
  18 # workaround for GNU ld (GNU Binutils) 2.33.1:
  19 #   relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
  20 # https://bugs.freebsd.org/242109
  21 .if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
  22 CFLAGS+=-Wl,--no-relax
  23 .endif


looks like Ed Maste caught this already in the
https://bugs.freebsd.org/242109 but wanted to flag it here as well in case
anyone else runs into this in the hopes it saves some debugging time :)


Reverted out of frustration in r354935.


thanks!

the issue seems to be on my amd64 system ${LINKER_TYPE} is not defined.  
i was contemplating suggesting updating the .if clause in the Makefile 
like so:


.if defined($LINKER_TYPE}) && ${LINKER_TYPE} == "bfd" && ${MACHINE} == 
"riscv"



it allows things to compile on my end, but i'm not sure this is best way 
to resolve this issue.


-p


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: breakage at usr.sbin/jail/Makefile

[Glen Barber]

On Wed, Nov 20, 2019 at 07:57:57PM -0800, Pete Wright wrote:
> Hello,
> looks like some of the recent commits to usr.sbin/jail/Makefile has broken
> CURRENT.  I am getting this error when attempting a buildworld:
> 
> ===> usr.sbin/jail (cleandir)
> make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21:
> Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
> make[4]: Fatal errors encountered -- cannot continue
> make[4]: stopped in /usr/home/pete/git/freebsd/usr.sbin/jail
> *** [cleandir_subdir_usr.sbin/jail] Error code 1
> 
> 
> here's the code in question:
>  18 # workaround for GNU ld (GNU Binutils) 2.33.1:
>  19 #   relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
>  20 # https://bugs.freebsd.org/242109
>  21 .if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
>  22 CFLAGS+=-Wl,--no-relax
>  23 .endif
> 
> 
> looks like Ed Maste caught this already in the
> https://bugs.freebsd.org/242109 but wanted to flag it here as well in case
> anyone else runs into this in the hopes it saves some debugging time :)
> 

Reverted out of frustration in r354935.

Glen



signature.asc
Description: PGP signature

breakage at usr.sbin/jail/Makefile

[Pete Wright]

Hello,
looks like some of the recent commits to usr.sbin/jail/Makefile has 
broken CURRENT.  I am getting this error when attempting a buildworld:


===> usr.sbin/jail (cleandir)
make[4]: "/usr/home/pete/git/freebsd/usr.sbin/jail/Makefile" line 21: 
Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")

make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /usr/home/pete/git/freebsd/usr.sbin/jail
*** [cleandir_subdir_usr.sbin/jail] Error code 1


here's the code in question:
 18 # workaround for GNU ld (GNU Binutils) 2.33.1:
 19 #   relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2'
 20 # https://bugs.freebsd.org/242109
 21 .if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv"
 22 CFLAGS+=-Wl,--no-relax
 23 .endif


looks like Ed Maste caught this already in the 
https://bugs.freebsd.org/242109 but wanted to flag it here as well in 
case anyone else runs into this in the hopes it saves some debugging time :)


-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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 breakage r348516 -> r348572

[Andreas Nilsson]

On Mon, Jun 3, 2019 at 9:35 PM O. Hartmann  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Make installworld after a successful build of r348572 fails due to:
>
> >>> Making hierarchy
> - --
> cd /usr/src; make -f Makefile.inc1  LOCAL_MTREE= hierarchy
> - --- hierarchy ---
> cd /usr/src/etc;
>
> PATH=/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin::/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin::/tmp/install.onYM9YQc
> make LOCAL_MTREE= distrib-dirs --- distrib-cleanup --- for file
> in /usr/share/doc/usd/10.exref /usr/share/doc/usd/11.edit
> /usr/share/doc/usd/12.vi /usr/share/doc/usd/13.viref;
> do  if [ -f /${file} ]; then  rm -f /${file};  fi;  done --- distrib-dirs
> --- -deU -i
> - -f /usr/src/etc/mtree/BSD.root.dist -p / sh: -deU: not found
> *** [distrib-dirs] Error code 127
>
> Greetings,
>
> oh
>
> - --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
>
> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXPV2AQAKCRA4N1ZZPba5
> Ry+RAP9inu4/g3bqyHRVSKOv82Gxpk8LUK/YToKzj56DtiCcIgEA31WCq5F5ja3t
> /EtvVa7hk5yAezafBEim/SRsNGjG/wM=
> =cgUI
> -END PGP SIGNATURE-
> ___
> 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"
>

See other mails from today:
"make packages broken"
"Post-installworld mergemaster breakage r348504 -> r348529"
which has info. A fix is supposed to have been commited.

Best regards
Andreas
___
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 breakage r348516 -> r348572

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Make installworld after a successful build of r348572 fails due to:

>>> Making hierarchy
- --
cd /usr/src; make -f Makefile.inc1  LOCAL_MTREE= hierarchy
- --- hierarchy ---
cd /usr/src/etc;
PATH=/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin::/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin::/tmp/install.onYM9YQc
make LOCAL_MTREE= distrib-dirs --- distrib-cleanup --- for file
in /usr/share/doc/usd/10.exref /usr/share/doc/usd/11.edit 
/usr/share/doc/usd/12.vi /usr/share/doc/usd/13.viref;
do  if [ -f /${file} ]; then  rm -f /${file};  fi;  done --- distrib-dirs --- 
-deU -i
- -f /usr/src/etc/mtree/BSD.root.dist -p / sh: -deU: not found
*** [distrib-dirs] Error code 127

Greetings,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXPV2AQAKCRA4N1ZZPba5
Ry+RAP9inu4/g3bqyHRVSKOv82Gxpk8LUK/YToKzj56DtiCcIgEA31WCq5F5ja3t
/EtvVa7hk5yAezafBEim/SRsNGjG/wM=
=cgUI
-END PGP SIGNATURE-
___
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: Post-installworld mergemaster breakage r348504 -> r348529?

[David Wolfskill]

On Mon, Jun 03, 2019 at 08:15:18AM -0600, Warner Losh wrote:
> I just committed this as a stop-gap fix.
> 
> Warner
> 

Cool.  I encountered the issue on my build box -- laptop was still busy
with other stuff.  Later, when the laptop was ready for the same update
to head, I applied the change proactively, and things Just Worked. :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"One of the things I learned is it’s not about the political view, it’s about 
the kind of person they are.” -- political reporter Dave Bryan (retired)

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


signature.asc
Description: PGP signature

Re: Post-installworld mergemaster breakage r348504 -> r348529?

[Warner Losh]

I just committed this as a stop-gap fix.

Warner

On Mon, Jun 3, 2019 at 5:33 AM Andreas Nilsson  wrote:

> On Mon, Jun 3, 2019 at 1:27 PM David Wolfskill 
> wrote:
>
> > On Mon, Jun 03, 2019 at 01:17:44PM +0200, Andreas Nilsson wrote:
> > > ...
> > > > Any hints?
> > > 
> >
> > > Might this be the same I noticed with "make packages", ie:
> > > diff --git a/Makefile.inc1 b/Makefile.inc1
> > > index 6c77c8abdb8..60ac6493c95 100644
> > > --- a/Makefile.inc1
> > > +++ b/Makefile.inc1
> > > @@ -888,7 +888,7 @@ INSTALLFLAGS+=  -h sha256
> > >  .endif
> > >  .if defined(DB_FROM_SRC) || defined(NO_ROOT)
> > >  IMAKE_INSTALL= INSTALL="${INSTALL} ${INSTALLFLAGS}"
> > > -IMAKE_MTREE=   MTREE_CMD="${MTREE_CMD} ${MTREEFLAGS}"
> > > +IMAKE_MTREE=   MTREE_CMD="${MTREE} ${MTREEFLAGS}"
> > >  .endif
> > >
> > >  DESTDIR_MTREEFLAGS=-deU
> > >
> > > Best regards
> > > Andreas
> > > 
> >
> > Thank you!  Yes; that fixes it.
> >
> > (Sorry for failing to recognize that the git hash you cited was related
> > to the r348504 - r348529 range)
> >
> > Peace,
> > david
> > --
> > David H. Wolfskill  da...@catwhisker.org
> > "One of the things I learned is it’s not about the political view, it’s
> > about
> > the kind of person they are.” -- political reporter Dave Bryan (retired)
> >
> > See http://www.catwhisker.org/~david/publickey.gpg for my public key.
> >
>
>
> Great :)
>
> I just want to point out that I'm not certain my "fix" does the right
> thing; it works for me for building packages for amd64 on amd64, I'm not
> sure it correctly handles crossbuilding, so I would wait for an upstream
> fix for any production workloads.
>
> Best regards
> Andreas
> ___
> 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: Post-installworld mergemaster breakage r348504 -> r348529?

[Andreas Nilsson]

On Mon, Jun 3, 2019 at 1:27 PM David Wolfskill  wrote:

> On Mon, Jun 03, 2019 at 01:17:44PM +0200, Andreas Nilsson wrote:
> > ...
> > > Any hints?
> > 
>
> > Might this be the same I noticed with "make packages", ie:
> > diff --git a/Makefile.inc1 b/Makefile.inc1
> > index 6c77c8abdb8..60ac6493c95 100644
> > --- a/Makefile.inc1
> > +++ b/Makefile.inc1
> > @@ -888,7 +888,7 @@ INSTALLFLAGS+=  -h sha256
> >  .endif
> >  .if defined(DB_FROM_SRC) || defined(NO_ROOT)
> >  IMAKE_INSTALL= INSTALL="${INSTALL} ${INSTALLFLAGS}"
> > -IMAKE_MTREE=   MTREE_CMD="${MTREE_CMD} ${MTREEFLAGS}"
> > +IMAKE_MTREE=   MTREE_CMD="${MTREE} ${MTREEFLAGS}"
> >  .endif
> >
> >  DESTDIR_MTREEFLAGS=-deU
> >
> > Best regards
> > Andreas
> > 
>
> Thank you!  Yes; that fixes it.
>
> (Sorry for failing to recognize that the git hash you cited was related
> to the r348504 - r348529 range)
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> "One of the things I learned is it’s not about the political view, it’s
> about
> the kind of person they are.” -- political reporter Dave Bryan (retired)
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>


Great :)

I just want to point out that I'm not certain my "fix" does the right
thing; it works for me for building packages for amd64 on amd64, I'm not
sure it correctly handles crossbuilding, so I would wait for an upstream
fix for any production workloads.

Best regards
Andreas
___
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: Post-installworld mergemaster breakage r348504 -> r348529?

[David Wolfskill]

On Mon, Jun 03, 2019 at 01:17:44PM +0200, Andreas Nilsson wrote:
> ...
> > Any hints?
>  

> Might this be the same I noticed with "make packages", ie:
> diff --git a/Makefile.inc1 b/Makefile.inc1
> index 6c77c8abdb8..60ac6493c95 100644
> --- a/Makefile.inc1
> +++ b/Makefile.inc1
> @@ -888,7 +888,7 @@ INSTALLFLAGS+=  -h sha256
>  .endif
>  .if defined(DB_FROM_SRC) || defined(NO_ROOT)
>  IMAKE_INSTALL= INSTALL="${INSTALL} ${INSTALLFLAGS}"
> -IMAKE_MTREE=   MTREE_CMD="${MTREE_CMD} ${MTREEFLAGS}"
> +IMAKE_MTREE=   MTREE_CMD="${MTREE} ${MTREEFLAGS}"
>  .endif
> 
>  DESTDIR_MTREEFLAGS=-deU
> 
> Best regards
> Andreas
> 

Thank you!  Yes; that fixes it.

(Sorry for failing to recognize that the git hash you cited was related
to the r348504 - r348529 range)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"One of the things I learned is it’s not about the political view, it’s about 
the kind of person they are.” -- political reporter Dave Bryan (retired)

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


signature.asc
Description: PGP signature

Re: Post-installworld mergemaster breakage r348504 -> r348529?

[Andreas Nilsson]

On Mon, Jun 3, 2019 at 1:06 PM David Wolfskill  wrote:

> I see:
>
> ...
> --
> >>> Installing everything completed on Mon Jun  3 03:48:55 PDT 2019
> --
> Mon Jun  3 03:48:55 PDT 2019
>
> *** 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: -N: not found
>
>   *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to
>   the temproot environment
>
>
>
> (using my usual set of csh aliases, so trying again "manually"):
>
> freebeast(13.0-C)[1] cd /usr/src
> freebeast(13.0-C)[2] mergemaster -F -U -u 0022 -i
>
> *** The directory specified for the temporary root environment,
> /var/tmp/temproot, exists.  This can be a security risk if untrusted
> users have access to the system.
>
>   Use 'd' to delete the old /var/tmp/temproot and continue
>   Use 't' to select a new temporary root directory
>   Use 'e' to exit mergemaster
>
>   Default is to use /var/tmp/temproot as is
>
> How should I deal with this? [Use the existing /var/tmp/temproot] d
>
>*** Deleting the old /var/tmp/temproot
>
> *** 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: -N: not found
>
>   *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to
>   the temproot environment
>
> freebeast(13.0-C)[3]
>
>
> As for the environment:
>
> FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #573
> r348504M/348508: Sun Jun  2 09:00:52 PDT 2019
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
>
> freebeast(13.0-C)[16] grep -v '^#' /etc/make.conf
> SENDMAIL_MC=/etc/mail/client.mc
> freebeast(13.0-C)[17]
>
> freebeast(13.0-C)[17] grep -v '^#' /etc/src.conf
>
> WITHOUT_DEBUG_FILES=1
> WITH_ELFCOPY_AS_OBJCOPY=1
> freebeast(13.0-C)[18]
>
> freebeast(13.0-C)[19] grep -v '^#' /etc/src-env.conf
> WITH_META_MODE=yes
> freebeast(13.0-C)[20]
>
> I find "-N ..." in /usr/src/Makefile.inc1 (for INSTALLFLAGS and
> MTREEFLAGS, but I don't see how that would cause this.  And I've
> been doing this (tracking head daily) for ... "a while" (usually
> without incident).
>
> Any hints?
>
> Thanks!
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> "One of the things I learned is it’s not about the political view, it’s
> about
> the kind of person they are.” -- political reporter Dave Bryan (retired)
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>


Might this be the same I noticed with "make packages", ie:
diff --git a/Makefile.inc1 b/Makefile.inc1
index 6c77c8abdb8..60ac6493c95 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -888,7 +888,7 @@ INSTALLFLAGS+=  -h sha256
 .endif
 .if defined(DB_FROM_SRC) || defined(NO_ROOT)
 IMAKE_INSTALL= INSTALL="${INSTALL} ${INSTALLFLAGS}"
-IMAKE_MTREE=   MTREE_CMD="${MTREE_CMD} ${MTREEFLAGS}"
+IMAKE_MTREE=   MTREE_CMD="${MTREE} ${MTREEFLAGS}"
 .endif

 DESTDIR_MTREEFLAGS=-deU

Best regards
Andreas
___
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"

Post-installworld mergemaster breakage r348504 -> r348529?

[David Wolfskill]

I see:

...
--
>>> Installing everything completed on Mon Jun  3 03:48:55 PDT 2019
--
Mon Jun  3 03:48:55 PDT 2019

*** 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: -N: not found

  *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to
  the temproot environment



(using my usual set of csh aliases, so trying again "manually"):

freebeast(13.0-C)[1] cd /usr/src
freebeast(13.0-C)[2] mergemaster -F -U -u 0022 -i

*** The directory specified for the temporary root environment,
/var/tmp/temproot, exists.  This can be a security risk if untrusted
users have access to the system.

  Use 'd' to delete the old /var/tmp/temproot and continue
  Use 't' to select a new temporary root directory
  Use 'e' to exit mergemaster

  Default is to use /var/tmp/temproot as is

How should I deal with this? [Use the existing /var/tmp/temproot] d

   *** Deleting the old /var/tmp/temproot

*** 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: -N: not found

  *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to
  the temproot environment

freebeast(13.0-C)[3] 


As for the environment:

FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #573 
r348504M/348508: Sun Jun  2 09:00:52 PDT 2019 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64

freebeast(13.0-C)[16] grep -v '^#' /etc/make.conf
SENDMAIL_MC=/etc/mail/client.mc
freebeast(13.0-C)[17] 

freebeast(13.0-C)[17] grep -v '^#' /etc/src.conf   
WITHOUT_DEBUG_FILES=1
WITH_ELFCOPY_AS_OBJCOPY=1
freebeast(13.0-C)[18] 

freebeast(13.0-C)[19] grep -v '^#' /etc/src-env.conf 
WITH_META_MODE=yes
freebeast(13.0-C)[20] 

I find "-N ..." in /usr/src/Makefile.inc1 (for INSTALLFLAGS and
MTREEFLAGS, but I don't see how that would cause this.  And I've
been doing this (tracking head daily) for ... "a while" (usually
without incident).

Any hints?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"One of the things I learned is it’s not about the political view, it’s about 
the kind of person they are.” -- political reporter Dave Bryan (retired)

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


signature.asc
Description: PGP signature

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

[Mark Johnston]

On Thu, Nov 16, 2017 at 09:07:56AM -0800, Ngie Cooper (yaneurabeya) wrote:
> Hi Mateusz,
>   Per Jenkins, these two tests are broken after r325719:325721: 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/4987/ 
>  .
> Thanks,
> -Ngie

Ping? These tests are still failing.
___
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: Breakage with sys.kern.ptrace_test.{ptrace__parent_sees_exit_after_child_debugger, parent_sees_exit_after_unrelated_debugger} after r325719:325721

[John Baldwin]

On Thursday, November 16, 2017 09:07:56 AM Ngie Cooper wrote:
> Hi Mateusz,
>   Per Jenkins, these two tests are broken after r325719:325721: 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/4987/ 
>  .
> Thanks,
> -Ngie

It is probably the first commit.  Previously, the kern.proc. sysctl
would fail for zombies, so these tests poll that sysctl waiting for it to
fail to determine when a process has become a zombie.  I think the first
commit broke this as the sysctl now works for zombies so the tests hang
forever.  I could fix the tests to check for the status in the kinfo_proc.
I've no idea if there are other programs aside from tests that depend on
this behavior that are also broken though.  I feel like I copied that
approach from some other bit of code when writing these tests.

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

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

[Ngie Cooper (yaneurabeya)]

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


signature.asc
Description: Message signed with OpenPGP

Re: i915kms breakage

[Maurizio Vairani]

2017-04-29 0:52 GMT+02:00 Andrey Fesenko :

> On Fri, Apr 28, 2017 at 10:10 PM, Maurizio Vairani
>  wrote:
> > 2017-04-22 14:47 GMT+02:00 Domagoj Stolfa :
> >
> >> Hello,
> >>
> >> ever since I've merged yesterday, it would seem that the i915kms driver
> >> panics every time it is loaded. Unfortunately, I am not able to provide
> >> a dump of the panic, as I am unable to see what the panic is, or what is
> >> even going on as a matter of fact due to my screen being overtaken by
> >> a driver that has just panicked. call doadump() does not seem to work
> >> either.
> >>
> >> Is anyone else having these problems, or know where the issue might be
> >> occurring?
> >>
> >> The same happens with 12.0-CURRENT r317513 updated yesterday. The laptop
> > is a Samsung NP270E5E with Intel Graphics 4000,
> > http://www.samsung.com/us/computer/pcs/NP270E5E-K02US-specs
> > --
>
> i5 r317402 and r317437 run only single mode, after r317561 work Xorg again
> :)
>

Thanks Andey,
updated to r317579 and works for me too.
--
Maurizio
___
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: i915kms breakage

[Andrey Fesenko]

On Fri, Apr 28, 2017 at 10:10 PM, Maurizio Vairani
 wrote:
> 2017-04-22 14:47 GMT+02:00 Domagoj Stolfa :
>
>> Hello,
>>
>> ever since I've merged yesterday, it would seem that the i915kms driver
>> panics every time it is loaded. Unfortunately, I am not able to provide
>> a dump of the panic, as I am unable to see what the panic is, or what is
>> even going on as a matter of fact due to my screen being overtaken by
>> a driver that has just panicked. call doadump() does not seem to work
>> either.
>>
>> Is anyone else having these problems, or know where the issue might be
>> occurring?
>>
>> The same happens with 12.0-CURRENT r317513 updated yesterday. The laptop
> is a Samsung NP270E5E with Intel Graphics 4000,
> http://www.samsung.com/us/computer/pcs/NP270E5E-K02US-specs
> --

i5 r317402 and r317437 run only single mode, after r317561 work Xorg again :)
___
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: i915kms breakage

[Maurizio Vairani]

2017-04-22 14:47 GMT+02:00 Domagoj Stolfa :

> Hello,
>
> ever since I've merged yesterday, it would seem that the i915kms driver
> panics every time it is loaded. Unfortunately, I am not able to provide
> a dump of the panic, as I am unable to see what the panic is, or what is
> even going on as a matter of fact due to my screen being overtaken by
> a driver that has just panicked. call doadump() does not seem to work
> either.
>
> Is anyone else having these problems, or know where the issue might be
> occurring?
>
> The same happens with 12.0-CURRENT r317513 updated yesterday. The laptop
is a Samsung NP270E5E with Intel Graphics 4000,
http://www.samsung.com/us/computer/pcs/NP270E5E-K02US-specs
--
Regards,
Maurizio
___
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"

i915kms breakage

[Domagoj Stolfa]

Hello,

ever since I've merged yesterday, it would seem that the i915kms driver
panics every time it is loaded. Unfortunately, I am not able to provide
a dump of the panic, as I am unable to see what the panic is, or what is
even going on as a matter of fact due to my screen being overtaken by
a driver that has just panicked. call doadump() does not seem to work
either.

Is anyone else having these problems, or know where the issue might be
occurring?

-- 
Best regards,
Domagoj Stolfa


signature.asc
Description: PGP signature

Re: Strange kernel build breakage (after r314283?)

[Warner Losh]

On Tue, Mar 7, 2017 at 12:36 PM, Chris H  wrote:
> On Tue, 7 Mar 2017 09:13:58 -0800 Kevin Oberman  wrote
>
>> On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov  wrote:
>>
>> > On 06.03.2017 20:10, Lev Serebryakov wrote:
>> >
>> > >  I've got this error when tried to update my -CURRENT VM to r314772:
>> > >
>> > > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
>> > > "XPT_PRINT_LEN is too large"
>> > > _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
>> > > large");
>> > > ^  ~
>> > >
>> > >  I didn't define any XPT_ macro by hands, but I have
>> > >
>> > > options PRINTF_BUFR_SIZE=1024
>> > >
>> > >  in my kernel config.
>> >  Yep, removing this option helps, but it is surprising and not obvious
>> > at all!
>> >
>> > --
>> > // Lev Serebryakov
>> >
>>
>> If my memory is good (and it may not be), this option was recommended to
>> prevent garbled syslog and console entries, but that was back in v8 days,
>> long, long ago. I have not had his problem for a long time and I think that
>> the option is no longer required and even they, 1024 was a LOT bigger than
>> was recommended at the time. 128 or 256 seems tike the value recommended.
>
> Relax. You're memory is still in good order. :-)
> It was in fact the reason. I had to add the then suggested amount:
> PRINTF_BUFR_SIZE=128
> to my KERNCONF even into early 9. But haven't required it since
> ~mid-9.
>
> OTOH I'm now seeing something similar on CURRENT. Only somewhat
> in reverse.
> The last message I receive on the console following halt(8) is
> the message telling me the NIC has been brought down. It then
> sits there until I hit the enter key to reboot(8).
>
> But that's another topic for another thread. :-)

Hmmm, looks like I broke this... Meaning the static config. I'll look
at it more closely.

Warner
___
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: Strange kernel build breakage (after r314283?)

[Chris H]

On Tue, 7 Mar 2017 09:13:58 -0800 Kevin Oberman  wrote

> On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov  wrote:
> 
> > On 06.03.2017 20:10, Lev Serebryakov wrote:
> >
> > >  I've got this error when tried to update my -CURRENT VM to r314772:
> > >
> > > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
> > > "XPT_PRINT_LEN is too large"
> > > _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
> > > large");
> > > ^  ~
> > >
> > >  I didn't define any XPT_ macro by hands, but I have
> > >
> > > options PRINTF_BUFR_SIZE=1024
> > >
> > >  in my kernel config.
> >  Yep, removing this option helps, but it is surprising and not obvious
> > at all!
> >
> > --
> > // Lev Serebryakov
> >
> 
> If my memory is good (and it may not be), this option was recommended to
> prevent garbled syslog and console entries, but that was back in v8 days,
> long, long ago. I have not had his problem for a long time and I think that
> the option is no longer required and even they, 1024 was a LOT bigger than
> was recommended at the time. 128 or 256 seems tike the value recommended.

Relax. You're memory is still in good order. :-)
It was in fact the reason. I had to add the then suggested amount:
PRINTF_BUFR_SIZE=128
to my KERNCONF even into early 9. But haven't required it since
~mid-9.

OTOH I'm now seeing something similar on CURRENT. Only somewhat
in reverse.
The last message I receive on the console following halt(8) is
the message telling me the NIC has been brought down. It then
sits there until I hit the enter key to reboot(8).

But that's another topic for another thread. :-)

--Chris
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


___
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: Strange kernel build breakage (after r314283?)

[Kevin Oberman]

On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov  wrote:

> On 06.03.2017 20:10, Lev Serebryakov wrote:
>
> >  I've got this error when tried to update my -CURRENT VM to r314772:
> >
> > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
> > "XPT_PRINT_LEN is too large"
> > _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
> > large");
> > ^  ~
> >
> >  I didn't define any XPT_ macro by hands, but I have
> >
> > options PRINTF_BUFR_SIZE=1024
> >
> >  in my kernel config.
>  Yep, removing this option helps, but it is surprising and not obvious
> at all!
>
> --
> // Lev Serebryakov
>

If my memory is good (and it may not be), this option was recommended to
prevent garbled syslog and console entries, but that was back in v8 days,
long, long ago. I have not had his problem for a long time and I think that
the option is no longer required and even they, 1024 was a LOT bigger than
was recommended at the time. 128 or 256 seems tike the value recommended.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Strange kernel build breakage (after r314283?)

[Lev Serebryakov]

On 06.03.2017 20:10, Lev Serebryakov wrote:

>  I've got this error when tried to update my -CURRENT VM to r314772:
> 
> /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
> "XPT_PRINT_LEN is too large"
> _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
> large");
> ^  ~
> 
>  I didn't define any XPT_ macro by hands, but I have
> 
> options PRINTF_BUFR_SIZE=1024
> 
>  in my kernel config.
 Yep, removing this option helps, but it is surprising and not obvious
at all!

-- 
// Lev Serebryakov
___
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"

Strange kernel build breakage (after r314283?)

[Lev Serebryakov]

 I've got this error when tried to update my -CURRENT VM to r314772:

/data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
"XPT_PRINT_LEN is too large"
_Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
large");
^  ~

 I didn't define any XPT_ macro by hands, but I have

options PRINTF_BUFR_SIZE=1024

 in my kernel config.

-- 
// Lev Serebryakov
___
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: PORTS_MODULES breakage on HEAD

[Don Lewis]

On 12 Aug, Bryan Drewery wrote:
> On 8/10/2016 4:20 PM, Bryan Drewery wrote:
>> On 8/7/16 5:44 PM, Don Lewis wrote:
>>> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
>>> HEAD.  When I do that I get this failure:
>>>
>>> ===> Ports module emulators/virtualbox-ose-kmod (all)
>>> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; 
>>> PATH=/usr/obj/usr/src/
>>> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
>>> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
>>> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  
>>> OSVERSION=12
>>> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
>>> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
>>> ===>  License GPLv2 accepted by the user
>>> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
>>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - 
>>> found
>>> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for 
>>> buildin
>>> g
>>> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
>>> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
>>> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
>>> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
>>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
>>> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
>>> Checking for environment: Determined build machine: freebsd.amd64, target 
>>> machin
>>> e: freebsd.amd64, OK.
>>> Checking for kBuild: found, OK.
>>> Checking for gcc:
>>>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not 
>>> found!
>>> Check 
>>> /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
>>> ox-5.0.26/configure.log for details
>>> ===>  Script "configure" failed unexpectedly.
>>> Please report the problem to v...@freebsd.org [maintainer] and attach the
>>> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
>>> .0.26/config.log"
>>>
>>>
>>> It appears that the problem is due to CC being set to:
>>> cc -target x86_64-unknown-freebsd12.0 --sysroot
>>> and the Makefile for the port passes this:
>>> --with-gcc="${CC}"
>>> to configure.  The configure script passes $CC to check_avail, which
>>> does a -z test on it.
>>>
>>> I think that CC should just be set to "cc" and the rest should get added
>>> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
>>>
>> 
>> 
>> It's a SYSTEM_COMPILER bug.  I'll look into fixing it.
>> 
>> For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround.
>> 
>> 
> 
> I've committed a fix to head in r304005. I will MFC it to stable/11 in
> about a week.

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: PORTS_MODULES breakage on HEAD

[Bryan Drewery]

On 8/10/2016 4:20 PM, Bryan Drewery wrote:
> On 8/7/16 5:44 PM, Don Lewis wrote:
>> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
>> HEAD.  When I do that I get this failure:
>>
>> ===> Ports module emulators/virtualbox-ose-kmod (all)
>> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; 
>> PATH=/usr/obj/usr/src/
>> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
>> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
>> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  
>> OSVERSION=12
>> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
>> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
>> ===>  License GPLv2 accepted by the user
>> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - 
>> found
>> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for 
>> buildin
>> g
>> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
>> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
>> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
>> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
>> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
>> Checking for environment: Determined build machine: freebsd.amd64, target 
>> machin
>> e: freebsd.amd64, OK.
>> Checking for kBuild: found, OK.
>> Checking for gcc:
>>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found!
>> Check 
>> /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
>> ox-5.0.26/configure.log for details
>> ===>  Script "configure" failed unexpectedly.
>> Please report the problem to v...@freebsd.org [maintainer] and attach the
>> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
>> .0.26/config.log"
>>
>>
>> It appears that the problem is due to CC being set to:
>>  cc -target x86_64-unknown-freebsd12.0 --sysroot
>> and the Makefile for the port passes this:
>>  --with-gcc="${CC}"
>> to configure.  The configure script passes $CC to check_avail, which
>> does a -z test on it.
>>
>> I think that CC should just be set to "cc" and the rest should get added
>> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
>>
> 
> 
> It's a SYSTEM_COMPILER bug.  I'll look into fixing it.
> 
> For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround.
> 
> 

I've committed a fix to head in r304005. I will MFC it to stable/11 in
about a week.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: PORTS_MODULES breakage on HEAD

[Bryan Drewery]

On 8/7/16 5:44 PM, Don Lewis wrote:
> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
> HEAD.  When I do that I get this failure:
> 
> ===> Ports module emulators/virtualbox-ose-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; 
> PATH=/usr/obj/usr/src/
> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  
> OSVERSION=12
> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
> ===>  License GPLv2 accepted by the user
> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - 
> found
> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for 
> buildin
> g
> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
> Checking for environment: Determined build machine: freebsd.amd64, target 
> machin
> e: freebsd.amd64, OK.
> Checking for kBuild: found, OK.
> Checking for gcc:
>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found!
> Check 
> /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
> ox-5.0.26/configure.log for details
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to v...@freebsd.org [maintainer] and attach the
> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
> .0.26/config.log"
> 
> 
> It appears that the problem is due to CC being set to:
>   cc -target x86_64-unknown-freebsd12.0 --sysroot
> and the Makefile for the port passes this:
>   --with-gcc="${CC}"
> to configure.  The configure script passes $CC to check_avail, which
> does a -z test on it.
> 
> I think that CC should just be set to "cc" and the rest should get added
> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
> 


It's a SYSTEM_COMPILER bug.  I'll look into fixing it.

For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: PORTS_MODULES breakage on HEAD

[Kevin Oberman]

On Sun, Aug 7, 2016 at 5:44 PM, Don Lewis  wrote:

> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
> HEAD.  When I do that I get this failure:
>
> ===> Ports module emulators/virtualbox-ose-kmod (all)
> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod;
> PATH=/usr/obj/usr/src/
> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/
> usr/obj/usr/src/tmp/leg
> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/
> usr/bin:/sbin:/bin:/u
> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src
> OSVERSION=12
> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
> ===>  License GPLv2 accepted by the user
> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg -
> found
> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for
> buildin
> g
> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
> Checking for environment: Determined build machine: freebsd.amd64, target
> machin
> e: freebsd.amd64, OK.
> Checking for kBuild: found, OK.
> Checking for gcc:
>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not
> found!
> Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-
> ose-kmod/work/VirtualB
> ox-5.0.26/configure.log for details
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to v...@freebsd.org [maintainer] and attach the
> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-
> ose-kmod/work/VirtualBox-5
> .0.26/config.log"
>
>
> It appears that the problem is due to CC being set to:
> cc -target x86_64-unknown-freebsd12.0 --sysroot
> and the Makefile for the port passes this:
> --with-gcc="${CC}"
> to configure.  The configure script passes $CC to check_avail, which
> does a -z test on it.
>
> I think that CC should just be set to "cc" and the rest should get added
> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
>
> ___
> 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"
>

Same issue on 11.0-BETA4 (and at least BETA3). It's not just HEAD.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

PORTS_MODULES breakage on HEAD

[Don Lewis]

Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
HEAD.  When I do that I get this failure:

===> Ports module emulators/virtualbox-ose-kmod (all)
cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; PATH=/usr/obj/usr/src/
tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  OSVERSION=12
0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
===>  License GPLv2 accepted by the user
===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for buildin
g
===>  Extracting for virtualbox-ose-kmod-5.0.26_1
=> SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
===>  Patching for virtualbox-ose-kmod-5.0.26_1
===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
===>  Configuring for virtualbox-ose-kmod-5.0.26_1
Checking for environment: Determined build machine: freebsd.amd64, target machin
e: freebsd.amd64, OK.
Checking for kBuild: found, OK.
Checking for gcc:
  ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found!
Check /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
ox-5.0.26/configure.log for details
===>  Script "configure" failed unexpectedly.
Please report the problem to v...@freebsd.org [maintainer] and attach the
"/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
.0.26/config.log"


It appears that the problem is due to CC being set to:
cc -target x86_64-unknown-freebsd12.0 --sysroot
and the Makefile for the port passes this:
--with-gcc="${CC}"
to configure.  The configure script passes $CC to check_avail, which
does a -z test on it.

I think that CC should just be set to "cc" and the rest should get added
to CFLAGS.  I suspect this got broken by the recent crossbuild changes.

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

[Shawn Webb]

On Fri, Feb 26, 2016 at 09:23:16AM -0500, Shawn Webb wrote:
> Hey All,
> 
> It looks like a recent commit to HEAD broke the `real-release` target in
> /usr/src/release. I suspect it's the capserd-related commits, but I
> haven't confirmed, yet. I'm going to spend some time trying to nail down
> which commit.
> 
> Here's the build log:
> 
> http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-i915kms-amd64/47/console

I have confirmed that this commit breaks the build:

https://github.com/freebsd/freebsd/commit/023f14d65b31db71d1a4e6655205dd919bfeb5fb

Reverting that commit fixes the build.

Thanks,

-- 
Shawn Webb
HardenedBSD

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


signature.asc
Description: PGP signature

Build Breakage

[Shawn Webb]

Hey All,

It looks like a recent commit to HEAD broke the `real-release` target in
/usr/src/release. I suspect it's the capserd-related commits, but I
haven't confirmed, yet. I'm going to spend some time trying to nail down
which commit.

Here's the build log:

http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-i915kms-amd64/47/console

Thanks,

-- 
Shawn Webb
HardenedBSD

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


signature.asc
Description: PGP signature

Re: buildkernel ULE related breakage

[Ngie Cooper]

On Thu, Feb 18, 2016 at 2:10 PM, Michal Suszko  wrote:
>
> Hi,
> Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT
> ( wrapped long lines )
>
> cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
>   -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
>   -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I.
>   -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica
>   -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
>   -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
>   -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2
>   -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c
> cc1: warnings being treated as errors
> /usr/src/sys/kern/sched_ule.c: In function `sched_setup':
> /usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i'
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/TEST.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.

I'm not sure what you're running, but it doesn't look like untainted CURRENT.

1. Please post `TEST` somewhere in pastebin.
2. Please note what revision you're on, whether you're forked from
another version, etc.

Thanks,
-Ngie

 526 /*
 527  * Load is maintained for all threads RUNNING and ON_RUNQ.  Add the load
 528  * for this thread to the referenced thread queue.
 529  */
 530 static void
 531 tdq_load_add(struct tdq *tdq, struct thread *td)
 532 {
 533
 534 TDQ_LOCK_ASSERT(tdq, MA_OWNED);
 535 THREAD_LOCK_ASSERT(td, MA_OWNED);
 536
 537 tdq->tdq_load++;
 538 if ((td->td_flags & TDF_NOLOAD) == 0)
 539 tdq->tdq_sysload++;
 540 KTR_COUNTER0(KTR_SCHED, "load", tdq->tdq_loadname, tdq->tdq_load);
 541 SDT_PROBE2(sched, , , load__change, (int)TDQ_ID(tdq),
tdq->tdq_load);
 542 }
___
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"

buildkernel ULE related breakage

[Michal Suszko]

Hi,
Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT 
( wrapped long lines )

cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
  -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
  -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I.
  -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica
  -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
  -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
  -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2
  -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c
cc1: warnings being treated as errors
/usr/src/sys/kern/sched_ule.c: In function `sched_setup':
/usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i'
*** Error code 1

Stop in /usr/obj/usr/src/sys/TEST.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


Michal

___
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: librt symbol versioning breakage (was Re: Build failure, undefined reference to __mq_oshandle)

[Konstantin Belousov]

On Thu, Dec 03, 2015 at 10:34:10PM -0500, Daniel Eischen wrote:
> On Mon, 30 Nov 2015, Konstantin Belousov wrote:
> 
> > On Sun, Nov 29, 2015 at 12:27:40PM -0500, Daniel Eischen wrote:
> >> On Sun, 29 Nov 2015, Konstantin Belousov wrote:
> >>
> >>> On Sun, Nov 29, 2015 at 01:23:04AM -0500, Daniel Eischen wrote:
> 
>  So I found out that sometime in the last year or so, symbol versioning
>  for librt was broken and leaking symbols that shouldn't have been
>  leaked.  I've just committed a fix for this.
> 
>  Do a 'readelf -sw /usr/lib/librt.so.1 | grep GLOBAL | grep -v UND'
>  and see the non FBSD_foo symbols that shouldn't be there.
> >>>
> >>> I did the following on the librt from the HEAD of about month ago:
> >>>
> >>> pooma% ls -l netboot/sandy/usr/lib/librt.so.1
> >>> -r--r--r--  1 root  wheel  23704 Oct 24 23:35 
> >>> netboot/sandy/usr/lib/librt.so.1
> >>>
> >>> pooma% readelf -sw netboot/sandy/usr/lib/librt.so.1 | grep GLOBAL | grep 
> >>> -v UND | grep -v FBSDpriv | grep FBSD
> >>>97:  0 OBJECT  GLOBAL DEFAULT  ABS FBSD_1.0
> >>>
> >>> But I think that your commit is the good change.
> >>
> >>
> >> Can you check librt.so.1 in your buildworld temporary build
> >> environment?
> >>
> >>$ readelf -sW /usr/obj/usr/FreeBSD/svn/src/tmp/usr/lib/librt.so.1 \
> >>   grep -v UND | grep GLOBAL
> >>
> >> There has to be a reason that tests/sys/mqueue/mqtest[3-4].c build
> >> without error when they reference __mq_oshandle.  That symbol is
> >> not exported from librt.
> >>
> >> Hmm, looks like libc and libthr are also the same (leaky) in the
> >> temporary build environment (TBE).  So something broke when building
> >> the TBE libraries.
> >>
> >> For r277320 on my system Jan 19, 2015, the TBE libraries must have
> >> been built correctly because mqtests[3-4] failed with unresolved
> >> references to __mq_oshandle.
> >
> > In fact, my command was wrong.  I see that there are indeed a lot of symbols
> > exported which are not versioned (this is where my command was wrong, the
> > grep FBSD part), even for the installed librt.
> 
> Arrgh, this bug also seems to have slipped into 10-stable.
> 
> $ uname -a
> FreeBSD  10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr  7 
> 01:09:46 UTC 2015 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> $ readelf -sW /usr/lib/librt.so.1 | grep -v UND | grep GLOBAL \
>| grep -v FBSD
>  71: 3ac0   432 FUNCGLOBAL DEFAULT   12 __sigev_alloc
>  ...
> $ readelf -sW /usr/lib/librt.so.1 | grep -v UND | grep GLOBAL \
>| grep -v FBSD | wc -l
>22

Yes, I did my check on stable/10 FWIW.
___
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: librt symbol versioning breakage (was Re: Build failure, undefined reference to __mq_oshandle)

[Daniel Eischen]

On Mon, 30 Nov 2015, Konstantin Belousov wrote:


On Sun, Nov 29, 2015 at 12:27:40PM -0500, Daniel Eischen wrote:

On Sun, 29 Nov 2015, Konstantin Belousov wrote:


On Sun, Nov 29, 2015 at 01:23:04AM -0500, Daniel Eischen wrote:


So I found out that sometime in the last year or so, symbol versioning
for librt was broken and leaking symbols that shouldn't have been
leaked.  I've just committed a fix for this.

Do a 'readelf -sw /usr/lib/librt.so.1 | grep GLOBAL | grep -v UND'
and see the non FBSD_foo symbols that shouldn't be there.


I did the following on the librt from the HEAD of about month ago:

pooma% ls -l netboot/sandy/usr/lib/librt.so.1
-r--r--r--  1 root  wheel  23704 Oct 24 23:35 netboot/sandy/usr/lib/librt.so.1

pooma% readelf -sw netboot/sandy/usr/lib/librt.so.1 | grep GLOBAL | grep -v UND 
| grep -v FBSDpriv | grep FBSD
   97:  0 OBJECT  GLOBAL DEFAULT  ABS FBSD_1.0

But I think that your commit is the good change.



Can you check librt.so.1 in your buildworld temporary build
environment?

   $ readelf -sW /usr/obj/usr/FreeBSD/svn/src/tmp/usr/lib/librt.so.1 \
  grep -v UND | grep GLOBAL

There has to be a reason that tests/sys/mqueue/mqtest[3-4].c build
without error when they reference __mq_oshandle.  That symbol is
not exported from librt.

Hmm, looks like libc and libthr are also the same (leaky) in the
temporary build environment (TBE).  So something broke when building
the TBE libraries.

For r277320 on my system Jan 19, 2015, the TBE libraries must have
been built correctly because mqtests[3-4] failed with unresolved
references to __mq_oshandle.


In fact, my command was wrong.  I see that there are indeed a lot of symbols
exported which are not versioned (this is where my command was wrong, the
grep FBSD part), even for the installed librt.


Arrgh, this bug also seems to have slipped into 10-stable.

$ uname -a
FreeBSD  10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr  7 
01:09:46 UTC 2015 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

$ readelf -sW /usr/lib/librt.so.1 | grep -v UND | grep GLOBAL \
  | grep -v FBSD
71: 3ac0   432 FUNCGLOBAL DEFAULT   12 __sigev_alloc
...
$ readelf -sW /usr/lib/librt.so.1 | grep -v UND | grep GLOBAL \
  | grep -v FBSD | wc -l
  22

--
DE
___
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: librt symbol versioning breakage (was Re: Build failure, undefined reference to __mq_oshandle)

[Konstantin Belousov]

On Sun, Nov 29, 2015 at 12:27:40PM -0500, Daniel Eischen wrote:
> On Sun, 29 Nov 2015, Konstantin Belousov wrote:
> 
> > On Sun, Nov 29, 2015 at 01:23:04AM -0500, Daniel Eischen wrote:
> >> On Fri, 27 Nov 2015, Daniel Eischen wrote:
> >>
> >>> Damn, please use deisc...@freebsd.org for replies.
> >>>
> >>> On Fri, 27 Nov 2015, Daniel Eischen wrote:
> >>>
>  On Fri, 27 Nov 2015, Daniel Eischen wrote:
> 
> > $ uname -a
> > FreeBSD vega 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277320: Mon Jan 19
> > 09:02:50 EST 2015
> > deischen@vega:/usr/FreeBSD/svn/obj/usr/FreeBSD/svn/src/sys/vega  amd64
> >
> > Upgrading to today's current, 'rm -rf /usr/obj/*; make -j8 buildworld'
> > fails here:
> >
> > ===> lib/libc/tests/gen/execve (buildconfig)
> > --- all_subdir_tests ---
> > --- all_subdir_mqueue ---
> > mqtest3.o: In function `main':
> > /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x139): undefined
> > reference to `__mq_oshandle'
> > /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x14c): undefined
> > reference to `__mq_oshandle'
> > /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x16c): undefined
> > reference to `__mq_oshandle'
> > /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3e6): undefined
> > reference to `__mq_oshandle'
> > /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3f9): undefined
> > reference to `__mq_oshandle'
> > mqtest3.o:/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x40f):
> > more undefined references to `__mq_oshandle' follow
> > cc: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> >
> > Going to try make [-j1], next, but anyone come across this?
> 
>  Still fails.
> 
>  Why do the tests in tests/sys/mqueue/ try to use non-public APIs?
> >>
> >> So I found out that sometime in the last year or so, symbol versioning
> >> for librt was broken and leaking symbols that shouldn't have been
> >> leaked.  I've just committed a fix for this.
> >>
> >> Do a 'readelf -sw /usr/lib/librt.so.1 | grep GLOBAL | grep -v UND'
> >> and see the non FBSD_foo symbols that shouldn't be there.
> >
> > I did the following on the librt from the HEAD of about month ago:
> >
> > pooma% ls -l netboot/sandy/usr/lib/librt.so.1
> > -r--r--r--  1 root  wheel  23704 Oct 24 23:35 
> > netboot/sandy/usr/lib/librt.so.1
> >
> > pooma% readelf -sw netboot/sandy/usr/lib/librt.so.1 | grep GLOBAL | grep -v 
> > UND | grep -v FBSDpriv | grep FBSD
> >97:  0 OBJECT  GLOBAL DEFAULT  ABS FBSD_1.0
> >
> > But I think that your commit is the good change.
> 
> 
> Can you check librt.so.1 in your buildworld temporary build
> environment?
> 
>$ readelf -sW /usr/obj/usr/FreeBSD/svn/src/tmp/usr/lib/librt.so.1 \
>   grep -v UND | grep GLOBAL
> 
> There has to be a reason that tests/sys/mqueue/mqtest[3-4].c build
> without error when they reference __mq_oshandle.  That symbol is
> not exported from librt.
> 
> Hmm, looks like libc and libthr are also the same (leaky) in the
> temporary build environment (TBE).  So something broke when building
> the TBE libraries.
> 
> For r277320 on my system Jan 19, 2015, the TBE libraries must have
> been built correctly because mqtests[3-4] failed with unresolved
> references to __mq_oshandle.

In fact, my command was wrong.  I see that there are indeed a lot of symbols
exported which are not versioned (this is where my command was wrong, the
grep FBSD part), even for the installed librt.

Your patch fixed the issue.
___
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: librt symbol versioning breakage (was Re: Build failure, undefined reference to __mq_oshandle)

[Konstantin Belousov]

On Sun, Nov 29, 2015 at 01:23:04AM -0500, Daniel Eischen wrote:
> On Fri, 27 Nov 2015, Daniel Eischen wrote:
> 
> > Damn, please use deisc...@freebsd.org for replies.
> >
> > On Fri, 27 Nov 2015, Daniel Eischen wrote:
> >
> >> On Fri, 27 Nov 2015, Daniel Eischen wrote:
> >> 
> >>> $ uname -a
> >>> FreeBSD vega 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277320: Mon Jan 19 
> >>> 09:02:50 EST 2015 
> >>> deischen@vega:/usr/FreeBSD/svn/obj/usr/FreeBSD/svn/src/sys/vega  amd64
> >>> 
> >>> Upgrading to today's current, 'rm -rf /usr/obj/*; make -j8 buildworld'
> >>> fails here:
> >>> 
> >>> ===> lib/libc/tests/gen/execve (buildconfig)
> >>> --- all_subdir_tests ---
> >>> --- all_subdir_mqueue ---
> >>> mqtest3.o: In function `main':
> >>> /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x139): undefined 
> >>> reference to `__mq_oshandle'
> >>> /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x14c): undefined 
> >>> reference to `__mq_oshandle'
> >>> /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x16c): undefined 
> >>> reference to `__mq_oshandle'
> >>> /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3e6): undefined 
> >>> reference to `__mq_oshandle'
> >>> /usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3f9): undefined 
> >>> reference to `__mq_oshandle'
> >>> mqtest3.o:/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x40f): 
> >>> more undefined references to `__mq_oshandle' follow
> >>> cc: error: linker command failed with exit code 1 (use -v to see 
> >>> invocation)
> >>> 
> >>> Going to try make [-j1], next, but anyone come across this?
> >> 
> >> Still fails.
> >> 
> >> Why do the tests in tests/sys/mqueue/ try to use non-public APIs?
> 
> So I found out that sometime in the last year or so, symbol versioning
> for librt was broken and leaking symbols that shouldn't have been
> leaked.  I've just committed a fix for this.
> 
> Do a 'readelf -sw /usr/lib/librt.so.1 | grep GLOBAL | grep -v UND'
> and see the non FBSD_foo symbols that shouldn't be there.

I did the following on the librt from the HEAD of about month ago:

 pooma% ls -l netboot/sandy/usr/lib/librt.so.1
-r--r--r--  1 root  wheel  23704 Oct 24 23:35 netboot/sandy/usr/lib/librt.so.1

pooma% readelf -sw netboot/sandy/usr/lib/librt.so.1 | grep GLOBAL | grep -v UND 
| grep -v FBSDpriv | grep FBSD 
97:  0 OBJECT  GLOBAL DEFAULT  ABS FBSD_1.0

But I think that your commit is the good change.
___
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: librt symbol versioning breakage (was Re: Build failure, undefined reference to __mq_oshandle)

[Daniel Eischen]

On Sun, 29 Nov 2015, Konstantin Belousov wrote:


On Sun, Nov 29, 2015 at 01:23:04AM -0500, Daniel Eischen wrote:

On Fri, 27 Nov 2015, Daniel Eischen wrote:


Damn, please use deisc...@freebsd.org for replies.

On Fri, 27 Nov 2015, Daniel Eischen wrote:


On Fri, 27 Nov 2015, Daniel Eischen wrote:


$ uname -a
FreeBSD vega 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277320: Mon Jan 19
09:02:50 EST 2015
deischen@vega:/usr/FreeBSD/svn/obj/usr/FreeBSD/svn/src/sys/vega  amd64

Upgrading to today's current, 'rm -rf /usr/obj/*; make -j8 buildworld'
fails here:

===> lib/libc/tests/gen/execve (buildconfig)
--- all_subdir_tests ---
--- all_subdir_mqueue ---
mqtest3.o: In function `main':
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x139): undefined
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x14c): undefined
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x16c): undefined
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3e6): undefined
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3f9): undefined
reference to `__mq_oshandle'
mqtest3.o:/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x40f):
more undefined references to `__mq_oshandle' follow
cc: error: linker command failed with exit code 1 (use -v to see
invocation)

Going to try make [-j1], next, but anyone come across this?


Still fails.

Why do the tests in tests/sys/mqueue/ try to use non-public APIs?


So I found out that sometime in the last year or so, symbol versioning
for librt was broken and leaking symbols that shouldn't have been
leaked.  I've just committed a fix for this.

Do a 'readelf -sw /usr/lib/librt.so.1 | grep GLOBAL | grep -v UND'
and see the non FBSD_foo symbols that shouldn't be there.


I did the following on the librt from the HEAD of about month ago:

pooma% ls -l netboot/sandy/usr/lib/librt.so.1
-r--r--r--  1 root  wheel  23704 Oct 24 23:35 netboot/sandy/usr/lib/librt.so.1

pooma% readelf -sw netboot/sandy/usr/lib/librt.so.1 | grep GLOBAL | grep -v UND 
| grep -v FBSDpriv | grep FBSD
   97:  0 OBJECT  GLOBAL DEFAULT  ABS FBSD_1.0

But I think that your commit is the good change.



Can you check librt.so.1 in your buildworld temporary build
environment?

  $ readelf -sW /usr/obj/usr/FreeBSD/svn/src/tmp/usr/lib/librt.so.1 \
 grep -v UND | grep GLOBAL

There has to be a reason that tests/sys/mqueue/mqtest[3-4].c build
without error when they reference __mq_oshandle.  That symbol is
not exported from librt.

Hmm, looks like libc and libthr are also the same (leaky) in the
temporary build environment (TBE).  So something broke when building
the TBE libraries.

For r277320 on my system Jan 19, 2015, the TBE libraries must have
been built correctly because mqtests[3-4] failed with unresolved
references to __mq_oshandle.

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

librt symbol versioning breakage (was Re: Build failure, undefined reference to __mq_oshandle)

[Daniel Eischen]

On Fri, 27 Nov 2015, Daniel Eischen wrote:


Damn, please use deisc...@freebsd.org for replies.

On Fri, 27 Nov 2015, Daniel Eischen wrote:


On Fri, 27 Nov 2015, Daniel Eischen wrote:


$ uname -a
FreeBSD vega 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277320: Mon Jan 19 
09:02:50 EST 2015 
deischen@vega:/usr/FreeBSD/svn/obj/usr/FreeBSD/svn/src/sys/vega  amd64


Upgrading to today's current, 'rm -rf /usr/obj/*; make -j8 buildworld'
fails here:

===> lib/libc/tests/gen/execve (buildconfig)
--- all_subdir_tests ---
--- all_subdir_mqueue ---
mqtest3.o: In function `main':
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x139): undefined 
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x14c): undefined 
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x16c): undefined 
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3e6): undefined 
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3f9): undefined 
reference to `__mq_oshandle'
mqtest3.o:/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x40f): 
more undefined references to `__mq_oshandle' follow
cc: error: linker command failed with exit code 1 (use -v to see 
invocation)


Going to try make [-j1], next, but anyone come across this?


Still fails.

Why do the tests in tests/sys/mqueue/ try to use non-public APIs?


So I found out that sometime in the last year or so, symbol versioning
for librt was broken and leaking symbols that shouldn't have been
leaked.  I've just committed a fix for this.

Do a 'readelf -sw /usr/lib/librt.so.1 | grep GLOBAL | grep -v UND'
and see the non FBSD_foo symbols that shouldn't be there.

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

parallel buildworld breakage

[Don Lewis]

I just got this failure during a make -j12 buildworld on head r280837.

--- realinstall ---
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtbegin.o 
/usr/obj/usr/src/tmp/usr/lib/crtbegin.o
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtend.o 
/usr/obj/usr/src/tmp/usr/lib/crtend.o
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtbeginT.o 
/usr/obj/usr/src/tmp/usr/lib/crtbeginT.o
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtbeginS.o 
/usr/obj/usr/src/tmp/usr/lib/crtbeginS.o
sh /usr/src/tools/install.sh -o root -g wheel -m 444  crtendS.o 
/usr/obj/usr/src/tmp/usr/lib/crtendS.o
--- lib/libc__L ---
/usr/src/lib/libc/net/nslexer.l:47:10: fatal error: 'nsparser.h' file not found
#include nsparser.h
 ^
1 error generated.
mkdep: compile failed
*** [.depend] Error code 1


I don't see any recent commits that look suspicious.

Starting a single-threaded buildworld now ...

___
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

userland breakage, zfs ?

[Sean Bruno]

Just updated two machines in the fbsd cluser, buildworld/kernel,
installkernel, reboot into single user.

zfs from oldworld (pre installworld) doesn't work and segfaults in new
and magical ways.

Trying to mount root from zfs:zroot []...
Enter full pathname of shell or RETURN for /bin/sh: 
Cannot read termcap database;
using dumb terminal settings.
# zfs set readonly=off zroot
internal error: pInvalid argumentid
 19 (zfs), uid 0: exited on signal 6
Abort trap


I guess, I could multiuser the box on old kernel and installworld from
multiuser, but this could lead to disaster.  I see no indication of ABI
breakage of this kind in UPDATING, so ... any ideas?

sean

___
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: userland breakage, zfs ?

[Xin LI]

I'll take a look on this.


On Tue, Jul 1, 2014 at 8:28 AM, Sean Bruno sbr...@ignoranthack.me wrote:

 Just updated two machines in the fbsd cluser, buildworld/kernel,
 installkernel, reboot into single user.

 zfs from oldworld (pre installworld) doesn't work and segfaults in new
 and magical ways.

 Trying to mount root from zfs:zroot []...
 Enter full pathname of shell or RETURN for /bin/sh:
 Cannot read termcap database;
 using dumb terminal settings.
 # zfs set readonly=off zroot
 internal error: pInvalid argumentid
  19 (zfs), uid 0: exited on signal 6
 Abort trap


 I guess, I could multiuser the box on old kernel and installworld from
 multiuser, but this could lead to disaster.  I see no indication of ABI
 breakage of this kind in UPDATING, so ... any ideas?

 sean

 ___
 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




-- 
Xin LI delp...@delphij.net https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
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: userland breakage, zfs ?

[Sean Bruno]

On Tue, 2014-07-01 at 08:41 -0700, Xin LI wrote:
 I'll take a look on this.
 
 

I'm updating from:
FreeBSD chaos.ysv.freebsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1
r267362: Wed Jun 11 15:50:24 UTC 2014
sbr...@chaos.ysv.freebsd.org:/usr/obj/usr/src/sys/CHAOS  amd64


sean

 On Tue, Jul 1, 2014 at 8:28 AM, Sean Bruno sbr...@ignoranthack.me
 wrote:
 Just updated two machines in the fbsd cluser,
 buildworld/kernel,
 installkernel, reboot into single user.
 
 zfs from oldworld (pre installworld) doesn't work and
 segfaults in new
 and magical ways.
 
 Trying to mount root from zfs:zroot []...
 Enter full pathname of shell or RETURN for /bin/sh:
 Cannot read termcap database;
 using dumb terminal settings.
 # zfs set readonly=off zroot
 internal error: pInvalid argumentid
  19 (zfs), uid 0: exited on signal 6
 Abort trap
 
 
 I guess, I could multiuser the box on old kernel and
 installworld from
 multiuser, but this could lead to disaster.  I see no
 indication of ABI
 breakage of this kind in UPDATING, so ... any ideas?
 
 sean
 
 ___
 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
 
 
 
 
 -- 
 Xin LI delp...@delphij.net https://www.delphij.net/
 FreeBSD - The Power to Serve! Live free or die
 


___
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 Build breakage

[Outback Dingo]

Heads up, seems compiling a kernel as of tonights broken

CC='cc ' mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE
-DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq
-I/usr/obj/usr/src/sys/GENERIC -std=iso9899:1999
/usr/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c
/usr/src/sys/modules/cpufreq/../../x86/cpufreq/est.c
/usr/src/sys/modules/cpufreq/../../x86/cpufreq/hwpstate.c
/usr/src/sys/modules/cpufreq/../../x86/cpufreq/p4tcc.c
/usr/src/sys/modules/cpufreq/../../x86/cpufreq/powernow.c
=== crypto (depend)
@ - /usr/src/sys
awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c
make[4]: don't know how to make deflate.c. Stop

make[4]: stopped in /usr/src/sys/modules/crypto
*** Error code 2

Stop.
___
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

minor breakage with GCC after SVN r255112?

[Michael Butler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A missing quote inside a disabled code-section seems to upset GCC, i.e.


*** sys/dev/virtio/network/if_vtnet.c~  Sun Sep  1 09:50:28 2013
- --- sys/dev/virtio/network/if_vtnet.c   Sun Sep  1 10:54:06 2013
***
*** 1531,1537 
 */
  #if 0
if_printf(sc-vtnet_ifp, cksum offload of unsupported 
!   protocol eth_type=%#x proto=%d csum_start=%d
csum_offset=%d\n, __func__, eth_type, proto,
hdr-csum_start, hdr-csum_offset);
  #endif
- --- 1531,1537 
 */
  #if 0
if_printf(sc-vtnet_ifp, cksum offload of unsupported 
!   protocol eth_type=%#x proto=%d csum_start=%d
csum_offset=%d\n, __func__, eth_type, proto,
hdr-csum_start, hdr-csum_offset);
  #endif

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (FreeBSD)

iEYEARECAAYFAlIjW8cACgkQQv9rrgRC1JI8qwCgrAug7uNBJA6LM5j3e8QoeyzB
RNQAn2vtpxrr6TML5pfCpdr3BDY+6Uvv
=9K43
-END PGP SIGNATURE-
___
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

breakage caused by changes to mount structure

[KiT Sin]

as of r224290, the mnt_flag in the mount structure was changed from
32 to 64 bits. should __FreeBSD_version be bumped to reflect breakage
introduced by this change?

fusefs-kmod broke after the kernel was upgraded, and the ports failed
to build due to inconsistent data type as it is expecting 32bit int.

thanks
kit
___
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

if_ether.c (svn revision 217315) breakage on i386

[Michael Butler]

cc1: warnings being treated as errors
/usr/home/imb/svn/head/sys/netinet/if_ether.c: In function 'in_arpinput':
/usr/home/imb/svn/head/sys/netinet/if_ether.c:540: warning: format '%ld'
expects type 'long int', but argument 3 has type 'unsigned int'
*** Error code 1

.. where unsigned int is actually a sizeof(struct in_addr),

imb
___
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: if_ether.c (svn revision 217315) breakage on i386

[Christian Peron]

On Wed, Jan 12, 2011 at 06:01:21PM -0500, Michael Butler wrote:
[..]
 
 .. where unsigned int is actually a sizeof(struct in_addr),
 
   imb

This has been corrected.

-- 
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments


pgp57B0Lr04LM.pgp
Description: PGP signature

tput clear/vi breakage on console

[Pyun YongHyeon]

Hi,

It seems tput clear on console wipes out entire screen without
even showing a shell prompt. The only way I get characters is to
enter enter key. I'm under the impression that the first line of
console output is not displayed at all after tput clear command.
Another thing I noticed is vi also does not show the first line
of a file. Any idea?
___
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: tput clear/vi breakage on console

[Pyun YongHyeon]

On Wed, Sep 22, 2010 at 11:18:05PM +0200, Alexey Shuvaev wrote:
 On Wed, Sep 22, 2010 at 01:58:31PM -0700, Pyun YongHyeon wrote:
  Hi,
  
  It seems tput clear on console wipes out entire screen without
  even showing a shell prompt. The only way I get characters is to
  enter enter key. I'm under the impression that the first line of
  console output is not displayed at all after tput clear command.
  Another thing I noticed is vi also does not show the first line
  of a file. Any idea?
 
 Seems to work fine for me both in xterm and in the text console.
 

Sorry, I was wrong. It seems I blindly trusted monitor's
auto-sizing capability. With manual adjustment the issue has gone.
___
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: tput clear/vi breakage on console

[Alexey Shuvaev]

On Wed, Sep 22, 2010 at 01:58:31PM -0700, Pyun YongHyeon wrote:
 Hi,
 
 It seems tput clear on console wipes out entire screen without
 even showing a shell prompt. The only way I get characters is to
 enter enter key. I'm under the impression that the first line of
 console output is not displayed at all after tput clear command.
 Another thing I noticed is vi also does not show the first line
 of a file. Any idea?

Seems to work fine for me both in xterm and in the text console.

~ uname -a
FreeBSD wep4035 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r212998: Wed Sep 22 16:28:09 
CEST 2010 r...@wep4035:/usr/obj/usr/src/sys/GENERIC  amd64

[In xterm]
~ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_NUMERIC=C
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=C
LC_ALL=

[In text console]
# locale
LANG=
LC_CTYPE=C
LC_COLLATE=C
LC_TIME=C
LC_NUMERIC=C
LC_MONETARY=C
LC_MESSAGES=C
LC_ALL=

The 'cl' capability from the xterm session (part of TERMCAP):
cl=\E[H\E[2J

HTH,
Alexey.
___
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: SVN rev 206755 breakage

[Michael Butler]

On 04/19/10 02:30, Alexander Motin wrote:
 Rui Paulo wrote:
 On 18 Apr 2010, at 14:05, Alexander Motin wrote:
 Most of AHCI controllers could also work as usual PCI ATA, but not every
 PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvbc`
 output in both working (Rui) and not working (Michael) cases.

 ah...@pci0:0:31:2:   class=0x01018f card=0x72708086 chip=0x27c48086 rev=0x02 
 hdr=0x00
 vendor = 'Intel Corporation'
 device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller'
 class  = mass storage
 subclass   = ATA
 
^^^
 It doesn't report itself as AHCI.
 
 bar   [10] = type I/O Port, range 32, base 0x20d8, size  8, enabled
 bar   [14] = type I/O Port, range 32, base 0x20fc, size  4, enabled
 bar   [18] = type I/O Port, range 32, base 0x20d0, size  8, enabled
 bar   [1c] = type I/O Port, range 32, base 0x20f8, size  4, enabled
 bar   [20] = type I/O Port, range 32, base 0x2020, size 16, enabled
 bar   [24] = type Memory, range 32, base 0x90445000, size 1024, enabled
 
 This resource (BAR(5)) is absent on Michael's system. It is needed to
 work in AHCI mode, but not required for legacy PCI ATA. Probably some
 kind of BIOS magic in your case makes it appear in this mode with this
 chip ID.

More for my own amusement than anything, I came up with an _horrible_
patch to force my ICH7M into AHCI mode (attached). It has two issues:

1) I haven't figured out how to automagically determine which
address(es) I can use without colliding with anything else. Simply
letting bus_allocate_any() decide where to point BAR(5) doesn't appear
to work. I suspect I have to dig through the SMAP stuff to find out what
the BIOS has already claimed and use something outside of those ranges.

2) Since my laptop has both a SATA drive and a PATA DVD-R/W, the
manufacturer commissioned a BIOS which brings the ICH7M up in combined
mode with D31-F1 completely disabled. Since it can't (per Intel spec)
be re-enabled without a platform reset, flipping into AHCI mode
effectively removes the DVD.

However - on the up side, I now get NCQ ;-)

ahci0: Intel ICH7M AHCI SATA controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18b0-0x18bf
at device 31.2 on pci0
ahci0: BAR(5): 0xf0d44400 AHCI_CAP: 0xdf12ff03 PI: 0x1
pcib0: matched entry for 0.31.INTB
pcib0: slot 31 INTB hardwired to IRQ 19
ahci0: [MPSAFE]
ahci0: [ITHREAD]
ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier supported
ahci0: Caps: 64bit NCQ MPS SS ALP AL CLO 1.5Gbps PM PMD SSC PSC
32cmd 4ports
ahci0: Caps2:
ahcich0: AHCI channel at channel 0 on ahci0
ahcich0: [MPSAFE]
ahcich0: [ITHREAD]
ahcich0: Caps:

 [ .. ]

ada0 at ahcich0 bus 0 scbus1 target 0 lun 0
ada0: FUJITSU MHZ2320BJ G2 001E ATA-8 SATA 2.x device
ada0: Serial Number K82BT89256VDGEOM: new disk ada0
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)

*** sys/dev/ahci/ahci.c.origSat Apr 24 21:36:42 2010
--- sys/dev/ahci/ahci.c Sun Apr 25 21:30:57 2010
***
*** 126,131 
--- 126,132 
{0x26838086, 0x00, Intel ESB2,0},
{0x27c18086, 0x00, Intel ICH7,0},
{0x27c38086, 0x00, Intel ICH7,0},
+   {0x27c48086, 0x00, Intel ICH7M,   0},
{0x27c58086, 0x00, Intel ICH7M,   0},
{0x27c68086, 0x00, Intel ICH7M,   0},
{0x28218086, 0x00, Intel ICH8,0},
***
*** 321,331 
--- 322,353 
ctlr-quirks = ahci_ids[i].quirks;
resource_int_value(device_get_name(dev),
device_get_unit(dev), ccc, ctlr-ccc);
+ 
+ #define AHCI_MEM_HACK 0xF0D44400  /* 0xf0d443ff is the last used by 
others on Toshiba A105 */
+ 
+   /* Need to set the SCRAE bit and ensure SCRD not set */
+   pci_write_config(dev, 0x94, (pci_read_config(dev, 0x94, 4) | 0x200)  
~0x4000, 4);
+   /* enable MSE */
+   pci_write_config(dev, 0x4, (pci_read_config(dev, 0x4, 2) | 2), 2);
+   pci_write_config(dev, 0x24, AHCI_MEM_HACK, 4);  
+   pci_write_config(dev, 0x90, 0x40, 1);   /* AHCI + non-combined */
+ 
+   /* allocate a free memory window for BAR(5) */
+   ctlr-r_rid = PCIR_BAR(5);
+   bus_set_resource(dev, SYS_RES_MEMORY, ctlr-r_rid, AHCI_MEM_HACK, 
0x400);
+ 
/* if we have a memory BAR(5) we are likely on an AHCI part */
ctlr-r_rid = PCIR_BAR(5);
if (!(ctlr-r_mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY,
ctlr-r_rid, RF_ACTIVE)))
return ENXIO;
+ 
+   /* enable ICH7M ports in AHCI space */
+   ATA_OUTL(ctlr-r_mem, AHCI_PI, ATA_INL(ctlr-r_mem, AHCI_PI) | 5);
+ #if 0
+   device_printf(dev, BAR(5): 0x%lx AHCI_CAP: 0x%lx PI: 0x%lx\n, 
(unsigned long)pci_read_config(dev, 0x24, 4),
+   (unsigned long)ATA_INL(ctlr-r_mem, 0), (unsigned 
long)ATA_INL(ctlr-r_mem, AHCI_PI));
+ #endif

Re: SVN rev 206755 breakage

[Alexander Motin]

Rui Paulo wrote:
 On 18 Apr 2010, at 14:05, Alexander Motin wrote:
 Most of AHCI controllers could also work as usual PCI ATA, but not every
 PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvbc`
 output in both working (Rui) and not working (Michael) cases.
 
 ah...@pci0:0:31:2:class=0x01018f card=0x72708086 chip=0x27c48086 rev=0x02 
 hdr=0x00
 vendor = 'Intel Corporation'
 device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller'
 class  = mass storage
 subclass   = ATA

   ^^^
It doesn't report itself as AHCI.

 bar   [10] = type I/O Port, range 32, base 0x20d8, size  8, enabled
 bar   [14] = type I/O Port, range 32, base 0x20fc, size  4, enabled
 bar   [18] = type I/O Port, range 32, base 0x20d0, size  8, enabled
 bar   [1c] = type I/O Port, range 32, base 0x20f8, size  4, enabled
 bar   [20] = type I/O Port, range 32, base 0x2020, size 16, enabled
 bar   [24] = type Memory, range 32, base 0x90445000, size 1024, enabled

This resource (BAR(5)) is absent on Michael's system. It is needed to
work in AHCI mode, but not required for legacy PCI ATA. Probably some
kind of BIOS magic in your case makes it appear in this mode with this
chip ID.
On ICH8 and above in non-AHCI mode BAR(5) is also present, but with
different meaning (access to some SATA registers). So it may be
difficult to distinguish what exactly we have there.

 cap 01[70] = powerspec 2  supports D0 D3  current D0
 
 BTW, Mac OS X also uses AHCI on this controller.

I think Mac OS X is very special beast, which could easily be tuned for
their specific hardware.

So I think either your patch should be either reverted, or somehow
improved to check presence of BAR(5) and may be something else on probe
stage, but IMHO it's a kind of magic and I wouldn't be doing so.

-- 
Alexander Motin
___
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: SVN rev 206755 breakage

[Rui Paulo]

On 19 Apr 2010, at 07:30, Alexander Motin m...@freebsd.org wrote:


Rui Paulo wrote:

On 18 Apr 2010, at 14:05, Alexander Motin wrote:
Most of AHCI controllers could also work as usual PCI ATA, but not  
every
PCI ATA could work as AHCI. It would be nice to compare `pciconf - 
lvbc`

output in both working (Rui) and not working (Michael) cases.


ah...@pci0:0:31:2:class=0x01018f card=0x72708086  
chip=0x27c48086 rev=0x02 hdr=0x00

   vendor = 'Intel Corporation'
   device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage  
Controller'

   class  = mass storage
   subclass   = ATA


  ^^^
It doesn't report itself as AHCI.

   bar   [10] = type I/O Port, range 32, base 0x20d8, size  8,  
enabled
   bar   [14] = type I/O Port, range 32, base 0x20fc, size  4,  
enabled
   bar   [18] = type I/O Port, range 32, base 0x20d0, size  8,  
enabled
   bar   [1c] = type I/O Port, range 32, base 0x20f8, size  4,  
enabled
   bar   [20] = type I/O Port, range 32, base 0x2020, size 16,  
enabled
   bar   [24] = type Memory, range 32, base 0x90445000, size 1024,  
enabled


This resource (BAR(5)) is absent on Michael's system. It is needed to
work in AHCI mode, but not required for legacy PCI ATA. Probably some
kind of BIOS magic in your case makes it appear in this mode with this
chip ID.
On ICH8 and above in non-AHCI mode BAR(5) is also present, but with
different meaning (access to some SATA registers). So it may be
difficult to distinguish what exactly we have there.


   cap 01[70] = powerspec 2  supports D0 D3  current D0

BTW, Mac OS X also uses AHCI on this controller.


I think Mac OS X is very special beast, which could easily be tuned  
for

their specific hardware.

So I think either your patch should be either reverted, or somehow
improved to check presence of BAR(5) and may be something else on  
probe

stage, but IMHO it's a kind of magic and I wouldn't be doing so.


Ok I'll revert it



___
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: SPOOFED: Re: SVN rev 206755 breakage

[Alexander Motin]

Rui Paulo wrote:
 On 18 Apr 2010, at 06:57, Alexander Motin wrote:
 Rui Paulo wrote:
 On 17 Apr 2010, at 23:12, Michael Butler wrote:
 On 04/17/10 18:05, Rui Paulo wrote:
 On 17 Apr 2010, at 22:34, Michael Butler wrote:
 The revision labeled:

 SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo

 Add another ICH7M chipset that works.

 .. is incorrect and will cause some laptops to not boot.
 So, in AHCI mode it doesn't find the disks?
 No - the driver fails to attach (ENXIO).
 But since ahci failed to attach, won't atapci attach later?
 If probe succeeded - no.

 Can you show me the dmesg?
 More important probably would be `pciconf -lvcb`.

 Intel controllers after ICH6 change both ID and set of resources,
 depending on AHCI enabled in BIOS. There is separate set of IDs for
 controllers with AHCI enabled. As I can see, Linux handles ID 0x27c4 as
 non-AHCI SATA. If for some reason this ID could be used for both modes
 (I have doubts),
 
 It can be used in both modes. atapci used to attach to it on my MacBook.

Most of AHCI controllers could also work as usual PCI ATA, but not every
PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvbc`
output in both working (Rui) and not working (Michael) cases.

-- 
Alexander Motin
___
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: SPOOFED: Re: SVN rev 206755 breakage

[Michael Butler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/18/10 01:57, Alexander Motin wrote:
 More important probably would be `pciconf -lvcb`.
 
 Intel controllers after ICH6 change both ID and set of resources,
 depending on AHCI enabled in BIOS. There is separate set of IDs for
 controllers with AHCI enabled. As I can see, Linux handles ID 0x27c4 as
 non-AHCI SATA. If for some reason this ID could be used for both modes
 (I have doubts), we may try to set AHCI_Q_NOFORCE flag to make driver
 check PCI class/subclass, if it is correct there.
 

atap...@pci0:0:31:2:class=0x010180 card=0xff101179 chip=0x27c48086
rev=0x02 hdr=0x00

vendor = 'Intel Corporation'


device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage
Controller'

class  = mass storage


subclass   = ATA


bar   [10] = type I/O Port, range 32, base 0x1f0, size  8, enabled


bar   [14] = type I/O Port, range 32, base 0x3f4, size  1, enabled


bar   [18] = type I/O Port, range 32, base 0x170, size  8, enabled


bar   [1c] = type I/O Port, range 32, base 0x374, size  1, enabled
bar   [20] = type I/O Port, range 32, base 0x18b0, size 16, enabled
cap 01[70] = powerspec 2  supports D0 D3  current D0

When AHCI is enabled, the device ID changes to 0x27c5.

In this case, the probe succeeds but, since MSE is not set, the
allocation of memory-IO space to BAR(5) is futile and the reset fails
since it addresses undecoded space. Thus the attach fails,

imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkvLCyoACgkQQv9rrgRC1JK3UQCfXG1K3B7kOo35koBWdTohYt7/
qygAoM0kn0ZSYeD5P0Hu7kr3ci+otV3m
=sk9Y
-END PGP SIGNATURE-
___
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: Re: SVN rev 206755 breakage

[Rui Paulo]

On 18 Apr 2010, at 14:05, Alexander Motin wrote:

 Rui Paulo wrote:
 On 18 Apr 2010, at 06:57, Alexander Motin wrote:
 Rui Paulo wrote:
 On 17 Apr 2010, at 23:12, Michael Butler wrote:
 On 04/17/10 18:05, Rui Paulo wrote:
 On 17 Apr 2010, at 22:34, Michael Butler wrote:
 The revision labeled:
 
 SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo
 
 Add another ICH7M chipset that works.
 
 .. is incorrect and will cause some laptops to not boot.
 So, in AHCI mode it doesn't find the disks?
 No - the driver fails to attach (ENXIO).
 But since ahci failed to attach, won't atapci attach later?
 If probe succeeded - no.
 
 Can you show me the dmesg?
 More important probably would be `pciconf -lvcb`.
 
 Intel controllers after ICH6 change both ID and set of resources,
 depending on AHCI enabled in BIOS. There is separate set of IDs for
 controllers with AHCI enabled. As I can see, Linux handles ID 0x27c4 as
 non-AHCI SATA. If for some reason this ID could be used for both modes
 (I have doubts),
 
 It can be used in both modes. atapci used to attach to it on my MacBook.
 
 Most of AHCI controllers could also work as usual PCI ATA, but not every
 PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvbc`
 output in both working (Rui) and not working (Michael) cases.

atap...@pci0:0:31:1:class=0x01018a card=0x72708086 chip=0x27df8086 rev=0x02 
hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) Ultra ATA Storage Controller'
class  = mass storage
subclass   = ATA
bar   [10] = type I/O Port, range 32, base 0x1f0, size  8, enabled
bar   [14] = type I/O Port, range 32, base 0x3f4, size  1, enabled
bar   [18] = type I/O Port, range 32, base 0x170, size  8, enabled
bar   [1c] = type I/O Port, range 32, base 0x374, size  1, enabled
bar   [20] = type I/O Port, range 32, base 0x20c0, size 16, enabled

ah...@pci0:0:31:2:  class=0x01018f card=0x72708086 chip=0x27c48086 rev=0x02 
hdr=0x00
vendor = 'Intel Corporation'
device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller'
class  = mass storage
subclass   = ATA
bar   [10] = type I/O Port, range 32, base 0x20d8, size  8, enabled
bar   [14] = type I/O Port, range 32, base 0x20fc, size  4, enabled
bar   [18] = type I/O Port, range 32, base 0x20d0, size  8, enabled
bar   [1c] = type I/O Port, range 32, base 0x20f8, size  4, enabled
bar   [20] = type I/O Port, range 32, base 0x2020, size 16, enabled
bar   [24] = type Memory, range 32, base 0x90445000, size 1024, enabled
cap 01[70] = powerspec 2  supports D0 D3  current D0

BTW, Mac OS X also uses AHCI on this controller.

--
Rui Paulo
___
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

SVN rev 206755 breakage

[Michael Butler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The revision labeled:

SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo

  Add another ICH7M chipset that works.

 .. is incorrect and will cause some laptops to not boot.

Of the following identifiers:

{0x27c48086, 0x00, Intel ICH7M,   0},

 .. is the ICH7M in legacy and/or combined mode, i.e. *not* AHCI

{0x27c58086, 0x00, Intel ICH7M,   0},

 .. is the *same* chipset in AHCI mode,

imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkvKKW4ACgkQQv9rrgRC1JIMUQCeKmCz2USYE2SSyb1X5f6tes7G
DtsAoKkjFHhlPdESsziKO92LCaxK6EI5
=JAg8
-END PGP SIGNATURE-
___
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: SVN rev 206755 breakage

[Doug Barton]

It's generally also a good idea to cc the author of the change just in
case they don't get to their -current mail in a timely manner.


hth,

Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

___
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: SVN rev 206755 breakage

[Michael Butler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/17/10 18:05, Rui Paulo wrote:
 On 17 Apr 2010, at 22:34, Michael Butler wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 The revision labeled:

 SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo

  Add another ICH7M chipset that works.

 .. is incorrect and will cause some laptops to not boot.
 
 So, in AHCI mode it doesn't find the disks?

No - the driver fails to attach (ENXIO).

I'm looking into which resource(s) it either couldn't allocate or gain
control.

The BIOS on my Toshiba does not initialize BAR(5) and, in the most
general case, combined mode (MAP.SMS=0b, MAP.MV=10b) is required as the
hard-drive is SATA but the DVD+RW is PATA :-(

imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkvKMloACgkQQv9rrgRC1JJ4FACdHxDzzfGIwBS4XEnfPWGCs2Qb
wSsAoJAV6q/b16joC9MylPS8ZbT2JB/b
=IeOp
-END PGP SIGNATURE-
___
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: SVN rev 206755 breakage

[Rui Paulo]

On 17 Apr 2010, at 22:34, Michael Butler wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 The revision labeled:
 
 SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo
 
  Add another ICH7M chipset that works.
 
 .. is incorrect and will cause some laptops to not boot.

So, in AHCI mode it doesn't find the disks?

 
 Of the following identifiers:
 
{0x27c48086, 0x00, Intel ICH7M,   0},
 
 .. is the ICH7M in legacy and/or combined mode, i.e. *not* AHCI
 
{0x27c58086, 0x00, Intel ICH7M,   0},
 
 .. is the *same* chipset in AHCI mode,

Unfortunately, this is not the case on my laptop and I would rather find a way 
to correctly identify the chipset instead of backing out this change.

Regards,
--
Rui Paulo


___
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: SPOOFED: Re: SVN rev 206755 breakage

[Rui Paulo]

On 17 Apr 2010, at 23:12, Michael Butler wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 04/17/10 18:05, Rui Paulo wrote:
 On 17 Apr 2010, at 22:34, Michael Butler wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 The revision labeled:
 
 SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo
 
 Add another ICH7M chipset that works.
 
 .. is incorrect and will cause some laptops to not boot.
 
 So, in AHCI mode it doesn't find the disks?
 
 No - the driver fails to attach (ENXIO).

But since ahci failed to attach, won't atapci attach later?

Can you show me the dmesg?

Regards,
--
Rui Paulo

___
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: SPOOFED: Re: SVN rev 206755 breakage

[Alexander Motin]

Rui Paulo wrote:
 On 17 Apr 2010, at 23:12, Michael Butler wrote:
 On 04/17/10 18:05, Rui Paulo wrote:
 On 17 Apr 2010, at 22:34, Michael Butler wrote:
 The revision labeled:

 SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo

 Add another ICH7M chipset that works.

 .. is incorrect and will cause some laptops to not boot.
 So, in AHCI mode it doesn't find the disks?
 No - the driver fails to attach (ENXIO).
 
 But since ahci failed to attach, won't atapci attach later?

If probe succeeded - no.

 Can you show me the dmesg?

More important probably would be `pciconf -lvcb`.

Intel controllers after ICH6 change both ID and set of resources,
depending on AHCI enabled in BIOS. There is separate set of IDs for
controllers with AHCI enabled. As I can see, Linux handles ID 0x27c4 as
non-AHCI SATA. If for some reason this ID could be used for both modes
(I have doubts), we may try to set AHCI_Q_NOFORCE flag to make driver
check PCI class/subclass, if it is correct there.

-- 
Alexander Motin
___
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: Ports breakage since r205471

[Erwin Lansing]

On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote:
 Hi all,
 I realize that this is most suitable for current@ and I'm
 cross-posting, but I wanted to jot down all of the ports broken since
 the zlib version bump so that we can keep track of what's going on and
 what needs to be fixed.

I have just started a new package build against todays HEAD on pointyhat
, actually before seeing this thread, so these, and any others, will be
picked up there.  I'll update the list with the results when it finishes
in a day or two.
 
Also, I really think we should add packaging metadata to third
 party libraries in base and at least track the versioning and
 dependencies because this CURRENT upgrade has turned into a royal mess
 and has eaten up more of my time than it should have.

Unfortunately, the story of ports on CuRRENT :-(

-erwin

-- 
Erwin Lansing   http://droso.org
Prediction is very difficult
especially about the futureer...@freebsd.org


pgpcMxDbzRDjq.pgp
Description: PGP signature

Re: Ports breakage since r205471

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2010/04/05 01:50, Erwin Lansing wrote:
 On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote:
 Hi all,
 I realize that this is most suitable for current@ and I'm
 cross-posting, but I wanted to jot down all of the ports broken since
 the zlib version bump so that we can keep track of what's going on and
 what needs to be fixed.
 
 I have just started a new package build against todays HEAD on pointyhat
 , actually before seeing this thread, so these, and any others, will be
 picked up there.  I'll update the list with the results when it finishes
 in a day or two.

Which svn revision is currently using on the build cluster?

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBAgAGBQJLuac2AAoJEATO+BI/yjfBusMH/jAc2pH439rkteRRX5oK+IXo
hV3qXE0pMNkrGDDciVbYuJ9r/niqdkBIqaaw2te8K97YwBAdpikheHV0NaHoOzYT
J+OiKmTu2o96J7FV7ORSRmPUcKhHHTjXwLMF2Kz9MeoRvYJqyVk1m33wMuDdIGEe
57Pxq3sXpbfmUoOq5S7ITLXSPqE+l5Xh0j4wM7wULQWhabTw1akliDGxvwr1XqrU
8r+3dbLASzV8hitIXk92MLCfomJNDgsW3VV3nqlzmiLlwBOfGrGowZblKlgHUWO4
VEJ6qCXpRPGpelIVSDyguR3BCEl2m9tyQ3xQ8MEznjwuOJGpp8vwNrwAUOB0PpE=
=g4ur
-END PGP SIGNATURE-
___
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: Ports breakage since r205471

[Erwin Lansing]

On Mon, Apr 05, 2010 at 02:02:46AM -0700, Xin LI wrote:
 On 2010/04/05 01:50, Erwin Lansing wrote:
  On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote:
  Hi all,
  I realize that this is most suitable for current@ and I'm
  cross-posting, but I wanted to jot down all of the ports broken since
  the zlib version bump so that we can keep track of what's going on and
  what needs to be fixed.
  
  I have just started a new package build against todays HEAD on pointyhat
  , actually before seeing this thread, so these, and any others, will be
  picked up there.  I'll update the list with the results when it finishes
  in a day or two.
 
 Which svn revision is currently using on the build cluster?
 
Unfortunately, we're still using cvs for updating, but I just double
checked that it is past r206058.  The update is less than an hour old
from cvs.

-erwin

-- 
Erwin Lansing   http://droso.org
Prediction is very difficult
especially about the futureer...@freebsd.org


pgpxXYOcVBKqh.pgp
Description: PGP signature

Re: Ports breakage since r205471

[Garrett Cooper]

On Mon, Apr 5, 2010 at 2:12 AM, Erwin Lansing er...@freebsd.org wrote:
 On Mon, Apr 05, 2010 at 02:02:46AM -0700, Xin LI wrote:
 On 2010/04/05 01:50, Erwin Lansing wrote:
  On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote:
  Hi all,
      I realize that this is most suitable for current@ and I'm
  cross-posting, but I wanted to jot down all of the ports broken since
  the zlib version bump so that we can keep track of what's going on and
  what needs to be fixed.
 
  I have just started a new package build against todays HEAD on pointyhat
  , actually before seeing this thread, so these, and any others, will be
  picked up there.  I'll update the list with the results when it finishes
  in a day or two.

 Which svn revision is currently using on the build cluster?

 Unfortunately, we're still using cvs for updating, but I just double
 checked that it is past r206058.  The update is less than an hour old
 from cvs.

You won't see the issue unless you roll back to before r206057;
r206057 and r206058 disguise the compatibility issue by completely
zapping the #ifdef _LARGEFILE64_SOURCE and #if _FILE_OFFSET_BITS == 64
enable pieces.
Thanks,
-Garrett
___
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

Ports breakage since r205471

[Garrett Cooper]

Hi all,
I realize that this is most suitable for current@ and I'm
cross-posting, but I wanted to jot down all of the ports broken since
the zlib version bump so that we can keep track of what's going on and
what needs to be fixed.
The following 3rd party libraries and all of their dependencies:

graphics/png
graphics/tiff
textproc/libxml2

   all needed to be rebuilt.
   The following items incorrectly define LARGEFILE64 and result in
errors like the following:

/usr/include/zlib.h:1561: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'gzseek64'
/usr/include/zlib.h:1562: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'gztell64'
/usr/include/zlib.h:1563: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'gzoffset64'
/usr/include/zlib.h:1564: error: expected declaration specifiers or
'...' before 'off64_t'
/usr/include/zlib.h:1565: error: expected declaration specifiers or
'...' before 'off64_t'

devel/qt-moc
lang/python (uses pieces from gpac-libgpac I think)
multimedia/gpac-libgpac
multimedia/vlc (draft patch attached to ports/145387)

   Also, I really think we should add packaging metadata to third
party libraries in base and at least track the versioning and
dependencies because this CURRENT upgrade has turned into a royal mess
and has eaten up more of my time than it should have.
Thanks,
-Garrett
___
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: Ports breakage since r205471

[Garrett Cooper]

On Sun, Apr 4, 2010 at 3:06 PM, Garrett Cooper yanef...@gmail.com wrote:
 Hi all,
    I realize that this is most suitable for current@ and I'm
 cross-posting, but I wanted to jot down all of the ports broken since
 the zlib version bump so that we can keep track of what's going on and
 what needs to be fixed.
    The following 3rd party libraries and all of their dependencies:

 graphics/png
 graphics/tiff
 textproc/libxml2

   all needed to be rebuilt.
   The following items incorrectly define LARGEFILE64 and result in
 errors like the following:

 /usr/include/zlib.h:1561: error: expected '=', ',', ';', 'asm' or
 '__attribute__' before 'gzseek64'
 /usr/include/zlib.h:1562: error: expected '=', ',', ';', 'asm' or
 '__attribute__' before 'gztell64'
 /usr/include/zlib.h:1563: error: expected '=', ',', ';', 'asm' or
 '__attribute__' before 'gzoffset64'
 /usr/include/zlib.h:1564: error: expected declaration specifiers or
 '...' before 'off64_t'
 /usr/include/zlib.h:1565: error: expected declaration specifiers or
 '...' before 'off64_t'

 devel/qt-moc
 lang/python (uses pieces from gpac-libgpac I think)
 multimedia/gpac-libgpac
 multimedia/vlc (draft patch attached to ports/145387)

   Also, I really think we should add packaging metadata to third
 party libraries in base and at least track the versioning and
 dependencies because this CURRENT upgrade has turned into a royal mess
 and has eaten up more of my time than it should have.

As jsa@ so kindly pointed out, upgrading to r206057 temporarily
alleviates this issue. I'll keep on looking for problematic areas
where this needs to be fixed, but a #warning should probably be added
to the header to catch all of the offenders.
Thanks,
-Garrett
___
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: Ports breakage since r205471

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2010/04/04 18:58, Garrett Cooper wrote:
[...]
 As jsa@ so kindly pointed out, upgrading to r206057 temporarily

I think you really want = 206058 :(

Cheers,
- -- 
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBAgAGBQJLuWZhAAoJEATO+BI/yjfBkrwH/iQTvZQJkYPCRXbqBPVqhTi2
5XMri6IMV7rEij2HIFd5X8IAbts+6YvzIEwEZnkNboBGvhHruwu3Jsip5B3dcNx/
vNPavaqm9p56RgM8Dkl8mg+zZ6VN0rTf9p4eJ1EsL1EuQF4HtiDWugK746CLI6Xa
FH7LEXOEHYfEkLoqWMR2nFjGqpBi65g7H6BoT/hj3egTmNHZsMKck+TdViKwsY6X
P4wqzlSQJ6u0Ri1k8GPeGgUiSyL8djG2DVXsbhMkWTfi6QS/YBy150tqqVT0ggjL
9pZ2e3jDcU3jrp+9iOrLLQUU5MgPdyz70OgnI2ZLTfiocAtXiVb5Z5xIp4F2BDM=
=TKt/
-END PGP SIGNATURE-
___
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

Vinum breakage - please update UPDATING

[Marcus Reid]

Hello,

I just upgraded a -CURRENT box this afternoon to discover that vinum
is broken. If I hadn't done dumps of my working world beforehand I
would be in pretty sad shape. Should UPDATING make note of this breakage?
It would have saved me some embarassment, and I'm sure others are about
to clobber their machines.

Marcus
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]