Re: Waiting for bufdaemon

[Chris]

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

[Mark Millard via freebsd-current]

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: timecounter frequency
kern.timecounter.tc.HPET.counter: current timecounter value
kern.timecounter.tc.HPET.mask: mask for 

Re: Waiting for bufdaemon

[Michael Gmelin]

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

[Yasuhiro Kimura]

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

[Konstantin Belousov]

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: Problem compiling gcc10

[Dimitry Andric]

On 5 Mar 2021, at 18:19, Filippo Moretti via freebsd-current 
 wrote:
> 
> The following is the error while compiling on:
> [root@sting /usr/ports]# uname -aFreeBSD sting 14.0-CURRENT FreeBSD 
> 14.0-CURRENT #32 main-n245104-dfff1de729b: Fri Feb 26 12:08:40 CET 2021 
> root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64
> 
> gmake[6]: *** [Makefile:1212: multi-do] Error 1gmake[6]: Leaving directory 
> '/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr 
> eebsd14.0/libgcc'gmake[5]: *** [Makefile:127: all-multi] Error 2gmake[5]: *** 
> Waiting for unfinished jobsgmake[5]: Leaving directory 
> '/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr 
> eebsd14.0/libgcc'gmake[4]: *** [Makefile:17599: all-stage1-target-libgcc] 
> Error 2gmake[4]: Leaving directory 
> '/usr/ports/lang/gcc10/work/.build'gmake[3]: *** [Makefile:22903: 
> stage1-bubble] Error 2gmake[3]: Leaving directory 
> '/usr/ports/lang/gcc10/work/.build'gmake[2]: *** [Makefile:23235: 
> bootstrap-lean] Error 2gmake[2]: Leaving directory 
> '/usr/ports/lang/gcc10/work/.build'===> Compilation failed unexpectedly.Try 
> to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure tothe 
> maintainer.*** Error code 1Stop.make[1]: stopped in /usr/ports/lang/gcc10*** 
> Error code 1

Hi Filippo,

Unfortunately the actual error is earlier in the build, so it is not
shown, and your log is wrapped very strangely. Can you run the build
under script(1) and upload a full build log somewhere?

Alternatively, you can set MAKE_JOBS_UNSAFE=yes so it would use a single
job make, and it should then show the error more clearly at the end. But
this is likely to take a bit longer to build.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: java web start / error

[Graham Perrin]

On 05/03/2021 14:01, Antonio Olivares wrote:

On Thu, Mar 4, 2021 at 8:39 PM Graham Perrin  wrote:

On 05/03/2021 00:53, Antonio Olivares wrote:

… It had worked before since a while.  But 2 updates ago I see this error
message on 12.2-RELEASE-amd64-p4 and it also happens on 13.0-BETA4 .  How
can I troubleshoot this?  javaws was used before, it opened up an *.jlnp
file.  Upon successfully loading an online gradebook is started.  I had
been using it successfully for several FreeBSD releases since 8.1/8.2. …

With which web browsers?

___
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"

worked well with firefox-esr which I use because the plugins
are deprecated using the newer firefox.  Despite that it also used to
work with the regular firefox.

On rare occasions in the past, I used Opera for pages that required a 
Java plug-in.


Today I find www/opera no longer working (with 14.0-CURRENT). Whilst 
non-secure  works, 
 and some other types of secure 
page no longer load. In any case, 
 it has 
been removed from ports.


Maybe you can run a Java Web Start compatible browser in a jail, or 
Linuxulator?


___
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"

Problem compiling gcc10

[Filippo Moretti via freebsd-current]

The following is the error while compiling on:
[root@sting /usr/ports]# uname -aFreeBSD sting 14.0-CURRENT FreeBSD 
14.0-CURRENT #32 main-n245104-dfff1de729b: Fri Feb 26 12:08:40 CET 2021 
root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64





