From owner-freebsd-current@freebsd.org Sat Jan 30 10:25:32 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 7E6994E50F4 for ; Sat, 30 Jan 2021 10:25:32 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4DSVhp4qDbz3jCS for ; Sat, 30 Jan 2021 10:25:29 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (115-38-187-204.shizuoka1.commufa.jp [115.38.187.204]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 10UAPLlR078121 for ; Sat, 30 Jan 2021 19:25:21 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 30 Jan 2021 19:25:20 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports? Message-Id: <20210130192520.e7cf7f680c0abd31b0771107@dec.sakura.ne.jp> In-Reply-To: <20210130073923.0b2a80c1@hermann.fritz.box> References: <20210130073923.0b2a80c1@hermann.fritz.box> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DSVhp4qDbz3jCS X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [1.41 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.990]; RECEIVED_SPAMHAUS_PBL(0.00)[115.38.187.204:received]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[153.125.133.21:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[153.125.133.21:from:127.0.2.255]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; 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 10:25:32 -0000 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