date:20210120

Re: Waiting for bufdaemon

2021-01-20 Thread Jakob Alvermark




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: boot loader blank screen

2021-01-20 Thread Jakob Alvermark



On 1/14/21 8:15 AM, Jakob Alvermark wrote:


On 1/14/21 4:49 AM, monochrome wrote:
I should add my experience to this since its different and haven't 
seen anyone else mention it.
I see the new boot loader, it's not blank, but its large text, and 
it's very SLOW.
I can see each char drawn, and then when it gets to the bottom and 
has to redraw all the lines to scroll up for new lines, it loads so 
slowly it's like watching an 8086 on a 300 baud modem, or slower! 
Takes like an extra 30 seconds to get through all the loaded modules, 
then back to normal speed boot with the same large font.


added these lines and everything is back to normal with new 
appearance and small font like before, and at normal speed.

hw.vga.textmode="0"
vbe_max_resolution=1280x800

also removed the old lines for the amdgpu efi problem with no effect 
so I assume those are no longer necessary and why I'm seeing this 
change?

#hw.syscons.disable=1
#kern.vty=vt
#hw.vga.textmode=1

am using X and everything seems fine for now

system:
AMD Ryzen 5 2400G, using integrated vega GPU
ASRock B450M Pro4
13-current



On 1/5/21 8:54 PM, David Wolfskill wrote:

On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote:

...
the 58661b3ba9eb should hopefully fix the loader text mode issue, 
it would be cool if you can verify:)


thanks,
toomas


I think, I got it fixed (at least idwer did confirm for his system, 
thanks). If you can test this patch: 
http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch 
 
it would be really nice.


thanks,
toomas


I tested with each of the following "stanzas' in /boot/loader.conf,
using vt (vs. syscons) in each case (though that breaks video reset
on resume after suspend):

# hw.vga.textmode="0"
vbe_max_resolution=1280x800

This works, and provides a graphical console (depth 32).


hw.vga.textmode="0"
# vbe_max_resolution=1280x800

This also works, and provides a low-resolution (and depth 16)
graphical console (800x320 or something similar, IIRC).


# hw.vga.textmode="0"
# vbe_max_resolution=1280x800

(That is, not specifying anything for hw.vga.textmode or
vbe_max_resolution.)

This boots OK, but I see no kernel probe messages or single- to
multi-user mode messages.  I can use (e.g.) Ctl+Alt+F2 to switch to
vty1, see a "login: " prompt, and that (also) works.  (This is the
initial symptom I had reported.)


hw.vga.textmode="1"
# vbe_max_resolution=1280x800

This works -- boots OK, and I see kernel probe (&c.) messages; this 
is a

