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 ki
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, si
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.timec
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 tha
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 tim
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
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 b
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 K
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, shou
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 exp
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 nich
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
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
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
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 hypervi
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
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
>>> happe
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 m
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 amd6
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.
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 th
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 w
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 Kons
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:
> O
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
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 Hurli
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:
> O
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 Alverm
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
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
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 ref
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
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,
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 followin
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 p
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) &&
> CP
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:
> >>
> >>
>
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,
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
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
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 299
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
(
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
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,
>
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
> 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
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
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
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 Uranka
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 t
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 th
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
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
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 6
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)
@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:>>
> 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
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
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 second
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 ...
> tim
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
.
62 matches
Mail list logo