gmake[6]: *** [Makefile:1212: multi-do] Error 1gmake[6]: Leaving directory 
'/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr eebsd14.0/libgcc'gmake[5]: 
*** [Makefile:127: all-multi] Error 2gmake[5]: *** Waiting for unfinished 
jobsgmake[5]: Leaving directory 
'/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr eebsd14.0/libgcc'gmake[4]: 
*** [Makefile:17599: all-stage1-target-libgcc] Error 2gmake[4]: Leaving 
directory '/usr/ports/lang/gcc10/work/.build'gmake[3]: *** [Makefile:22903: 
stage1-bubble] Error 2gmake[3]: Leaving directory 
'/usr/ports/lang/gcc10/work/.build'gmake[2]: *** [Makefile:23235: 
bootstrap-lean] Error 2gmake[2]: Leaving directory 
'/usr/ports/lang/gcc10/work/.build'===> Compilation failed unexpectedly.Try to 
set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure tothe 
maintainer.*** Error code 1Stop.make[1]: stopped in /usr/ports/lang/gcc10*** 
Error code 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: xfig menu on xfce

[Antonio Olivares]

On Fri, Mar 5, 2021 at 3:34 AM Guido Falsi 
> > Thanks for reporting it!
>
> Filed bug report with patch:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254031
>
> --
> Guido Falsi 

Thank you very much for filing bug and for submitting patch.  Great Job!

Best Regards,


Antonio
___
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: java web start / error

[Antonio Olivares]

On Thu, Mar 4, 2021 at 8:39 PM Graham Perrin  wrote:
>
> On 05/03/2021 00:53, Antonio Olivares wrote:
> > … It had worked before since a while.  But 2 updates ago I see this error
> > message on 12.2-RELEASE-amd64-p4 and it also happens on 13.0-BETA4 .  How
> > can I troubleshoot this?  javaws was used before, it opened up an *.jlnp
> > file.  Upon successfully loading an online gradebook is started.  I had
> > been using it successfully for several FreeBSD releases since 8.1/8.2. …
>
> With which web browsers?
>
> ___
> 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"

worked well with firefox-esr which I use because the plugins
are deprecated using the newer firefox.  Despite that it also used to
work with the regular firefox.

Best Regards,


Antonio
___
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: xfig menu on xfce

[Guido Falsi via freebsd-current]

On 04/03/21 21:16, Guido Falsi via freebsd-current wrote:

On 04/03/21 20:56, Antonio Olivares wrote:
On Thu, Mar 4, 2021 at 1:55 PM Antonio Olivares 
 wrote:


On Thu, Mar 4, 2021 at 1:51 PM David Wolfskill  
wrote:


On Thu, Mar 04, 2021 at 01:47:03PM -0600, Antonio Olivares wrote:

xfig installed from pkg
on the menu click on xfce we get error message


Failed to execute command "/usr/bin/xfig".
Failed to execute child process "/usr/bin/xfig" (No such file or 
directory)

x Close


running from command line does work.  which xfig reports
/usr/local/bin/xfig

olivares@deepcool:~ $ which xfig
/usr/local/bin/xfig
olivares@deepcool:~ $ uname -a
FreeBSD deepcool 13.0-BETA4 FreeBSD 13.0-BETA4 #0
releng/13.0-n244592-e32bc253629: Fri Feb 26 06:17:34 UTC 2021
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
olivares@deepcool:~ $

Best Regards,



I am unfamiliar with xfce, but that seems like a bug in the menu entry
itself.  Not sure whose responsibility that is

Peace,
david


I do not know how to edit the link, but it is not a big deal.  It runs
from comand line.


Menu entries are created fort all desktop environments creating files 
defined by common standards. Each installed software is responsible for 
creating the correct file. (".desktop" files)


Looking at xfig port the desktop entry provided by upstream has that 
patch coded in. The port is not patching it. The error you see would 
happen with any desktop environment in FreeBSD. I'll provide a patch to 
fix this.


Thanks for reporting it!


Filed bug report with patch:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254031

--
Guido Falsi 
___
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"