text console (mostly blue text; some white, against a dark background.
It's a medium-light blue, so it's easy enough to read (unlike a navy
blue, for example).


FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 
main-c255601-g9fd96b416c45-dirty: Tue Jan  5 17:24:45 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY 
amd64



+1 on the slowness.

I like the graphics mode, it's very pretty.

But slow. It seems to depend a lot on the screen resolution. On my 
small laptop, 1366x768, it's fairly OK. On the 1080p laptop it is very 
much slower, it takes about 35 seconds longer compared to the old loader.


Booting on a 4K monitor, well, I didn't time it...


Observations with the current version:

1. The font is now a lot smaller.

2. It feels quicker. However, still a bit slow. Something that seems 
very slow is clearing the screen. It's like pulling down a curtain slowly.


3. Booting on the 4k monitor does not work now. Loader looks alright, 
but when it hands over to the kernel, the screen just goes blank, and 
the machine hangs. This worked before.



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

2021-01-20 Thread 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 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

2021-01-20 Thread Jakob Alvermark


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

2021-01-20 Thread Rainer Hurling

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: DRM problem installing kernel on main-c561-gc3e75b6c1

2021-01-20 Thread Thomas Laus

On 1/19/21 4:18 PM, Emmanuel Vadot wrote:
> 
>  drm-current-kmod will also install its sources in /usr/local/sys/ and
> this will get built with buildkernel. The problem is that if the
> package is old (and it is right now) you might have sources that either
> don't compile or don't work correctly.
>
For years, I have been building world and kernel on a faster PC and just
exporting /usr/src and /usr/obj for installation on other computers.
Now it looks like it will require exporting /usr/local/sys as well to
allow a installation of the kernel on the slower PC's.  Does placing the
drm-current-kmod files in /usr/local/sys during the kernel build agree
with hier(7)layout ?

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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

2021-01-20 Thread 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?
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

2021-01-20 Thread Rainer Hurling

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

2021-01-20 Thread 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.

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

2021-01-20 Thread Rainer Hurling

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

2021-01-20 Thread 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?
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

2021-01-20 Thread Santiago Martinez

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: VM UMA counters.

2021-01-20 Thread Mark Johnston

On Tue, Jan 19, 2021 at 12:44:14PM +, Santiago Martinez wrote:
> Hi there, sorry to ask this as it might be a silly question...
> 
> Since a few weeks im seeing random locks on application and sometimes
> when using truss it show resource temporally unavailable.
>
> Now, checking random things, i see that the
> vm.uma.256_Bucket.stats.fails counter is increasing while the other are
> not (at least for now).
> 
> Here goes the output:
> 
> vm.uma.256_Bucket.stats.xdomain: 0
> vm.uma.256_Bucket.stats.fails: 762142
> vm.uma.256_Bucket.stats.frees: 41935
> vm.uma.256_Bucket.stats.allocs: 42721
> vm.uma.256_Bucket.stats.current: 786
> 
> root@tucho:/home/smartinez # uname -a
> FreeBSD tucho 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #13
> main-c256107-g7d3310c4fcdd: Tue Jan 19 10:50:12 GMT 2021
> smartinez@tucho:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64
> 
> My question is, is this the expected behavior?

There are situations where bucket allocations must fail to avoid
recursing back into the VM.  For instance, allocation of a UMA slab may
require allocation of a radix node entry from UMA, which may attempt
allocation of a bucket, which could trigger allocation of a slab.

It's therefore normal to see a non-zero number of failures after
booting, but after that the bucket zone's caches are populated and
failures should become rare.  Failures might also be triggered during
severe memory shortages.  Could you show vmstat -s from an affected
system?  Are you using any DRM graphics drivers by any chance?
___
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

2021-01-20 Thread Santiago Martinez

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: VM UMA counters.

2021-01-20 Thread Santiago Martinez

Hi Mark,

To the DRM question, indeed I am using drm-devel with amdgpu.

Here is the vmstat -s output.

Cheers

Santiago

root@tucho:/home/smartinez # vmstat -s
1882578 cpu context switches
100445 device interrupts
23777 software interrupts
1054356 traps
13811750 system calls
39 kernel threads created
1398  fork() calls
343 vfork() calls
84 rfork() calls
0 swap pager pageins
0 swap pager pages paged in
0 swap pager pageouts
0 swap pager pages paged out
12579 vnode pager pageins
138821 vnode pager pages paged in
4 vnode pager pageouts
37 vnode pager pages paged out
0 page daemon wakeups
160056 pages examined by the page daemon
0 clean page reclamation shortfalls
0 pages reactivated by the page daemon
194549 copy-on-write faults
190 copy-on-write optimized faults
697804 zero fill pages zeroed
0 zero fill pages prezeroed
2559 intransit blocking page faults
1018606 total VM faults taken
12262 page faults requiring I/O
0 pages affected by kernel thread creation
138718 pages affected by  fork()
12177 pages affected by vfork()
14704 pages affected by rfork()
746501 pages freed
0 pages freed by daemon
338813 pages freed by exiting processes
418069 pages active
200941 pages inactive
1123 pages in the laundry queue
513309 pages wired down
32 virtual user pages wired down
7003759 pages free
4096 bytes per page
4311229 total name lookups
cache hits (94% pos + 2% neg) system 0% per-directory
deletions 0%, falsehits 0%, toolong 0%


On 1/20/21 2:17 PM, Mark Johnston wrote:
> On Tue, Jan 19, 2021 at 12:44:14PM +, Santiago Martinez wrote:
>> Hi there, sorry to ask this as it might be a silly question...
>>
>> Since a few weeks im seeing random locks on application and sometimes
>> when using truss it show resource temporally unavailable.
>>
>> Now, checking random things, i see that the
>> vm.uma.256_Bucket.stats.fails counter is increasing while the other are
>> not (at least for now).
>>
>> Here goes the output:
>>
>> vm.uma.256_Bucket.stats.xdomain: 0
>> vm.uma.256_Bucket.stats.fails: 762142
>> vm.uma.256_Bucket.stats.frees: 41935
>> vm.uma.256_Bucket.stats.allocs: 42721
>> vm.uma.256_Bucket.stats.current: 786
>>
>> root@tucho:/home/smartinez # uname -a
>> FreeBSD tucho 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #13
>> main-c256107-g7d3310c4fcdd: Tue Jan 19 10:50:12 GMT 2021
>> smartinez@tucho:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64
>>
>> My question is, is this the expected behavior?
> There are situations where bucket allocations must fail to avoid
> recursing back into the VM.  For instance, allocation of a UMA slab may
> require allocation of a radix node entry from UMA, which may attempt
> allocation of a bucket, which could trigger allocation of a slab.
>
> It's therefore normal to see a non-zero number of failures after
> booting, but after that the bucket zone's caches are populated and
> failures should become rare.  Failures might also be triggered during
> severe memory shortages.  Could you show vmstat -s from an affected
> system?  Are you using any DRM graphics drivers by any chance?
> ___
> 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: VM UMA counters.

2021-01-20 Thread Mark Johnston

On Wed, Jan 20, 2021 at 02:24:59PM +, Santiago Martinez wrote:
> Hi Mark,
> 
> To the DRM question, indeed I am using drm-devel with amdgpu.

Have you updated to commit 4af932354260 or later?  That helps address a
memory reclamation bug triggered by amdgpu.

> Here is the vmstat -s output.

I guess this is from a fresh boot?  It would be most useful to see 
vmstat -s output taken at a time when the number of bucket allocation
failures is also increasing.  But, please try updating first to see if
the lockups persist.
___
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: VM UMA counters.

2021-01-20 Thread Santiago Martinez

yes that correct, just booted with the patch applied for the bufdaemon .

Will keep an eye on it, and let you know how it goes.

Any specific values that i should look on vmstat?

Santiago


On 1/20/21 2:30 PM, Mark Johnston wrote:
> On Wed, Jan 20, 2021 at 02:24:59PM +, Santiago Martinez wrote:
>> Hi Mark,
>>
>> To the DRM question, indeed I am using drm-devel with amdgpu.
> Have you updated to commit 4af932354260 or later?  That helps address a
> memory reclamation bug triggered by amdgpu.
>
>> Here is the vmstat -s output.
> I guess this is from a fresh boot?  It would be most useful to see 
> vmstat -s output taken at a time when the number of bucket allocation
> failures is also increasing.  But, please try updating first to see if
> the lockups persist.
> ___
> 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

2021-01-20 Thread 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 ...


> 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: VM UMA counters.

2021-01-20 Thread Mark Johnston

On Wed, Jan 20, 2021 at 02:34:28PM +, Santiago Martinez wrote:
> yes that correct, just booted with the patch applied for the bufdaemon .
> 
> Will keep an eye on it, and let you know how it goes.
> 
> Any specific values that i should look on vmstat?

The ones I'm interested in are:

0 page daemon wakeups
160056 pages examined by the page daemon
0 clean page reclamation shortfalls
0 pages reactivated by the page daemon
0 pages freed by daemon

In particular I wanted to see if any clean page reclamation shortfalls
had occurred, since that indicates a severe free memory shortage which
could be responsible for UMA allocation failures.

> 
> On 1/20/21 2:30 PM, Mark Johnston wrote:
> > On Wed, Jan 20, 2021 at 02:24:59PM +, Santiago Martinez wrote:
> >> Hi Mark,
> >>
> >> To the DRM question, indeed I am using drm-devel with amdgpu.
> > Have you updated to commit 4af932354260 or later?  That helps address a
> > memory reclamation bug triggered by amdgpu.
> >
> >> Here is the vmstat -s output.
> > I guess this is from a fresh boot?  It would be most useful to see 
> > vmstat -s output taken at a time when the number of bucket allocation
> > failures is also increasing.  But, please try updating first to see if
> > the lockups persist.
> > ___
> > 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

2021-01-20 Thread 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.
___
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

2021-01-20 Thread Rainer Hurling

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

2021-01-20 Thread Santiago Martinez

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: DRM problem installing kernel on main-c561-gc3e75b6c1

2021-01-20 Thread Pete Wright





On 1/19/21 11:55 PM, Emmanuel Vadot wrote:



i'm happy now running the current-kmod but let me know if it'd be
helpful to do any more tests or provide additional info.

  So what did you change ?



ok i think i spot the issue - in my checkout of the ports tree via the 
github mirror at git://github.com/freebsd/freebsd-ports.git it looks 
like the pkg-plist doesn't include the %%SOURCE%%KMODSRC%% statements:


$ cat pkg-plist
%%AMDGPU%%/%%KMODDIR%%/amdgpu.ko
%%AMDKFD%%/%%KMODDIR%%/amdkfd.ko
/%%KMODDIR%%/drm.ko
%%I915%%/%%KMODDIR%%/i915kms.ko
/%%KMODDIR%%/linuxkpi_gplv2.ko
/%%KMODDIR%%/radeonkms.ko
/%%KMODDIR%%/ttm.ko
$

on the drm-current-kmod plist things look as we would expect them i believe:
$ head pkg-plist
%%AMDGPU%%/%%KMODDIR%%/amdgpu.ko
/%%KMODDIR%%/drm.ko
%%I915%%/%%KMODDIR%%/i915kms.ko
/%%KMODDIR%%/linuxkpi_gplv2.ko
/%%KMODDIR%%/radeonkms.ko
/%%KMODDIR%%/ttm.ko
%%SOURCEKMODSRC%%/Makefile
%%SOURCEKMODSRC%%/kconfig.mk
%%SOURCEKMODSRC%%/amd/Makefile
%%SOURCEKMODSRC%%/amd/amdgpu/Makefile
$


I can file a PR with a patch later today if that's helpful, if this 
isn't due to bad git workspace on my end.


cheers,
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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

2021-01-20 Thread Rainer Hurling

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: DRM problem installing kernel on main-c561-gc3e75b6c1

2021-01-20 Thread Emmanuel Vadot

On Wed, 20 Jan 2021 09:47:28 -0800
Pete Wright  wrote:

> 
> 
> On 1/19/21 11:55 PM, Emmanuel Vadot wrote:
> >
> >> i'm happy now running the current-kmod but let me know if it'd be
> >> helpful to do any more tests or provide additional info.
> >   So what did you change ?
> 
> 
> ok i think i spot the issue - in my checkout of the ports tree via the 
> github mirror at git://github.com/freebsd/freebsd-ports.git it looks 
> like the pkg-plist doesn't include the %%SOURCE%%KMODSRC%% statements:
> 
> $ cat pkg-plist
> %%AMDGPU%%/%%KMODDIR%%/amdgpu.ko
> %%AMDKFD%%/%%KMODDIR%%/amdkfd.ko
> /%%KMODDIR%%/drm.ko
> %%I915%%/%%KMODDIR%%/i915kms.ko
> /%%KMODDIR%%/linuxkpi_gplv2.ko
> /%%KMODDIR%%/radeonkms.ko
> /%%KMODDIR%%/ttm.ko
> $
> 
> on the drm-current-kmod plist things look as we would expect them i believe:
> $ head pkg-plist
> %%AMDGPU%%/%%KMODDIR%%/amdgpu.ko
> /%%KMODDIR%%/drm.ko
> %%I915%%/%%KMODDIR%%/i915kms.ko
> /%%KMODDIR%%/linuxkpi_gplv2.ko
> /%%KMODDIR%%/radeonkms.ko
> /%%KMODDIR%%/ttm.ko
> %%SOURCEKMODSRC%%/Makefile
> %%SOURCEKMODSRC%%/kconfig.mk
> %%SOURCEKMODSRC%%/amd/Makefile
> %%SOURCEKMODSRC%%/amd/amdgpu/Makefile
> $
> 
> 
> I can file a PR with a patch later today if that's helpful, if this 
> isn't due to bad git workspace on my end.
> 
> cheers,
> -pete
> 
> -- 
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA

 drm-devel-kmod doesn't install the sources on purpose.
 It never had and never will.

 So, did you "solve" the problem by switching to drm-current-kmod or to
drm-devel-kmod ?

-- 
Emmanuel Vadot  
___
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: DRM problem installing kernel on main-c561-gc3e75b6c1

2021-01-20 Thread Pete Wright





On 1/20/21 11:09 AM, Emmanuel Vadot wrote:

On Wed, 20 Jan 2021 09:47:28 -0800
Pete Wright  wrote:



On 1/19/21 11:55 PM, Emmanuel Vadot wrote:

i'm happy now running the current-kmod but let me know if it'd be
helpful to do any more tests or provide additional info.

   So what did you change ?


ok i think i spot the issue - in my checkout of the ports tree via the
github mirror at git://github.com/freebsd/freebsd-ports.git it looks
like the pkg-plist doesn't include the %%SOURCE%%KMODSRC%% statements:

$ cat pkg-plist
%%AMDGPU%%/%%KMODDIR%%/amdgpu.ko
%%AMDKFD%%/%%KMODDIR%%/amdkfd.ko
/%%KMODDIR%%/drm.ko
%%I915%%/%%KMODDIR%%/i915kms.ko
/%%KMODDIR%%/linuxkpi_gplv2.ko
/%%KMODDIR%%/radeonkms.ko
/%%KMODDIR%%/ttm.ko
$

on the drm-current-kmod plist things look as we would expect them i believe:
$ head pkg-plist
%%AMDGPU%%/%%KMODDIR%%/amdgpu.ko
/%%KMODDIR%%/drm.ko
%%I915%%/%%KMODDIR%%/i915kms.ko
/%%KMODDIR%%/linuxkpi_gplv2.ko
/%%KMODDIR%%/radeonkms.ko
/%%KMODDIR%%/ttm.ko
%%SOURCEKMODSRC%%/Makefile
%%SOURCEKMODSRC%%/kconfig.mk
%%SOURCEKMODSRC%%/amd/Makefile
%%SOURCEKMODSRC%%/amd/amdgpu/Makefile
$


I can file a PR with a patch later today if that's helpful, if this
isn't due to bad git workspace on my end.

cheers,
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

  drm-devel-kmod doesn't install the sources on purpose.
  It never had and never will.

  So, did you "solve" the problem by switching to drm-current-kmod or to
drm-devel-kmod ?


ah i see, thanks for the clarification.

so as of now i'm using the drm-current-kmod on my amdgpu system. using 
the drm-devel-kmod throws the previously reported error trying to load 
linuxkpi_gplv2.ko:


KLD drm.ko: depends on linuxkpi_gplv2 - not available or version mismatch
linker_load_file: /boot/modules/drm.ko - unsupported file type
KLD amdgpu.ko: depends on drmn - not available or version mismatch
linker_load_file: /boot/modules/amdgpu.ko - unsupported file type

-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

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

Can In-Kernel TLS (kTLS) work with any OpenSSL Application?

2021-01-20 Thread Neel Chauhan


Hi freebsd-current@,

I know that In-Kernel TLS was merged into the FreeBSD HEAD tree a while 
back.


With 13.0-RELEASE around the corner, I'm thinking about upgrading my 
home server, well if I can accelerate any SSL application.


I'm asking because I have a home server on a symmetrical Gigabit 
connection (Google Fiber/Webpass), and that server runs a Tor relay. If 
you're interested in how Tor works, the EFF has a writeup: 
https://www.eff.org/pages/what-tor-relay


But the main point for you all is: more-or-less Tor relays deal with 
1000s TLS connections going into and out of the server.


Would In-Kernel TLS help with an application like Tor (or even load 
balancers/TLS termination), or is it more for things like web servers 
sending static files via sendfile() (e.g. CDN used by Netflix).


My server could also work with Intel's QuickAssist (since it has an 
Intel Xeon "Scalable" CPU). Would QuickAssist SSL be more helpful here?


