Date: Sun, 7 Mar 2021 14:25:45 -0600 From: Kyle Evans <kevans@freebsd.org> To: Yasuhiro Kimura <yasu@utahime.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Waiting for bufdaemon Message-ID: <CACNAnaEPJftb_1Jg94zpR4AoU5TKEjbXuYcAA0ByUmL0=hPQCg@mail.gmail.com> In-Reply-To: <20210306.185955.1096959917131550098.yasu@utahime.org> References: <20210305.160311.867123118349124334.yasu@utahime.org> <YEKYDlPuvn6TL4xs@kib.kiev.ua> <20210306.083323.1112779300812727243.yasu@utahime.org> <20210306005643.45feb56d@bsd64.grem.de> <DDC414A9-108B-43F1-A8FC-1DE22393A386@yahoo.com> <8a549830a3087998c1e2f80a5fb58199@bsdforge.com> <20210306.185955.1096959917131550098.yasu@utahime.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 6, 2021 at 4:02 AM Yasuhiro Kimura <yasu@utahime.org> wrote: > > From: Yasuhiro Kimura <yasu@utahime.org> > Subject: Re: Waiting for bufdaemon > Date: Sat, 06 Mar 2021 08:33:23 +0900 (JST) > > >> My belief is that this commit helps more users than it hurts. Namely, > >> the VMWare and KVM users, which are majority, use fast timecounter, > >> comparing to the more niche hypervisors like VirtualBox. > >> > >> For you, a simple but manual workaround, setting the timecounter to > >> ACPI (?) or might be HPET, with a loader tunable, should do it. > > > > Then please let me know the name of it. > > From: Michael Gmelin <freebsd@grem.de> > Subject: Re: Waiting for bufdaemon > Date: Sat, 6 Mar 2021 00:56:43 +0100 > > > see `man 4 timecounters': > > > > https://www.freebsd.org/cgi/man.cgi?query=timecounters > > From: Mark Millard via freebsd-current <freebsd-current@freebsd.org> > Subject: Re: Waiting for bufdaemon > Date: Fri, 5 Mar 2021 17:35:14 -0800 > > > Its somewhat messy but there is a technique of using > > the "timecounter" in kib's wording to explore: > ... > > From: Chris <bsd-lists@bsdforge.com> > Subject: Re: Waiting for bufdaemon > Date: Fri, 05 Mar 2021 18:54:05 -0800 > > > Not exactly what you're asking for. But sysctl sysctl(3) and loader(8) > > will provide some good clues. > > Thank you for reply. > > On the system in question 'kern.timecounter.choice' and > 'kern.timecounter.hardware' tunables have following values. > > ---------------------------------------------------------------------- > yasu@rolling-vm-freebsd1[1002]% sysctl kern.timecounter.choice > kern.timecounter.choice: ACPI-fast(900) i8254(0) TSC-low(-100) dummy(-1000000) > yasu@rolling-vm-freebsd1[1003]% sysctl kern.timecounter.hardware > kern.timecounter.hardware: ACPI-fast > yasu@rolling-vm-freebsd1[1004]% > ---------------------------------------------------------------------- > > So I tried setting the latter to 'i8254', 'TSC-low' and 'dummy', and > checked if the problem disappear. But unfortunately it still happened. > On the contrary changing the value from default made thing worse. > If it is set to either 'i8254' or 'TSC-low', timeout of bufdaemon also > happens when I shutdown the system just after bootstrap is completed. > And if it is set to 'dummy', the sytem hung up in the middle of > bootstrap. > > So setting 'kern.timecounter.hardware' tunable doesn't work in my > case. Then is there any way to try? I'm going to be pedantic here, but note that this isn't a tunable. You cannot, AFAIK, influence the timecounter chosen with kenv; it has to be set post-boot via sysctl, and if you're really unlucky it could be that bufdaemon wedges before you manage to change it (though it seems unlikely). I've had some success with setting it to ACPI-fast in sysctl.conf here.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEPJftb_1Jg94zpR4AoU5TKEjbXuYcAA0ByUmL0=hPQCg>