Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[David Wolfskill]

On Thu, Aug 16, 2018 at 12:49:06PM -0700, Bryan Drewery wrote:
> ...
> r337928 should fix it.
> 
> 
> -- 
> Regards,
> Bryan Drewery
> 

Just tested after applying r337928 on top of sources at r337903; the
rebuild after restoring crypto/openssh/moduli was successful:

FreeBSD freebeast.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #285  
r337903M/337903:1200078: Thu Aug 16 13:30:45 PDT 2018 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

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


signature.asc
Description: PGP signature

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Brad Davis]

On Thu, Aug 16, 2018, at 1:49 PM, Bryan Drewery wrote:
> On 8/16/18 12:09 PM, Ian Lepore wrote:
> > On Thu, 2018-08-16 at 11:25 -0700, Xin LI wrote:
> >> On Thu, Aug 16, 2018 at 9:26 AM Brad Davis  wrote:> >>>
> >>>
> >>> On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> 
>  This was caused by r337852, but I didn't investigated further.
> 
>  The problem is that we have a source file called 'moduli.c' in
>  crypto/openssh/ while the build target was moduli, and bmake seen>  
>  'moduli' in source tree as older than moduli.c, and decided to
>  rebuild
>  it from source, while the two files are unrelated.
> >>> Hi Xin,
> >>>
> >>> I don't see how that could be the case as I didn't move the file
> >>> around, I just moved how it gets installed.
> >>>
> >>> I have done many many builds with this change in and haven't seen> >>> 
> >>> this problem..
> >> Yeah, let me rephrase: this might have been exposed by r337852; I
> >> don't think your change itself really caused or should have caused> >> 
> >> problem, but my theory based on what we have observed was that it
> >> might have exposed a bug where either bmake itself, or some .mk
> >> files> >> might have generated e.g. automatic rule for ${foo}: ${foo}.c 
> >> rules> >> (haven't traced that part down yet).
> >>
> >
> > There is an implicit rule to build file from file.c, it's why
> > you can> > type "make foo" in a dir that contains a foo.c and no Makefile.
> >
> > The CONFS=moduli makes moduli into a target.  The implicit rules
> > search> > finds the rule to make moduli from moduli.c and because of the 
> > .PATH> > it's able to find a moduli.c.
> >
> > It might be fixable by simply adding a target with a do-nothing
> > script> > for building moduli in usr.sbin/sshd/Makefile.  Something like
> >
> > moduli:
> > @ : # Do nothing.
> >
> > But that's just a wild guess on my part, not sure that'll work.
> > Hmm, in> > fact, it'll probably cause a make warning about duplicate
> > targets with> > scripts.
> >
> > --Ian
> >
> >> The most scaring part is that the build system seems to trying
> >> building crypto/openssh/moduli because moduli.c was newer, and the> >> 
> >> file was deleted as part of the rebuild; should moduli.c compile by> >> 
> >> its own, we would end up with a binary moduli file.
> >>
> >> I'll take another look tonight if I had some time.
> >>
> >>>
> >>>
> >>>
> >>> Regards,
> >>> Brad Davis
> >>>
> 
>  On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill   
>  .org> wrote:
> >
> >
> > Running:
> >
> > FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1
> > #80  r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018> > 
> > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/s> > 
> > ys/CANARY  amd64
> >
> > after updating working copy to r337903, I'm seeing:
> >
> > ...
> >>
> >>>
> 
>  stage 4.3: building everything
> > ...
> > --- ifconfig_make ---
> > Building
> > /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/i> > 
> > fconfig/af_inet6.o
> > --- all_subdir_secure ---
> > --- moduli ---
> > /usr/bin/ld: error: undefined symbol: main
> >>
>
> r337928 should fix it.
>

Thank you. 


Regards,
Brad Davis

___
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: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Bryan Drewery]

On 8/16/18 12:09 PM, Ian Lepore wrote:
> On Thu, 2018-08-16 at 11:25 -0700, Xin LI wrote:
>> On Thu, Aug 16, 2018 at 9:26 AM Brad Davis  wrote:
>>>
>>>
>>> On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:

 This was caused by r337852, but I didn't investigated further.

 The problem is that we have a source file called 'moduli.c' in
 crypto/openssh/ while the build target was moduli, and bmake seen
 'moduli' in source tree as older than moduli.c, and decided to
 rebuild
 it from source, while the two files are unrelated.
