No battery status on 13-CURRENT?
Hi freebsd-current@ I have a a HP Spectre x360 13-ap0053dx running 13-CURRENT r360134, I get this when running acpiconf -i 0: root@spectre:/home/neel # acpiconf -i 0 Design capacity:0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Design voltage: 0 mV Capacity (warn):0 mWh Capacity (low): 0 mWh Cycle Count:0 Mesurement Accuracy:0 % Max Sampling Time: 0 ms Min Sampling Time: 0 ms Max Average Interval: 0 ms Min Average Interval: 0 ms Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage:unknown root@spectre:/home/neel # Also, hw.acpi.acline appears if my system is plugged in when it isn't: root@spectre:/home/neel # sysctl hw.acpi.acline hw.acpi.acline: 1 root@spectre:/home/neel # However, using my "old" kernel with build r359837 works, and so does Windows 10. I also posted to Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245778 Is anyone else having this issue? -Neel === https://www.neelc.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: FreeBSD Office Hours
On 2020-04-20 9:49, Allan Jude wrote: Last week we had another FreeBSD Office Hours session, the video can be found here: https://www.youtube.com/watch?v=-MpltC87L3E It was less well attended, likely due to the time slot. TBQH, I thought "FreeBSD Office Hours" was an April Fools' joke. The original announcement was dated for April 1, and having something called "Office Hours" for an online development community was enough of a non sequitur to make me conclude it was tongue-in-cheek. ___ 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: toolchain status
On 4/18/20 5:46 PM, Eric van Gyzen wrote: > Which architectures are still often built with an external toolchain? > I'd like to re-commit jemalloc 5.2.1. It was reverted because > "compilation fails for non-llvm-based platforms." I just built > tinderbox worlds with 5.2.1 with no problems, albeit with llvm. All platforms now use LLVM. You can still use GCC to build platforms, but if amd64 builds fine with GCC 9 with the patch applied, I think you should be fine to move forward (that is, if only GCC 6 fails to build, we can just deprecate using GCC 6 as an external toolchain for 13) -- John Baldwin ___ 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: xtoolchain-llvm10 missing?
On Mon, Apr 20, 2020 at 05:52:04PM +0800, Li-Wen Hsu wrote: > On Sat, Apr 18, 2020 at 11:15 PM Ronald Klop wrote: > > > > Hi, > > > > Building CURRENT on my laptop takes very very long because every little > > change in llvm/clang makes it recompile a complete compiler. So I want to > > build with CROSS_TOOLCHAIN=xtoolchain-llvm10 (10.0) and > > WITHOUT_TOOLCHAIN=yes. > > In ports/pkgs the most recent versions I see are xtoolchain-llvm90 or > > xtoolchain-llvm-devel (11.0?). > > Is xtoolchain-llvm10 missing on purpose? > > I guess you want something like CROSS_TOOLCHAIN=llvm10, and > > /usr/local/share/toolchains/llvm10.mk > /usr/local/share/toolchains/llvm-devel.mk > > Are installed by llvm10 and llvm-devel now. For further clarification, we're moving to a model were we always install the toolchains/*.mk file for cross toolchains. This means that if you want CROSS_TOOLCHAIN=foo to work you just need to install the foo package. There's probably an argument I should make the change to llvm90 since that one is still of some use, but I've been too lazy to change the older ones. -- Brooks signature.asc Description: PGP signature
Re: FreeBSD Office Hours
Last week we had another FreeBSD Office Hours session, the video can be found here: https://www.youtube.com/watch?v=-MpltC87L3E It was less well attended, likely due to the time slot. Please vote in this poll to choose the time slot(s) for future Office Hours sessions. We will likely alternate between two time slots to try to make sure it is possible for everyone to attend some of the time. https://forms.gle/3HjjRx9KMcM3SL4H7 If you would like to host a future office hours session, please fill in a slot on the wiki: https://wiki.freebsd.org/OfficeHours -- Allan Jude signature.asc Description: OpenPGP digital signature
FreeBSD CI Weekly Report 2020-04-19
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-19 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-04-13 to 2020-04-19. During this period, we have: * 2136 builds (89.3% (-4.7) passed, 10.7% (+4.7) 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. * 333 test runs (42.0% (+17.0) passed, 55.9% (+26.0) unstable, 2.1% (-43.0) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 20 doc and www builds (95.0% (+11.7) passed, 5.0% (-11.7) failed) Test case status (on 2020-04-19 23:59): | Branch/Architecture | Total | Pass | Fail| Skipped | | --- | -- | -- | --- | | | head/amd64 | 7756 (+12) | 7657 (+19) | 5 (-9) | 94 (+2) | | head/i386 | 7754 (+12) | 7646 (+18) | 8 (-8) | 100 (+2) | | 12-STABLE/amd64 | 7518 (+10) | 7462 (+13) | 0 (-1) | 56 (-2) | | 12-STABLE/i386 | 7516 (+10) | 7452 (+27) | 0 (-2) | 64 (-15) | | 11-STABLE/amd64 | 6882 (0) | 6830 (+1) | 0 (-1) | 52 (0) | | 11-STABLE/i386 | 6880 (0) | 6826 (+77) | 0 (-80) | 54 (+3) | (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-20200419 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Failing tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * local.kyua.integration.cmd_about_test.topic__authors__installed * sys.netipsec.tunnel.empty.v4 * sys.netipsec.tunnel.empty.v6 * sys.opencrypto.blake2_test.blake2b_vectors_x86 * sys.opencrypto.blake2_test.blake2s_vectors_x86 * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ All amd64 failures and: * sys.kqueue.libkqueue.kqueue_test.main * sys.netinet.divert.ipdivert_ip_input_local_success * sys.netinet.divert.ipdivert_ip_output_remote_success ## 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/ * Total 3670 tests (0), 2285 success (-5), 579 failures (+5), 806 skipped (0) ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main
Re: xtoolchain-llvm10 missing?
On Sat, Apr 18, 2020 at 11:15 PM Ronald Klop wrote: > > Hi, > > Building CURRENT on my laptop takes very very long because every little > change in llvm/clang makes it recompile a complete compiler. So I want to > build with CROSS_TOOLCHAIN=xtoolchain-llvm10 (10.0) and > WITHOUT_TOOLCHAIN=yes. > In ports/pkgs the most recent versions I see are xtoolchain-llvm90 or > xtoolchain-llvm-devel (11.0?). > Is xtoolchain-llvm10 missing on purpose? I guess you want something like CROSS_TOOLCHAIN=llvm10, and /usr/local/share/toolchains/llvm10.mk /usr/local/share/toolchains/llvm-devel.mk Are installed by llvm10 and llvm-devel now. Best, Li-Wen ___ 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: Outdated jemalloc in CURRENT
On Sat, Apr 18, 2020 at 11:22 PM Steve Kargl wrote: > > On Sat, Apr 18, 2020 at 05:01:08PM +0200, Gordon Bergling wrote: > > > > On Sat, Apr 18, 2020 at 07:20:03AM -0700, Steve Kargl wrote: > >> On Sat, Apr 18, 2020 at 03:05:25PM +0300, nonamel...@ukr.net wrote: > >>> Hi everyone! > >>> > >>> As I see, CURRENT still uses outdated jemalloc 5.1.0 with some > >>> performance regressions that was fixed in 5.2.1. > >>> > >>> Are there some issues that blocking update jemalloc to recent version? > >>> > >> > >> > >> r354606 | jasone | 2019-11-10 21:06:49 -0800 (Sun, 10 Nov 2019) | 4 lines > >> > >> Revert r354605: Update jemalloc to version 5.2.1. > >> > >> Compilation fails for non-llvm-based platforms. > >> > >> > >> r354605 | jasone | 2019-11-10 19:27:14 -0800 (Sun, 10 Nov 2019) | 2 lines > >> > >> Update jemalloc to version 5.2.1. > >> > > > > I am not sure, that this info is correct. As far as I remember the > > update for jemalloc was reverted due to build problems, on some > > architecture. An updated revision has still to be commited to -CURRENT. > > > > Those two commits confirm your memory. 5.2.1 was committed > in r354605. 5.2.1 was reverted with r354606 where the reason > for reverting is stated. As 5.2.1 has not been re-committed > and there is nothing in reviews.freebsd.org for review, one > may expect the reason in r354606 still stands. > > PS: Please, do not top-post. > PPS: Please, wrap your messages to something less than 80 characters. I think it's fine to (and hope we can) update it again as the previous error was on outdated gcc which is not existing anymore: https://lists.freebsd.org/pipermail/svn-src-all/2020-March/195013.html Li-Wen ___ 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: PAE on i386
On Sun, Apr 19, 2020 at 11:40:06PM -0400, Yoshihiro Ota wrote: > Hi, > > I recall this result was committed a while ago to 13-CURRENT: > https://svnweb.freebsd.org/base?view=revision=343567 > > Is there a plan to MFC to 12-STABLE? There are no plans to merge it to 12. The feature is too invasive. > Does this feature results changing ABI? I do not believe so. One thing that changes is the UVA layout, but this is exactly the reason why this feature exists. On the other hand, the patch does change KBI by expanding vm_paddr_t to 64bit unconditionally. > > Regards, > Hiro > > On Sun, 20 Jan 2019 13:18:54 +0200 > Konstantin Belousov wrote: > > > Hello, > > at https://reviews.freebsd.org/D18894 I put a review which main goal is > > to allow i386 kernels to use NX bits on capable hardware. In essence, > > single kernel now can operate using either PAE or non-PAE pagetables, > > the selection is done at the cold (very early boot, before paging is > > turned on) time. > > > > This together with earlier 4/4 work gives much more life into i386 kernels > > for whoever still needs them. Please review/test, see the differential > > review text for more explanation. > > ___ > > 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"
