Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[Hartmann, O.]

On Tue, 9 Feb 2021 15:15:38 -0800
John Baldwin  wrote:

> On 2/9/21 2:16 PM, Hartmann, O. wrote:
> > On Wed, 3 Feb 2021 17:34:24 +0100
> > Guido Falsi via freebsd-current  wrote:
> >   
> >> On 03/02/21 17:02, John Baldwin wrote:  
> >>> On 2/2/21 10:16 PM, Hartmann, O. wrote:  
>  On Mon, 1 Feb 2021 03:24:45 +
>  Rick Macklem  wrote:
>  
> > Rick Macklem wrote:  
> >> Guido Falsi wrote:
> >> [good stuff snipped]  
> >>> Performed a full bisect. Tracked it down to commit aa906e2a4957,
> >>> adding
> >>> KTLS support to embedded OpenSSL.
> >>>
> >>> I filed a bug report about this:
> >>>
> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135
> >>>
> >>>
> >>> Apart from switching to svn:// scheme, another workaround is to build
> >>> base using WITHOUT_OPENSSL_KTLS.  
> >> Just fyi, when I tested the daemons I have for nfs-over-tls (which
> >> use ktls),
> >> they acted like things were ok (no handshake problems), but the data
> >> ended up on the wire unencrypted (nfs-over-tls doesn't do a
> >> SSL_write(),
> >> so it depends on ktls to do the encryption).
> >>
> >> Since these daemons work fine with openssl3 in
> >> ports/security/openssl-devel,
> >> I suspect the ktls backport is not quite right. I've sent jhb@ email.  
> > I was wrong on the above. I did a full buildworld/installworld and
> > the daemons
> > now seem to work with the openssl in head/main.
> >
> > Btw, did anyone try rebuilding svn from sources after doing
> > the system upgrade?
> > (The openssl library calls and .h files definitely changed.)  
> 
>  Yes, I did, on all boxes and its a pain in the a..., we had to rebuild
>  EVERY port (at
>  least, I did, to avoid further problem). Yesterday, on of our fastes
>  boxes got ready and
>  even with a full rebuild of the system AND a full rebuild of the ports
>  (no poudriere,
>  traditional way via make), the Apache 2.4 webservice doesn't work, and
>  so does subversion
>  not (Firefox reports problems with SSL handshake, subversion is
>  stuck/frozen forever).
>  I will run today another full world build today, hopefully finishing
>  on friday (portmaster
>  -dfR doesn't get everything in line on some ports, I assume).
> 
>  oh  
> >>>
> >>> I tracked the subversion hang down to a bug in serf (an Apache library
> >>> used by
> >>> subversion).  It would also affect any other software using serf.  The
> >>> serf in
> >>> ports will also have to be patched.
> >>>  
> >>
> >> I submitted your patch as a bug report to the serf port:
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253214
> >>  
> > 
> > What is the status of this bug?
> > As PR 253214 might suggest, the patch to www/serf has been commited. We 
> > still face a
> > problem with FreeBSD CURRENT-14 based systems running Apache24:
> > 
> > FreeBSD 14.0-CURRENT #4 main-n244672-866c8b8d5dd: Mon Feb  8 08:38:59 CET 
> > 2021 amd64
> > 
> > /usr/ports is at Revision: 564736.
> > 
> > www/apache24, www/serf have been rebuilt using "portmaster -f www/apache24 
> > www/serf".
> > 
> > Restarting Apache 2.4 still fails on any access with SSL enabled, firefox 
> > reports:
> > 
> > SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT  
> 
> This is the first report I've had after the serf update.
> 
> Here's an untested patch that is similar to the serf bug.  You would
> apply this in the www/apache24 port.
> 
> Index: files/patch-modules_ssl_ssl__engine__io.c
> ===
> --- files/patch-modules_ssl_ssl__engine__io.c   (nonexistent)
> +++ files/patch-modules_ssl_ssl__engine__io.c   (working copy)
> @@ -0,0 +1,11 @@
> +--- modules/ssl/ssl_engine_io.c.orig   2021-02-09 15:09:39.362123000 -0800
>  modules/ssl/ssl_engine_io.c2021-02-09 15:12:13.59669 -0800
> +@@ -542,7 +542,7 @@ static int bio_filter_in_gets(BIO *bio, char *buf, int
> +
> + static long bio_filter_in_ctrl(BIO *bio, int cmd, long num, void *ptr)
> + {
> +-return -1;
> ++return 0;
> + }
> +
> + #if MODSSL_USE_OPENSSL_PRE_1_1_API
> 

Thank you very much for investigating and the patch.

I haven't got the chance to apply the patch yet, I'll do within the next two 
hours. For
the record: I filed a PR on this specific problem in Apache 2.4, please see 
here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253394

Kind regards,

O. Hartmann


pgpbfcPEzuqvy.pgp
Description: OpenPGP digital signature

Re: [PACTH,libm] hypothl(x) mishandles subnormal numbers.

[Steve Kargl]

On Wed, Feb 10, 2021 at 12:26:29AM +0100, Dimitry Andric wrote:
> 
> > On 10 Feb 2021, at 00:15, Steve Kargl  
> > wrote:
> > 
> > This patch fixes the issue.  t1 is used to scale the subnormal
> > numbers.  It is generated by scaling the exponent, but that
> > only works if t1 is 1 not 0.
> > 
> > Index: src/e_hypotl.c
> > ===
> > --- src/e_hypotl.c  (revision 2342)
> > +++ src/e_hypotl.c  (working copy)
> > @@ -82,7 +82,7 @@ hypotl(long double x, long double y)
> > man_t manh, manl;
> > GET_LDBL_MAN(manh,manl,b);
> > if((manh|manl)==0) return a;
> > -   t1=0;
> > +   t1=1;
> > SET_HIGH_WORD(t1,ESW(MAX_EXP-2));   /* t1=2^(MAX_EXP-2) */
> > b *= t1;
> > a *= t1;
> > 
> 
> Ah, having looked at the glibc code, I had concluded something similar
> in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253313#c2, but
> using INSERT_LDBL80_WORDS(t1,ESW(MAX_EXP-2),0x8000).
> 
> Your solution is a lot simpler though. :) Note that to make it work, I
> also needed to insert a volatile into the INSERT_LDBL80_WORDS() macro.

I don't look at glibc's libm code due to possible Copyright
issues (long/short story that I rather not get into here).
I do, however, have a math_sgk.h that appears at the
end of math_privated.h with a bunch of instrumentation code
hidden behind -DEBUG.  For the above, it becomes

t1=0;
SET_HIGH_WORD(t1,ESW(MAX_EXP-2));   /* t1=2^(MAX_EXP-2) */
PRNL(t1);

which yields inf as output.  Clearly, not a scaling of a subnormal
to a normal number.


> There are more places where this is apparently needed, due to the way
> recent clang versions tend to over-optimize floating point code at
> compile time. And specifically for the case where one union field is
> written, and then another field read, sometimes leading to unexpected
> results...

Hmmm.  This is a bummer.  I suppose someone will say the code
in msun is using undefined behavior or some such standardese.

-- 
Steve
___
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: cgit: orientation

[Warner Losh]

On Tue, Feb 9, 2021 at 5:52 PM Warner Losh  wrote:

>
>
> On Tue, Feb 9, 2021 at 5:47 PM Graham Perrin 
> wrote:
>
>> Given this, for example:
>>
>> <
>> https://cgit.freebsd.org/src/commit/?id=174a7e578a33c01401e33f9bfcc077fc3155251c=stable%2F12
>> >
>>
>> – with 'stable' in the URL and 'stable/12' visible in the page – how
>> would a reader know that the commit was to main (not stable/12)?
>>
>> Is there scope to make improved use of cgit, or is this a limitation of
>> cgit?
>>
>
> There's a pulldown in the upper right corner that says 'stable/12' though
> it took me a while to find it as my eyes glided over it a couple of times.
>

But that is due to the stable%2F12 in the URL... W/o it, it's no good.

Warner

Warner
>
>
>> TIA
>>
>> ___
>> freebsd-...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-git
>> To unsubscribe, send any mail to "freebsd-git-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: cgit: orientation

[Warner Losh]

On Tue, Feb 9, 2021 at 5:47 PM Graham Perrin  wrote:

> Given this, for example:
>
> <
> https://cgit.freebsd.org/src/commit/?id=174a7e578a33c01401e33f9bfcc077fc3155251c=stable%2F12
> >
>
> – with 'stable' in the URL and 'stable/12' visible in the page – how
> would a reader know that the commit was to main (not stable/12)?
>
> Is there scope to make improved use of cgit, or is this a limitation of
> cgit?
>

There's a pulldown in the upper right corner that says 'stable/12' though
it took me a while to find it as my eyes glided over it a couple of times.

Warner


> TIA
>
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-git
> To unsubscribe, send any mail to "freebsd-git-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: ZFS assertions

[Alan Somers]

On Tue, Feb 9, 2021 at 5:37 PM Graham Perrin  wrote:

> On 09/02/2021 14:41, Alan Somers wrote:
>
> Re: Current - kernel dump while plasma loading.
> > … ZFS assertions weren't actually enabled until last night. …
>
> <
> https://cgit.freebsd.org/src/commit/?id=174a7e578a33c01401e33f9bfcc077fc3155251c>
>
> noted with thanks.
>
> I typically use a GENERIC-NODEBUG kernel config, does this partially
> negate the benefits of assertions?
>
> (If so: for the ZFS case, I'll change it.)
>
> Thanks
>

That's right.  Most assertions are disabled in GENERIC-NODEBUG.
___
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"

cgit: orientation

[Graham Perrin]

Given this, for example:



– with 'stable' in the URL and 'stable/12' visible in the page – how 
would a reader know that the commit was to main (not stable/12)?


Is there scope to make improved use of cgit, or is this a limitation of 
cgit?


TIA

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

ZFS assertions

[Graham Perrin]

On 09/02/2021 14:41, Alan Somers wrote:

Re: Current - kernel dump while plasma loading.

… ZFS assertions weren't actually enabled until last night. …


 
noted with thanks.


I typically use a GENERIC-NODEBUG kernel config, does this partially 
negate the benefits of assertions?


(If so: for the ZFS case, I'll change it.)

Thanks

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

Re: [PACTH,libm] hypothl(x) mishandles subnormal numbers.

[Dimitry Andric]

> On 10 Feb 2021, at 00:15, Steve Kargl  
> wrote:
> 
> On Sat, Feb 06, 2021 at 10:32:33PM +0100, Dimitry Andric wrote:
>> On 6 Feb 2021, at 22:04, Steve Kargl  
>> wrote:
>>> 
>>> On Sat, Feb 06, 2021 at 12:39:29PM -0800, Steve Kargl wrote:
 I've long forgotten by freebsd bugzilla password.
 So, if someone would like to submit a bug report,
 here's a test program.
 
>>> Forgot to include that issue was identified from
>>> a bug report in the OpenLibm bug mailing list.
>>> 
>>> https://github.com/JuliaMath/openlibm/issues/224
>> 
>> I put this in . Now the trick is to
>> figure out what is going on in e_hypotl.c... :)
>> 
> 
> This patch fixes the issue.  t1 is used to scale the subnormal
> numbers.  It is generated by scaling the exponent, but that
> only works if t1 is 1 not 0.
> 
> Index: src/e_hypotl.c
> ===
> --- src/e_hypotl.c(revision 2342)
> +++ src/e_hypotl.c(working copy)
> @@ -82,7 +82,7 @@ hypotl(long double x, long double y)
>   man_t manh, manl;
>   GET_LDBL_MAN(manh,manl,b);
>   if((manh|manl)==0) return a;
> - t1=0;
> + t1=1;
>   SET_HIGH_WORD(t1,ESW(MAX_EXP-2));   /* t1=2^(MAX_EXP-2) */
>   b *= t1;
>   a *= t1;
> 

Ah, having looked at the glibc code, I had concluded something similar
in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253313#c2, but
using INSERT_LDBL80_WORDS(t1,ESW(MAX_EXP-2),0x8000).

Your solution is a lot simpler though. :) Note that to make it work, I
also needed to insert a volatile into the INSERT_LDBL80_WORDS() macro.

There are more places where this is apparently needed, due to the way
recent clang versions tend to over-optimize floating point code at
compile time. And specifically for the case where one union field is
written, and then another field read, sometimes leading to unexpected
results...

In any case, I will apply this soon, and also add a test case. Thanks!

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[John Baldwin]

On 2/9/21 2:16 PM, Hartmann, O. wrote:

On Wed, 3 Feb 2021 17:34:24 +0100
Guido Falsi via freebsd-current  wrote:


On 03/02/21 17:02, John Baldwin wrote:

On 2/2/21 10:16 PM, Hartmann, O. wrote:

On Mon, 1 Feb 2021 03:24:45 +
Rick Macklem  wrote:
  

Rick Macklem wrote:

Guido Falsi wrote:
[good stuff snipped]

Performed a full bisect. Tracked it down to commit aa906e2a4957,
adding
KTLS support to embedded OpenSSL.

I filed a bug report about this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135


Apart from switching to svn:// scheme, another workaround is to build
base using WITHOUT_OPENSSL_KTLS.

Just fyi, when I tested the daemons I have for nfs-over-tls (which
use ktls),
they acted like things were ok (no handshake problems), but the data
ended up on the wire unencrypted (nfs-over-tls doesn't do a
SSL_write(),
so it depends on ktls to do the encryption).

Since these daemons work fine with openssl3 in
ports/security/openssl-devel,
I suspect the ktls backport is not quite right. I've sent jhb@ email.

I was wrong on the above. I did a full buildworld/installworld and
the daemons
now seem to work with the openssl in head/main.

Btw, did anyone try rebuilding svn from sources after doing
the system upgrade?
(The openssl library calls and .h files definitely changed.)


Yes, I did, on all boxes and its a pain in the a..., we had to rebuild
EVERY port (at
least, I did, to avoid further problem). Yesterday, on of our fastes
boxes got ready and
even with a full rebuild of the system AND a full rebuild of the ports
(no poudriere,
traditional way via make), the Apache 2.4 webservice doesn't work, and
so does subversion
not (Firefox reports problems with SSL handshake, subversion is
stuck/frozen forever).
I will run today another full world build today, hopefully finishing
on friday (portmaster
-dfR doesn't get everything in line on some ports, I assume).

oh


I tracked the subversion hang down to a bug in serf (an Apache library
used by
subversion).  It would also affect any other software using serf.  The
serf in
ports will also have to be patched.
   


I submitted your patch as a bug report to the serf port:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253214



What is the status of this bug?
As PR 253214 might suggest, the patch to www/serf has been commited. We still 
face a
problem with FreeBSD CURRENT-14 based systems running Apache24:

FreeBSD 14.0-CURRENT #4 main-n244672-866c8b8d5dd: Mon Feb  8 08:38:59 CET 2021 
amd64

/usr/ports is at Revision: 564736.

www/apache24, www/serf have been rebuilt using "portmaster -f www/apache24 
www/serf".

Restarting Apache 2.4 still fails on any access with SSL enabled, firefox 
reports:

SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT


This is the first report I've had after the serf update.

Here's an untested patch that is similar to the serf bug.  You would
apply this in the www/apache24 port.

Index: files/patch-modules_ssl_ssl__engine__io.c
===
--- files/patch-modules_ssl_ssl__engine__io.c   (nonexistent)
+++ files/patch-modules_ssl_ssl__engine__io.c   (working copy)
@@ -0,0 +1,11 @@
+--- modules/ssl/ssl_engine_io.c.orig   2021-02-09 15:09:39.362123000 -0800
 modules/ssl/ssl_engine_io.c2021-02-09 15:12:13.59669 -0800
+@@ -542,7 +542,7 @@ static int bio_filter_in_gets(BIO *bio, char *buf, int
+
+ static long bio_filter_in_ctrl(BIO *bio, int cmd, long num, void *ptr)
+ {
+-return -1;
++return 0;
+ }
+
+ #if MODSSL_USE_OPENSSL_PRE_1_1_API

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

[PACTH,libm] hypothl(x) mishandles subnormal numbers.

[Steve Kargl]

On Sat, Feb 06, 2021 at 10:32:33PM +0100, Dimitry Andric wrote:
> On 6 Feb 2021, at 22:04, Steve Kargl  
> wrote:
> > 
> > On Sat, Feb 06, 2021 at 12:39:29PM -0800, Steve Kargl wrote:
> >> I've long forgotten by freebsd bugzilla password.
> >> So, if someone would like to submit a bug report,
> >> here's a test program.
> >> 
> > Forgot to include that issue was identified from
> > a bug report in the OpenLibm bug mailing list.
> > 
> > https://github.com/JuliaMath/openlibm/issues/224
> 
> I put this in . Now the trick is to
> figure out what is going on in e_hypotl.c... :)
> 

This patch fixes the issue.  t1 is used to scale the subnormal
numbers.  It is generated by scaling the exponent, but that 
only works if t1 is 1 not 0.

Index: src/e_hypotl.c
===
--- src/e_hypotl.c  (revision 2342)
+++ src/e_hypotl.c  (working copy)
@@ -82,7 +82,7 @@ hypotl(long double x, long double y)
man_t manh, manl;
GET_LDBL_MAN(manh,manl,b);
if((manh|manl)==0) return a;
-   t1=0;
+   t1=1;
SET_HIGH_WORD(t1,ESW(MAX_EXP-2));   /* t1=2^(MAX_EXP-2) */
b *= t1;
a *= t1;


-- 
Steve
___
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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[Hartmann, O.]

On Wed, 3 Feb 2021 17:34:24 +0100
Guido Falsi via freebsd-current  wrote:

> On 03/02/21 17:02, John Baldwin wrote:
> > On 2/2/21 10:16 PM, Hartmann, O. wrote:  
> >> On Mon, 1 Feb 2021 03:24:45 +
> >> Rick Macklem  wrote:
> >>  
> >>> Rick Macklem wrote:  
>  Guido Falsi wrote:
>  [good stuff snipped]  
> > Performed a full bisect. Tracked it down to commit aa906e2a4957, 
> > adding
> > KTLS support to embedded OpenSSL.
> >
> > I filed a bug report about this:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135
> >
> >
> > Apart from switching to svn:// scheme, another workaround is to build
> > base using WITHOUT_OPENSSL_KTLS.  
>  Just fyi, when I tested the daemons I have for nfs-over-tls (which 
>  use ktls),
>  they acted like things were ok (no handshake problems), but the data
>  ended up on the wire unencrypted (nfs-over-tls doesn't do a 
>  SSL_write(),
>  so it depends on ktls to do the encryption).
> 
>  Since these daemons work fine with openssl3 in 
>  ports/security/openssl-devel,
>  I suspect the ktls backport is not quite right. I've sent jhb@ email.  
> >>> I was wrong on the above. I did a full buildworld/installworld and 
> >>> the daemons
> >>> now seem to work with the openssl in head/main.
> >>>
> >>> Btw, did anyone try rebuilding svn from sources after doing
> >>> the system upgrade?
> >>> (The openssl library calls and .h files definitely changed.)  
> >>
> >> Yes, I did, on all boxes and its a pain in the a..., we had to rebuild 
> >> EVERY port (at
> >> least, I did, to avoid further problem). Yesterday, on of our fastes 
> >> boxes got ready and
> >> even with a full rebuild of the system AND a full rebuild of the ports 
> >> (no poudriere,
> >> traditional way via make), the Apache 2.4 webservice doesn't work, and 
> >> so does subversion
> >> not (Firefox reports problems with SSL handshake, subversion is 
> >> stuck/frozen forever).
> >> I will run today another full world build today, hopefully finishing 
> >> on friday (portmaster
> >> -dfR doesn't get everything in line on some ports, I assume).
> >>
> >> oh  
> > 
> > I tracked the subversion hang down to a bug in serf (an Apache library 
> > used by
> > subversion).  It would also affect any other software using serf.  The 
> > serf in
> > ports will also have to be patched.
> >   
> 
> I submitted your patch as a bug report to the serf port:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253214
> 

What is the status of this bug?
As PR 253214 might suggest, the patch to www/serf has been commited. We still 
face a
problem with FreeBSD CURRENT-14 based systems running Apache24:

FreeBSD 14.0-CURRENT #4 main-n244672-866c8b8d5dd: Mon Feb  8 08:38:59 CET 2021 
amd64

/usr/ports is at Revision: 564736.

www/apache24, www/serf have been rebuilt using "portmaster -f www/apache24 
www/serf".

Restarting Apache 2.4 still fails on any access with SSL enabled, firefox 
reports:

SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT

What am I missing here? What is to be rebuilt? FreeBSD 14-CURRENT has been 
rebuilt from
scratch on the 7th of February, ports have been completely rebuilt after KTLS
introduction and several critical ports as www/serf and www/apache and mod_ 
ports have
been rebuilt afterwards with ports tree revision 564736. Something is still 
missing.

Kind regards and thanks in advance,

oh


pgpBCi0eehNq7.pgp
Description: OpenPGP digital signature

make release broken?

[Michael Butler via freebsd-current]

Any ideas what broke this?


--
>>> Kernel build for GENERIC completed on Tue Feb  9 20:48:05 UTC 2021
--
>>> Kernel(s)  GENERIC built in 465 seconds, ncpu: 8, make -j8
--
make -C /usr/src/release  obj
make -C /usr/src/release  ftp cdrom dvdrom memstick.img mini-memstick.img
`ftp' is up to date.
sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_CD 
disc1.iso disc1
makefs: cd9660_add_boot_disk: lstat("disc1/boot/cdboot"): No such file 
or directory

*** Error code 1

Stop.
make[1]: stopped in /usr/src/release
*** Error code 1

    imb




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

upgrade contrib/dma mail agent?

[Ronald Klop]

Hi,

In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244630 there is a patch to 
upgrade contrib/dma to a more recent version.
I'm also running with this patch locally for a while now.

Is somebody interested in committing this?

Regards,
Ronald.

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

Enable veriexec for 13 Beta 1

[dan_partelly]

Hey guys,

What are the config knobs for enabling the veriexec driver and veriexec 
mac modules for testing and playing with this new subystem ? User mode 
knob for user mode tool and lib is documented in man src.conf 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: Current - kernel dump while plasma loading.

[Santiago Martinez]

Hi Alan, away from the machine, but i can send it tonight (CET).

Cheers

Santiago


On 2/9/21 2:41 PM, Alan Somers wrote:
> On Tue, Feb 9, 2021 at 3:52 AM Santiago Martinez 
> wrote:
>
>> Hi there, this morning i did the usual git pull and make..
>>
>> After reboot and loading the desktop (while starting plasma with drm), i
>> get a kernel dump.
>>
>> This was ok until this morning...
>>
>> This is the info:
>>
>> root@tucho:/var/crash # cat info.last
>> Dump header from device: /dev/ada0p2
>>   Architecture: amd64
>>   Architecture Version: 2
>>   Dump Length: 1381969920
>>   Blocksize: 512
>>   Compression: none
>>   Dumptime: 2021-02-09 10:24:21 +
>>   Hostname: tucho
>>   Magic: FreeBSD Kernel Dump
>>   Version String: FreeBSD 14.0-CURRENT #5 main-n244705-504ebd612ec6: Tue
>> Feb  9 10:20:32 GMT 2021
>> root@tucho:/usr/obj/usr/src/amd64.amd64/sys/TUCHO
>>   Panic String: VERIFY(avl_find(tree, new_node, ) == NULL) failed
>>
>>   Dump Parity: 2603051126
>>   Bounds: 6
>>   Dump Status: good
>>
>>
>> Best regards.
>>
>> Santi
>>
> I can tell you why it was "fine" until this morning.  It's because ZFS
> assertions weren't actually enabled until last night.  So this isn't a
> newly introduced ZFS bug, just a newly noticed one.  Could you please post
> the full stack trace?
> -Alan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



OpenPGP_signature
Description: OpenPGP digital signature

Re: regression in /etc/rc.d/linux

[Yuri Pankov]

Sergey V. Dyatko wrote:

Hi,

Subj was introduced in  e40787f900f3c262d5134d342e5a16757dd2193c

compat.linux.emul_path isn't defined before kldload`ing linux/linux64 kernel.


Looks like it's already fixed:

https://cgit.freebsd.org/src/commit/?id=07cac176fba947381c8111b8e02e8067e7fa542a
___
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"

regression in /etc/rc.d/linux

[Sergey V. Dyatko]

Hi,

Subj was introduced in  e40787f900f3c262d5134d342e5a16757dd2193c

compat.linux.emul_path isn't defined before kldload`ing linux/linux64 kernel. 

diff --git a/libexec/rc/rc.d/linux b/libexec/rc/rc.d/linux
index 4381b62cc660..f44a9d02fc8d 100755
--- a/libexec/rc/rc.d/linux
+++ b/libexec/rc/rc.d/linux
@@ -18,7 +18,6 @@ stop_cmd=":"
 linux_start()
 {
local _emul_path _tmpdir
-   _emul_path="$(sysctl -n compat.linux.emul_path)"
 
load_kld -e 'linux(aout|elf)' linux
case `sysctl -n hw.machine_arch` in
@@ -26,6 +25,9 @@ linux_start()
load_kld -e 'linux64elf' linux64
;;
esac
+
+ _emul_path="$(sysctl -n compat.linux.emul_path)"
+
if [ -x ${_emul_path}/sbin/ldconfigDisabled ]; then
_tmpdir=`mktemp -d -t linux-ldconfig`
${_emul_path}/sbin/ldconfig -C ${_tmpdir}/ld.so.cache

--
wbr, Sergey

___
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: Current - kernel dump while plasma loading.

[Alan Somers]

On Tue, Feb 9, 2021 at 3:52 AM Santiago Martinez 
wrote:

> Hi there, this morning i did the usual git pull and make..
>
> After reboot and loading the desktop (while starting plasma with drm), i
> get a kernel dump.
>
> This was ok until this morning...
>
> This is the info:
>
> root@tucho:/var/crash # cat info.last
> Dump header from device: /dev/ada0p2
>   Architecture: amd64
>   Architecture Version: 2
>   Dump Length: 1381969920
>   Blocksize: 512
>   Compression: none
>   Dumptime: 2021-02-09 10:24:21 +
>   Hostname: tucho
>   Magic: FreeBSD Kernel Dump
>   Version String: FreeBSD 14.0-CURRENT #5 main-n244705-504ebd612ec6: Tue
> Feb  9 10:20:32 GMT 2021
> root@tucho:/usr/obj/usr/src/amd64.amd64/sys/TUCHO
>   Panic String: VERIFY(avl_find(tree, new_node, ) == NULL) failed
>
>   Dump Parity: 2603051126
>   Bounds: 6
>   Dump Status: good
>
>
> Best regards.
>
> Santi
>

I can tell you why it was "fine" until this morning.  It's because ZFS
assertions weren't actually enabled until last night.  So this isn't a
newly introduced ZFS bug, just a newly noticed one.  Could you please post
the full stack trace?
-Alan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Current - kernel dump while plasma loading.

[Santiago Martinez]

Hi there, this morning i did the usual git pull and make..

After reboot and loading the desktop (while starting plasma with drm), i
get a kernel dump.

This was ok until this morning...

This is the info:

root@tucho:/var/crash # cat info.last
Dump header from device: /dev/ada0p2
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 1381969920
  Blocksize: 512
  Compression: none
  Dumptime: 2021-02-09 10:24:21 +
  Hostname: tucho
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 14.0-CURRENT #5 main-n244705-504ebd612ec6: Tue
Feb  9 10:20:32 GMT 2021
    root@tucho:/usr/obj/usr/src/amd64.amd64/sys/TUCHO
  Panic String: VERIFY(avl_find(tree, new_node, ) == NULL) failed

  Dump Parity: 2603051126
  Bounds: 6
  Dump Status: good


Best regards.

Santi





OpenPGP_signature
Description: OpenPGP digital signature