>>> Hi Xin,
>>>
>>> I don't see how that could be the case as I didn't move the file
>>> around, I just moved how it gets installed.
>>>
>>> I have done many many builds with this change in and haven't seen
>>> this problem..
>> Yeah, let me rephrase: this might have been exposed by r337852; I
>> don't think your change itself really caused or should have caused
>> problem, but my theory based on what we have observed was that it
>> might have exposed a bug where either bmake itself, or some .mk files
>> might have generated e.g. automatic rule for ${foo}: ${foo}.c rules
>> (haven't traced that part down yet).
>>
> 
> There is an implicit rule to build file from file.c, it's why you can
> type "make foo" in a dir that contains a foo.c and no Makefile.
> 
> The CONFS=moduli makes moduli into a target.  The implicit rules search
> finds the rule to make moduli from moduli.c and because of the .PATH
> it's able to find a moduli.c.
> 
> It might be fixable by simply adding a target with a do-nothing script
> for building moduli in usr.sbin/sshd/Makefile.  Something like
> 
> moduli:
>     @ : # Do nothing.
> 
> But that's just a wild guess on my part, not sure that'll work. Hmm, in
> fact, it'll probably cause a make warning about duplicate targets with
> scripts.
> 
> --Ian
> 
>> The most scaring part is that the build system seems to trying
>> building crypto/openssh/moduli because moduli.c was newer, and the
>> file was deleted as part of the rebuild; should moduli.c compile by
>> its own, we would end up with a binary moduli file.
>>
>> I'll take another look tonight if I had some time.
>>
>>>
>>>
>>>
>>> Regards,
>>> Brad Davis
>>>

 On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill >>> .org> wrote:
>
>
> Running:
>
> FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1
> #80  r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/s
> ys/CANARY  amd64
>
> after updating working copy to r337903, I'm seeing:
>
> ...
>>
>>>

 stage 4.3: building everything
> ...
> --- ifconfig_make ---
> Building
> /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/i
> fconfig/af_inet6.o
> --- all_subdir_secure ---
> --- moduli ---
> /usr/bin/ld: error: undefined symbol: main
>>

r337928 should fix it.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Bryan Drewery]

On 8/16/18 9:53 AM, Larry Rosenman wrote:
> On Thu, Aug 16, 2018 at 12:43:42PM -0400, Charlie Li wrote:
>> On 16/08/2018 12:26, Brad Davis wrote:
>>> On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
 This was caused by r337852, but I didn't investigated further.

 The problem is that we have a source file called 'moduli.c' in
 crypto/openssh/ while the build target was moduli, and bmake seen
 'moduli' in source tree as older than moduli.c, and decided to rebuild
 it from source, while the two files are unrelated.
>>>
>>> Hi Xin,
>>>
>>> I don't see how that could be the case as I didn't move the file around, I 
>>> just moved how it gets installed.
>>>
>>> I have done many many builds with this change in and haven't seen this 
>>> problem..
>>>
>> I've found this one intermittent at best. I'll run a buildworld on
>> anything newer than r337852, get the linker error, update to even the
>> next newer revision that changes completely unrelated files, build
>> succeeds. Case in point, r337835 to r337863 failed, but r337863 to
>> r337865 succeeded.
>>
>> This is all with META_MODE, so could be a bug with that.
> I've seen the same thing with meta-mode.  A svn up after the failure
> restores the missing moduli file, and a re-run will succeed.
> 
> borg.lerctr.org /usr/src $ sudo svn up
> Updating '.':
> Restored 'crypto/openssh/moduli'
> At revision 337914.
> borg.lerctr.org /usr/src $
> 
> 

FYI it's not META_MODE related. It happens with a clean build as long as
the moduli timestamp is old enough.

