Re: HEADSUP: math is broken with clang and optimization
On Mon, Feb 15, 2021 at 03:27:08PM -0800, Mark Millard wrote: > > On Mon, Feb 15, 2021 at 01:03:36PM -0800, Steve Kargl wrote: > > > On Mon, Feb 15, 2021 at 12:49:13PM -0800, Steve Kargl wrote: > > > > On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote: > > > > > Just a headsup for anyone doing numerical work with > > > > > FreeBSD-current. clang with optimization of -O1 or > > > > > higher produces wrong results. Testing 1 million > > > > > complex values of ccoshf and limiting |z| < 20, > > > > > shows > > > > > > > > > > > > > This is either an in-ling bug or discarding a cast issue. > > > > With everything in the same file so clang has dp_ccosh > > > > available to it when compiling main. > > > > > > > > > > Code builds and works as expected with gcc 10.2and > > > gcc 11.0.0. > > > > > > > Can't find a list of options that is equivalent to -O1, > > so cannot test various optimizations. > > > > Notice that -march=i686 gives the wrong results and > > -march=core2 gives the correct result. Trying -march=i686 > > -msse -msse2 gives the correct result. It seems that > > clang does not understand how the x87 (on i585-freebsd). > > I tried looking around some and got the following > that might be contributing: variations in > __FLT_EVAL_METHOD__ used . . . > > # cc -target i386-unknown-freebsd14.0 -march=i686 -O2 -x c /dev/null -dM -E | > egrep "(FLT_EVAL_METHOD|ILP32|LP64)" > #define _ILP32 1 > #define __FLT_EVAL_METHOD__ 2 > #define __ILP32__ 1 > > # cc -target i386-unknown-freebsd14.0 -march=core2 -O2 -x c /dev/null -dM -E > | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" > #define _ILP32 1 > #define __FLT_EVAL_METHOD__ 0 > #define __ILP32__ 1 > > # cc -target x86_64-unknown-freebsd14.0 -march=core2 -O2 -x c /dev/null -dM > -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" > #define _LP64 1 > #define __FLT_EVAL_METHOD__ 0 > #define __LP64__ 1 > > FYI: It does not look like FreeBSD's /usr/include/x86/float.h > matches all the detail: > > #if __ISO_C_VISIBLE >= 1999 > #ifdef __LP64__ > #define FLT_EVAL_METHOD 0 /* no promotions */ > #else > #define FLT_EVAL_METHOD (-1)/* i387 semantics are...interesting */ > #endif > . . . > #endif > > > For reference: > > # cc -target i386-unknown-freebsd14.0 -O2 -x c /dev/null -dM -E | egrep > "(FLT_EVAL_METHOD|ILP32|LP64)" > #define _ILP32 1 > #define __FLT_EVAL_METHOD__ 2 > #define __ILP32__ 1 > > # cc -target x86_64-unknown-freebsd14.0 -O2 -x c /dev/null -dM -E | egrep > "(FLT_EVAL_METHOD|ILP32|LP64)" > #define _LP64 1 > #define __FLT_EVAL_METHOD__ 0 > #define __LP64__ 1 > > # cc -target x86_64-unknown-freebsd14.0 -march=i686 -O2 -x c /dev/null -dM -E > | grep FLT_EVAL_METHOD | sort > error: unknown target CPU 'i686' > note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, > silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, > sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, > broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, > icelake-client, icelake-server, tigerlake, knl, knm, k8, athlon64, athlon-fx, > opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, > btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, x86-64 > > # cc -v > FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git > llvmorg-11.0.1-0-g43ff75f2c3fe) > Target: x86_64-unknown-freebsd14.0 > Thread model: posix > InstalledDir: /usr/bin > Doesn't surprise me. gcc knows about freebsd special handling of the i387 on i686-*-freebsd. clang does not. clang: % cc -E -dM -c -march=i686 testf.c | egrep "(FLT_EVAL_METHOD|__ILP32|__LP64)" #define FLT_EVAL_METHOD (-1) #define __FLT_EVAL_METHOD__ 2 #define __ILP32__ 1 gcc10: % gcc10 -E -dM -c -march=i686 testf.c | egrep "(FLT_EVAL_METHOD|__ILP32|__LP64)" #define __FLT_EVAL_METHOD__ 2 #define __FLT_EVAL_METHOD_TS_18661_3__ 2 #define __ILP32__ 1 #define FLT_EVAL_METHOD __FLT_EVAL_METHOD__ -- 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: Interface counter inaccurate
On Mon, Feb 15, 2021 at 10:25:47PM +0100, Kristof Provost wrote: > On 15 Feb 2021, at 22:09, Daniel Ponte wrote: > > I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c from > > 12.2-STABLE, throughput on my WAN interface (the box runs pf) is > > incorrectly showing double in systat -if, as well as in vnstat and pftop > > from ports. The LAN interface does not appear to be so afflicted. > > > `systat -if` doesn’t read the pf counters, so I wouldn’t expect that to be > related. > > Those are the interface counters. > What network card and driver do you use? > > Kristof I, too, questioned the relation. They are igb(4) I210 builtin interfaces (in a Protectli Vault 4). systat -if during said speed test: igb1 in 11.670 Mb/s 11.670 Mb/s1.067 GB out 319.975 Mb/s320.458 Mb/s2.062 GB igb0 in640.120 Mb/s640.690 Mb/s6.351 GB out 5.824 Mb/s 5.824 Mb/s 987.050 MB igb1 is inside, igb0 is outside. The 6GB:2GB difference in totals seen above is indeed real; this machine did not initiate that much traffic on its own. ___ 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: HEADSUP: math is broken with clang and optimization
> On Mon, Feb 15, 2021 at 01:03:36PM -0800, Steve Kargl wrote: > > On Mon, Feb 15, 2021 at 12:49:13PM -0800, Steve Kargl wrote: > > > On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote: > > > > Just a headsup for anyone doing numerical work with > > > > FreeBSD-current. clang with optimization of -O1 or > > > > higher produces wrong results. Testing 1 million > > > > complex values of ccoshf and limiting |z| < 20, > > > > shows > > > > > > > > > > This is either an in-ling bug or discarding a cast issue. > > > With everything in the same file so clang has dp_ccosh > > > available to it when compiling main. > > > > > > > Code builds and works as expected with gcc 10.2and > > gcc 11.0.0. > > > > Can't find a list of options that is equivalent to -O1, > so cannot test various optimizations. > > Notice that -march=i686 gives the wrong results and > -march=core2 gives the correct result. Trying -march=i686 > -msse -msse2 gives the correct result. It seems that > clang does not understand how the x87 (on i585-freebsd). I tried looking around some and got the following that might be contributing: variations in __FLT_EVAL_METHOD__ used . . . # cc -target i386-unknown-freebsd14.0 -march=i686 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _ILP32 1 #define __FLT_EVAL_METHOD__ 2 #define __ILP32__ 1 # cc -target i386-unknown-freebsd14.0 -march=core2 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _ILP32 1 #define __FLT_EVAL_METHOD__ 0 #define __ILP32__ 1 # cc -target x86_64-unknown-freebsd14.0 -march=core2 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _LP64 1 #define __FLT_EVAL_METHOD__ 0 #define __LP64__ 1 FYI: It does not look like FreeBSD's /usr/include/x86/float.h matches all the detail: #if __ISO_C_VISIBLE >= 1999 #ifdef __LP64__ #define FLT_EVAL_METHOD 0 /* no promotions */ #else #define FLT_EVAL_METHOD (-1)/* i387 semantics are...interesting */ #endif . . . #endif For reference: # cc -target i386-unknown-freebsd14.0 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _ILP32 1 #define __FLT_EVAL_METHOD__ 2 #define __ILP32__ 1 # cc -target x86_64-unknown-freebsd14.0 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _LP64 1 #define __FLT_EVAL_METHOD__ 0 #define __LP64__ 1 # cc -target x86_64-unknown-freebsd14.0 -march=i686 -O2 -x c /dev/null -dM -E | grep FLT_EVAL_METHOD | sort error: unknown target CPU 'i686' note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, icelake-server, tigerlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, x86-64 # cc -v FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: math is broken with clang and optimization
On Mon, Feb 15, 2021 at 01:03:36PM -0800, Steve Kargl wrote: > On Mon, Feb 15, 2021 at 12:49:13PM -0800, Steve Kargl wrote: > > On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote: > > > Just a headsup for anyone doing numerical work with > > > FreeBSD-current. clang with optimization of -O1 or > > > higher produces wrong results. Testing 1 million > > > complex values of ccoshf and limiting |z| < 20, > > > shows > > > > > > > This is either an in-ling bug or discarding a cast issue. > > With everything in the same file so clang has dp_ccosh > > available to it when compiling main. > > > > Code builds and works as expected with gcc 10.2and > gcc 11.0.0. > Can't find a list of options that is equivalent to -O1, so cannot test various optimizations. Notice that -march=i686 gives the wrong results and -march=core2 gives the correct result. Trying -march=i686 -msse -msse2 gives the correct result. It seems that clang does not understand how the x87 (on i585-freebsd). -- 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: Interface counter inaccurate
On 15 Feb 2021, at 22:09, Daniel Ponte wrote: I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c from 12.2-STABLE, throughput on my WAN interface (the box runs pf) is incorrectly showing double in systat -if, as well as in vnstat and pftop from ports. The LAN interface does not appear to be so afflicted. `systat -if` doesn’t read the pf counters, so I wouldn’t expect that to be related. Those are the interface counters. What network card and driver do you use? Kristof ___ 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"
Interface counter inaccurate
All, I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c from 12.2-STABLE, throughput on my WAN interface (the box runs pf) is incorrectly showing double in systat -if, as well as in vnstat and pftop from ports. The LAN interface does not appear to be so afflicted. Running a speedtest on my 300Mb connection shows correctly in systat on a 12.2 client on the LAN, but on the router running 13-STABLE that it traverses, it shows ~600Mb. Someone suggested I send email here, as the pf counter code has recently been worked on. I'm happy to perform further testing, if desired. Thanks, Dan ___ 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: HEADSUP: math is broken with clang and optimization
On Mon, Feb 15, 2021 at 12:49:13PM -0800, Steve Kargl wrote: > On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote: > > Just a headsup for anyone doing numerical work with > > FreeBSD-current. clang with optimization of -O1 or > > higher produces wrong results. Testing 1 million > > complex values of ccoshf and limiting |z| < 20, > > shows > > > > This is either an in-ling bug or discarding a cast issue. > With everything in the same file so clang has dp_ccosh > available to it when compiling main. > Code builds and works as expected with gcc 10.2and gcc 11.0.0. -- 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: HEADSUP: math is broken with clang and optimization
On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote:
> Just a headsup for anyone doing numerical work with
> FreeBSD-current. clang with optimization of -O1 or
> higher produces wrong results. Testing 1 million
> complex values of ccoshf and limiting |z| < 20,
> shows
>
This is either an in-ling bug or discarding a cast issue.
With everything in the same file so clang has dp_ccosh
available to it when compiling main.
void
dp_ccosh(double x, double y, double *re, double *im)
{
*re = cosh(x) * cos(y);
*im = sinh(x) * sin(y);
}
int
main(int argc, char *argv[])
{
float complex f, z;
double re, im, ur, ui;
float x, y;
float xmax;
...
for (j = 0; j < NUM; j++) {
x = xmax * rangef();
y = xmax * rangef();
z = CMPLXF(x,y);
f = ccoshf(z);
dp_ccosh((double)x, (double)y, , );
gives the wrong results. Changing this to
int
main(int argc, char *argv[])
{
float complex f, z;
double re, im, ur, ui;
float x, y;
volatile float xv, yv;
float xmax;
...
for (j = 0; j < NUM; j++) {
xv = x = xmax * rangef();
yv = y = xmax * rangef();
z = CMPLXF(x,y);
f = ccoshf(z);
dp_ccosh((double)xv, (double)yv, , );
gives the expected and correct results.
--
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"
DRM related panic 13-STABLE
This is a third panic after the update to 13-STABLE and corresponding drm-fbsd13-kmod-5.4.92.g20210202 port. My hardware is ThinkPad T440p with Intel Haswell iGPU. It happens once in a week or two. Unread portion of the kernel message buffer: <4>WARN_ON(atomic_read(>bits) & frontbuffer_bits)WARN_ON(!(atomic_read(>bits) & frontbuffer_bits)) Fatal trap 9: general protection fault while in kernel mode cpuid = 3; apic id = 03 instruction pointer = 0x20:0x8376bb7d stack pointer= 0x28:0xfe01116b9750 frame pointer= 0x28:0xfe01116b9760 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1224 (MainThread) trap number = 9 WARNING !drm_modeset_is_locked(>mutex) failed at /usr/local/sys/modules/drm-fbsd13-kmod/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0x80e3e243 at linux_dump_stack+0x23 #1 0x8385a3c3 at drm_atomic_helper_check_modeset+0xb3 #2 0x8374ebcd at intel_atomic_check+0x8d #3 0x83859360 at drm_atomic_check_only+0x400 #4 0x83859793 at drm_atomic_commit+0x13 #5 0x838668f8 at drm_client_modeset_commit_atomic+0x148 #6 0x83866621 at drm_client_modeset_commit_force+0x71 #7 0x838a9757 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77 #8 0x838a3551 at vt_kms_postswitch+0x191 #9 0x80a6508b at vt_window_switch+0x12b #10 0x80a6219f at vtterm_cngrab+0x4f #11 0x80ba3be6 at cngrab+0x16 #12 0x80c091cc at vpanic+0xec #13 0x80c090d3 at panic+0x43 #14 0x810891a7 at trap_fatal+0x387 #15 0x8108866e at trap+0x8e #16 0x8105fd28 at calltrap+0x8 #17 0x8374be6a at intel_user_framebuffer_destroy+0x1a WARNING !drm_modeset_is_locked(>mutex) failed at /usr/local/sys/modules/drm-fbsd13-kmod/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0x80e3e243 at linux_dump_stack+0x23 #1 0x8385a3c3 at drm_atomic_helper_check_modeset+0xb3 #2 0x8374ebcd at intel_atomic_check+0x8d #3 0x83859360 at drm_atomic_check_only+0x400 #4 0x83859793 at drm_atomic_commit+0x13 #5 0x838668f8 at drm_client_modeset_commit_atomic+0x148 #6 0x83866621 at drm_client_modeset_commit_force+0x71 #7 0x838a9757 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77 #8 0x838a3551 at vt_kms_postswitch+0x191 #9 0x80a6508b at vt_window_switch+0x12b #10 0x80a6219f at vtterm_cngrab+0x4f #11 0x80ba3be6 at cngrab+0x16 #12 0x80c091cc at vpanic+0xec #13 0x80c090d3 at panic+0x43 #14 0x810891a7 at trap_fatal+0x387 #15 0x8108866e at trap+0x8e #16 0x8105fd28 at calltrap+0x8 #17 0x8374be6a at intel_user_framebuffer_destroy+0x1a WARNING !drm_modeset_is_locked(>mutex) failed at /usr/local/sys/modules/drm-fbsd13-kmod/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0x80e3e243 at linux_dump_stack+0x23 #1 0x8385a3c3 at drm_atomic_helper_check_modeset+0xb3 #2 0x8374ebcd at intel_atomic_check+0x8d #3 0x83859360 at drm_atomic_check_only+0x400 #4 0x83859793 at drm_atomic_commit+0x13 #5 0x838668f8 at drm_client_modeset_commit_atomic+0x148 #6 0x83866621 at drm_client_modeset_commit_force+0x71 #7 0x838a9757 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77 #8 0x838a3551 at vt_kms_postswitch+0x191 #9 0x80a6508b at vt_window_switch+0x12b #10 0x80a6219f at vtterm_cngrab+0x4f #11 0x80ba3be6 at cngrab+0x16 #12 0x80c091cc at vpanic+0xec #13 0x80c090d3 at panic+0x43 #14 0x810891a7 at trap_fatal+0x387 #15 0x8108866e at trap+0x8e #16 0x8105fd28 at calltrap+0x8 #17 0x8374be6a at intel_user_framebuffer_destroy+0x1a WARNING !drm_modeset_is_locked(>mode_config.connection_mutex) failed at /usr/local/sys/modules/drm-fbsd13-kmod/drivers/gpu/drm/drm_atomic_helper.c:666 #0 0x80e3e243 at linux_dump_stack+0x23 #1 0x8385a553 at drm_atomic_helper_check_modeset+0x243 #2 0x8374ebcd at intel_atomic_check+0x8d #3 0x83859360 at drm_atomic_check_only+0x400 #4 0x83859793 at drm_atomic_commit+0x13 #5 0x838668f8 at drm_client_modeset_commit_atomic+0x148 #6 0x83866621 at drm_client_modeset_commit_force+0x71 #7 0x838a9757 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77 #8 0x838a3551 at vt_kms_postswitch+0x191 #9 0x80a6508b at vt_window_switch+0x12b #10 0x80a6219f at vtterm_cngrab+0x4f #11 0x80ba3be6 at cngrab+0x16 #12 0x80c091cc at vpanic+0xec #13 0x80c090d3 at panic+0x43 #14 0x810891a7 at trap_fatal+0x387 #15 0x8108866e at trap+0x8e #16 0x8105fd28 at calltrap+0x8 #17 0x8374be6a at intel_user_framebuffer_destroy+0x1a WARNING !drm_modeset_is_locked(>mutex) failed at
Re: jails: /pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or directory
O. Hartmann wrote:
> > If reverting this does not help, can you try with:
> > sysctl vfs.cache_fast_lookup=0
>
> reverting the mentioned commit helped and made things working as expected
> again.
>
> Thank you very much.
Sorry looks like bsd.links.mk expects full paths.
Can you confirm the below works for you:
diff --git a/usr.bin/bmake/Makefile.inc b/usr.bin/bmake/Makefile.inc
index 8c4cb659e1d..9960f0ceeb2 100644
--- a/usr.bin/bmake/Makefile.inc
+++ b/usr.bin/bmake/Makefile.inc
@@ -9,7 +9,7 @@
.if exists(${.CURDIR}/tests)
PROG= make
-LINKS= make bmake
+LINKS= ${BINDIR}/make ${BINDIR}/bmake
MLINKS= ${MAN} b${MAN}
.endif
___
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: loader/boot fonts are painfully small (again)
On Fri, 12 Feb 2021 at 15:33, Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > > On 11. Feb 2021, at 23:21, Yuri Pankov wrote: > > > > > > Lenovo P51 laptop, 15'' 4k (3840x2160) display. > > > > > > Booting from the latest available current snapshot (20210107), fonts > > > were at least readable; updating to the latest bits (manually > installing > > > new loader as well) made them really small -- terminal size reported by > > > stty is 480x135. > > > > > > > It is a issue about not so good automatic font size setup. The original > code was using 80x24 terminal as base, it was complained it did end up with > too large fonts, so I did pick uefi terminal size as base (see output from > mode command), but thats also not perfect. Till better solution, right now > the option is to set font manually (screen.font variable). > > Can we just stick with the "known to work almost everywhere and always" > default value of 80x24? These small fonts are great for those of you > who have 20/20 un corrected vision, but it is a royal PITA for almost > anyone who has even a slight visual imparement, even corrected I find > it near imposible to read the default efi screens we put up. > > I would suggest we also override this in the -RELEASE/SNAPSHOT > media as one just does not need to fight this font size issue > while trying to install a new system. > > Thanks, > Rod > > > > > I have also noticed large delays between different loader screens, > > > probably caused by very slow screen blanking given the terminal size? > > > > yes, it definitely needs boost.There are few things we can do about it. > > > > rgds, > > toomas > > If we assume that 16:9 screens are the most common aspect ratio, and that the font we use is 1:2 (which is just guesswork, based on the 8x16 console font), that gives us a 32:9 aspect ratio counted in characters. It seems sensible to stick to an integer multiple of that, to avoid any uncomfortable stretching or scaling. The 480x135 console you got follows that idea - it's the 15x scale. That's obviously a bit optimistic, but how about the 3x or 4x scale, at 96x27 or 128x36? -- Daniel Nebdal ___ 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: jails: /pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or directory
On Mon, 15 Feb 2021 11:47:07 +0100
Mateusz Guzik wrote:
> Can you try this with reverting:
>
> commit ee10666327b622c2f20a4ac17e7a5673b04e7c9a
> Author: Simon J. Gerraty
> Date: Sun Feb 14 17:20:10 2021 -0800
>
> Links for bmake and bmake.1
>
> Some folk forget that make is bmake, and want the links...
>
> MFC after: 1 week
>
> diff --git a/usr.bin/bmake/Makefile.inc b/usr.bin/bmake/Makefile.inc
> index 96431c19d2af..8c4cb659e1d8 100644
> --- a/usr.bin/bmake/Makefile.inc
> +++ b/usr.bin/bmake/Makefile.inc
> @@ -9,6 +9,8 @@
>
> .if exists(${.CURDIR}/tests)
> PROG= make
> +LINKS= make bmake
> +MLINKS= ${MAN} b${MAN}
> .endif
>
> .if !defined(MK_SHARED_TOOLCHAIN) || ${MK_SHARED_TOOLCHAIN} == "no"
>
> If reverting this does not help, can you try with:
> sysctl vfs.cache_fast_lookup=0
reverting the mentioned commit helped and made things working as expected again.
Thank you very much.
oh
>
> On 2/15/21, O. Hartmann wrote:
> > The base host is running FreeBSD 14.0-CURRENT #6 main-n244784-8563de2f279:
> > Fri
> > Feb 12 12:48:34 CET 2021 amd64, the source tree is at "commit
> > 5dce03847fdc7bc6eb959282c0ae2117b1991746".
> >
> >
> > Updating jails via "ezjail-admin update -i", or for poudriere based CURRENT
> > (14-CURRENT) jails via "poudriere jail -j jail -u -b", installation of
> > world
> > fails due to an error, shown below:
> >
> > [...]
> >
> > ===> usr.bin/bmake (install)
> > install -s -o root -g wheel -m 555 make
> > /pool/jails/fulljail/usr/bin/make
> > install -o root -g wheel -m 444 make.1.gz
> > /pool/jails/fulljail/usr/share/man/man1/ rm -f
> > /pool/jails/fulljail/usr/share/man/man1/bmake.1
> > /pool/jails/fulljail/usr/share/man/man1/bmake.1.gz; install -l h -o root
> > -g
> > wheel -m 444 /pool/jails/fulljail/usr/share/man/man1/make.1.gz
> > /pool/jails/fulljail/usr/share/man/man1/bmake.1.gz install -l h -o root -g
> > wheel -m 555 /pool/jails/fulljailmake /pool/jails/fulljailbmake install:
> > link
> > /pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or
> > directory *** Error code 71
> >
> > Stop.
> > make[5]: stopped in /usr/src/usr.bin/bmake
> > *** 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"
> >
>
>
___
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: jails: /pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or directory
Am 15.02.21 um 11:47 schrieb Mateusz Guzik:
Can you try this with reverting:
commit ee10666327b622c2f20a4ac17e7a5673b04e7c9a
Author: Simon J. Gerraty
Date: Sun Feb 14 17:20:10 2021 -0800
Links for bmake and bmake.1
Some folk forget that make is bmake, and want the links...
MFC after: 1 week
diff --git a/usr.bin/bmake/Makefile.inc b/usr.bin/bmake/Makefile.inc
index 96431c19d2af..8c4cb659e1d8 100644
--- a/usr.bin/bmake/Makefile.inc
+++ b/usr.bin/bmake/Makefile.inc
@@ -9,6 +9,8 @@
.if exists(${.CURDIR}/tests)
PROG= make
+LINKS= make bmake
+MLINKS= ${MAN} b${MAN}
.endif
.if !defined(MK_SHARED_TOOLCHAIN) || ${MK_SHARED_TOOLCHAIN} == "no"
If reverting this does not help, can you try with:
sysctl vfs.cache_fast_lookup=0
On 2/15/21, O. Hartmann wrote:
The base host is running FreeBSD 14.0-CURRENT #6 main-n244784-8563de2f279:
Fri
Feb 12 12:48:34 CET 2021 amd64, the source tree is at "commit
5dce03847fdc7bc6eb959282c0ae2117b1991746".
Updating jails via "ezjail-admin update -i", or for poudriere based CURRENT
(14-CURRENT) jails via "poudriere jail -j jail -u -b", installation of
world
fails due to an error, shown below:
[...]
===> usr.bin/bmake (install)
install -s -o root -g wheel -m 555 make
/pool/jails/fulljail/usr/bin/make
install -o root -g wheel -m 444 make.1.gz
/pool/jails/fulljail/usr/share/man/man1/ rm -f
/pool/jails/fulljail/usr/share/man/man1/bmake.1
/pool/jails/fulljail/usr/share/man/man1/bmake.1.gz; install -l h -o root
-g
wheel -m 444 /pool/jails/fulljail/usr/share/man/man1/make.1.gz
/pool/jails/fulljail/usr/share/man/man1/bmake.1.gz install -l h -o root -g
wheel -m 555 /pool/jails/fulljailmake /pool/jails/fulljailbmake install:
link
/pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or
directory *** Error code 71
I've got the same problem in a simple buildworld/installworld:
===> usr.bin/bmake/tests/variables/t0 (install)
install -o root -g wheel -m 555 legacy_test
//usr/tests/usr.bin/bmake/variables/t0/legacy_test
installing DIRS testsFILESDIR
install -d -m 0755 -o root -g wheel
//usr/tests/usr.bin/bmake/variables/t0
install -o root -g wheel -m 444
/usr/git/src/usr.bin/bmake/tests/variables/t0/Makefile.test
//usr/tests/usr.bin/bmake/variables/t0/Makefile.test
install -o root -g wheel -m 444
/usr/git/src/usr.bin/bmake/tests/variables/t0/expected.status.1
//usr/tests/usr.bin/bmake/variables/t0/expected.status.1
install -o root -g wheel -m 444
/usr/git/src/usr.bin/bmake/tests/variables/t0/expected.stderr.1
//usr/tests/usr.bin/bmake/variables/t0/expected.stderr.1
install -o root -g wheel -m 444
/usr/git/src/usr.bin/bmake/tests/variables/t0/expected.stdout.1
//usr/tests/usr.bin/bmake/variables/t0/expected.stdout.1
install -o root -g wheel -m 444 Kyuafile
//usr/tests/usr.bin/bmake/variables/t0/Kyuafile
install -l h -o root -g wheel -m 555 /make /bmake
install: link /make -> /bmake: No such file or directory
It seems that "/" is used as a path prefix instead of "/usr/bin/".
Removal of the LINKS line solves the issue for me, but with a sane
path prefix the link could be installed.
Regards, STefan
OpenPGP_signature
Description: OpenPGP digital signature
Re: jails: /pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or directory
Can you try this with reverting:
commit ee10666327b622c2f20a4ac17e7a5673b04e7c9a
Author: Simon J. Gerraty
Date: Sun Feb 14 17:20:10 2021 -0800
Links for bmake and bmake.1
Some folk forget that make is bmake, and want the links...
MFC after: 1 week
diff --git a/usr.bin/bmake/Makefile.inc b/usr.bin/bmake/Makefile.inc
index 96431c19d2af..8c4cb659e1d8 100644
--- a/usr.bin/bmake/Makefile.inc
+++ b/usr.bin/bmake/Makefile.inc
@@ -9,6 +9,8 @@
.if exists(${.CURDIR}/tests)
PROG= make
+LINKS= make bmake
+MLINKS= ${MAN} b${MAN}
.endif
.if !defined(MK_SHARED_TOOLCHAIN) || ${MK_SHARED_TOOLCHAIN} == "no"
If reverting this does not help, can you try with:
sysctl vfs.cache_fast_lookup=0
On 2/15/21, O. Hartmann wrote:
> The base host is running FreeBSD 14.0-CURRENT #6 main-n244784-8563de2f279:
> Fri
> Feb 12 12:48:34 CET 2021 amd64, the source tree is at "commit
> 5dce03847fdc7bc6eb959282c0ae2117b1991746".
>
>
> Updating jails via "ezjail-admin update -i", or for poudriere based CURRENT
> (14-CURRENT) jails via "poudriere jail -j jail -u -b", installation of
> world
> fails due to an error, shown below:
>
> [...]
>
> ===> usr.bin/bmake (install)
> install -s -o root -g wheel -m 555 make
> /pool/jails/fulljail/usr/bin/make
> install -o root -g wheel -m 444 make.1.gz
> /pool/jails/fulljail/usr/share/man/man1/ rm -f
> /pool/jails/fulljail/usr/share/man/man1/bmake.1
> /pool/jails/fulljail/usr/share/man/man1/bmake.1.gz; install -l h -o root
> -g
> wheel -m 444 /pool/jails/fulljail/usr/share/man/man1/make.1.gz
> /pool/jails/fulljail/usr/share/man/man1/bmake.1.gz install -l h -o root -g
> wheel -m 555 /pool/jails/fulljailmake /pool/jails/fulljailbmake install:
> link
> /pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or
> directory *** Error code 71
>
> Stop.
> make[5]: stopped in /usr/src/usr.bin/bmake
> *** 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"
>
--
Mateusz Guzik
___
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"
jails: /pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or directory
The base host is running FreeBSD 14.0-CURRENT #6 main-n244784-8563de2f279: Fri Feb 12 12:48:34 CET 2021 amd64, the source tree is at "commit 5dce03847fdc7bc6eb959282c0ae2117b1991746". Updating jails via "ezjail-admin update -i", or for poudriere based CURRENT (14-CURRENT) jails via "poudriere jail -j jail -u -b", installation of world fails due to an error, shown below: [...] ===> usr.bin/bmake (install) install -s -o root -g wheel -m 555 make /pool/jails/fulljail/usr/bin/make install -o root -g wheel -m 444 make.1.gz /pool/jails/fulljail/usr/share/man/man1/ rm -f /pool/jails/fulljail/usr/share/man/man1/bmake.1 /pool/jails/fulljail/usr/share/man/man1/bmake.1.gz; install -l h -o root -g wheel -m 444 /pool/jails/fulljail/usr/share/man/man1/make.1.gz /pool/jails/fulljail/usr/share/man/man1/bmake.1.gz install -l h -o root -g wheel -m 555 /pool/jails/fulljailmake /pool/jails/fulljailbmake install: link /pool/jails/fulljailmake -> /pool/jails/fulljailbmake: No such file or directory *** Error code 71 Stop. make[5]: stopped in /usr/src/usr.bin/bmake *** 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: panic: condition seqc_in_modify(_vp->v_seqc) not met at zfs_acl.c:1147 (zfs_acl_chown_setattr)
On 15/02/2021 10:22, Andriy Gapon wrote:
>
> I've got this panic once when copying a couple of files.
> The system is stable/13 as of 1996360d7338d, a custom kernel configuration,
> but
> no local source code modifications.
>
> Unread portion of the kernel message buffer:
> VNASSERT failed: ({ seqc_t __seqc = (_vp->v_seqc); __builtin_expect((__seqc &
> 1), 0); }) not true at
> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
> (zfs_acl_chown_setattr)
> 0xf8013e4e85b8: type VDIR
> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0
> hold count flags ()
> flags ()
> lock type zfs: EXCL by thread 0xfe01dd1cd560 (pid 30747, kdeinit5, tid
> 159911)
> panic: condition seqc_in_modify(_vp->v_seqc) not met at
> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
> (zfs_acl_chown_setattr)
>
> Any ideas, suggestions, hints?
> Thanks!
>
...
> #4 0x8036fd21 in zfs_acl_chown_setattr (zp=0xf801ccd203b0)
> at
> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
> #5 0x8037e52d in zfs_setattr (zp=0xf8024b04f760,
> vap=vap@entry=0xfe029a36c870, flags=flags@entry=0,
> cr=, cr@entry=0xf8003ecedc00)
> at
> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:2758
So, this is actually the second zfs_acl_chown_setattr call here:
err = zfs_acl_chown_setattr(zp);
ASSERT(err == 0);
if (attrzp) {
err = zfs_acl_chown_setattr(attrzp);
ASSERT(err == 0);
}
I am not sure if the assertion is actually applicable to attrzp (extended
attributes "directory").
At least I do not see any seq calls for it.
--
Andriy Gapon
___
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"
panic: condition seqc_in_modify(_vp->v_seqc) not met at zfs_acl.c:1147 (zfs_acl_chown_setattr)
I've got this panic once when copying a couple of files.
The system is stable/13 as of 1996360d7338d, a custom kernel configuration, but
no local source code modifications.
Unread portion of the kernel message buffer:
VNASSERT failed: ({ seqc_t __seqc = (_vp->v_seqc); __builtin_expect((__seqc &
1), 0); }) not true at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
(zfs_acl_chown_setattr)
0xf8013e4e85b8: type VDIR
usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0
hold count flags ()
flags ()
lock type zfs: EXCL by thread 0xfe01dd1cd560 (pid 30747, kdeinit5, tid
159911)
panic: condition seqc_in_modify(_vp->v_seqc) not met at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
(zfs_acl_chown_setattr)
Any ideas, suggestions, hints?
Thanks!
(kgdb) #0 doadump (textdump=textdump@entry=1)
at /usr/devel/git/trant/sys/kern/kern_shutdown.c:399
#1 0x8083bea2 in kern_reboot (howto=260)
at /usr/devel/git/trant/sys/kern/kern_shutdown.c:486
#2 0x8083c4f7 in vpanic (
fmt=0x80c33e58 "condition %s not met at %s:%d (%s)",
ap=0xfe029a36c2c0)
at /usr/devel/git/trant/sys/kern/kern_shutdown.c:919
#3 0x8083c0a3 in panic (fmt=)
at /usr/devel/git/trant/sys/kern/kern_shutdown.c:843
#4 0x8036fd21 in zfs_acl_chown_setattr (zp=0xf801ccd203b0)
at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
#5 0x8037e52d in zfs_setattr (zp=0xf8024b04f760,
vap=vap@entry=0xfe029a36c870, flags=flags@entry=0,
cr=, cr@entry=0xf8003ecedc00)
at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:2758
#6 0x803817ee in zfs_freebsd_setattr (ap=)
at
/usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:4918
#7 0x80ba6087 in VOP_SETATTR_APV (
vop=0x80e59280 , a=a@entry=0xfe029a36ca00)
at vnode_if.c:927
#8 0x80915a89 in VOP_SETATTR (vp=vp@entry=0xf8016524d5b8,
vap=vap@entry=0xfe029a36ca30, cred=,
cred@entry=0xf8003ecedc00) at ./vnode_if.h:485
#9 0x80915d67 in setfown (td=,
cred=0xf8003ecedc00, vp=0xf8016524d5b8, uid=uid@entry=4294967295,
gid=gid@entry=20) at /usr/devel/git/trant/sys/kern/vfs_syscalls.c:2942
#10 0x80915eb6 in kern_fchownat (td=0xfe01dd1cd560,
fd=fd@entry=-100,
path=0x803697858 ,
pathseg=pathseg@entry=UIO_USERSPACE, uid=-1, gid=, flag=0)
at /usr/devel/git/trant/sys/kern/vfs_syscalls.c:3002
#11 0x80915db6 in sys_chown (td=, uap=)
at /usr/devel/git/trant/sys/kern/vfs_syscalls.c:2962
#12 0x80b25b69 in syscallenter (td=0xfe01dd1cd560)
at /usr/devel/git/trant/sys/amd64/amd64/../../kern/subr_syscall.c:189
#13 0x80b25845 in amd64_syscall (td=0xfe01dd1cd560, traced=0)
at /usr/devel/git/trant/sys/amd64/amd64/trap.c:1156
--
Andriy Gapon
___
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"
