From owner-freebsd-current@freebsd.org Sat Jan 30 15:22:55 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 E08144F0456 for ; Sat, 30 Jan 2021 15:22:55 +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 4DSdHz02wBz4gZs for ; Sat, 30 Jan 2021 15:22:54 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4DSdHx1cPJz6dWw; Sat, 30 Jan 2021 16:22:53 +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 wbtkBbpur7z3; Sat, 30 Jan 2021 16:22:51 +0100 (CET) Subject: Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports? To: junchoon@dec.sakura.ne.jp, freebsd-current@freebsd.org References: <20210130073923.0b2a80c1@hermann.fritz.box> <20210130192520.e7cf7f680c0abd31b0771107@dec.sakura.ne.jp> <18e15d74-d95b-76b7-59a4-64a8f338ba73@madpilot.net> From: Guido Falsi Message-ID: Date: Sat, 30 Jan 2021 16:22:50 +0100 In-Reply-To: <18e15d74-d95b-76b7-59a4-64a8f338ba73@madpilot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4DSdHz02wBz4gZs X-Spamd-Bar: - X-Spamd-Result: default: False [-1.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[159.69.1.99:from]; MISSING_MIME_VERSION(2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; 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:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-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: Sat, 30 Jan 2021 15:22:55 -0000 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