> ~/git/freebsd/secure/usr.sbin/sshd # make buildconfig -dmM MK_META_MODE=no
> Make_ExpandUse: examine buildconfig
> MakeAddChild: need to examine moduli
> MakeAddChild: need to examine sshd_config
> Make_ExpandUse: examine moduli
> MakeAddChild: need to examine moduli.c
> Make_ExpandUse: examine sshd_config
> Make_ExpandUse: examine moduli.c
> Examining moduli.c...modified  7:59:30 Jun 07, 2018...up-to-date.
> Examining moduli...modified  0:00:00 Nov 30, 2017...modified before source 
> /root/git/freebsd/crypto/openssh/moduli.c...out-of-date.
> cc -O2 -pipe   -I/root/git/freebsd/crypto/openssh -include ssh_namespace.h 
> -DHAVE_LDNS=1 -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
> -I/root/git/freebsd/contrib/blacklist/include -include
>  krb5_config.h -DLIBWRAP=1 -DXAUTH_PATH=\"/usr/local/bin/xauth\" -g  
> -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
> -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautologic
> al-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member 
> -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa
> rameter -Wno-parentheses  -fcolor-diagnostics -Qunused-arguments   
> -L/scratch/obj/root/git/freebsd/amd64.amd64/lib/libblacklist  
> /root/git/freebsd/crypto/openssh/moduli.c  -o /root/git/freebsd/crypto/op
> enssh/moduli
> /usr/bin/ld: error: undefined symbol: main



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

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Ian Lepore]

On Thu, 2018-08-16 at 11:25 -0700, Xin LI wrote:
> On Thu, Aug 16, 2018 at 9:26 AM Brad Davis  wrote:
> > 
> > 
> > On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> > > 
> > > This was caused by r337852, but I didn't investigated further.
> > > 
> > > The problem is that we have a source file called 'moduli.c' in
> > > crypto/openssh/ while the build target was moduli, and bmake seen
> > > 'moduli' in source tree as older than moduli.c, and decided to
> > > rebuild
> > > it from source, while the two files are unrelated.
> > Hi Xin,
> > 
> > I don't see how that could be the case as I didn't move the file
> > around, I just moved how it gets installed.
> > 
> > I have done many many builds with this change in and haven't seen
> > this problem..
> Yeah, let me rephrase: this might have been exposed by r337852; I
> don't think your change itself really caused or should have caused
> problem, but my theory based on what we have observed was that it
> might have exposed a bug where either bmake itself, or some .mk files
> might have generated e.g. automatic rule for ${foo}: ${foo}.c rules
> (haven't traced that part down yet).
> 

There is an implicit rule to build file from file.c, it's why you can
type "make foo" in a dir that contains a foo.c and no Makefile.

The CONFS=moduli makes moduli into a target.  The implicit rules search
finds the rule to make moduli from moduli.c and because of the .PATH
it's able to find a moduli.c.

It might be fixable by simply adding a target with a do-nothing script
for building moduli in usr.sbin/sshd/Makefile.  Something like

moduli:
    @ : # Do nothing.

But that's just a wild guess on my part, not sure that'll work. Hmm, in
fact, it'll probably cause a make warning about duplicate targets with
scripts.

--Ian

> The most scaring part is that the build system seems to trying
> building crypto/openssh/moduli because moduli.c was newer, and the
> file was deleted as part of the rebuild; should moduli.c compile by
> its own, we would end up with a binary moduli file.
> 
> I'll take another look tonight if I had some time.
> 
> > 
> > 
> > 
> > Regards,
> > Brad Davis
> > 
> > > 
> > > On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  > > .org> wrote:
> > > > 
> > > > 
> > > > Running:
> > > > 
> > > > FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1
> > > > #80  r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> > > > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/s
> > > > ys/CANARY  amd64
> > > > 
> > > > after updating working copy to r337903, I'm seeing:
> > > > 
> > > > ...
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > stage 4.3: building everything
> > > > ...
> > > > --- ifconfig_make ---
> > > > Building
> > > > /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/i
> > > > fconfig/af_inet6.o
> > > > --- all_subdir_secure ---
> > > > --- moduli ---
> > > > /usr/bin/ld: error: undefined symbol: main
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > referenced by crt1.c
> > > > > > >   /common/S4/obj/usr/src/amd64.amd64/tmp/usr/
> > > > > > > lib/crt1.o:(_start)
> > > > /usr/bin/ld: error: undefined symbol: Fssh_error
> > > > 
> > > > make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> > > > .ERROR_TARGET='moduli'
> > > > .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr
> > > > .sbin/sshd/moduli.meta'
> > > > .MAKE.LEVEL='5'
> > > > MAKEFILE=''
> > > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes
> > > > silent=yes verbose'
> > > > _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 --
> > > > sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp
> > > > -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   -
> > > > I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1
> > > > -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1
> > > > -I/usr/src/contrib/blacklist/include -include krb5_config.h
> > > > -DLIBWRAP=1 -std=gnu99 -fstack-protector-strong -Wno-pointer-
> > > > sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-
> > > > variable -Wno-tautological-compare -Wno-unused-value -Wno-
> > > > parentheses-equality -Wno-unused-function -Wno-enum-conversion
> > > > -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-
> > > > switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-
> > > > parentheses  -Qunused-arguments   -
> > > > L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  /usr/src/
> > > > crypto/openssh/moduli.c  -o moduli; ;'
> > > > .CURDIR='/usr/src/secure/usr.sbin/sshd'
> > > > .MAKE='make'
> > > > .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/ssh
> > > > d'
> > > > .TARGETS='all'
> > > > DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> > > > 
> > > > 
> > > > (on both the laptop and the build machine).
> > > > 
> > > > I have copied the .ERROR_META_FILE to
> > > >  > > > eta and
> > > > a typescript of the attempted build to
> > > > 

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Xin LI]

