Re: Waiting for bufdaemon
From: Kyle Evans
Subject: Re: Waiting for bufdaemon
Date: Mon, 8 Mar 2021 11:07:23 -0600
> I've tried tracking down exactly what the problem is that causes the
> symptoms we're seeing, but no luck so far. I'm eyeballing the
> following patch which partially reverts kib's 84eaf2ccc6aa05 ("x86:
> stop punishing VMs with low priority for TSC timecounter") and only
> punishes VirtualBox guests.
>
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 68fc57e6ea7..6f25360a67c 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -501,7 +501,12 @@ test_tsc(int adj_max_count)
> uint64_t *data, *tsc;
> u_int i, size, adj;
>
> - if ((!smp_tsc && !tsc_is_invariant) || vm_guest)
> + /*
> +* Misbehavior of TSC under VirtualBox has been observed. In
> +* particular, threads doing small (~1 second) sleeps may miss their
> +* wakeup and hang around in sleep state, causing hangs on shutdown.
> +*/
> + if ((!smp_tsc && !tsc_is_invariant) || vm_guest == VM_GUEST_VBOX)
> return (-100);
> size = (mp_maxid + 1) * 3;
> data = malloc(sizeof(*data) * size * N, M_TEMP, M_WAITOK);
After updating to 6ffdaa5f2d4, I confirmed timeout of bufdaemon
dosen't happen even if I don't set kern.timecounter.hardware at all in
loader.conf.
Thank you for fixing the problem.
---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Mon, 8 Mar 2021 at 12:07, Kyle Evans wrote: > > diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c > index 68fc57e6ea7..6f25360a67c 100644 > --- a/sys/x86/x86/tsc.c > +++ b/sys/x86/x86/tsc.c > @@ -501,7 +501,12 @@ test_tsc(int adj_max_count) > uint64_t *data, *tsc; > u_int i, size, adj; > > - if ((!smp_tsc && !tsc_is_invariant) || vm_guest) > + /* > +* Misbehavior of TSC under VirtualBox has been observed. In > +* particular, threads doing small (~1 second) sleeps may miss their > +* wakeup and hang around in sleep state, causing hangs on shutdown. > +*/ > + if ((!smp_tsc && !tsc_is_invariant) || vm_guest == VM_GUEST_VBOX) > return (-100); > size = (mp_maxid + 1) * 3; > data = malloc(sizeof(*data) * size * N, M_TEMP, M_WAITOK); This seems like a sensible change to me. To make it explicilty clear what the comment/workaround applies to, maybe rewrite it as: if (!smp_tsc && !tsc_is_invariant) return (-100); /* * Misbehavior of TSC under VirtualBox has been observed. In * particular, threads doing small (~1 second) sleeps may miss their * wakeup and hang around in sleep state, causing hangs on shutdown. */ if (vm_guest == VM_GUEST_VBOX) return (-100); ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Mon, Mar 8, 2021 at 10:51 AM Yasuhiro Kimura wrote:
>
> From: Yasuhiro Kimura
> Subject: Re: Waiting for bufdaemon
> Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST)
>
> > But still one question remains. Why have the value of
> > kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter
> > changed by applying the patch? My understanding is that it only makes
> > 'kern.timecounter.hardware' loader tunable that can be configured with
> > loader.conf. Is it unexpected side effect? Or is everything expected
> > result?
>
> Oops, I made a mistake.
>
> > If I do it with unpatched kernel, I get following result.
>
> This isn't correct. I did it with reverted kernel (i.e. 705d06b289e of
> main + revert of 84eaf2ccc6a). If I do it with really unpatch kernel,
> I get same result as patched one.
>
> Sorry for noise.
>
I've tried tracking down exactly what the problem is that causes the
symptoms we're seeing, but no luck so far. I'm eyeballing the
following patch which partially reverts kib's 84eaf2ccc6aa05 ("x86:
stop punishing VMs with low priority for TSC timecounter") and only
punishes VirtualBox guests.
diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
index 68fc57e6ea7..6f25360a67c 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -501,7 +501,12 @@ test_tsc(int adj_max_count)
uint64_t *data, *tsc;
u_int i, size, adj;
- if ((!smp_tsc && !tsc_is_invariant) || vm_guest)
+ /*
+* Misbehavior of TSC under VirtualBox has been observed. In
+* particular, threads doing small (~1 second) sleeps may miss their
+* wakeup and hang around in sleep state, causing hangs on shutdown.
+*/
+ if ((!smp_tsc && !tsc_is_invariant) || vm_guest == VM_GUEST_VBOX)
return (-100);
size = (mp_maxid + 1) * 3;
data = malloc(sizeof(*data) * size * N, M_TEMP, M_WAITOK);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST) > But still one question remains. Why have the value of > kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter > changed by applying the patch? My understanding is that it only makes > 'kern.timecounter.hardware' loader tunable that can be configured with > loader.conf. Is it unexpected side effect? Or is everything expected > result? Oops, I made a mistake. > If I do it with unpatched kernel, I get following result. This isn't correct. I did it with reverted kernel (i.e. 705d06b289e of main + revert of 84eaf2ccc6a). If I do it with really unpatch kernel, I get same result as patched one. Sorry for noise. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
From: Konstantin Belousov Subject: Re: Waiting for bufdaemon Date: Mon, 8 Mar 2021 02:03:13 +0200 > On Sun, Mar 07, 2021 at 02:25:45PM -0600, Kyle Evans wrote: >> 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. > Right, I forgot that timecounter.hardware is not tunable, I thought that > it was fixed. > > https://reviews.freebsd.org/D29122 I applied the patch of D29122 to 705d06b289e of main, do `make kernel` and reboot. Then I tried the test that consists of following 6 steps. 1. Edit /boot/loader.conf.local 2. shutdow -r now 3. Login as root 4. cd /usr/src 5. make -j 4 -s buildworld 6. shutdown -r now Though I didn't intend it at first, I repeated this test 3 times changing how /boot/loader.conf.local was edited at step 1. And I got the result that was surprising and confusing, at least for me. At first trial I changed /boot/loader.conf.local so it includes 'kern.timecounter.hardware=i8254' in it. Then timeout of bufdaemon didn't happen at step 6. This means adding the line works as workaound for the problem. Next I replaced 'kern.timecounter.hardware=i8254' with 'kern.timecounter.hardware=ACPI-fast'and did test. As I wrote previous mail, 'ACPI-fast' is the initial value of kern.timecounter.hardware on the system in question. So I tried it for comparison purpose expecting the problem happens. But the result is unexpected one. Timeout of bufdaemon didn't happen at step 6 with this case either. So tried yet another case. I removed 'kern.timecounter.hardware=ACPI-fast' from /boot/loader.conf.local and did test again. In this case 'kern.timecounter.hardware' isn't touched at all. So the result should have been same as 2nd case. But it was different. Timeout of bufdeamon happend at step 6 in this case. The result surprised and confused me with following 2 points. (a) Setting initial value (2nd case) should be same as not touching at all (3rd case). But actually they caused different results. (b) 2nd case should have caused same result as one without patch. But actually it caused different one. I found the reason when I execute `sysctl kernel.timecount` and checked the output. If I do it with unpatched kernel, I get following result. -- yasu@rolling-vm-freebsd1[1005]% sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) i8254(0) TSC-low(-100) dummy(-100) kern.timecounter.hardware: ACPI-fast kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 1311282421 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 9931 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: -100 kern.timecounter.tc.TSC-low.frequency: 1500035122 kern.timecounter.tc.TSC-low.counter: 4026452692 kern.timecounter.tc.TSC-low.mask: 4294967295 yasu@rolling-vm-freebsd1[1006]% -- But if I do it with patched kernel, I get a bit different one. -- yasu@rolling-vm-freebsd1[1001]% sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) i8254(0) TSC-low(1000) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 401131388 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 9975 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1500035491 kern.timecounter.tc.TSC-low.counter: 581590125 kern.timecounter.tc.TSC-low.mask: 4294967295 yasu@rolling-vm-freebsd1[1002]% -- Comparing
Re: Waiting for bufdaemon
On Sun, Mar 07, 2021 at 02:25:45PM -0600, Kyle Evans wrote: > 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. Right, I forgot that timecounter.hardware is not tunable, I thought that it was fixed. https://reviews.freebsd.org/D29122 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 2021-Mar-5, at 17:35, Mark Millard wrote: > Yasuhiro Kimura yasu at utahime.org wrote on > Fri Mar 5 23:34:59 UTC 2021 : > >> From: Konstantin Belousov >> Subject: Re: Waiting for bufdaemon >> Date: Fri, 5 Mar 2021 22:43:58 +0200 >> >>> 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. >> >> I have experienced same situation several time. That is, I faced a >> problem and asked for it on ML. Then I was told to try some tunable. >> So I thought there may be tunable that can be used as workaround in >> this case. But for those who isn't familiar with kernel internal, it >> it quite hard to find it without knowing its name. If all tunable were >> listed with brief explanation in one document, then I saw it and could >> pick up possible candidates. But actually they are documented >> separately among many man pages. So the first difficulty is to find >> man page in which possible tunable may be explained. If the problem is >> releted to some device, it is most hopeful to check its man page. But >> in this case, even after reading the commit message, I had no idea >> which man page to check. > > Its somewhat messy but there is a technique of using > the "timecounter" in kib's wording to explore: > > # sysctl -a | grep -i timecounter > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) TSC-low(1000) > dummy(-100) > kern.timecounter.hardware: TSC-low > kern.timecounter.alloweddeviation: 5 > kern.timecounter.timehands_count: 2 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 3054367693 > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 43913 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.counter: 3575335307 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.tc.TSC-low.frequency: 1696849832 > kern.timecounter.tc.TSC-low.counter: 590106679 > kern.timecounter.tc.TSC-low.mask: 4294967295 > > Given the references to ACPI and HPET in kib's > wording, notable seems to be (from one of my > contexts): > > kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) TSC-low(1000) > dummy(-100) > kern.timecounter.hardware: TSC-low > > The descriptions of those two look like: > > # sysctl -ad kern.timecounter.choice kern.timecounter.hardware > kern.timecounter.choice: Timecounter hardware detected > kern.timecounter.hardware: Timecounter hardware selected > > The "selected" wording suggests that kern.timecounter.hardware > might be able to be assigned --and kib's wording would imply > that it can be. > > Looking at the descriptions without also looking at the > values need not be clear: > > # sysctl -ad | grep -i timecounter > kern.timecounter: > kern.timecounter.tsc_shift: Shift to pre-apply for the maximum TSC frequency > kern.timecounter.smp_tsc_adjust: Try to adjust TSC on APs to match BSP > kern.timecounter.smp_tsc: Indicates whether the TSC is safe to use in SMP mode > kern.timecounter.invariant_tsc: Indicates whether the TSC is P-state invariant > kern.timecounter.fast_gettime: Enable fast time of day > kern.timecounter.tick: Approximate number of hardclock ticks in a millisecond > kern.timecounter.choice: Timecounter hardware detected > kern.timecounter.hardware: Timecounter hardware selected > kern.timecounter.alloweddeviation: Allowed time interval deviation in percents > kern.timecounter.timehands_count: Count of timehands in rotation > kern.timecounter.stepwarnings: Log time steps > kern.timecounter.tc: > kern.timecounter.tc.ACPI-fast: timecounter description > kern.timecounter.tc.ACPI-fast.quality: goodness of time counter > kern.timecounter.tc.ACPI-fast.frequency: timecounter frequency > kern.timecounter.tc.ACPI-fast.counter:
Re: Waiting for bufdaemon
On Sat, Mar 6, 2021 at 4:02 AM Yasuhiro Kimura wrote: > > From: Yasuhiro Kimura > 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 > 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 > 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 > 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(-100) > 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Alexander Leidinger Alexander at leidinger.net wrote on Sat Mar 6 10:47:29 UTC 2021 : > Quoting Konstantin Belousov (from Fri, 5 Mar > 2021 22:43:58 +0200): > . . . > > For you, a simple but manual workaround, setting the timecounter to > > ACPI (?) or might be HPET, with a loader tunable, should do it. > > > Do you propose this to him as a test if this solves the issue with the > intend to change the code to use a more suitable TC if VirtualBox is > detected? Turns out to not matter: Yasuhiro reported that all the kern.timecounter.choice alternatives [ACPI-fast(900) i8254(0) TSC-low(-100) dummy(-100)] failed to make a usable environment. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Quoting Konstantin Belousov (from Fri, 5 Mar 2021 22:43:58 +0200): On Fri, Mar 05, 2021 at 04:03:11PM +0900, Yasuhiro Kimura wrote: Dear src committers, From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) >>> I have been experiencing same problem with my 13-CURRENT amd64 >>> VirtualBox VM for about a month. The conditions that the problem >>> happens are unclear and all what I can say is >>> >>> * It happens only after I login in the VM and do something for a >>> while. If I boot the VM and shut it down immediately, it never >>> happens. >>> * When the problem happens, one or more unkillable processes seem to >>> be left. >> >> CPU of my host is not AMD but Intel. According to the >> /var/run/dmesg.boot of VM, information of CPU is as following. >> >> CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) >> Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 >> Features=0x1783fbff >> Features2=0x5eda2203 >> AMD Features=0x28100800 >> AMD Features2=0x121 >> Structured Extended Features=0x842421 >> Structured Extended Features3=0x3400 >> IA32_ARCH_CAPS=0x29 >> TSC: P-state invariant >> >> Just FYI. > > It took for a while to investigate, but according to the result of > bisect following commit is the source of problem in my case. > > -- > commit 84eaf2ccc6a > Author: Konstantin Belousov > Date: Mon Dec 21 19:02:31 2020 +0200 > > x86: stop punishing VMs with low priority for TSC timecounter > > I suspect that virtualization techniques improved from the time when we > have to effectively disable TSC use in VM. For instance, it was reported > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > FreeBSD is groundlessly slow on AWS with some loads. > > Remove the check and start watching for complaints. > > Reviewed by:emaste, grehan > Discussed with: cperciva > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27629 > -- > > I confirmed the problem still happens with 5c325977b11 but reverting > above commit fixes it. Would someone please revert above commit from main, stable/13 and releng/13.0? As I wrote previous mail I submitted this problem to Bugzilla as bug 253087 and added the committer to Cc. But there is no response for 34 days. I confirmed the problem still happens with 37cd6c20dbc of main and 13.0-RC1. 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. Do you propose this to him as a test if this solves the issue with the intend to change the code to use a more suitable TC if VirtualBox is detected? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpZtn2nb4T4U.pgp Description: Digitale PGP-Signatur
Re: Waiting for bufdaemon
From: Yasuhiro Kimura 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 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 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 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(-100) 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? --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 2021-03-05 15:33, Yasuhiro Kimura wrote: From: Konstantin Belousov Subject: Re: Waiting for bufdaemon Date: Fri, 5 Mar 2021 22:43:58 +0200 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. I have experienced same situation several time. That is, I faced a problem and asked for it on ML. Then I was told to try some tunable. So I thought there may be tunable that can be used as workaround in this case. But for those who isn't familiar with kernel internal, it it quite hard to find it without knowing its name. If all tunable were listed with brief explanation in one document, then I saw it and could pick up possible candidates. Not exactly what you're asking for. But sysctl sysctl(3) and loader(8) will provide some good clues. HTH --Chris But actually they are documented separately among many man pages. So the first difficulty is to find man page in which possible tunable may be explained. If the problem is releted to some device, it is most hopeful to check its man page. But in this case, even after reading the commit message, I had no idea which man page to check. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Yasuhiro Kimura yasu at utahime.org wrote on Fri Mar 5 23:34:59 UTC 2021 : > From: Konstantin Belousov > Subject: Re: Waiting for bufdaemon > Date: Fri, 5 Mar 2021 22:43:58 +0200 > > > 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. > > I have experienced same situation several time. That is, I faced a > problem and asked for it on ML. Then I was told to try some tunable. > So I thought there may be tunable that can be used as workaround in > this case. But for those who isn't familiar with kernel internal, it > it quite hard to find it without knowing its name. If all tunable were > listed with brief explanation in one document, then I saw it and could > pick up possible candidates. But actually they are documented > separately among many man pages. So the first difficulty is to find > man page in which possible tunable may be explained. If the problem is > releted to some device, it is most hopeful to check its man page. But > in this case, even after reading the commit message, I had no idea > which man page to check. Its somewhat messy but there is a technique of using the "timecounter" in kib's wording to explore: # sysctl -a | grep -i timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) TSC-low(1000) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 3054367693 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 43913 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 3575335307 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1696849832 kern.timecounter.tc.TSC-low.counter: 590106679 kern.timecounter.tc.TSC-low.mask: 4294967295 Given the references to ACPI and HPET in kib's wording, notable seems to be (from one of my contexts): kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) TSC-low(1000) dummy(-100) kern.timecounter.hardware: TSC-low The descriptions of those two look like: # sysctl -ad kern.timecounter.choice kern.timecounter.hardware kern.timecounter.choice: Timecounter hardware detected kern.timecounter.hardware: Timecounter hardware selected The "selected" wording suggests that kern.timecounter.hardware might be able to be assigned --and kib's wording would imply that it can be. Looking at the descriptions without also looking at the values need not be clear: # sysctl -ad | grep -i timecounter kern.timecounter: kern.timecounter.tsc_shift: Shift to pre-apply for the maximum TSC frequency kern.timecounter.smp_tsc_adjust: Try to adjust TSC on APs to match BSP kern.timecounter.smp_tsc: Indicates whether the TSC is safe to use in SMP mode kern.timecounter.invariant_tsc: Indicates whether the TSC is P-state invariant kern.timecounter.fast_gettime: Enable fast time of day kern.timecounter.tick: Approximate number of hardclock ticks in a millisecond kern.timecounter.choice: Timecounter hardware detected kern.timecounter.hardware: Timecounter hardware selected kern.timecounter.alloweddeviation: Allowed time interval deviation in percents kern.timecounter.timehands_count: Count of timehands in rotation kern.timecounter.stepwarnings: Log time steps kern.timecounter.tc: kern.timecounter.tc.ACPI-fast: timecounter description kern.timecounter.tc.ACPI-fast.quality: goodness of time counter kern.timecounter.tc.ACPI-fast.frequency: timecounter frequency kern.timecounter.tc.ACPI-fast.counter: current timecounter value kern.timecounter.tc.ACPI-fast.mask: mask for implemented bits kern.timecounter.tc.i8254: timecounter description kern.timecounter.tc.i8254.quality: goodness of time counter kern.timecounter.tc.i8254.frequency: timecounter frequency kern.timecounter.tc.i8254.counter: current timecounter value kern.timecounter.tc.i8254.mask: mask for implemented bits kern.timecounter.tc.HPET: timecounter description kern.timecounter.tc.HPET.quality: goodness of time counter kern.timecounter.tc.HPET.frequency: time
Re: Waiting for bufdaemon
On Sat, 06 Mar 2021 08:33:23 +0900 (JST) Yasuhiro Kimura wrote: > From: Konstantin Belousov > Subject: Re: Waiting for bufdaemon > Date: Fri, 5 Mar 2021 22:43:58 +0200 > > > 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. > > I have experienced same situation several time. That is, I faced a > problem and asked for it on ML. Then I was told to try some tunable. > So I thought there may be tunable that can be used as workaround in > this case. But for those who isn't familiar with kernel internal, it > it quite hard to find it without knowing its name. If all tunable were > listed with brief explanation in one document, then I saw it and could > pick up possible candidates. But actually they are documented > separately among many man pages. So the first difficulty is to find > man page in which possible tunable may be explained. If the problem is > releted to some device, it is most hopeful to check its man page. But > in this case, even after reading the commit message, I had no idea > which man page to check. > see `man 4 timecounters': https://www.freebsd.org/cgi/man.cgi?query=timecounters -m -- Michael Gmelin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
From: Konstantin Belousov Subject: Re: Waiting for bufdaemon Date: Fri, 5 Mar 2021 22:43:58 +0200 > 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. I have experienced same situation several time. That is, I faced a problem and asked for it on ML. Then I was told to try some tunable. So I thought there may be tunable that can be used as workaround in this case. But for those who isn't familiar with kernel internal, it it quite hard to find it without knowing its name. If all tunable were listed with brief explanation in one document, then I saw it and could pick up possible candidates. But actually they are documented separately among many man pages. So the first difficulty is to find man page in which possible tunable may be explained. If the problem is releted to some device, it is most hopeful to check its man page. But in this case, even after reading the commit message, I had no idea which man page to check. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Fri, Mar 05, 2021 at 04:03:11PM +0900, Yasuhiro Kimura wrote: > Dear src committers, > > From: Yasuhiro Kimura > Subject: Re: Waiting for bufdaemon > Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) > > >>> I have been experiencing same problem with my 13-CURRENT amd64 > >>> VirtualBox VM for about a month. The conditions that the problem > >>> happens are unclear and all what I can say is > >>> > >>> * It happens only after I login in the VM and do something for a > >>> while. If I boot the VM and shut it down immediately, it never > >>> happens. > >>> * When the problem happens, one or more unkillable processes seem to > >>> be left. > >> > >> CPU of my host is not AMD but Intel. According to the > >> /var/run/dmesg.boot of VM, information of CPU is as following. > >> > >> CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) > >> Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 > >> > >> Features=0x1783fbff > >> > >> Features2=0x5eda2203 > >> AMD Features=0x28100800 > >> AMD Features2=0x121 > >> Structured Extended > >> Features=0x842421 > >> Structured Extended Features3=0x3400 > >> IA32_ARCH_CAPS=0x29 > >> TSC: P-state invariant > >> > >> Just FYI. > > > > It took for a while to investigate, but according to the result of > > bisect following commit is the source of problem in my case. > > > > -- > > commit 84eaf2ccc6a > > Author: Konstantin Belousov > > Date: Mon Dec 21 19:02:31 2020 +0200 > > > > x86: stop punishing VMs with low priority for TSC timecounter > > > > I suspect that virtualization techniques improved from the time when we > > have to effectively disable TSC use in VM. For instance, it was > > reported > > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > > FreeBSD is groundlessly slow on AWS with some loads. > > > > Remove the check and start watching for complaints. > > > > Reviewed by:emaste, grehan > > Discussed with: cperciva > > Sponsored by: The FreeBSD Foundation > > Differential Revision: https://reviews.freebsd.org/D27629 > > -- > > > > I confirmed the problem still happens with 5c325977b11 but reverting > > above commit fixes it. > > Would someone please revert above commit from main, stable/13 and > releng/13.0? As I wrote previous mail I submitted this problem to > Bugzilla as bug 253087 and added the committer to Cc. But there is no > response for 34 days. > > I confirmed the problem still happens with 37cd6c20dbc of main and > 13.0-RC1. 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Dear src committers, From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) >>> I have been experiencing same problem with my 13-CURRENT amd64 >>> VirtualBox VM for about a month. The conditions that the problem >>> happens are unclear and all what I can say is >>> >>> * It happens only after I login in the VM and do something for a >>> while. If I boot the VM and shut it down immediately, it never >>> happens. >>> * When the problem happens, one or more unkillable processes seem to >>> be left. >> >> CPU of my host is not AMD but Intel. According to the >> /var/run/dmesg.boot of VM, information of CPU is as following. >> >> CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) >> Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 >> >> Features=0x1783fbff >> >> Features2=0x5eda2203 >> AMD Features=0x28100800 >> AMD Features2=0x121 >> Structured Extended >> Features=0x842421 >> Structured Extended Features3=0x3400 >> IA32_ARCH_CAPS=0x29 >> TSC: P-state invariant >> >> Just FYI. > > It took for a while to investigate, but according to the result of > bisect following commit is the source of problem in my case. > > -- > commit 84eaf2ccc6a > Author: Konstantin Belousov > Date: Mon Dec 21 19:02:31 2020 +0200 > > x86: stop punishing VMs with low priority for TSC timecounter > > I suspect that virtualization techniques improved from the time when we > have to effectively disable TSC use in VM. For instance, it was reported > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > FreeBSD is groundlessly slow on AWS with some loads. > > Remove the check and start watching for complaints. > > Reviewed by:emaste, grehan > Discussed with: cperciva > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27629 > -- > > I confirmed the problem still happens with 5c325977b11 but reverting > above commit fixes it. Would someone please revert above commit from main, stable/13 and releng/13.0? As I wrote previous mail I submitted this problem to Bugzilla as bug 253087 and added the committer to Cc. But there is no response for 34 days. I confirmed the problem still happens with 37cd6c20dbc of main and 13.0-RC1. Best Regards. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) > It took for a while to investigate, but according to the result of > bisect following commit is the source of problem in my case. > > -- > commit 84eaf2ccc6a > Author: Konstantin Belousov > Date: Mon Dec 21 19:02:31 2020 +0200 > > x86: stop punishing VMs with low priority for TSC timecounter > > I suspect that virtualization techniques improved from the time when we > have to effectively disable TSC use in VM. For instance, it was reported > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > FreeBSD is groundlessly slow on AWS with some loads. > > Remove the check and start watching for complaints. > > Reviewed by:emaste, grehan > Discussed with: cperciva > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27629 > -- > > I confirmed the problem still happens with 5c325977b11 but reverting > above commit fixes it. I submitted this problem to Bugzilla. Timeout of bufdaemon happens at shutdown time with -CURRENT amd64 and VirtulaBox VM https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253087 --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Sat, 16 Jan 2021 04:03:23 +0900 (JST) > From: Yasuhiro Kimura > Subject: Re: Waiting for bufdaemon > Date: Fri, 15 Jan 2021 20:10:30 +0900 (JST) > >> I have been experiencing same problem with my 13-CURRENT amd64 >> VirtualBox VM for about a month. The conditions that the problem >> happens are unclear and all what I can say is >> >> * It happens only after I login in the VM and do something for a >> while. If I boot the VM and shut it down immediately, it never >> happens. >> * When the problem happens, one or more unkillable processes seem to >> be left. > > CPU of my host is not AMD but Intel. According to the > /var/run/dmesg.boot of VM, information of CPU is as following. > > CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 > > Features=0x1783fbff > > Features2=0x5eda2203 > AMD Features=0x28100800 > AMD Features2=0x121 > Structured Extended > Features=0x842421 > Structured Extended Features3=0x3400 > IA32_ARCH_CAPS=0x29 > TSC: P-state invariant > > Just FYI. It took for a while to investigate, but according to the result of bisect following commit is the source of problem in my case. -- commit 84eaf2ccc6a Author: Konstantin Belousov Date: Mon Dec 21 19:02:31 2020 +0200 x86: stop punishing VMs with low priority for TSC timecounter I suspect that virtualization techniques improved from the time when we have to effectively disable TSC use in VM. For instance, it was reported (complained) in https://github.com/JuliaLang/julia/issues/38877 that FreeBSD is groundlessly slow on AWS with some loads. Remove the check and start watching for complaints. Reviewed by:emaste, grehan Discussed with: cperciva Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D27629 -- I confirmed the problem still happens with 5c325977b11 but reverting above commit fixes it. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 20.01.21 um 15:36 schrieb Rainer Hurling: > Am 20.01.21 um 14:52 schrieb Konstantin Belousov: >> On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote: >>> Am 20.01.21 um 14:12 schrieb Konstantin Belousov: On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: > Am 20.01.21 um 13:34 schrieb Konstantin Belousov: >> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: > This patch hides the problem for me. The system seems to work better > now. > > No waiting on reboot, and the webcam works better. I am curious what do you mean by the above reference to webcam. Can you explain it with more details, even if only the impressions? >>> >>> I should mention, that beside the already discussed timing problem with >>> bufdaemon, I also have problems with several apps: >>> >>> >>> After a high system load, several programs only react very slowly (e.g. >>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >>> not update their windows anymore, they freeze. After some time, Firefox >>> updates its screen content only after switching back from another >>> window ... >>> >>> When such frozen programs are killed and restarted, they run normally >>> again for an indefinite time before they freeze again. >>> >>> These symptoms completely disappeared, after I patched the Ryzen box as >>> suggested on 01/17: >> >> Do you load latest microcode update from devcpu-data? > > Yes, sysutils/devcpu-data is installed and the following to lines are in > /boot/loader.conf > > cpu_microcode_load="YES" > cpu_microcode_name="/boot/firmware/intel-ucode.bin" > > But isn't this just for Intel (i387 and amd64), not AMD cpus? You need microcode_update_enable="YES" in /etc/rc.conf for late microcode update. I think that early boot update should work on AMD, bit for this you need to select and put right blob. It is enough to load late to answer my question. >>> >>> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in >>> /etc/rc.conf for a late update. >>> >>> Should I try again without your patch of sys/x86/tsc.c, whether the >>> problem still occurs? > > Unfornately, without the patch from 01/17 the problem is _not_ solved. > > Next I will try your patch from today, f lib/libc/x86/sys/__vdso_gettc.c > an lib/libc/x86/sys/__vdso_gettc.c ... I can confirm that this patch also works for me on Ryzen 3950X. No more bufdaemon waitings, no frozen apps, ... > > >> Yes. >> >>> >>> >>> And for the early boot update, how do I know about the right blob? >> I am not aware of the mechanism. My best suggestion is that you match >> the blob against your CPU family/model id manually. >> >>> > >> It might be not enough, which means that additionally latest BIOS needs >> to be flushed. >> > > I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" > mainboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Same here Mark, and if you need remote access to a AMD Ryzen let me know. Santi On 1/20/21 2:54 PM, Rainer Hurling wrote: > Thanks for the info. So for now, I can remove > microcode_update_enable="YES" in /boot/loader.conf ... > > Is there anything, I can test for you (without having skills in the area > ;) )? > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" OpenPGP_signature Description: OpenPGP digital signature
Re: Waiting for bufdaemon
Am 20.01.21 um 15:42 schrieb Mark Johnston: > On Wed, Jan 20, 2021 at 03:12:27PM +0200, Konstantin Belousov wrote: >> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: >>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov: On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: > Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: >>> This patch hides the problem for me. The system seems to work better >>> now. >>> >>> No waiting on reboot, and the webcam works better. >> I am curious what do you mean by the above reference to webcam. >> Can you explain it with more details, even if only the impressions? > > I should mention, that beside the already discussed timing problem with > bufdaemon, I also have problems with several apps: > > > After a high system load, several programs only react very slowly (e.g. > Firefox). Several dockable apps from WindowMaker, but also e.g. conky do > not update their windows anymore, they freeze. After some time, Firefox > updates its screen content only after switching back from another window > ... > > When such frozen programs are killed and restarted, they run normally > again for an indefinite time before they freeze again. > > These symptoms completely disappeared, after I patched the Ryzen box as > suggested on 01/17: Do you load latest microcode update from devcpu-data? >>> >>> Yes, sysutils/devcpu-data is installed and the following to lines are in >>> /boot/loader.conf >>> >>> cpu_microcode_load="YES" >>> cpu_microcode_name="/boot/firmware/intel-ucode.bin" >>> >>> But isn't this just for Intel (i387 and amd64), not AMD cpus? >> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode >> update. >> >> I think that early boot update should work on AMD, bit for this you need to >> select and put right blob. It is enough to load late to answer my question. > > The early microcode loader still doesn't support AMD. I did not do it > for lack of a test system at the time. > Thanks for the info. So for now, I can remove microcode_update_enable="YES" in /boot/loader.conf ... Is there anything, I can test for you (without having skills in the area ;) )? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Wed, Jan 20, 2021 at 03:12:27PM +0200, Konstantin Belousov wrote: > On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: > > Am 20.01.21 um 13:34 schrieb Konstantin Belousov: > > > On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: > > >> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: > > >>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: > > This patch hides the problem for me. The system seems to work better > > now. > > > > No waiting on reboot, and the webcam works better. > > >>> I am curious what do you mean by the above reference to webcam. > > >>> Can you explain it with more details, even if only the impressions? > > >> > > >> I should mention, that beside the already discussed timing problem with > > >> bufdaemon, I also have problems with several apps: > > >> > > >> > > >> After a high system load, several programs only react very slowly (e.g. > > >> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do > > >> not update their windows anymore, they freeze. After some time, Firefox > > >> updates its screen content only after switching back from another window > > >> ... > > >> > > >> When such frozen programs are killed and restarted, they run normally > > >> again for an indefinite time before they freeze again. > > >> > > >> These symptoms completely disappeared, after I patched the Ryzen box as > > >> suggested on 01/17: > > > > > > Do you load latest microcode update from devcpu-data? > > > > Yes, sysutils/devcpu-data is installed and the following to lines are in > > /boot/loader.conf > > > > cpu_microcode_load="YES" > > cpu_microcode_name="/boot/firmware/intel-ucode.bin" > > > > But isn't this just for Intel (i387 and amd64), not AMD cpus? > You need microcode_update_enable="YES" in /etc/rc.conf for late microcode > update. > > I think that early boot update should work on AMD, bit for this you need to > select and put right blob. It is enough to load late to answer my question. The early microcode loader still doesn't support AMD. I did not do it for lack of a test system at the time. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 20.01.21 um 14:52 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 14:12 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: Am 20.01.21 um 13:34 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: This patch hides the problem for me. The system seems to work better now. No waiting on reboot, and the webcam works better. >>> I am curious what do you mean by the above reference to webcam. >>> Can you explain it with more details, even if only the impressions? >> >> I should mention, that beside the already discussed timing problem with >> bufdaemon, I also have problems with several apps: >> >> >> After a high system load, several programs only react very slowly (e.g. >> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >> not update their windows anymore, they freeze. After some time, Firefox >> updates its screen content only after switching back from another window >> ... >> >> When such frozen programs are killed and restarted, they run normally >> again for an indefinite time before they freeze again. >> >> These symptoms completely disappeared, after I patched the Ryzen box as >> suggested on 01/17: > > Do you load latest microcode update from devcpu-data? Yes, sysutils/devcpu-data is installed and the following to lines are in /boot/loader.conf cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" But isn't this just for Intel (i387 and amd64), not AMD cpus? >>> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode >>> update. >>> >>> I think that early boot update should work on AMD, bit for this you need to >>> select and put right blob. It is enough to load late to answer my question. >> >> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in >> /etc/rc.conf for a late update. >> >> Should I try again without your patch of sys/x86/tsc.c, whether the >> problem still occurs? Unfornately, without the patch from 01/17 the problem is _not_ solved. Next I will try your patch from today, f lib/libc/x86/sys/__vdso_gettc.c an lib/libc/x86/sys/__vdso_gettc.c ... > Yes. > >> >> >> And for the early boot update, how do I know about the right blob? > I am not aware of the mechanism. My best suggestion is that you match > the blob against your CPU family/model id manually. > >> >>> > It might be not enough, which means that additionally latest BIOS needs > to be flushed. > I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" mainboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Hi, excellent the patch clear the problem for me when rebooting after a kern compile, etc, etc. Also seems that Firefox and pycharm or any other java related tools are not freezing any more, but its maybe to early to confirm this 100%. Will keep you posted. Santiago On 1/20/21 1:58 PM, Santiago Martinez wrote: > Hi Everyone, i have exactly the same behavior as Rainer described. > > "After a high system load, several programs only react very slowly (e.g. > Firefox).." > > I will try with the patch and see if it also clear this on my machine > (AMD R7). > > Santiago > > > On 1/20/21 1:52 PM, Konstantin Belousov wrote: >> On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote: >>> Am 20.01.21 um 14:12 schrieb Konstantin Belousov: On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: > Am 20.01.21 um 13:34 schrieb Konstantin Belousov: >> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: > This patch hides the problem for me. The system seems to work better > now. > > No waiting on reboot, and the webcam works better. I am curious what do you mean by the above reference to webcam. Can you explain it with more details, even if only the impressions? >>> I should mention, that beside the already discussed timing problem with >>> bufdaemon, I also have problems with several apps: >>> >>> >>> After a high system load, several programs only react very slowly (e.g. >>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >>> not update their windows anymore, they freeze. After some time, Firefox >>> updates its screen content only after switching back from another >>> window ... >>> >>> When such frozen programs are killed and restarted, they run normally >>> again for an indefinite time before they freeze again. >>> >>> These symptoms completely disappeared, after I patched the Ryzen box as >>> suggested on 01/17: >> Do you load latest microcode update from devcpu-data? > Yes, sysutils/devcpu-data is installed and the following to lines are in > /boot/loader.conf > > cpu_microcode_load="YES" > cpu_microcode_name="/boot/firmware/intel-ucode.bin" > > But isn't this just for Intel (i387 and amd64), not AMD cpus? You need microcode_update_enable="YES" in /etc/rc.conf for late microcode update. I think that early boot update should work on AMD, bit for this you need to select and put right blob. It is enough to load late to answer my question. >>> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in >>> /etc/rc.conf for a late update. >>> >>> Should I try again without your patch of sys/x86/tsc.c, whether the >>> problem still occurs? >> Yes. >> >>> And for the early boot update, how do I know about the right blob? >> I am not aware of the mechanism. My best suggestion is that you match >> the blob against your CPU family/model id manually. >> >> It might be not enough, which means that additionally latest BIOS needs >> to be flushed. >> > I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" > mainboard. >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" OpenPGP_signature Description: OpenPGP digital signature
Re: Waiting for bufdaemon
Hi Everyone, i have exactly the same behavior as Rainer described. "After a high system load, several programs only react very slowly (e.g. Firefox).." I will try with the patch and see if it also clear this on my machine (AMD R7). Santiago On 1/20/21 1:52 PM, Konstantin Belousov wrote: > On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 14:12 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: Am 20.01.21 um 13:34 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: This patch hides the problem for me. The system seems to work better now. No waiting on reboot, and the webcam works better. >>> I am curious what do you mean by the above reference to webcam. >>> Can you explain it with more details, even if only the impressions? >> I should mention, that beside the already discussed timing problem with >> bufdaemon, I also have problems with several apps: >> >> >> After a high system load, several programs only react very slowly (e.g. >> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >> not update their windows anymore, they freeze. After some time, Firefox >> updates its screen content only after switching back from another window >> ... >> >> When such frozen programs are killed and restarted, they run normally >> again for an indefinite time before they freeze again. >> >> These symptoms completely disappeared, after I patched the Ryzen box as >> suggested on 01/17: > Do you load latest microcode update from devcpu-data? Yes, sysutils/devcpu-data is installed and the following to lines are in /boot/loader.conf cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" But isn't this just for Intel (i387 and amd64), not AMD cpus? >>> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode >>> update. >>> >>> I think that early boot update should work on AMD, bit for this you need to >>> select and put right blob. It is enough to load late to answer my question. >> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in >> /etc/rc.conf for a late update. >> >> Should I try again without your patch of sys/x86/tsc.c, whether the >> problem still occurs? > Yes. > >> >> And for the early boot update, how do I know about the right blob? > I am not aware of the mechanism. My best suggestion is that you match > the blob against your CPU family/model id manually. > > It might be not enough, which means that additionally latest BIOS needs > to be flushed. > I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" mainboard. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" OpenPGP_signature Description: OpenPGP digital signature
Re: Waiting for bufdaemon
On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote: > Am 20.01.21 um 14:12 schrieb Konstantin Belousov: > > On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: > >> Am 20.01.21 um 13:34 schrieb Konstantin Belousov: > >>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: > Am 20.01.21 um 11:18 schrieb Konstantin Belousov: > > On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: > >> This patch hides the problem for me. The system seems to work better > >> now. > >> > >> No waiting on reboot, and the webcam works better. > > I am curious what do you mean by the above reference to webcam. > > Can you explain it with more details, even if only the impressions? > > I should mention, that beside the already discussed timing problem with > bufdaemon, I also have problems with several apps: > > > After a high system load, several programs only react very slowly (e.g. > Firefox). Several dockable apps from WindowMaker, but also e.g. conky do > not update their windows anymore, they freeze. After some time, Firefox > updates its screen content only after switching back from another window > ... > > When such frozen programs are killed and restarted, they run normally > again for an indefinite time before they freeze again. > > These symptoms completely disappeared, after I patched the Ryzen box as > suggested on 01/17: > >>> > >>> Do you load latest microcode update from devcpu-data? > >> > >> Yes, sysutils/devcpu-data is installed and the following to lines are in > >> /boot/loader.conf > >> > >> cpu_microcode_load="YES" > >> cpu_microcode_name="/boot/firmware/intel-ucode.bin" > >> > >> But isn't this just for Intel (i387 and amd64), not AMD cpus? > > You need microcode_update_enable="YES" in /etc/rc.conf for late microcode > > update. > > > > I think that early boot update should work on AMD, bit for this you need to > > select and put right blob. It is enough to load late to answer my question. > > Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in > /etc/rc.conf for a late update. > > Should I try again without your patch of sys/x86/tsc.c, whether the > problem still occurs? Yes. > > > And for the early boot update, how do I know about the right blob? I am not aware of the mechanism. My best suggestion is that you match the blob against your CPU family/model id manually. > > > > >> > >>> It might be not enough, which means that additionally latest BIOS needs > >>> to be flushed. > >>> > >> > >> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" > >> mainboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 20.01.21 um 14:12 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 13:34 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: Am 20.01.21 um 11:18 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: >> This patch hides the problem for me. The system seems to work better now. >> >> No waiting on reboot, and the webcam works better. > I am curious what do you mean by the above reference to webcam. > Can you explain it with more details, even if only the impressions? I should mention, that beside the already discussed timing problem with bufdaemon, I also have problems with several apps: After a high system load, several programs only react very slowly (e.g. Firefox). Several dockable apps from WindowMaker, but also e.g. conky do not update their windows anymore, they freeze. After some time, Firefox updates its screen content only after switching back from another window ... When such frozen programs are killed and restarted, they run normally again for an indefinite time before they freeze again. These symptoms completely disappeared, after I patched the Ryzen box as suggested on 01/17: >>> >>> Do you load latest microcode update from devcpu-data? >> >> Yes, sysutils/devcpu-data is installed and the following to lines are in >> /boot/loader.conf >> >> cpu_microcode_load="YES" >> cpu_microcode_name="/boot/firmware/intel-ucode.bin" >> >> But isn't this just for Intel (i387 and amd64), not AMD cpus? > You need microcode_update_enable="YES" in /etc/rc.conf for late microcode > update. > > I think that early boot update should work on AMD, bit for this you need to > select and put right blob. It is enough to load late to answer my question. Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in /etc/rc.conf for a late update. Should I try again without your patch of sys/x86/tsc.c, whether the problem still occurs? And for the early boot update, how do I know about the right blob? > >> >>> It might be not enough, which means that additionally latest BIOS needs >>> to be flushed. >>> >> >> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" >> mainboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: > Am 20.01.21 um 13:34 schrieb Konstantin Belousov: > > On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: > >> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: > >>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: > This patch hides the problem for me. The system seems to work better now. > > No waiting on reboot, and the webcam works better. > >>> I am curious what do you mean by the above reference to webcam. > >>> Can you explain it with more details, even if only the impressions? > >> > >> I should mention, that beside the already discussed timing problem with > >> bufdaemon, I also have problems with several apps: > >> > >> > >> After a high system load, several programs only react very slowly (e.g. > >> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do > >> not update their windows anymore, they freeze. After some time, Firefox > >> updates its screen content only after switching back from another window > >> ... > >> > >> When such frozen programs are killed and restarted, they run normally > >> again for an indefinite time before they freeze again. > >> > >> These symptoms completely disappeared, after I patched the Ryzen box as > >> suggested on 01/17: > > > > Do you load latest microcode update from devcpu-data? > > Yes, sysutils/devcpu-data is installed and the following to lines are in > /boot/loader.conf > > cpu_microcode_load="YES" > cpu_microcode_name="/boot/firmware/intel-ucode.bin" > > But isn't this just for Intel (i387 and amd64), not AMD cpus? You need microcode_update_enable="YES" in /etc/rc.conf for late microcode update. I think that early boot update should work on AMD, bit for this you need to select and put right blob. It is enough to load late to answer my question. > > > It might be not enough, which means that additionally latest BIOS needs > > to be flushed. > > > > I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" > mainboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 20.01.21 um 13:34 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: This patch hides the problem for me. The system seems to work better now. No waiting on reboot, and the webcam works better. >>> I am curious what do you mean by the above reference to webcam. >>> Can you explain it with more details, even if only the impressions? >> >> I should mention, that beside the already discussed timing problem with >> bufdaemon, I also have problems with several apps: >> >> >> After a high system load, several programs only react very slowly (e.g. >> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >> not update their windows anymore, they freeze. After some time, Firefox >> updates its screen content only after switching back from another window ... >> >> When such frozen programs are killed and restarted, they run normally >> again for an indefinite time before they freeze again. >> >> These symptoms completely disappeared, after I patched the Ryzen box as >> suggested on 01/17: > > Do you load latest microcode update from devcpu-data? Yes, sysutils/devcpu-data is installed and the following to lines are in /boot/loader.conf cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" But isn't this just for Intel (i387 and amd64), not AMD cpus? > It might be not enough, which means that additionally latest BIOS needs > to be flushed. > I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" mainboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: > Am 20.01.21 um 11:18 schrieb Konstantin Belousov: > > On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: > >> This patch hides the problem for me. The system seems to work better now. > >> > >> No waiting on reboot, and the webcam works better. > > I am curious what do you mean by the above reference to webcam. > > Can you explain it with more details, even if only the impressions? > > I should mention, that beside the already discussed timing problem with > bufdaemon, I also have problems with several apps: > > > After a high system load, several programs only react very slowly (e.g. > Firefox). Several dockable apps from WindowMaker, but also e.g. conky do > not update their windows anymore, they freeze. After some time, Firefox > updates its screen content only after switching back from another window ... > > When such frozen programs are killed and restarted, they run normally > again for an indefinite time before they freeze again. > > These symptoms completely disappeared, after I patched the Ryzen box as > suggested on 01/17: Do you load latest microcode update from devcpu-data? It might be not enough, which means that additionally latest BIOS needs to be flushed. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>> This patch hides the problem for me. The system seems to work better now.
>>
>> No waiting on reboot, and the webcam works better.
> I am curious what do you mean by the above reference to webcam.
> Can you explain it with more details, even if only the impressions?
I should mention, that beside the already discussed timing problem with
bufdaemon, I also have problems with several apps:
After a high system load, several programs only react very slowly (e.g.
Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
not update their windows anymore, they freeze. After some time, Firefox
updates its screen content only after switching back from another window ...
When such frozen programs are killed and restarted, they run normally
again for an indefinite time before they freeze again.
These symptoms completely disappeared, after I patched the Ryzen box as
suggested on 01/17:
diff --git a/sys/x86/tsc.c b/sys/x86/tsc.c
index 85924df98312..5700a8ca98e5 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -639,7 +639,7 @@ init_TSC_tc(void)
* on Intel, and MFENCE;RDTSC on AMD.
* - For really old CPUs, just use RDTSC.
*/
- if ((cpu_vendor_id == CPU_VENDOR_AMD ||
+ if (false && (cpu_vendor_id == CPU_VENDOR_AMD ||
cpu_vendor_id == CPU_VENDOR_HYGON) &&
CPUID_TO_FAMILY(cpu_id) >= 0x17) {
tsc_timecounter.tc_get_timecount = shift > 0 ?
HTH,
Rainer
>
> I probably going to commit the following patch in the next 24 hours.
>
> commit 02505d07bca320a638c96918ac9076c6eece2fff
> Author: Konstantin Belousov
> Date: Wed Jan 20 11:32:21 2021 +0200
>
> AMD Zen CPUs: switch TSC timecounter to RDTSCP
>
> Reported by:many
> MFC after: 1 weel
> Sponsored by: The FreeBSD Foundation
>
> diff --git a/lib/libc/x86/sys/__vdso_gettc.c b/lib/libc/x86/sys/__vdso_gettc.c
> index 7f224f8758cb..7a64f2a0b556 100644
> --- a/lib/libc/x86/sys/__vdso_gettc.c
> +++ b/lib/libc/x86/sys/__vdso_gettc.c
> @@ -125,7 +125,7 @@ struct tsc_selector_tag {
> };
>
> static const struct tsc_selector_tag tsc_selector[] = {
> - [0] = { /* Intel or AMD Zen+, LFENCE */
> + [0] = { /* Intel, LFENCE */
> .ts_rdtsc32 = rdtsc32_mb_lfence,
> .ts_rdtsc_low = rdtsc_low_mb_lfence,
> },
> @@ -164,9 +164,6 @@ tsc_selector_idx(u_int cpu_feature)
> do_cpuid(1, p);
> cpu_id = p[0];
>
> - if (amd_cpu && CPUID_TO_FAMILY(cpu_id) >= 0x17)
> - return (0);
> -
> if (cpu_feature != 0) {
> do_cpuid(0x8000, p);
> cpu_exthigh = p[0];
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 85924df98312..de0a1505c2f6 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -633,19 +633,12 @@ init_TSC_tc(void)
>
> /*
>* Timecounter implementation selection, top to bottom:
> - * - For AMD Zens and newer, use LFENCE;RDTSC.
>* - If RDTSCP is available, use RDTSCP.
>* - If fence instructions are provided (SSE2), use LFENCE;RDTSC
>* on Intel, and MFENCE;RDTSC on AMD.
>* - For really old CPUs, just use RDTSC.
>*/
> - if ((cpu_vendor_id == CPU_VENDOR_AMD ||
> - cpu_vendor_id == CPU_VENDOR_HYGON) &&
> - CPUID_TO_FAMILY(cpu_id) >= 0x17) {
> - tsc_timecounter.tc_get_timecount = shift > 0 ?
> - tsc_get_timecount_low_lfence :
> - tsc_get_timecount_lfence;
> - } else if ((amd_feature & AMDID_RDTSCP) != 0) {
> + if ((amd_feature & AMDID_RDTSCP) != 0) {
> tsc_timecounter.tc_get_timecount = shift > 0 ?
> tscp_get_timecount_low : tscp_get_timecount;
> } else if ((cpu_feature & CPUID_SSE2) != 0 && mp_ncpus > 1) {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 1/20/21 11:18 AM, Konstantin Belousov wrote:
On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
This patch hides the problem for me. The system seems to work better now.
No waiting on reboot, and the webcam works better.
I am curious what do you mean by the above reference to webcam.
Can you explain it with more details, even if only the impressions?
I probably going to commit the following patch in the next 24 hours.
commit 02505d07bca320a638c96918ac9076c6eece2fff
Author: Konstantin Belousov
Date: Wed Jan 20 11:32:21 2021 +0200
AMD Zen CPUs: switch TSC timecounter to RDTSCP
Reported by:many
MFC after: 1 weel
Sponsored by: The FreeBSD Foundation
diff --git a/lib/libc/x86/sys/__vdso_gettc.c b/lib/libc/x86/sys/__vdso_gettc.c
index 7f224f8758cb..7a64f2a0b556 100644
--- a/lib/libc/x86/sys/__vdso_gettc.c
+++ b/lib/libc/x86/sys/__vdso_gettc.c
@@ -125,7 +125,7 @@ struct tsc_selector_tag {
};
static const struct tsc_selector_tag tsc_selector[] = {
- [0] = { /* Intel or AMD Zen+, LFENCE */
+ [0] = { /* Intel, LFENCE */
.ts_rdtsc32 = rdtsc32_mb_lfence,
.ts_rdtsc_low = rdtsc_low_mb_lfence,
},
@@ -164,9 +164,6 @@ tsc_selector_idx(u_int cpu_feature)
do_cpuid(1, p);
cpu_id = p[0];
- if (amd_cpu && CPUID_TO_FAMILY(cpu_id) >= 0x17)
- return (0);
-
if (cpu_feature != 0) {
do_cpuid(0x8000, p);
cpu_exthigh = p[0];
diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
index 85924df98312..de0a1505c2f6 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -633,19 +633,12 @@ init_TSC_tc(void)
/*
* Timecounter implementation selection, top to bottom:
-* - For AMD Zens and newer, use LFENCE;RDTSC.
* - If RDTSCP is available, use RDTSCP.
* - If fence instructions are provided (SSE2), use LFENCE;RDTSC
* on Intel, and MFENCE;RDTSC on AMD.
* - For really old CPUs, just use RDTSC.
*/
- if ((cpu_vendor_id == CPU_VENDOR_AMD ||
- cpu_vendor_id == CPU_VENDOR_HYGON) &&
- CPUID_TO_FAMILY(cpu_id) >= 0x17) {
- tsc_timecounter.tc_get_timecount = shift > 0 ?
- tsc_get_timecount_low_lfence :
- tsc_get_timecount_lfence;
- } else if ((amd_feature & AMDID_RDTSCP) != 0) {
+ if ((amd_feature & AMDID_RDTSCP) != 0) {
tsc_timecounter.tc_get_timecount = shift > 0 ?
tscp_get_timecount_low : tscp_get_timecount;
} else if ((cpu_feature & CPUID_SSE2) != 0 && mp_ncpus > 1) {
I have a Logitech C270 USB webcam that I use for all the online meetings
now that everyone is working from home. (MS Teams, Google Meet, Slack,
Zoom, whatever...).
It is supported by multimedia/webcamd and has been working mostly fine.
(just some rare, occasional hickups)
When I started to notice the bufdaemon problems, I also noticed the
webcam not behaving as before.
It sometimes took me two or three tries to start the camera when joining
a meeting and once it started my video would freeze sometimes, being
frozen for a minute or so. Sometimes when I noticed that it frooze I
would try to restart it, and again it might take a couple of tries to
get it working again.
With the patch it seems to work better again.
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
> This patch hides the problem for me. The system seems to work better now.
>
> No waiting on reboot, and the webcam works better.
I am curious what do you mean by the above reference to webcam.
Can you explain it with more details, even if only the impressions?
I probably going to commit the following patch in the next 24 hours.
commit 02505d07bca320a638c96918ac9076c6eece2fff
Author: Konstantin Belousov
Date: Wed Jan 20 11:32:21 2021 +0200
AMD Zen CPUs: switch TSC timecounter to RDTSCP
Reported by:many
MFC after: 1 weel
Sponsored by: The FreeBSD Foundation
diff --git a/lib/libc/x86/sys/__vdso_gettc.c b/lib/libc/x86/sys/__vdso_gettc.c
index 7f224f8758cb..7a64f2a0b556 100644
--- a/lib/libc/x86/sys/__vdso_gettc.c
+++ b/lib/libc/x86/sys/__vdso_gettc.c
@@ -125,7 +125,7 @@ struct tsc_selector_tag {
};
static const struct tsc_selector_tag tsc_selector[] = {
- [0] = { /* Intel or AMD Zen+, LFENCE */
+ [0] = { /* Intel, LFENCE */
.ts_rdtsc32 = rdtsc32_mb_lfence,
.ts_rdtsc_low = rdtsc_low_mb_lfence,
},
@@ -164,9 +164,6 @@ tsc_selector_idx(u_int cpu_feature)
do_cpuid(1, p);
cpu_id = p[0];
- if (amd_cpu && CPUID_TO_FAMILY(cpu_id) >= 0x17)
- return (0);
-
if (cpu_feature != 0) {
do_cpuid(0x8000, p);
cpu_exthigh = p[0];
diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
index 85924df98312..de0a1505c2f6 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -633,19 +633,12 @@ init_TSC_tc(void)
/*
* Timecounter implementation selection, top to bottom:
-* - For AMD Zens and newer, use LFENCE;RDTSC.
* - If RDTSCP is available, use RDTSCP.
* - If fence instructions are provided (SSE2), use LFENCE;RDTSC
* on Intel, and MFENCE;RDTSC on AMD.
* - For really old CPUs, just use RDTSC.
*/
- if ((cpu_vendor_id == CPU_VENDOR_AMD ||
- cpu_vendor_id == CPU_VENDOR_HYGON) &&
- CPUID_TO_FAMILY(cpu_id) >= 0x17) {
- tsc_timecounter.tc_get_timecount = shift > 0 ?
- tsc_get_timecount_low_lfence :
- tsc_get_timecount_lfence;
- } else if ((amd_feature & AMDID_RDTSCP) != 0) {
+ if ((amd_feature & AMDID_RDTSCP) != 0) {
tsc_timecounter.tc_get_timecount = shift > 0 ?
tscp_get_timecount_low : tscp_get_timecount;
} else if ((cpu_feature & CPUID_SSE2) != 0 && mp_ncpus > 1) {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 1/17/21 10:49 AM, Konstantin Belousov wrote:
On Sun, Jan 17, 2021 at 10:37:18AM +0100, Rainer Hurling wrote:
Am 17.01.21 um 05:33 schrieb Konstantin Belousov:
On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote:
During another shutdown after heavy usage of the box, the following
messages were also seen:
[...]
Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14
efirtc0: CLOCK_SETTIME error 14
This means that BIOS code faulted during RTC settime call. I doubt that
it is related.
On the other hand, it is good that the onfault EFI RT code got tested finally.
Thanks for clarification :)
Any chance of getting a fix for the AMD CPUs in the foreseeable future?
Or should I revert commit 9e680e4005b7 on affected boxes until further
notice (as a workaround)?
I am working on it, no ETA.
Interesting point would be to check on machines of other testers,
if the following hides the problem.
diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
index 85924df98312..5700a8ca98e5 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -639,7 +639,7 @@ init_TSC_tc(void)
* on Intel, and MFENCE;RDTSC on AMD.
* - For really old CPUs, just use RDTSC.
*/
- if ((cpu_vendor_id == CPU_VENDOR_AMD ||
+ if (false && (cpu_vendor_id == CPU_VENDOR_AMD ||
cpu_vendor_id == CPU_VENDOR_HYGON) &&
CPUID_TO_FAMILY(cpu_id) >= 0x17) {
tsc_timecounter.tc_get_timecount = shift > 0 ?
This patch hides the problem for me. The system seems to work better now.
No waiting on reboot, and the webcam works better.
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
From: Konstantin Belousov Subject: Re: Waiting for bufdaemon Date: Sun, 17 Jan 2021 11:49:40 +0200 > I am working on it, no ETA. > > Interesting point would be to check on machines of other testers, > if the following hides the problem. I tried this patch but unfortunately the problem still happens with my environment. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 17.01.21 um 10:49 schrieb Konstantin Belousov:
> On Sun, Jan 17, 2021 at 10:37:18AM +0100, Rainer Hurling wrote:
>> Am 17.01.21 um 05:33 schrieb Konstantin Belousov:
>>> On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote:
>>>> During another shutdown after heavy usage of the box, the following
>>>> messages were also seen:
>>>>
>>>>
>>>> [...]
>>>> Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14
>>>> efirtc0: CLOCK_SETTIME error 14
>>>
>>> This means that BIOS code faulted during RTC settime call. I doubt that
>>> it is related.
>>>
>>> On the other hand, it is good that the onfault EFI RT code got tested
>>> finally.
>>>
>>
>> Thanks for clarification :)
>>
>>
>> Any chance of getting a fix for the AMD CPUs in the foreseeable future?
>>
>> Or should I revert commit 9e680e4005b7 on affected boxes until further
>> notice (as a workaround)?
>
> I am working on it, no ETA.
>
> Interesting point would be to check on machines of other testers,
> if the following hides the problem.
>
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 85924df98312..5700a8ca98e5 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -639,7 +639,7 @@ init_TSC_tc(void)
>* on Intel, and MFENCE;RDTSC on AMD.
>* - For really old CPUs, just use RDTSC.
>*/
> - if ((cpu_vendor_id == CPU_VENDOR_AMD ||
> + if (false && (cpu_vendor_id == CPU_VENDOR_AMD ||
> cpu_vendor_id == CPU_VENDOR_HYGON) &&
> CPUID_TO_FAMILY(cpu_id) >= 0x17) {
> tsc_timecounter.tc_get_timecount = shift > 0 ?
>
I tried the above patch on a Ryzen 3950X.
After reboot (again with long waiting for bufdaemon and more) the box
had some heavy load with several jobs (llvm on Poudriere, building
qt5-webengine, libreoffice and some more in parallel). All went fine.
Afterwards I rebooted again. This time, the shutdown was fast without
any unusual delays :)
Many thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Sun, Jan 17, 2021 at 10:37:18AM +0100, Rainer Hurling wrote:
> Am 17.01.21 um 05:33 schrieb Konstantin Belousov:
> > On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote:
> >> During another shutdown after heavy usage of the box, the following
> >> messages were also seen:
> >>
> >>
> >> [...]
> >> Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14
> >> efirtc0: CLOCK_SETTIME error 14
> >
> > This means that BIOS code faulted during RTC settime call. I doubt that
> > it is related.
> >
> > On the other hand, it is good that the onfault EFI RT code got tested
> > finally.
> >
>
> Thanks for clarification :)
>
>
> Any chance of getting a fix for the AMD CPUs in the foreseeable future?
>
> Or should I revert commit 9e680e4005b7 on affected boxes until further
> notice (as a workaround)?
I am working on it, no ETA.
Interesting point would be to check on machines of other testers,
if the following hides the problem.
diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
index 85924df98312..5700a8ca98e5 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -639,7 +639,7 @@ init_TSC_tc(void)
* on Intel, and MFENCE;RDTSC on AMD.
* - For really old CPUs, just use RDTSC.
*/
- if ((cpu_vendor_id == CPU_VENDOR_AMD ||
+ if (false && (cpu_vendor_id == CPU_VENDOR_AMD ||
cpu_vendor_id == CPU_VENDOR_HYGON) &&
CPUID_TO_FAMILY(cpu_id) >= 0x17) {
tsc_timecounter.tc_get_timecount = shift > 0 ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 17.01.21 um 05:33 schrieb Konstantin Belousov: > On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote: >> During another shutdown after heavy usage of the box, the following >> messages were also seen: >> >> >> [...] >> Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14 >> efirtc0: CLOCK_SETTIME error 14 > > This means that BIOS code faulted during RTC settime call. I doubt that > it is related. > > On the other hand, it is good that the onfault EFI RT code got tested finally. > Thanks for clarification :) Any chance of getting a fix for the AMD CPUs in the foreseeable future? Or should I revert commit 9e680e4005b7 on affected boxes until further notice (as a workaround)? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote: > During another shutdown after heavy usage of the box, the following > messages were also seen: > > > [...] > Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14 > efirtc0: CLOCK_SETTIME error 14 This means that BIOS code faulted during RTC settime call. I doubt that it is related. On the other hand, it is good that the onfault EFI RT code got tested finally. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 15.01.21 um 19:48 schrieb Rainer Hurling: > Am 15.01.21 um 16:45 schrieb Konstantin Belousov: >> On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote: >>> On 15/01/2021 16:02, Konstantin Belousov wrote: >>>> On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: >>>>> On 15/01/2021 11:26, Jakob Alvermark wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> When rebooting my thinkpad the 'bufdaemon' times out: >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed >>>>>> out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop >>>>>> ... timed out >>>>>> >>>>>> >>>>>> This started happening recently (within the last week I think). >>>>> >>>>> Hi, >>>>> >>>>> I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. >>>>> >>>>> 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of >>>>> orphaned >>>>> groups) "seems" ok >>>>> >>>>> cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP >>>>> support), affected by the timeout. >>>>> >>>>> I haven't tried the intermediate commit yet. >>>>> >>>>> My intel machine doesn't seem to be affected >>>> >>>> If you revert only 9e680e4005b7, is it fixed ? >>>> >>> Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests, >>> I can do more if you want) >> Please show me the output from sysctl >> kern.timecounter >> kern.eventtimer >> and first 100 lines of dmesg from the verbose boot (that contains the CPU >> ident lines). > > > I also have this timeout issue only on AMD, here Ryzen 3950X: > > [...] > Waiting for PIDS: 2905 > 90 seconds watchdog timeout expired. Shutdown terminated. > Fri Jan 15 19:21:01 xx init[1]: /etc/rc.shutdown terminated > abnormally, going to single user mode > Fri Jan 15 19:21:01 xx syslogd: exiting on signal 15 > wg0: link state changed to DOWN > Waiting (max 69 seconds) for system process `vnlru' to stop... done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining... 22 23 23 1 1 0 0 0 done > Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done > Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... > done > Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... > done > Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop... > done > Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop... > timeout > Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop... > timeout > Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop... > done > Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop... > > > You will find the wanted output from sysctl and boot -v in the attachment. > > HTH, > Rainer Hurling > During another shutdown after heavy usage of the box, the following messages were also seen: [...] Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14 efirtc0: CLOCK_SETTIME error 14 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 1/15/21 3:26 AM, Jakob Alvermark wrote: > > When rebooting my thinkpad the 'bufdaemon' times out: > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... > timed out I'm glad other people are seeing this: I was about to report it to the list! I'm running an AMD Threadripper 2990WX. I can trigger it by running a buildworld/buildkernel and then rebooting. -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
In the interest of documenting some variability . . . While not readily reproducible, on a ThreadRipper 1950X that I have access to, a recent reboot had one "system thread" time out: bufspacedaemon-3 . The rest of the "system thread" list behaved normally. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Fri, 15 Jan 2021 20:10:30 +0900 (JST) > I have been experiencing same problem with my 13-CURRENT amd64 > VirtualBox VM for about a month. The conditions that the problem > happens are unclear and all what I can say is > > * It happens only after I login in the VM and do something for a > while. If I boot the VM and shut it down immediately, it never > happens. > * When the problem happens, one or more unkillable processes seem to > be left. CPU of my host is not AMD but Intel. According to the /var/run/dmesg.boot of VM, information of CPU is as following. CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 Features=0x1783fbff Features2=0x5eda2203 AMD Features=0x28100800 AMD Features2=0x121 Structured Extended Features=0x842421 Structured Extended Features3=0x3400 IA32_ARCH_CAPS=0x29 TSC: P-state invariant Just FYI. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 15.01.21 um 16:45 schrieb Konstantin Belousov: > On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote: >> On 15/01/2021 16:02, Konstantin Belousov wrote: >>> On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: >>>> On 15/01/2021 11:26, Jakob Alvermark wrote: >>>>> Hi, >>>>> >>>>> >>>>> When rebooting my thinkpad the 'bufdaemon' times out: >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed >>>>> out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop >>>>> ... timed out >>>>> >>>>> >>>>> This started happening recently (within the last week I think). >>>> >>>> Hi, >>>> >>>> I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. >>>> >>>> 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of >>>> orphaned >>>> groups) "seems" ok >>>> >>>> cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP >>>> support), affected by the timeout. >>>> >>>> I haven't tried the intermediate commit yet. >>>> >>>> My intel machine doesn't seem to be affected >>> >>> If you revert only 9e680e4005b7, is it fixed ? >>> >> Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests, >> I can do more if you want) > Please show me the output from sysctl > kern.timecounter > kern.eventtimer > and first 100 lines of dmesg from the verbose boot (that contains the CPU > ident lines). I also have this timeout issue only on AMD, here Ryzen 3950X: [...] Waiting for PIDS: 2905 90 seconds watchdog timeout expired. Shutdown terminated. Fri Jan 15 19:21:01 xx init[1]: /etc/rc.shutdown terminated abnormally, going to single user mode Fri Jan 15 19:21:01 xx syslogd: exiting on signal 15 wg0: link state changed to DOWN Waiting (max 69 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 22 23 23 1 1 0 0 0 done Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop... timeout Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop... timeout Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop... You will find the wanted output from sysctl and boot -v in the attachment. HTH, Rainer Hurling #sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 3355373301 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 3626460971 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 21196 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1746752087 kern.timecounter.tc.TSC-low.counter: 86914443
Re: Waiting for bufdaemon
On Fri., Jan. 15, 2021, 9:41 a.m. Juraj Lutter, wrote: > > On 15 Jan 2021, at 18:26, Freddie Cash wrote: > > > > /var/run/dmesg.boot includes all output from dmesg for the current boot. > No > > need to manually redirect dmesg output to a file or play with buffer > sizes. > > :) Just upload that file. > > On boot, dmesg is saved to dmesg.boot quite lately and start of the > circular > buffer can already be rewritten. > Really? Interesting. Haven't run into that (not saying it can't happen). I always thought it was essentially streamed to that file once / or /var was mounted. Now I'll have to read some RC scripts to see. :) Thanks for the info. Cheers, Freddie Typos due to smartphone keyboard. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
> On 15 Jan 2021, at 18:26, Freddie Cash wrote: > > > /var/run/dmesg.boot includes all output from dmesg for the current boot. No > need to manually redirect dmesg output to a file or play with buffer sizes. > :) Just upload that file. On boot, dmesg is saved to dmesg.boot quite lately and start of the circular buffer can already be rewritten. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Fri., Jan. 15, 2021, 8:47 a.m. Mikaël Urankar, wrote: > On 15/01/2021 17:35, Konstantin Belousov wrote: > > It is clipped at the start, and that was the information which I need. > > Add something like > > kern.msgbufsize=1048576 > > to /boot/loader.conf and try again. I need to see the lines starting > with > > > > CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU) > >Origin="GenuineIntel" Id=0x806ea Family=0x6 Model=0x8e Stepping=10 > > > Features=0xbfebfbff > MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > ... > > > > (well, this is my w/s, your CPU would be different of course). > > > Thanks, I've updated the file on freefall. /var/run/dmesg.boot includes all output from dmesg for the current boot. No need to manually redirect dmesg output to a file or play with buffer sizes. :) Just upload that file. Cheers, Freddie Typos due to smartphone keyboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 15/01/2021 17:35, Konstantin Belousov wrote: On Fri, Jan 15, 2021 at 05:18:56PM +0100, Mikaël Urankar wrote: On 15/01/2021 16:45, Konstantin Belousov wrote: On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote: On 15/01/2021 16:02, Konstantin Belousov wrote: On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: On 15/01/2021 11:26, Jakob Alvermark wrote: Hi, When rebooting my thinkpad the 'bufdaemon' times out: Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ... timed out This started happening recently (within the last week I think). Hi, I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned groups) "seems" ok cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP support), affected by the timeout. I haven't tried the intermediate commit yet. My intel machine doesn't seem to be affected If you revert only 9e680e4005b7, is it fixed ? Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests, I can do more if you want) Please show me the output from sysctl kern.timecounter kern.eventtimer and first 100 lines of dmesg from the verbose boot (that contains the CPU ident lines). I put the /var/run/dmesg.boot file on freefall /home/mikael/dmesg.boot (it seems to be truncated though, I don't know how to retrieve the full log) sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 1470549582 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 378058131 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 20425 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1900039387 kern.timecounter.tc.TSC-low.counter: 2386729797 kern.timecounter.tc.TSC-low.mask: 4294967295 sysctl kern.eventtimer kern.eventtimer.choice: LAPIC(600) HPET(350) HPET1(350) HPET2(350) i8254(100) RTC(0) kern.eventtimer.et.HPET2.quality: 350 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET1.quality: 350 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET.quality: 350 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.LAPIC.quality: 600 kern.eventtimer.et.LAPIC.frequency: 50001034 kern.eventtimer.et.LAPIC.flags: 7 kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 It is clipped at the start, and that was the information which I need. Add something like kern.msgbufsize=1048576 to /boot/loader.conf and try again. I need to see the lines starting with CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU) Origin="GenuineIntel" Id=0x806ea Family=0x6 Model=0x8e Stepping=10 Features=0xbfebfbff ... (well, this is my w/s, your CPU would be different of course). Thanks, I've updated the file on freefall ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Fri, Jan 15, 2021 at 05:18:56PM +0100, Mikaël Urankar wrote: > On 15/01/2021 16:45, Konstantin Belousov wrote: > > On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote: > > > On 15/01/2021 16:02, Konstantin Belousov wrote: > > > > On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: > > > > > On 15/01/2021 11:26, Jakob Alvermark wrote: > > > > > > Hi, > > > > > > > > > > > > > > > > > > When rebooting my thinkpad the 'bufdaemon' times out: > > > > > > > > > > > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... > > > > > > timed > > > > > > out > > > > > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to > > > > > > stop > > > > > > ... timed out > > > > > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to > > > > > > stop > > > > > > ... timed out > > > > > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to > > > > > > stop > > > > > > ... timed out > > > > > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to > > > > > > stop > > > > > > ... timed out > > > > > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to > > > > > > stop > > > > > > ... timed out > > > > > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to > > > > > > stop > > > > > > ... timed out > > > > > > > > > > > > > > > > > > This started happening recently (within the last week I think). > > > > > > > > > > Hi, > > > > > > > > > > I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare > > > > > metal. > > > > > > > > > > 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of > > > > > orphaned > > > > > groups) "seems" ok > > > > > > > > > > cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP > > > > > support), affected by the timeout. > > > > > > > > > > I haven't tried the intermediate commit yet. > > > > > > > > > > My intel machine doesn't seem to be affected > > > > > > > > If you revert only 9e680e4005b7, is it fixed ? > > > > > > > Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 > > > tests, > > > I can do more if you want) > > Please show me the output from sysctl > > kern.timecounter > > kern.eventtimer > > and first 100 lines of dmesg from the verbose boot (that contains the CPU > > ident lines). > > > > I put the /var/run/dmesg.boot file on freefall /home/mikael/dmesg.boot (it > seems to be truncated though, I don't know how to retrieve the full log) > > sysctl kern.timecounter > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > dummy(-100) > kern.timecounter.hardware: TSC-low > kern.timecounter.alloweddeviation: 5 > kern.timecounter.timehands_count: 2 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 1470549582 > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.counter: 378058131 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 20425 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.tc.TSC-low.frequency: 1900039387 > kern.timecounter.tc.TSC-low.counter: 2386729797 > kern.timecounter.tc.TSC-low.mask: 4294967295 > > sysctl kern.eventtimer > kern.eventtimer.choice: LAPIC(600) HPET(350) HPET1(350) HPE
Re: Waiting for bufdaemon
On 15/01/2021 16:45, Konstantin Belousov wrote: On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote: On 15/01/2021 16:02, Konstantin Belousov wrote: On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: On 15/01/2021 11:26, Jakob Alvermark wrote: Hi, When rebooting my thinkpad the 'bufdaemon' times out: Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ... timed out This started happening recently (within the last week I think). Hi, I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned groups) "seems" ok cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP support), affected by the timeout. I haven't tried the intermediate commit yet. My intel machine doesn't seem to be affected If you revert only 9e680e4005b7, is it fixed ? Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests, I can do more if you want) Please show me the output from sysctl kern.timecounter kern.eventtimer and first 100 lines of dmesg from the verbose boot (that contains the CPU ident lines). I put the /var/run/dmesg.boot file on freefall /home/mikael/dmesg.boot (it seems to be truncated though, I don't know how to retrieve the full log) sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 1470549582 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 378058131 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 20425 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1900039387 kern.timecounter.tc.TSC-low.counter: 2386729797 kern.timecounter.tc.TSC-low.mask: 4294967295 sysctl kern.eventtimer kern.eventtimer.choice: LAPIC(600) HPET(350) HPET1(350) HPET2(350) i8254(100) RTC(0) kern.eventtimer.et.HPET2.quality: 350 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET1.quality: 350 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET.quality: 350 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.LAPIC.quality: 600 kern.eventtimer.et.LAPIC.frequency: 50001034 kern.eventtimer.et.LAPIC.flags: 7 kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote: > On 15/01/2021 16:02, Konstantin Belousov wrote: > > On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: > > > On 15/01/2021 11:26, Jakob Alvermark wrote: > > > > Hi, > > > > > > > > > > > > When rebooting my thinkpad the 'bufdaemon' times out: > > > > > > > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed > > > > out > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop > > > > ... timed out > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop > > > > ... timed out > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop > > > > ... timed out > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop > > > > ... timed out > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop > > > > ... timed out > > > > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop > > > > ... timed out > > > > > > > > > > > > This started happening recently (within the last week I think). > > > > > > Hi, > > > > > > I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. > > > > > > 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of > > > orphaned > > > groups) "seems" ok > > > > > > cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP > > > support), affected by the timeout. > > > > > > I haven't tried the intermediate commit yet. > > > > > > My intel machine doesn't seem to be affected > > > > If you revert only 9e680e4005b7, is it fixed ? > > > Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests, > I can do more if you want) Please show me the output from sysctl kern.timecounter kern.eventtimer and first 100 lines of dmesg from the verbose boot (that contains the CPU ident lines). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 15/01/2021 16:02, Konstantin Belousov wrote: On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: On 15/01/2021 11:26, Jakob Alvermark wrote: Hi, When rebooting my thinkpad the 'bufdaemon' times out: Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ... timed out This started happening recently (within the last week I think). Hi, I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned groups) "seems" ok cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP support), affected by the timeout. I haven't tried the intermediate commit yet. My intel machine doesn't seem to be affected If you revert only 9e680e4005b7, is it fixed ? Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests, I can do more if you want) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 1/15/21 3:56 PM, Mikaël Urankar wrote: On 15/01/2021 11:26, Jakob Alvermark wrote: Hi, When rebooting my thinkpad the 'bufdaemon' times out: Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ... timed out This started happening recently (within the last week I think). Hi, I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned groups) "seems" ok cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP support), affected by the timeout. I haven't tried the intermediate commit yet. My intel machine doesn't seem to be affected I observed the same here. It seems to only happen on my AMD laptop. I have an Intel laptop which seems fine. Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: > On 15/01/2021 11:26, Jakob Alvermark wrote: > > Hi, > > > > > > When rebooting my thinkpad the 'bufdaemon' times out: > > > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed > > out > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop > > ... timed out > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop > > ... timed out > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop > > ... timed out > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop > > ... timed out > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop > > ... timed out > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop > > ... timed out > > > > > > This started happening recently (within the last week I think). > > Hi, > > I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. > > 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned > groups) "seems" ok > > cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP > support), affected by the timeout. > > I haven't tried the intermediate commit yet. > > My intel machine doesn't seem to be affected If you revert only 9e680e4005b7, is it fixed ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 15/01/2021 11:26, Jakob Alvermark wrote: Hi, When rebooting my thinkpad the 'bufdaemon' times out: Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ... timed out This started happening recently (within the last week I think). Hi, I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned groups) "seems" ok cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP support), affected by the timeout. I haven't tried the intermediate commit yet. My intel machine doesn't seem to be affected ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Hi, there, im having the same issue here ( AMD Ryzen7). i do not use mrsas but in my case even if i try to reboot immediately after a fresh reboot i get the timeouts. Regards Santiago Original message From: Juraj Lutter Date: 15/01/2021 12:17 (GMT+01:00) To: freebsd-current@freebsd.org Subject: Re: Waiting for bufdaemon > On 15 Jan 2021, at 12:10, Yasuhiro Kimura wrote:> > From: Jakob Alvermark > Subject: Waiting for bufdaemon> Date: Fri, 15 Jan 2021 11:26:47 +0100> >> When rebooting my thinkpad the 'bufdaemon' times out:>> >> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop>> ... timed out>> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop>> ... timed out>> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop>> ... timed out>> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop>> ... timed out>> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop>> ... timed out>> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop>> ... timed out>> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop>> ... timed out>> >> >> This started happening recently (within the last week I think).>> >> >> Any ideas?> > I have been experiencing same problem with my 13-CURRENT amd64> VirtualBox VM for about a month. The conditions that the problem> happens are unclear and all what I can say is> > * It happens only after I login in the VM and do something for a> while. If I boot the VM and shut it down immediately, it never> happens.> * When the problem happens, one or more unkillable processes seem to> be left.I have been fighting with situations like this for month or two, opened more PRs about it.My observation was that after putting some load on the machine, mysterious mrsas(4)timeouts started to happen, processes were unkillable, reboots could not complete in time...For sake of bisect, main-c255656-gb500c184b656 is known to work OK for me as of now.___freebsd-curr...@freebsd.org mailing listhttps://lists.freebsd.org/mailman/listinfo/freebsd-currentTo unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
> On 15 Jan 2021, at 12:10, Yasuhiro Kimura wrote: > > From: Jakob Alvermark > Subject: Waiting for bufdaemon > Date: Fri, 15 Jan 2021 11:26:47 +0100 > >> When rebooting my thinkpad the 'bufdaemon' times out: >> >> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop >> ... timed out >> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop >> ... timed out >> >> >> This started happening recently (within the last week I think). >> >> >> Any ideas? > > I have been experiencing same problem with my 13-CURRENT amd64 > VirtualBox VM for about a month. The conditions that the problem > happens are unclear and all what I can say is > > * It happens only after I login in the VM and do something for a > while. If I boot the VM and shut it down immediately, it never > happens. > * When the problem happens, one or more unkillable processes seem to > be left. I have been fighting with situations like this for month or two, opened more PRs about it. My observation was that after putting some load on the machine, mysterious mrsas(4) timeouts started to happen, processes were unkillable, reboots could not complete in time... For sake of bisect, main-c255656-gb500c184b656 is known to work OK for me as of now. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On 1/15/21 11:53 AM, Konstantin Belousov wrote: On Fri, Jan 15, 2021 at 11:26:47AM +0100, Jakob Alvermark wrote: Hi, When rebooting my thinkpad the 'bufdaemon' times out: Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ... timed out This started happening recently (within the last week I think). Any ideas? It is bare metal install, right? Yes, this is a Thinkpad X395 (AMD Ryzen 5 PRO 3500U) Do you see any mis-handling of time or timeouts while the system operates? My webcam (using webcamd) seems to be a little flakey, but that's about the only thing I have noticed. Can you bisect it? I could try, but it will take some time, it seems this only happens when system has been running for a while. Rebooting right after a boot does not show this behavior. Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
From: Jakob Alvermark Subject: Waiting for bufdaemon Date: Fri, 15 Jan 2021 11:26:47 +0100 > When rebooting my thinkpad the 'bufdaemon' times out: > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop > ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop > ... timed out > > > This started happening recently (within the last week I think). > > > Any ideas? I have been experiencing same problem with my 13-CURRENT amd64 VirtualBox VM for about a month. The conditions that the problem happens are unclear and all what I can say is * It happens only after I login in the VM and do something for a while. If I boot the VM and shut it down immediately, it never happens. * When the problem happens, one or more unkillable processes seem to be left. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
On Fri, Jan 15, 2021 at 11:26:47AM +0100, Jakob Alvermark wrote: > Hi, > > > When rebooting my thinkpad the 'bufdaemon' times out: > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ... > timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ... > timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ... > timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ... > timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ... > timed out > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ... > timed out > > > This started happening recently (within the last week I think). > > > Any ideas? It is bare metal install, right? Do you see any mis-handling of time or timeouts while the system operates? Can you bisect it? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Waiting for bufdaemon
Hi, When rebooting my thinkpad the 'bufdaemon' times out: Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ... timed out Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ... timed out This started happening recently (within the last week I think). Any ideas? Thanks, Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