I'm asking since I don't know whether to upgrade my home server to 13.x 
or leave it at 12.x. Yes, I do know we need a special OpenSSL to use 
kTLS.


-Neel


signature.asc
Description: OpenPGP digital signature

Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld

2021-01-20 Thread Mark Millard

On 2021-Jan-19, at 17:42, Mark Millard  wrote:

> On 2021-Jan-18, at 21:12, Mark Millard  wrote:
> 
>> On 2021-Jan-18, at 19:19, Mark Millard  wrote:
>> 
>>> . . .
 FYI: I re-established my access to a RPi2B V1.1 and made
 it report: "maximum recommended amount (468832 pages)"
 
 (The figure can vary some from release to release.)
 
 468832*4096 == 1920335872 or a little over 1831 MiBytes
 
 For the 4096 Byte pages, that means that the following from
 gpart fits without complaint (size is in blocks, not pages):
 
 4131409923686400  da0p2  freebsd-swap  (1.8G)
 
 3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So
 I've left some room below 1831 MiBytes, but not a lot.
 
 FYI about my build experiment that is running:
 
 # sysctl hw.physmem
 hw.physmem: 979042304
 
 which, in recent times for armv7, I can (and did) set in
 /boot/loader.conf on a faster cortex-A7 SBC (that can boot
 the same media but has more RAM).
 
 So I tried a -j4 build, but with LDFLAGS.lld+= -Wl,--threads=1
 in use and my other particular src.conf/make.conf like content
 (so the builds do likely differ from yours in various ways).
 My build is producing a non-debug build (but with -g symbols).
 Somewhat after where your buildworld.log stops, my odd variant
 of top was reporting:
 
 Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki 
 MaxObs(Act+Wir)
 Swap: . . . , 145832Ki MaxObsUsed
 
 and top was also showing lots of processes as having "0B" RES
 in STATE "wait" or "nanslp" (so, apparently swapped out, not paging).
 ("MaxObs" is short for "maximum observed".)
 
 For comparison, your swapscript.log reported a maximum total of
 346192 KiBytes "Used" for swap, about 98% into the log file.
 
 (Time goes by . . .)
 
 It finished with building libllvm and is part way into building
 libclang. This is probably well past where your hangup happened,
 given that your published buildworldlog file stopped with
 libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows:
 
 Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki 
 MaxObs(Act+Wir)
 Swap: . . . , 392328Ki MaxObsUsed
 
 The build continues to run. I'll let you know how it goes.
 . . .