On Thu, Aug 16, 2018 at 9:26 AM Brad Davis  wrote:
>
> On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> > This was caused by r337852, but I didn't investigated further.
> >
> > The problem is that we have a source file called 'moduli.c' in
> > crypto/openssh/ while the build target was moduli, and bmake seen
> > 'moduli' in source tree as older than moduli.c, and decided to rebuild
> > it from source, while the two files are unrelated.
>
> Hi Xin,
>
> I don't see how that could be the case as I didn't move the file around, I 
> just moved how it gets installed.
>
> I have done many many builds with this change in and haven't seen this 
> problem..

Yeah, let me rephrase: this might have been exposed by r337852; I
don't think your change itself really caused or should have caused
problem, but my theory based on what we have observed was that it
might have exposed a bug where either bmake itself, or some .mk files
might have generated e.g. automatic rule for ${foo}: ${foo}.c rules
(haven't traced that part down yet).

The most scaring part is that the build system seems to trying
building crypto/openssh/moduli because moduli.c was newer, and the
file was deleted as part of the rebuild; should moduli.c compile by
its own, we would end up with a binary moduli file.

I'll take another look tonight if I had some time.

>
>
> Regards,
> Brad Davis
>
> > On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  
> > wrote:
> > >
> > > Running:
> > >
> > > FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80  
> > > r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> > > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> > > amd64
> > >
> > > after updating working copy to r337903, I'm seeing:
> > >
> > > ...
> > > >>> stage 4.3: building everything
> > > ...
> > > --- ifconfig_make ---
> > > Building 
> > > /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/ifconfig/af_inet6.o
> > > --- all_subdir_secure ---
> > > --- moduli ---
> > > /usr/bin/ld: error: undefined symbol: main
> > > >>> referenced by crt1.c
> > > >>>   
> > > >>> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> > > /usr/bin/ld: error: undefined symbol: Fssh_error
> > > 
> > > make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> > > .ERROR_TARGET='moduli'
> > > .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd/moduli.meta'
> > > .MAKE.LEVEL='5'
> > > MAKEFILE=''
> > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> > > _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 
> > > --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
> > > -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   
> > > -I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 
> > > -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
> > > -I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 
> > > -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
> > > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> > > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> > > -Wno-enum-conversion -Wno-unused-local-typedef 
> > > -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
> > > -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments   
> > > -L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  
> > > /usr/src/crypto/openssh/moduli.c  -o moduli; ;'
> > > .CURDIR='/usr/src/secure/usr.sbin/sshd'
> > > .MAKE='make'
> > > .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd'
> > > .TARGETS='all'
> > > DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> > > 
> > >
> > > (on both the laptop and the build machine).
> > >
> > > I have copied the .ERROR_META_FILE to
> > >  > > a typescript of the attempted build to
> > > .
> > >
> > > Additional information (previous day's verbose dmesg.bot, etc.) may
> > > be found at .
> > >
> > > Peace,
> > > david
> > > --
> > > David H. Wolfskill  da...@catwhisker.org
> > > Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
> > >
> > > See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Larry Rosenman]

On Thu, Aug 16, 2018 at 12:43:42PM -0400, Charlie Li wrote:
> On 16/08/2018 12:26, Brad Davis wrote:
> > On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> >> This was caused by r337852, but I didn't investigated further.
> >>
> >> The problem is that we have a source file called 'moduli.c' in
> >> crypto/openssh/ while the build target was moduli, and bmake seen
> >> 'moduli' in source tree as older than moduli.c, and decided to rebuild
> >> it from source, while the two files are unrelated.
> > 
> > Hi Xin,
> > 
> > I don't see how that could be the case as I didn't move the file around, I 
> > just moved how it gets installed.
> > 
> > I have done many many builds with this change in and haven't seen this 
> > problem..
> > 
> I've found this one intermittent at best. I'll run a buildworld on
> anything newer than r337852, get the linker error, update to even the
> next newer revision that changes completely unrelated files, build
> succeeds. Case in point, r337835 to r337863 failed, but r337863 to
> r337865 succeeded.
> 
> This is all with META_MODE, so could be a bug with that.
I've seen the same thing with meta-mode.  A svn up after the failure
restores the missing moduli file, and a re-run will succeed.

borg.lerctr.org /usr/src $ sudo svn up
Updating '.':
Restored 'crypto/openssh/moduli'
At revision 337914.
borg.lerctr.org /usr/src $


> 
> -- 
> Charlie Li
> Can't think of a witty .sigline today…
> 
> (This email address is for mailing list use only; replace local-part
> with vishwin for off-list communication)
> 




-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[David Wolfskill]

On Thu, Aug 16, 2018 at 12:43:42PM -0400, Charlie Li wrote:
> 
> I've found this one intermittent at best. I'll run a buildworld on
> anything newer than r337852, get the linker error, update to even the
> next newer revision that changes completely unrelated files, build
> succeeds. Case in point, r337835 to r337863 failed, but r337863 to
> r337865 succeeded.

I got the "one" I reported twice this morning, on each of two
different machines, so that's four out of four.  Granted, that
doesn't necessarily make it "reproducible," but it does reduce the
odds that its another race condition, for example.

And one of those machines is currently available for testing possible
fixes (after I power it back up).

> This is all with META_MODE, so could be a bug with that.

True -- I am using META_MODE (as my mention of the .ERROR_META_FILE
indicated).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

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


signature.asc
Description: PGP signature

Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Charlie Li]

