On 31/01/21 10:35, Hartmann, O. wrote: > On Sat, 30 Jan 2021 16:22:50 +0100 > Guido Falsi via freebsd-current <freebsd-current_at_freebsd.org> 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." <ohartmann_at_walstatt.org> 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 <mad_at_madpilot.net>Received on Sun Jan 31 2021 - 17:44:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC