Bridge project update (Week of March 16th)
Hi, A quick status update this week. I’ve been preoccupied with the AsiaBSDcon replacement hackathon (Thanks for organising hrs@!) and repeated changes to my travel plans. I did get the chance to discuss my ideas with manu@, which was very helpful. I believe I have a good idea of how to approach the epoch-ification now, and hope to have a functional prototype in a few weeks. Best regards, Kristof Provost ___ 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: EFI loader failure, after 20191114-r354699 Z87MX-D3H
On Thu, Nov 28, 2019 at 11:31 PM Toomas Soome wrote: > > > On 28. Nov 2019, at 22:20, Andrey Fesenko wrote: > > > > Fixed > > > > Thanks. And yea, that one is nasty. I have some guess but nothing too solid… > it may take time to get figured out. > > Have you tested BIOS boot? > > rgds, > toomas > > > On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome wrote: > >> > >> > >> > >> On 28. Nov 2019, at 22:16, Andrey Fesenko wrote: > >> > >> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome wrote: > >> > >> > >> hi! > >> > >> I did try to reach you, but mail did bounce back… > >> > >> unicast ping me:) > >> > >> rgds, > >> toomas > >> > >> On 28. Nov 2019, at 11:43, Andrey Fesenko wrote: > >> > >> Hello, > >> > >> Around starting 20191114 r354699 (memstick tested), my desktop not > >> boot normally. Boot only loader menu (black and white mode) after > >> start i'm see load modules, after this monitor gray, and 15-20s > >> disabled, system block not disable but run silently. system not boot. > >> > >> If i'm change efi (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1 > >> release, system boot normally > >> > >> > >> > >> This video boot second version (Name: "loader.efi") 545 KB > >> https://bsdnir.info/files/efi_fail.mp4 > >> > >> > >> 403 Forbidden > >> > >> :=) > >> > >> rgds, > >> toomas > New news ;) r359151 i'm make memstick with custom refind /mnt/ `-- EFI |-- BOOT | |-- bootx64.efi - refind |-- freebsd | `-- loader.efi - freebsd not boot |-- freebsd_lua | `-- loader_lua.efi - not boot |-- freebsd_simple | `-- loader_simp.efi - boot fine ___ 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: HOWTO donate CPU to the fight against the Corona-virus
Quoting Alexander Leidinger via freebsd-stable (from Thu, 19 Mar 2020 08:57:45 +0100): Hi, if someone wants to donate some FreeBSD based CPU resources to the fight against the Corona-virus, here is a quick HOWTO in terms of installing the Folding@Home client on FreeBSD: https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ This is now available as a port: biology/linux-foldingathome (thanks 0mp@). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpeG1W621XEN.pgp Description: Digitale PGP-Signatur
FreeBSD CI Weekly Report 2020-03-15
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-03-15 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-03-09 to 2020-03-15. During this period, we have: * 1903 builds (90.1% (+41.9) passed, 9.9% (-41.9) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 293 test runs (75.1% (-12.4) passed, 17.1% (+12.9) unstable, 7.8% (-0.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 34 doc and www builds (88.2% (+5.4) passed, 11.8 (-5.4) failed) Test case status (on 2020-03-15 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | -- | - | - | | | head/amd64 | 7721 (+12) | 7624 (+7) | 0 (0) | 97 (+5) | | head/i386 | 7719 (+12) | 7613 (+4) | 0 (0) | 106 (+8) | | 12-STABLE/amd64 | 7506 (+5) | 7453 (+1) | 0 (0) | 53 (+4) | | 12-STABLE/i386 | 7504 (+5) | 7443 (+1) | 0 (0) | 61 (+4) | | 11-STABLE/amd64 | 6880 (+2) | 6833 (+2) | 0 (0) | 47 (0) | | 11-STABLE/i386 | 6878 (+2) | 6826 (+2) | 0 (0) | 52 (0) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200315 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-mips64-build This job is using devel/gcc6@mips64 port (mips64-gcc6 pacakge) ``` ===> include/rpcsvc (includes) RPCGEN_CPP=/usr/local/bin/mips64-unknown-freebsd12.0-cpp6\ --sysroot=/usr/home/lwhsu/freebsd-obj-gcc6/usr/home/lwhsu/freebsd-src/mips.mips64/tmp\ -B/usr/local/mips64-unknown-freebsd12.0/bin/ rpcgen -C -h -DWANT_NFS3 /usr/home/lwhsu/freebsd-src/include/rpcsvc/mount.x -o mount.h /usr/home/lwhsu/freebsd-src/include/rpcsvc/mount.x:1:0: error: '-march=mips1' is not compatible with the selected ABI /*- *** [mount.h] Error code 1 make[4]: stopped in /usr/home/lwhsu/freebsd-src/include/rpcsvc 1 error ``` * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` --- all_subdir_usr.bin/clang/lldb --- /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandler.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:926: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:926: undefined reference to `box' collect2: error: ld returned 1 exit status ``` * https://ci.freebsd.org/job/FreeBSD-head-amd64-test Usually panics when executing sys.netpfil.pf.nat.exhaust For more details: https://bugs.freebsd.org/244703 ## Regressions * 3 tests start failing after llvm10 import * lib.libproc.proc_test.symbol_lookup * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * fusefs tests fail when mac_bsdextended.ko is loaded https://bugs.freebsd.org/244229 * `dtrace -c` causes program dumps core after somewhere between (r357694, r357701] https://bugs.freebsd.org/244053 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/
Re: cannot build 12.1-RELEASE on latest current-snapshot
Hi again,
On 21.03.20 21:52, Dimitry Andric wrote:
>> ...
> It needs a merge of r355588 ("Fix WITHOUT_CLANG build"), actually. For
> some reason, the logic in 12.1-R's version of src.opts.mk does not work
> correctly. I tried setting MK_SYSTEM_COMPILER=no, but even that does
> not work as it should. If you can, I would use 12-STABLE instead.
>
> -Dimitry
I applied r355588 and now and it proceeds further but bails out again
shortly thereafter:
--- C U T ---
...
Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/yp_xdr.o
--- pkru.o ---
/usr/src/12.1/lib/libc/x86/sys/pkru.c:74: warning: 'ifunc' attribute
directive ignored
/usr/src/12.1/lib/libc/x86/sys/pkru.c:109: warning: 'ifunc' attribute
directive ignored
--- getcontextx.o ---
/usr/src/12.1/lib/libc/x86/gen/getcontextx.c:64: warning: 'ifunc'
attribute directive ignored
/usr/src/12.1/lib/libc/x86/gen/getcontextx.c:103: warning: 'ifunc'
attribute directive ignored
Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/yplib.o
--- __vdso_gettc.o ---
/usr/src/12.1/lib/libc/x86/sys/__vdso_gettc.c:75: warning: 'ifunc'
attribute directive ignored
/usr/src/12.1/lib/libc/x86/sys/__vdso_gettc.c:75: warning: 'rdtsc_mb'
used but never defined
Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/subr_capability.o
--- pkru.o ---
{standard input}: Assembler messages:
{standard input}:39: Error: no such instruction: `rdpkru'
{standard input}:60: Error: no such instruction: `wrpkru'
{standard input}:171: Error: no such instruction: `rdpkru'
*** [pkru.o] Error code 1
make[4]: stopped in /usr/src/12.1/lib/libc
.ERROR_TARGET='pkru.o'
.ERROR_META_FILE='/usr/obj/usr/src/12.1/amd64.amd64/lib/libc/pkru.o.meta'
--- C U T ---
this looks even more serious to me.. are the other patches to apply ?
Best
Henry
___
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: HOWTO donate CPU to the fight against the Corona-virus
Alexander Leidinger wrote: > First step would be to get CUDA support in FreeBSD. Ahem, I have a little patch, consisting of several functions copy-pasted from the Linux driver, which is supposed to enable core CUDA functionality: https://github.com/shkhln/nvshim/issues/1#issuecomment-600358438. This won't work for applications depending on unified memory support, but otherwise should be good enough. ___ 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"
[LAST OFFICIAL REMINDER] Call for 2020Q1 quarterly status reports
Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is April 1, 2020, for work done since the last round of Quarterly Reports: January, 2020 - March, 2020. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarte...@freebsd.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md We look forward to seeing your 2020Q1 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) ___ 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: HOWTO donate CPU to the fight against the Corona-virus
On Saturday, March 21, 2020 12:07:55 PM CET Alexander Leidinger wrote: > Quoting Stefan Ehmann (from Sat, 21 Mar 2020 > > 11:38:26 +0100): > > On Thursday, March 19, 2020 8:57:45 AM CET Alexander Leidinger via > > freebsd- > > > > stable wrote: > >> Hi, > >> > >> if someone wants to donate some FreeBSD based CPU resources to the > >> fight against the Corona-virus, here is a quick HOWTO in terms of > >> installing the Folding@Home client on FreeBSD: > >> > >> https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-f > >> ree bsd-foldinghome/ > > > > Unfortunately, (using a CPU slot for the same work unit) TPF is 2-3 times > > slower than on Ubuntu for me. Much of the speed difference seems to > > be related > > to libOpenCL. If remove libOpenCL on Ubuntu, it's still 20-30% faster than > > on FreeBSD. > > The pure CPU based code should be the same. Someone would have to > trace / reverse engineer what is going on. I'm pretty sure now that libOpenCL is only relevant for GPU slots. I couldn't reproduce that the presence of libOpenCL.so has any effect on CPU slots. Didn't make much sense anyway, something else must have been going on. So there's probably no point in getting OpenCL to run on FreeBSD until we have GPU rendering. The numbers displayed by FAHControl are rather strange: * There is no discernible difference in speed if 1 or all CPU cores are used (but top shows that 600% CPU cycles are burned) - happens on both Ubuntu and Linuxolator * According to the progress bar, Ubuntu completes 1% per minute, but Linuxolator only 0.1% (for the same work unit) Don't know if the numbers displayed are bogus or there is really that much of a difference. Maybe the issue is only related to a specific WU or to AMD-CPUs. I've also tried https://fahbench.github.io/ but it's mainly targeted at GPUs and uses a different Core. ___ 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"