On 16/08/2018 12:26, Brad Davis wrote:
> On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
>> This was caused by r337852, but I didn't investigated further.
>>
>> The problem is that we have a source file called 'moduli.c' in
>> crypto/openssh/ while the build target was moduli, and bmake seen
>> 'moduli' in source tree as older than moduli.c, and decided to rebuild
>> it from source, while the two files are unrelated.
> 
> Hi Xin,
> 
> I don't see how that could be the case as I didn't move the file around, I 
> just moved how it gets installed.
> 
> I have done many many builds with this change in and haven't seen this 
> problem..
> 
I've found this one intermittent at best. I'll run a buildworld on
anything newer than r337852, get the linker error, update to even the
next newer revision that changes completely unrelated files, build
succeeds. Case in point, r337835 to r337863 failed, but r337863 to
r337865 succeeded.

This is all with META_MODE, so could be a bug with that.

-- 
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)



signature.asc
Description: OpenPGP digital signature

buffer device_printf...

[John-Mark Gurney]

On my arm64 board, various console messages get intermixed because of
SMP.  This makes messages harder to read than the could be.  One issue
is that device_printf uses two printf's, one for the device, and one
for the provided message..  This prevents PRINTF_BUFR_SIZE from combining
the two messages into a single write.

The review https://reviews.freebsd.org/D16690 makes device_printf use
an sbuf w/ a printf drain to effectively buffer these messages together.

previously:
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
mmc0:  Instruction Set Attributes 0 = 
ACMD42 failed, RESULT: 4
 Instruction Set Attributes 1 = <>
mmc0:  Processor Features 0 = 
Card at relative address 43690 failed to set bus width

w/ patch:
mmc0: ACMD42 failed, RESULT: 4
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
 Instruction Set Attributes 0 = 
mmc0: Card at relative address 43690 failed to set bus width
 Instruction Set Attributes 1 = <>
 Processor Features 0 = 

Comments?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Brad Davis]

On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> This was caused by r337852, but I didn't investigated further.
> 
> The problem is that we have a source file called 'moduli.c' in
> crypto/openssh/ while the build target was moduli, and bmake seen
> 'moduli' in source tree as older than moduli.c, and decided to rebuild
> it from source, while the two files are unrelated.