>>> 
>>> Just after libclang finished my odd top showed:
>>> 
>>> Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892736Ki 
>>> MaxObs(Act+Wir)
>>> Swap: . . . , 537588Ki MaxObsUsed
>>> 
>>> After liblldb:
>>> 
>>> Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 899276Ki 
>>> MaxObs(Act+Wir)
>>> Swap: . . . , 537588Ki MaxObsUsed
>>> 
>>> Much later, after the lldb program had been built:
>>> 
>>> Mem:  . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki 
>>> MaxObs(Act+Wir)
>>> Swap: . . . , 537588Ki MaxObsUsed
>>> 
>> World build completed on Mon Jan 18 19:10:08 PST 2021
>> World built in 72960 seconds, ncpu: 4, make -j4
>>> 
>>> This was building from scratch what was already installed:
>>> 
>>> # ~/fbsd-based-on-what-freebsd-main.sh 
>>> merge-base: 818390ce0ca539300dd15d7a817784f1e3f7a9b8
>>> merge-base: CommitDate: 2021-01-13 21:27:44 +
>>> 4180404713ec (HEAD -> mm-src) mm-src snapshot for mm's patched build in git 
>>> context.
>>> 818390ce0ca5 (freebsd/main, freebsd/HEAD, pure-src, main) arm64: fix early 
>>> devmap assertion
>>> FreeBSD OPiP2E_RPi2v11 13.0-CURRENT FreeBSD 13.0-CURRENT 
>>> mm-src-c255938-g4180404713ec GENERIC-NODBG  arm armv7 1300135 1300135
>>> 
>>> This suggests that you should be able to build on the RPi2B v1.1,
>>> using -j4, with appropriate configuration for what and how to build.
>>> 
>>> 
>>> It is now building the matching kernel, my GENERIC-NODBG style.
>> 
>> Done:
>> 
> Kernel build for GENERIC-NODBG completed on Mon Jan 18 20:33:26 PST 2021
> Kernel(s)  GENERIC-NODBG built in 4998 seconds, ncpu: 4, make -j4
>> 
>> So, World+Kernel in somewhat under 22 hours.
>> 
>> The "MaxObs*" figures were unchanged, so:
>> 
>> Mem:  . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki 
>> MaxObs(Act+Wir)
>> Swap: . . . , 537588Ki MaxObsUsed
>> 
>> This suggests that, for now, 800 MiByte of swap would be something
>> more than 1.5 times what it actually used and 1050 MiBytes would
>> be something like 2.0 times what it actually used, so leaving some
>> notable margin for variations in peek usage, at least when linker
>> threading is avoided.
>> 
>> 
>> 
>> As for what I used to control "what and how to build" . . .
>> 
>> # more 
>> ~/sys_build_scripts.armv7-host/make_armv7_nodebug_clang_bootstrap-armv7-host.sh
>>  
>> kldload -n filemon && \
>> script 
>> ~/sys_typescripts/typescript_make_armv7_nodebug_clang_bootstrap-armv7-host-$(date
>>  +%Y-%m-%d:%H:%M:%S) \
>> env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" 
>> SRC_ENV_CONF="/root/src.conf

FreeBSD 13.0 Build Option Sweep

2021-01-20 Thread Michael Dexter


Hello all,

I have been experimenting with FreeBSD build options on and off since 
FreeBSD 4.8/5.0 for use with minimum jails and later virtual machines.


If you have ever tried to build "without all" and working your way back 
up, you have probably found this to be a very frustrating adventure in 
make-related failures after hours of compilation and, on the darkest 
days, concurrent deletion bugs which would give a different error every 
time you run a build.


Fortunately, with the help of people like Ed Maste, Bryan Drewery, 
Bjoern Zeeb, Kyle Evans, and others, we have been gradually knocking 
broken build options off of the lists generated by the 
tools/tools/build_option_survey that PHK wrote long ago.


An annotated list of working and failing build options in FreeBSD 
13.0-ALPHA1 can be found here:


https://callfortesting.org/results/bos-FreeBSD-13A1/

Two have been fixed and PRs exist for the majority of them with some 
possible fixes for those who know the code best to consider. One broken 
option is a recent regression while one pair, 
WITHOUT_LIBTHR/WITHOUT_LIBPTHREAD is quite stale and is a candidate for 
significant attention or possibly removal.


If you are wondering, as of 13.0-ALPHA1, the following KERNCONF and 
generated /usr/src.conf are the minimum to build FreeBSD and build it in 
a bhyve VM from a UFS-formatted disk image:


cpu HAMMER
ident   LESSBSD
makeoptions MODULES_OVERRIDE="virtio"
options SCHED_ULE
device  pci
device  loop
device  ether
device  uart
device  atpic
device  ahci
device  scbus
options GEOM_PART_GPT
options FFS

sh /usr/src/tools/tools/build_option_survey/listallopts.sh \
| grep -v WITH_ | sed 's/$/=YES/' | \
grep -v WITHOUT_AUTO_OBJ | \
grep -v WITHOUT_UNIFIED_OBJDIR | \
grep -v WITHOUT_CRYPT | \
grep -v WITHOUT_DYNAMICROOT | \
grep -v WITHOUT_LIBCPLUSPLUS | \
grep -v WITHOUT_INSTALLLIB | \
grep -v WITHOUT_LIBTHR | \
grep -v WITHOUT_LIBPTHREAD | \
grep -v WITHOUT_BOOT | \
grep -v WITHOUT_LOADER_LUA | \
grep -v WITHOUT_LOCALES | \
grep -v WITHOUT_ZONEINFO | \
grep -v WITHOUT_VI \
> /etc/src.conf

Explanation/Status:

WITHOUT_AUTO_OBJ and WITHOUT_UNIFIED_OBJDIR belong in src-env.conf and 
kindly instantly warn you of this and terminate the build.


WITHOUT_DYNAMICROOT and WITHOUT_LIBCPLUSPLUS are fixed in CURRENT.

WITHOUT_INSTALLLIB and WITHOUT_LIBCPLUSPLUS should be easy to fix and 
candidate syntax is in the PRs linked in the above link.


WITHOUT_CRYPT has regressed in recent months.

WITHOUT_LIBTHR and WITHOUT_LIBPTHREAD are challenges.

WITHOUT_BOOT onward are optional to build but are needed to boot the VM, 
see a console, set the time zone, and optionally edit files.


The resulting kernel is 5M in size and the world and kernel are 90M. 
Basic networking adds another 1M.


The build times on an EPYC 7402p are:
buildworld 1m43.34s Warm ARC: 1m33.73s
buildkernel 9.35s
installworld 18.75s
installkernel 0.32s
Total: 3m23.44s

Boot time: About three seconds

I sincerely hope that all build options worked at some point and, given 
how much progress has been made, FreeBSD 13.0 can also support all 
options, or at a minimum, abort the build early as appropriate as the 
src-env.conf ones do.


Think of the Developers! Spare them continued frustration with these.

We can do this. I am happy to test any patches on multiple platforms. I 
am also happy to send individuals my minimum VM script and fortunately, 
it is out-of-date with every build option fix.


All the best,

Michael
___
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: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld

2021-01-20 Thread bob prohaska

