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. Kind regards, oh
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC