From owner-freebsd-current@freebsd.org Sun Jan 31 18:44:23 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 45617522777 for ; Sun, 31 Jan 2021 18:44:23 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DTKjx63wrz4ShR for ; Sun, 31 Jan 2021 18:44:21 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4DTKjp2xfwz6dWw; Sun, 31 Jan 2021 19:44:14 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id P8TWsOKPJ1n8; Sun, 31 Jan 2021 19:44:12 +0100 (CET) Subject: Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports? To: "Hartmann, O." , FreeBSD CURRENT Cc: junchoon@dec.sakura.ne.jp References: <20210130073923.0b2a80c1@hermann.fritz.box> <20210130192520.e7cf7f680c0abd31b0771107@dec.sakura.ne.jp> <18e15d74-d95b-76b7-59a4-64a8f338ba73@madpilot.net> <20210131103510.30d9a322@hermann.fritz.box> From: Guido Falsi Message-ID: <86a368dc-f118-79fb-2ed8-af461041198a@madpilot.net> Date: Sun, 31 Jan 2021 19:44:11 +0100 In-Reply-To: <20210131103510.30d9a322@hermann.fritz.box> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4DTKjx63wrz4ShR X-Spamd-Bar: / X-Spamd-Result: default: False [-0.99 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[159.69.1.99:from]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MISSING_MIME_VERSION(2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; SPAMHAUS_ZRD(0.00)[159.69.1.99:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 18:44:23 -0000 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