On Wed, Jan 20, 2021 at 09:51:33AM -0800, Mark Millard wrote:
> On 2021-Jan-19, at 17:42, Mark Millard  wrote:
> 
> > On 2021-Jan-18, at 21:12, Mark Millard  wrote:
> > 
> >> On 2021-Jan-18, at 19:19, Mark Millard  wrote:
> >> 
> >>> . . .
>  FYI: I re-established my access to a RPi2B V1.1 and made
>  it report: "maximum recommended amount (468832 pages)"
>  
>  (The figure can vary some from release to release.)
>  
>  468832*4096 == 1920335872 or a little over 1831 MiBytes
>  
>  For the 4096 Byte pages, that means that the following from
>  gpart fits without complaint (size is in blocks, not pages):
>  
>  4131409923686400  da0p2  freebsd-swap  (1.8G)
>  
>  3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So
>  I've left some room below 1831 MiBytes, but not a lot.
>  
>  FYI about my build experiment that is running:
>  
>  # sysctl hw.physmem
>  hw.physmem: 979042304
>  
>  which, in recent times for armv7, I can (and did) set in
>  /boot/loader.conf on a faster cortex-A7 SBC (that can boot
>  the same media but has more RAM).
>  
>  So I tried a -j4 build, but with LDFLAGS.lld+= -Wl,--threads=1
>  in use and my other particular src.conf/make.conf like content
>  (so the builds do likely differ from yours in various ways).
>  My build is producing a non-debug build (but with -g symbols).
>  Somewhat after where your buildworld.log stops, my odd variant
>  of top was reporting:
>  
>  Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki 
>  MaxObs(Act+Wir)
>  Swap: . . . , 145832Ki MaxObsUsed
>  
>  and top was also showing lots of processes as having "0B" RES
>  in STATE "wait" or "nanslp" (so, apparently swapped out, not paging).
>  ("MaxObs" is short for "maximum observed".)
>  
>  For comparison, your swapscript.log reported a maximum total of
>  346192 KiBytes "Used" for swap, about 98% into the log file.
>  
>  (Time goes by . . .)
>  
>  It finished with building libllvm and is part way into building
>  libclang. This is probably well past where your hangup happened,
>  given that your published buildworldlog file stopped with
>  libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows:
>  
>  Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki 
>  MaxObs(Act+Wir)
>  Swap: . . . , 392328Ki MaxObsUsed
>  
>  The build continues to run. I'll let you know how it goes.
>  . . .
> >>> 
> >>> Just after libclang finished my odd top showed:
> >>> 
> >>> Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892736Ki 
> >>> MaxObs(Act+Wir)
> >>> Swap: . . . , 537588Ki MaxObsUsed
> >>> 
> >>> After liblldb:
> >>> 
> >>> Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 899276Ki 
> >>> MaxObs(Act+Wir)
> >>> Swap: . . . , 537588Ki MaxObsUsed
> >>> 
> >>> Much later, after the lldb program had been built:
> >>> 
> >>> Mem:  . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki 
> >>> MaxObs(Act+Wir)
> >>> Swap: . . . , 537588Ki MaxObsUsed
> >>> 
> >> World build completed on Mon Jan 18 19:10:08 PST 2021
> >> World built in 72960 seconds, ncpu: 4, make -j4
> >>> 
> >>> This was building from scratch what was already installed:
> >>> 
> >>> # ~/fbsd-based-on-what-freebsd-main.sh 
> >>> merge-base: 818390ce0ca539300dd15d7a817784f1e3f7a9b8
> >>> merge-base: CommitDate: 2021-01-13 21:27:44 +
> >>> 4180404713ec (HEAD -> mm-src) mm-src snapshot for mm's patched build in 
> >>> git context.
> >>> 818390ce0ca5 (freebsd/main, freebsd/HEAD, pure-src, main) arm64: fix 
> >>> early devmap assertion
> >>> FreeBSD OPiP2E_RPi2v11 13.0-CURRENT FreeBSD 13.0-CURRENT 
> >>> mm-src-c255938-g4180404713ec GENERIC-NODBG  arm armv7 1300135 1300135
> >>> 
> >>> This suggests that you should be able to build on the RPi2B v1.1,
> >>> using -j4, with appropriate configuration for what and how to build.
> >>> 
> >>> 
> >>> It is now building the matching kernel, my GENERIC-NODBG style.
> >> 
> >> Done:
> >> 
> > Kernel build for GENERIC-NODBG completed on Mon Jan 18 20:33:26 PST 2021
> > Kernel(s)  GENERIC-NODBG built in 4998 seconds, ncpu: 4, make -j4
> >> 
> >> So, World+Kernel in somewhat under 22 hours.
> >> 
> >> The "MaxObs*" figures were unchanged, so:
> >> 
> >> Mem:  . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki 
> >> MaxObs(Act+Wir)
> >> Swap: . . . , 537588Ki MaxObsUsed
> >> 
> >> This suggests that, for now, 800 MiByte of swap would be something
> >> more than 1.5 times what it actually used and 1050 MiBytes would
> >> be something like 2.0 times what it actually used, so leaving some
> >> notable margin for variations in peek usage, at least when linker
> >> threading is avoided.
> >> 
> >> 
> >> 
> >> As for what I used to control "what and how to build" . . .
> >> 
> >> # more 
> >> ~/sys_build_scripts

Re: FreeBSD 13.0 Build Option Sweep

2021-01-20 Thread Michael Dexter


On 1/20/21 5:47 PM, Michael Dexter wrote:
Two have been fixed and PRs exist for the majority of them with some 
possible fixes for those who know the code best to consider. One broken 
option is a recent regression while one pair, 
WITHOUT_LIBTHR/WITHOUT_LIBPTHREAD is quite stale and is a candidate for 
significant attention or possibly removal.


Thank you Kyle for addressing the single greatest challenge I have 
described, with this review:


https://reviews.freebsd.org/D28263

I have closed the PR.

All the best,

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

make buildkernel is broken (linuxkpi vs drm)

2021-01-20 Thread Steve Kargl

My buildkernel after a buildworld is dying with

In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/pci.h:10:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:51:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/dmapool.h:36:
In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/scatterlist.h:32:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/scatterlist.h:36:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/slab.h:43:
In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/llist.h:64:
In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/kernel.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h:49:
In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/sched.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/sched.h:41:
/usr/src/sys/compat/linuxkpi/common/include/linux/bitmap.h:338:10: error: 
implicit declaration of function 'kmalloc_array' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]

I have removed the drm-current-kmod port and still get this error.
-- 
Steve
___
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: make buildkernel is broken (linuxkpi vs drm)

2021-01-20 Thread Hans Petter Selasky


On 1/21/21 6:46 AM, Steve Kargl wrote:

My buildkernel after a buildworld is dying with

In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/pci.h:10:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:51:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/dmapool.h:36:
In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/scatterlist.h:32:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/scatterlist.h:36:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/slab.h:43:
In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/llist.h:64:
In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/kernel.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h:49:
In file included from 
/media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/sched.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/sched.h:41:
/usr/src/sys/compat/linuxkpi/common/include/linux/bitmap.h:338:10: error: 
implicit declaration of function 'kmalloc_array' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]

I have removed the drm-current-kmod port and still get this error.



Is /usr/src and /usr/ports up-to-date ?

--HPS
___
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: make buildkernel is broken (linuxkpi vs drm)

2021-01-20 Thread Steve Kargl

On Thu, Jan 21, 2021 at 07:07:27AM +0100, Hans Petter Selasky wrote:
> On 1/21/21 6:46 AM, Steve Kargl wrote:
> > My buildkernel after a buildworld is dying with
> > 
> > In file included from 
> > /media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/pci.h:10:
> > In file included from 
> > /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:51:
> > In file included from 
> > /usr/src/sys/compat/linuxkpi/common/include/linux/dmapool.h:36:
> > In file included from 
> > /media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/scatterlist.h:32:
> > In file included from 
> > /usr/src/sys/compat/linuxkpi/common/include/linux/scatterlist.h:36:
> > In file included from 
> > /usr/src/sys/compat/linuxkpi/common/include/linux/slab.h:43:
> > In file included from 
> > /media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/llist.h:64:
> > In file included from 
> > /media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/kernel.h:4:
> > In file included from 
> > /usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h:49:
> > In file included from 
> > /media/obj/usr/src/i386.i386/sys/MOBILE/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_7/linuxkpi/gplv2/include/linux/sched.h:4:
> > In file included from 
> > /usr/src/sys/compat/linuxkpi/common/include/linux/sched.h:41:
> > /usr/src/sys/compat/linuxkpi/common/include/linux/bitmap.h:338:10: error: 
> > implicit declaration of function 'kmalloc_array' is invalid in C99 
> > [-Werror,-Wimplicit-function-declaration]
> > 
> > I have removed the drm-current-kmod port and still get this error.
> > 
> 
> Is /usr/src and /usr/ports up-to-date ?
> 

It is 'make buildkernel' in /usr/src after a 'make buildworld'.
I have 'PORTS_MODULES+= graphics/drm-current-kmod' in /etc/make.conf.

-- 
Steve
___
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: make buildkernel is broken (linuxkpi vs drm)

2021-01-20 Thread Hans Petter Selasky


On 1/21/21 7:13 AM, Steve Kargl wrote:

It is 'make buildkernel' in /usr/src after a 'make buildworld'.
I have 'PORTS_MODULES+= graphics/drm-current-kmod' in /etc/make.conf.


Try to update the ports tree. I'm not aware of any current build issues 
in this area.


--HPS
___
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: make buildkernel is broken (linuxkpi vs drm)

2021-01-20 Thread Steve Kargl

On Thu, Jan 21, 2021 at 07:18:07AM +0100, Hans Petter Selasky wrote:
> On 1/21/21 7:13 AM, Steve Kargl wrote:
> > It is 'make buildkernel' in /usr/src after a 'make buildworld'.
> > I have 'PORTS_MODULES+= graphics/drm-current-kmod' in /etc/make.conf.
> 
> Try to update the ports tree. I'm not aware of any current build issues in
> this area.
> 

I tried that.  I did not fix the problem.  Commenting
out the PORTS_MODULES line in /etc/make.conf allows
me to finish building the new kernel.  I re-install
the port after I install world/kernel.

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

Re: boot loader blank screen

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: DRM problem installing kernel on main-c561-gc3e75b6c1

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: VM UMA counters.

Re: Waiting for bufdaemon

Re: VM UMA counters.

Re: VM UMA counters.

Re: VM UMA counters.

Re: Waiting for bufdaemon

Re: VM UMA counters.

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: Waiting for bufdaemon

Re: DRM problem installing kernel on main-c561-gc3e75b6c1

Re: Waiting for bufdaemon

Re: DRM problem installing kernel on main-c561-gc3e75b6c1

Re: DRM problem installing kernel on main-c561-gc3e75b6c1

Can In-Kernel TLS (kTLS) work with any OpenSSL Application?

Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld

FreeBSD 13.0 Build Option Sweep

Re: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld

Re: FreeBSD 13.0 Build Option Sweep

make buildkernel is broken (linuxkpi vs drm)

Re: make buildkernel is broken (linuxkpi vs drm)

Re: make buildkernel is broken (linuxkpi vs drm)

Re: make buildkernel is broken (linuxkpi vs drm)

Re: make buildkernel is broken (linuxkpi vs drm)

36 matches

Site Navigation

Mail list logo

Footer information