Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 2/11/21 9:59 AM, Hartmann, O. wrote:
On Wed, 10 Feb 2021 07:21:20 +0100
"Hartmann, O." wrote:
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
I tried the patch, it doesn't work.
Assuming that it is sufficient to recompile from scratch/clean tree the whole
OS and then
recompile every port required by www/apach24, applying then the patch, I tried
to connect
to pages served by the 14-CURRENT server running the pacthed Apache 2.4 (ports
tree at
the most recent state at that time), I still get the error described above.
Kind regards,
oh
I finally reproduced this today and was able to at least get a valid response
back
from the server using openssl s_client as the client with a larger version of
this
patch.
You can find the full patch at https://reviews.freebsd.org/D28932
--
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"
Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On Wed, 10 Feb 2021 07:21:20 +0100
"Hartmann, O." wrote:
> 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
I tried the patch, it doesn't work.
Assuming that it is sufficient to recompile from
Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
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"
Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
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
Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
___ 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?
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 -- Guido Falsi ___ 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?
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. -- 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"
Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
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. Both *cd /usr/src/usr.bin/svn ; make clean ; make ; make install *Rebuild whole base OS after (each twice to be sure) make clean make cleandepend make cleandir didn't help. Only rebuilding WITHOUT_OPENSSL_KTLS=yes in /etc/src.conf in conjunction with WITHOUT_CLEAN=yes helped. Regards. > > rick > > rick > > -- > Guido Falsi > ___ > 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" > ___ > 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" -- Tomoaki AOKI ___ 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?
On 03/02/21 07:16, 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). Ass I said a confirmed woraround is building world with WITHOUT_OPENSSL_KTLS defined. -- Guido Falsi ___ 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?
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 > > rick > > rick > > -- > Guido Falsi > ___ > 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" > ___ > 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" pgpWSTdd57lVc.pgp Description: OpenPGP digital signature
Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 01/02/21 04:24, 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.) The problem happens with svnlite from base, which should have been rebuilt and reinstalled with the system upgrade. I also tested with ports svn which I did rebuild in poudriere and force reinstalled. So, actually yes I did rebuild it, but I could force a new rebuild just to be sure. -- Guido Falsi ___ 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?
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.) rick rick -- Guido Falsi ___ 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" ___ 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?
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. rick -- Guido Falsi ___ 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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 31/01/21 10:35, Hartmann, O. wrote: On Sat, 30 Jan 2021 16:22:50 +0100 Guido Falsi via freebsd-current wrote: On 30/01/21 12:34, Guido Falsi via freebsd-current wrote: On 30/01/21 11:25, Tomoaki AOKI wrote: On Sat, 30 Jan 2021 07:39:23 +0100 "Hartmann, O." wrote: We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann +1. IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not. Unfortunately, I currently don't have enough time to bisect further. :-( I'm running 07d218f70c2f and it is affected, this restricts the range slightly more. I tried bisecting the kernel only between d6327ae8c11b and 07d218f70c2f, but got no results. Looks like the problem is not in the kernel but somewhere else (libc? ssl?) Bisecting the whole system is going to take longer. I'll try to find the time. We also have running a 14-CURRENT-based webserver with www/apach24. After upgrading from an earlier (working) 14-CURRENT (FreeBSD 14.0-CURRENT #40 main-c256208-geb61de5b787: Fri Jan 22 16:28:09 CET 2021 amd64), the reported phenomenon took place. I also have to admit that after main-c256208-geb61de5b787, the whole system has been rebuilt from a clean /usr/src (otherwise we use -DNO_CLEAN or its WITHOUT_CLEAN equivalent). Hopefully that helps. 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. -- Guido Falsi ___ 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?
On Sat, 30 Jan 2021 16:22:50 +0100 Guido Falsi via freebsd-current wrote: > On 30/01/21 12:34, Guido Falsi via freebsd-current wrote: > > On 30/01/21 11:25, Tomoaki AOKI wrote: > >> On Sat, 30 Jan 2021 07:39:23 +0100 > >> "Hartmann, O." wrote: > >> > >>> We recently updated to FreeBSD 14.0-CURRENT #9 > >>> main-n244517-f17fc5439f5: Fri Jan 29 > >>> 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, > >>> the command > >>> > >>> make update > >>> > >>> issued in /usr/ports on those 14-CURRENT boxes remains stuck forever > >>> or it is working > >>> like a snail! > >>> Hitting Ctrl-t on the console gives: > >>> > >>> load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k > >>> mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 > >>> _sleep+0x188 > >>> kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd > >>> sys_kevent+0x61 > >>> amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: > >>> /usr/ports > >>> > >>> > >>> The system is idle otherwise. > >>> > >>> How can this be resolved? Is this phenomenon known? > >>> > >>> Kind regards and thank you very much in advance, > >>> > >>> O. Hartmann > >>> > >> > >> +1. > >> IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not. > >> > >> Unfortunately, I currently don't have enough time to bisect > >> further. :-( > > > > I'm running 07d218f70c2f and it is affected, this restricts the range > > slightly more. > > > > I tried bisecting the kernel only between d6327ae8c11b and 07d218f70c2f, > but got no results. > > Looks like the problem is not in the kernel but somewhere else (libc? ssl?) > > Bisecting the whole system is going to take longer. I'll try to find the > time. > We also have running a 14-CURRENT-based webserver with www/apach24. After upgrading from an earlier (working) 14-CURRENT (FreeBSD 14.0-CURRENT #40 main-c256208-geb61de5b787: Fri Jan 22 16:28:09 CET 2021 amd64), the reported phenomenon took place. I also have to admit that after main-c256208-geb61de5b787, the whole system has been rebuilt from a clean /usr/src (otherwise we use -DNO_CLEAN or its WITHOUT_CLEAN equivalent). Hopefully that helps. Kind regards, oh pgpPZmVwgXoWt.pgp Description: OpenPGP digital signature
Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 30/01/21 12:34, Guido Falsi via freebsd-current wrote: On 30/01/21 11:25, Tomoaki AOKI wrote: On Sat, 30 Jan 2021 07:39:23 +0100 "Hartmann, O." wrote: We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann +1. IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not. Unfortunately, I currently don't have enough time to bisect further. :-( I'm running 07d218f70c2f and it is affected, this restricts the range slightly more. I tried bisecting the kernel only between d6327ae8c11b and 07d218f70c2f, but got no results. Looks like the problem is not in the kernel but somewhere else (libc? ssl?) Bisecting the whole system is going to take longer. I'll try to find the time. -- Guido Falsi ___ 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?
On 30/01/21 11:25, Tomoaki AOKI wrote: On Sat, 30 Jan 2021 07:39:23 +0100 "Hartmann, O." wrote: We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann +1. IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not. Unfortunately, I currently don't have enough time to bisect further. :-( I'm running 07d218f70c2f and it is affected, this restricts the range slightly more. -- Guido Falsi ___ 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?
On Sat, 30 Jan 2021 07:39:23 +0100 "Hartmann, O." wrote: > We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri > Jan 29 > 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the > command > > make update > > issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is > working > like a snail! > Hitting Ctrl-t on the console gives: > > load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k > mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 > _sleep+0x188 > kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd > sys_kevent+0x61 > amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports > > > The system is idle otherwise. > > How can this be resolved? Is this phenomenon known? > > Kind regards and thank you very much in advance, > > O. Hartmann > +1. IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not. Unfortunately, I currently don't have enough time to bisect further. :-( As stable/13 is OK via https at 76dd854f47f4, so it wouldn't be a server-side problem. Regards. -- Tomoaki AOKI ___ 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?
On 30/01/21 07:39, Hartmann, O. wrote: We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? I'm seeing similar behaviour. Switching to the svn:// scheme was a successful workaround. -- Guido Falsi ___ 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"
(n244517-f17fc5439f5) svn stuck forever in /usr/ports?
We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann pgpOHXqEHBAI8.pgp Description: OpenPGP digital signature
(n244517-f17fc5439f5) svn stuck forever in /usr/ports?
We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann pgpin0lvgx68o.pgp Description: OpenPGP digital signature