Hi Xin,

I don't see how that could be the case as I didn't move the file around, I just 
moved how it gets installed.

I have done many many builds with this change in and haven't seen this problem..


Regards,
Brad Davis

> On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  wrote:
> >
> > Running:
> >
> > FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80  
> > r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> > r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> > amd64
> >
> > after updating working copy to r337903, I'm seeing:
> >
> > ...
> > >>> stage 4.3: building everything
> > ...
> > --- ifconfig_make ---
> > Building 
> > /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/ifconfig/af_inet6.o
> > --- all_subdir_secure ---
> > --- moduli ---
> > /usr/bin/ld: error: undefined symbol: main
> > >>> referenced by crt1.c
> > >>>   
> > >>> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> > /usr/bin/ld: error: undefined symbol: Fssh_error
> > 
> > make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> > .ERROR_TARGET='moduli'
> > .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd/moduli.meta'
> > .MAKE.LEVEL='5'
> > MAKEFILE=''
> > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> > _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 
> > --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
> > -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   
> > -I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 
> > -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
> > -I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 
> > -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
> > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> > -Wno-enum-conversion -Wno-unused-local-typedef 
> > -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
> > -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments   
> > -L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  
> > /usr/src/crypto/openssh/moduli.c  -o moduli; ;'
> > .CURDIR='/usr/src/secure/usr.sbin/sshd'
> > .MAKE='make'
> > .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd'
> > .TARGETS='all'
> > DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> > 
> >
> > (on both the laptop and the build machine).
> >
> > I have copied the .ERROR_META_FILE to
> >  > a typescript of the attempted build to
> > .
> >
> > Additional information (previous day's verbose dmesg.bot, etc.) may
> > be found at .
> >
> > Peace,
> > david
> > --
> > David H. Wolfskill  da...@catwhisker.org
> > Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
> >
> > See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[Xin LI]

This was caused by r337852, but I didn't investigated further.

The problem is that we have a source file called 'moduli.c' in
crypto/openssh/ while the build target was moduli, and bmake seen
'moduli' in source tree as older than moduli.c, and decided to rebuild
it from source, while the two files are unrelated.

Cheers,
On Thu, Aug 16, 2018 at 4:19 AM David Wolfskill  wrote:
>
> Running:
>
> FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80  
> r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
>
> after updating working copy to r337903, I'm seeing:
>
> ...
> >>> stage 4.3: building everything
> ...
> --- ifconfig_make ---
> Building 
> /common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/ifconfig/af_inet6.o
> --- all_subdir_secure ---
> --- moduli ---
> /usr/bin/ld: error: undefined symbol: main
> >>> referenced by crt1.c
> >>>   
> >>> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
> /usr/bin/ld: error: undefined symbol: Fssh_error
> 
> make[5]: stopped in /usr/src/secure/usr.sbin/sshd
> .ERROR_TARGET='moduli'
> .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd/moduli.meta'
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 
> --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   
> -I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 
> -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
> -I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 
> -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
> -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member 
> -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  
> -Qunused-arguments   -L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  
> /usr/src/crypto/openssh/moduli.c  -o moduli; ;'
> .CURDIR='/usr/src/secure/usr.sbin/sshd'
> .MAKE='make'
> .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd'
> .TARGETS='all'
> DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> 
>
> (on both the laptop and the build machine).
>
> I have copied the .ERROR_META_FILE to
>  a typescript of the attempted build to
> .
>
> Additional information (previous day's verbose dmesg.bot, etc.) may
> be found at .
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

[Michael Gmelin]

> On 15. Aug 2018, at 15:55, Konstantin Belousov  wrote:
> 
>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote:
>> 
>> 
 On 15. Aug 2018, at 15:04, Konstantin Belousov  wrote:
 
 On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin wrote:
 Reviving this old thread, since I just updated to r337818 and a similar
 problem is happening again. Since the fix in r334799 (review
 https://reviews.freebsd.org/D15675) (mp_)machdep.c have been touched,
 so maybe this is related
 (https://svnweb.freebsd.org/base?view=revision=334799).
 
 Please see the screenshot of the panic below:
 https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658
 
 This is me not digging any deeper, hoping that this is something
 obvious. Please let me know if you need more input.
>>> 
>>> I do not see how recent mp_machdep.c changes could affect this.
>>> Can you try newest kernel but old loader ?
>> 
>> I will try (but that will take a while). Oh, also, it still boots in save 
>> mode/with smp disabled.
> 
> Right, this is because the access to that address through DMAP is only 
> needed when configuring AP startup resources.
> 
> Also, I think it is safe to suggest that the bisect is needed.

Using an older loader didn’t help, but I identified the problem:

https://svnweb.freebsd.org/base?view=revision=334952

modified the code you introduced in

https://svnweb.freebsd.org/base?view=revision=334799

By correcting units to pages it also broke booting the Chromebook as a side 
effect - so the previous fix just worked due to a bug it seems.

Is there an easy way to output the content of physmap at that point 
(debug.late_console=0 doesn’t work) - like an existing buffer I could use, or 
would this be more elaborate (I did something complicated last time but didn’t 
save it, so any simple solution would be preferred).

Thanks,
Michael 

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

/usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

[David Wolfskill]

Running:

FreeBSD g1-215.catwhisker.org 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #80  
r337834M/337834:1200077: Wed Aug 15 04:34:45 PDT 2018 
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

after updating working copy to r337903, I'm seeing:

...
>>> stage 4.3: building everything
...
--- ifconfig_make ---
Building 
/common/S4/obj/usr/src/amd64.amd64/rescue/rescue/usr/src/sbin/ifconfig/af_inet6.o
--- all_subdir_secure ---
--- moduli ---
/usr/bin/ld: error: undefined symbol: main
>>> referenced by crt1.c
>>>   /common/S4/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
/usr/bin/ld: error: undefined symbol: Fssh_error

make[5]: stopped in /usr/src/secure/usr.sbin/sshd
.ERROR_TARGET='moduli'
.ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd/moduli.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe   
-I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 
-DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 
-I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 
-std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  
-Qunused-arguments   -L/common/S4/obj/usr/src/amd64.amd64/lib/libblacklist  
/usr/src/crypto/openssh/moduli.c  -o moduli; ;'
.CURDIR='/usr/src/secure/usr.sbin/sshd'
.MAKE='make'
.OBJDIR='/common/S4/obj/usr/src/amd64.amd64/secure/usr.sbin/sshd'
.TARGETS='all'
DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'


(on both the laptop and the build machine).

I have copied the .ERROR_META_FILE to
.

Additional information (previous day's verbose dmesg.bot, etc.) may
be found at .

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

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


signature.asc
Description: PGP signature

4kn and biosdisk.c

[Toomas Soome]

hi!

if you have 4kn disks and BIOS capable of 4k IO with INT13, could you please 
test https://reviews.freebsd.org/D11174  
and give some feedback:)

The patch itself has been in use for some time in illumos. PS: as noted in test 
plan, this only can be tested by loader now and not by earlier stages (lsdev, 
lszfs, ls device:path commands).

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

Re: Make drm drivers use MTRR write-combine

[Johannes Lundberg]

On Tue, Aug 14, 2018 at 9:54 PM Johannes Lundberg 
wrote:

>
>
> On Tue, Aug 14, 2018 at 3:39 PM Konstantin Belousov 
> wrote:
>
>> On Tue, Aug 14, 2018 at 08:55:36AM -0500, Eric van Gyzen wrote:
>> > On 8/14/18 4:12 AM, Johannes Lundberg wrote:
>> > > Hi
>> > >
>> > > Something that we have seen for a long time on FreeBSD is the boot
>> message
>> > >
>> > > Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance
>> may
>> > > suffer
>> > >
>> > > Taking a closer look at this with memcontrol I can see that the 256 MB
>> > > region that DRM wants to set as WC is already covered by this entry
>> > > 0xc000/0x4000 BIOS uncacheable set-by-firmware active
>> > >
>> > > Similar on both my Skylake and Broadwell systems.
>> > I see something similar on my Dell XPS 13 with a Kaby Lake R:
>> >
>> > Failed to add WC MTRR for [0x9000-0x9fff]: -22; performance may
>> > suffer
>> >
>> > 0x8000/0x8000 BIOS uncacheable set-by-firmware active
>> >
>> > The only mappings in this range are MMIO:
>> >
>> > machdep.efi_map:
>> >Type Physical  Virtual   #Pages Attr
>> > [snip]
>> > MemoryMappedIO e000   0xe000 0001 RUNTIME
>> > MemoryMappedIO fe00   0xfe00 0011 UC RUNTIME
>> > MemoryMappedIO fec0   0xfec0 0001 UC RUNTIME
>> > MemoryMappedIO fee0   0xfee0 0001 UC WT WB WP RUNTIME
>> > MemoryMappedIO ff00   0xff00 1000 UC WT WB WP RUNTIME
>>
>> Yes, the cause of the message is that current x86 mtrr code is not
>> sufficient to handle this situation. You have BIOS-configured variable
>> range MTRR which covers upper half of the low 4G, as uncacheable (UC).
>> It is reasonable for BIOS to set it up this way because this is where
>> PCIe BARs and other devices MMIO regions are located.
>>
>> One of the BARs there is the GPU aperture that really should be WC
>> (write-combining). There are two ways to achieve this: split the UC
>> variable-length MTRR range into three, UC/WC/UC, which would require
>> three MTRRs to cover. This is what current x86_mem.c code does not
>> support.
>>
>> Another way is to set WC mode in the page table entries (PTEs) using
>> Page Attribute Table (PAT), for all PTEs. According to the rules of
>> combination of the memory access types between MTRR and PAT, WC in PAT
>> and any access mode in MTRR gives effective WC.
>>
>> I saw the same warning when I initially ported GEM. My code used WC PAT
>> type, which makes the warning cosmetical, and which made me to not add
>> MTRR split. If new drm driver also consistently uses WC memattr when
>> creating aperture mappings, then the warning can be ignored as well.
>>
>
> Hi Kib
>
> Thanks for the detailed answer. This might already be the case for the out
> of tree drivers as well. From what I read about the VESA driver the
> performance difference should be quite big w/o WC and I haven't noticed and
> performance issues with the newer drivers at all.
>
> I will confirm this tomorrow.
>

Yeah, seems like it's already done.

https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/linuxkpi/gplv2/src/linux_page.c#L260

https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/drivers/gpu/drm/i915/i915_gem_gtt.c#L415
https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/drivers/gpu/drm/ttm/ttm_page_alloc.c#L534


>
> ___
>> 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: swapping is completely broken in -CURRENT r334649?

[Alexey Dokuchaev]

On Wed, Jun 27, 2018 at 07:55:26AM -0400, Mark Johnston wrote:
> On Wed, Jun 27, 2018 at 10:46:38AM +, Alexey Dokuchaev wrote:
> > On Fri, Jun 15, 2018 at 04:40:22AM -0400, Mark Johnston wrote:
> > > ...
> > > The change was committed as r334752.  Are you seeing unexpected OOM
> > > kills on or after that revision?
> > 
> > I've just discovered this thread.  I've updated my -CURRENT desktop ca.
> > June 4th and my X.org session crashes within several minutes.  This is
> > on i386 system with 4G RAM.
> > 
> > I cannot get SVN revision of that kernel because something got broken
> > and it was not embedded in the image. :-(
> > 
> > Rebooting with kernel="kernel.old" from May 12th made this problem go
> > away.  Is the root cause is known at this time?  Which revision shall
> > I try to see whether it does not exhibit this bug any longer?  Thanks,
> 
> As noted earlier in the thread, r329882 introduced a problem where
> out-of-memory kills were taking place despite an abundance of free pages
> and swap space.  That bug was fixed in r334752.  If you are seeing a
> problem that is fixed in a kernel from May 12th, then it is possibly
> unrelated to this bug, but it is worth testing r334752 or later to
> confirm.

Thanks, I can confirm that r334752 fixed the out-of-memory kills for me
now that I've been running it for two weeks without a single problem.

./danfe
___
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: gif does not work when going over IPv6 on current

[Andrey V. Elsukov]

On 15.08.2018 23:47, Lars Schotte wrote:
> Hey folks,
> 
> when you create a gif with IPv6 tunnel endpoints
> tcpdump on the underlying interface will show you some kind of error
> that 0 != 6 and packets will be dropped.
> 
> IP6 version error: 0 != 6
> repeating for each packet.
> happens only while sending. receiving works.
> 
> This happens only on 12-current as I am aware, 11-stable works good.
> I worked around this issue by setting IPv4 tunnel endpoints.

Hi,

should be fixed in r337900.
Thanks for the report. And sorry for breakage.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature