Re: page fault due to close(2), possibly drm and i915kms related
On Thu, 3 Dec 2020 11:45+0100, Mateusz Guzik wrote: > This should be fixed by r368271 Thank you, guys. I'll upgrade my laptop when I get home. -- Trond. ___ 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"
page fault due to close(2), possibly drm and i915kms related
Fam, After close(2) got fixed in r368006 last week, my laptop at home has been acting up. It currently runs: FreeBSD E590T.ufp 13.0-CURRENT FreeBSD 13.0-CURRENT #870 r368192: Mon Nov 30 20:29:15 CET 2020 r...@e590t.ufp:/usr/obj/usr/src/amd64.amd64/sys/E590T amd64 1300130 1300130 a5c28607a47e84c68f4c8063d23189c475e61ac8 The DRM and KMS drivers (i915kms) are compiled from the source code of graphics/drm-kmod and are automatically installed along with the kernel. >From time to time whenever I'm logged in using X.org, I sometimes get crashes like this one: Script started on Thu Dec 3 07:13:33 2020 Command: kkgdb /boot/kernel/kernel /var/crash/vmcore.2 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: [160176] [160176] [160176] Fatal trap 12: page fault while in kernel mode [160176] cpuid = 0; apic id = 00 [160176] fault virtual address = 0x440 [160176] fault code = supervisor read data, page not present [160176] instruction pointer= 0x20:0x808cbd2c [160176] stack pointer = 0x28:0xfe018500e700 [160176] frame pointer = 0x28:0xfe018500e780 [160176] code segment = base 0x0, limit 0xf, type 0x1b [160176]= DPL 0, pres 1, long 1, def32 0, gran 1 [160176] processor eflags = interrupt enabled, resume, IOPL = 0 [160176] current process= 3874 (wc) [160176] trap number= 12 [160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621 [160176] #0 0x82766583 at linux_dump_stack+0x23 [160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3 [160176] #2 0x831dfd9d at intel_atomic_check+0x8d [160176] #3 0x830fa360 at drm_atomic_check_only+0x400 [160176] #4 0x830fa793 at drm_atomic_commit+0x13 [160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148 [160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71 [160176] #7 0x8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77 [160176] #8 0x831445d1 at vt_kms_postswitch+0x191 [160176] #9 0x8076202b at vt_window_switch+0x12b [160176] #10 0x8075f12f at vtterm_cngrab+0x1f [160176] #11 0x80887c36 at cngrab+0x16 [160176] #12 0x808ee35c at vpanic+0xec [160176] #13 0x808ee263 at panic+0x43 [160176] #14 0x80cf7af7 at trap_fatal+0x387 [160176] #15 0x80cf7b4f at trap_pfault+0x4f [160176] #16 0x80cf71ad at trap+0x27d [160176] #17 0x80ccf3e8 at calltrap+0x8 [160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621 [160176] #0 0x82766583 at linux_dump_stack+0x23 [160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3 [160176] #2 0x831dfd9d at intel_atomic_check+0x8d [160176] #3 0x830fa360 at drm_atomic_check_only+0x400 [160176] #4 0x830fa793 at drm_atomic_commit+0x13 [160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148 [160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71 [160176] #7 0x8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77 [160176] #8 0x831445d1 at vt_kms_postswitch+0x191 [160176] #9 0x8076202b at vt_window_switch+0x12b [160176] #10 0x8075f12f at vtterm_cngrab+0x1f [160176] #11 0x80887c36 at cngrab+0x16 [160176] #12 0x808ee35c at vpanic+0xec [160176] #13 0x808ee263 at panic+0x43 [160176] #14 0x80cf7af7 at trap_fatal+0x387 [160176] #15 0x80cf7b4f at trap_pfault+0x4f [160176] #16 0x80cf71ad at trap+0x27d [160176] #17 0x80ccf3e8 at calltrap+0x8 [160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621 [160176] #0 0x82766583 at linux_dump_stack+0x23 [160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3 [160176] #2 0x831dfd9d at intel_atomic_check+0x8d [160176] #3 0x830fa360 at drm_atomic_check_only+0x400 [160176] #4 0x830fa793 at drm_atomic_commit+0x13 [160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148 [160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71 [160176] #7 0x8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77 [160176] #8 0x831445d1 at vt_kms_postswitch+0x191 [160176] #9 0x8076202b at vt_window_switch+0x12b [160176] #10 0x8075f12f at
In-kernel DTrace incompatible with in-kernel OpenZFS
It would seem options dtrace options dtraceall are incompatible with options zfs This is on base/head, r365358, amd64. Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x7fff8 fault code = supervisor write data, page not present instruction pointer = 0x20:0xf808cf8db stack pointer = 0x20:0xf82378a00 frame pointer = 0x20:0xf82378a00 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 = 0 (dtrace_taskq) trap number = 12 panic: page fault cpuid = 4 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at vpanic() at panic() at trap_fatal() at trap_pfatal() at trap() at calltrap() at --- trap 0xc, rip = 0xf808cf8db, rsp = 0xf82378a00, rbp = 0xf82378a00 --- osd_set_reserved() at taskqueue_thread_loop() at fork_exit() at fork_trampoline() at --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort I don't mind having dtraceall_load="YES" in /boot/loader.conf; I have to do so anyway to get systrace_freebsd32.ko loaded at boot time. Can this latter .ko file be made part of the kernel using an option statement? -- Trond. ___ 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: buildkernel failure because ctfconvert not installed
On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: > OK, I figured it out. > > I used to have MK_CTF=no in src.conf, but I recently changed it to > WITH_CTF=no. It's either WITH_xxx=yes or WITHOUT_xxx=yes. > /sys/conf/kern.post.mk checks whether MK_CTF is no and apparently > does not invoke ctfconvert if that is the case. > > I put MK_CTF=no back into src.conf. > > So, now everything works without having cftconvert installed. -- Trond. ___ 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: mouse is broken
On Tue, 10 Mar 2020 06:37-0600, The Doctor wrote: > On Mon, Mar 09, 2020 at 09:12:49PM -0400, AN wrote: > > > > After an update today to world, kernel, and ports my mouse no longer works. > > Mouse works on console. I use startx, mouse seems to break after startx is > > issued. > > > > Is any one else seeing anything similar? Any help is appreciated, thanks > > in advance. > > I have the same issue. You might be missing x11-drivers/xf86-input-evdev and/or x11-drivers/xf86-input-libinput. -- Trond. ___ 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: can't build rust -- out of swap space
On Tue, 3 Mar 2020 15:31+0300, Yuri Pankov wrote: > On 03.03.2020 15:27, Trond Endrestøl wrote: > > On Tue, 3 Mar 2020 12:56+0300, Yuri Pankov wrote: > > > > > On 03.03.2020 12:44, Trond Endrestøl wrote: > > > > On Tue, 3 Mar 2020 12:40+0300, Yuri Pankov wrote: > > > > > > > > > On 03.03.2020 11:49, Yuri Pankov wrote: > > > > > > With recent pkg fallout, I'm trying to build rust myself first time > > > > > > ever > > > > > > (as > > > > > > far as I can remember), and it's failing running out of swap on the > > > > > > following step: > > > > > > > > > > > > Building stage0 std artifacts (x86_64-unknown-freebsd -> > > > > > > x86_64-unknown-freebsd) > > > > > > running: > > > > > > "/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo" > > > > > > "build" "-Zconfig-profile" "--target" "x86_64-unknown-freebsd" > > > > > > "-Zbinary-dep-depinfo" "-j" "1" "-v" "--release" "--frozen" > > > > > > "--features" > > > > > > "panic-unwind backtrace compiler-builtins-c" "--manifest-path" > > > > > > "/usr/ports/lang/rust/work/rustc-1.41.1-src/src/libtest/Cargo.toml" > > > > > > "--message-format" "json-render-diagnostics" > > > > > > ^C^C^C > > > > > > Build completed unsuccessfully in 0:00:55 > > > > > > > > > > > > Here I pressed ^C as the build actually continues despite several > > > > > > rustdoc, > > > > > > python, and other processes being killed. > > > > > > > > > > > > swap_pager: out of swap space > > > > > > swp_pager_getswapspace(20): failed > > > > > > swap_pager: out of swap space > > > > > > swp_pager_getswapspace(11): failed > > > > > > > > > > > > The system has 32G of RAM and 2GB swap partition (as advised by > > > > > > zfs-auto > > > > > > installation option), top shows about 28G of memory free at that > > > > > > moment, > > > > > > so > > > > > > I'm wondering why the swap is being used, and if 2G should be enough > > > > > > to > > > > > > build rust. > > > > > > > > > > Looks like I got this wrong, adding a file-backed swap space I was > > > > > actually > > > > > able to run top, and seeing only 100M of memory being "Free", ~20G > > > > > memory > > > > > reported as "Active", and swap usage constantly growing being consumed > > > > > by > > > > > rustdoc process; something is really wrong here. > > > > > > > > Run top(1), hit the o key, type in size, and hit enter to have top > > > > sort the process list according to their virtual size. The culprit > > > > will eventually work its way to the top. > > > > > > Yes, it's rustdoc, and I'm seeing the same behavior as you described in > > > your > > > other reply. What's more interesting, having a little swap, processes get > > > killed almost immediately, and the build happily continues resulting > > > successful rust package. > > > > In my case, I see this behaviour twice during the build. I'll try and > > reduce my swap partition to 2 GiB and see if that makes a difference > > during the build. > > I wonder if you are seeing the problem for a long time, or it's something > recent for you? I just tried reinstalling the system from 20200227 snapshot, > and NOT seeing it, with or w/o the swap. Once I have everything installed, > I'll update to latest and re-check (note that I had WITH_CTF defined in > src.conf, though I doubt it's related). I have struggled for the past three weeks, with mad hypotheses ranging from ccache poisoning to faulty memory sticks, culminating in bootstrapping my localbase from scratch last weekend. One positive outcome is that I finally raised the size limit for my localbase ccache. -- Trond. ___ 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: can't build rust -- out of swap space
On Tue, 3 Mar 2020 12:56+0300, Yuri Pankov wrote: > On 03.03.2020 12:44, Trond Endrestøl wrote: > > On Tue, 3 Mar 2020 12:40+0300, Yuri Pankov wrote: > > > > > On 03.03.2020 11:49, Yuri Pankov wrote: > > > > With recent pkg fallout, I'm trying to build rust myself first time ever > > > > (as > > > > far as I can remember), and it's failing running out of swap on the > > > > following step: > > > > > > > > Building stage0 std artifacts (x86_64-unknown-freebsd -> > > > > x86_64-unknown-freebsd) > > > > running: > > > > "/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo" > > > > "build" "-Zconfig-profile" "--target" "x86_64-unknown-freebsd" > > > > "-Zbinary-dep-depinfo" "-j" "1" "-v" "--release" "--frozen" "--features" > > > > "panic-unwind backtrace compiler-builtins-c" "--manifest-path" > > > > "/usr/ports/lang/rust/work/rustc-1.41.1-src/src/libtest/Cargo.toml" > > > > "--message-format" "json-render-diagnostics" > > > > ^C^C^C > > > > Build completed unsuccessfully in 0:00:55 > > > > > > > > Here I pressed ^C as the build actually continues despite several > > > > rustdoc, > > > > python, and other processes being killed. > > > > > > > > swap_pager: out of swap space > > > > swp_pager_getswapspace(20): failed > > > > swap_pager: out of swap space > > > > swp_pager_getswapspace(11): failed > > > > > > > > The system has 32G of RAM and 2GB swap partition (as advised by zfs-auto > > > > installation option), top shows about 28G of memory free at that moment, > > > > so > > > > I'm wondering why the swap is being used, and if 2G should be enough to > > > > build rust. > > > > > > Looks like I got this wrong, adding a file-backed swap space I was > > > actually > > > able to run top, and seeing only 100M of memory being "Free", ~20G memory > > > reported as "Active", and swap usage constantly growing being consumed by > > > rustdoc process; something is really wrong here. > > > > Run top(1), hit the o key, type in size, and hit enter to have top > > sort the process list according to their virtual size. The culprit > > will eventually work its way to the top. > > Yes, it's rustdoc, and I'm seeing the same behavior as you described in your > other reply. What's more interesting, having a little swap, processes get > killed almost immediately, and the build happily continues resulting > successful rust package. In my case, I see this behaviour twice during the build. I'll try and reduce my swap partition to 2 GiB and see if that makes a difference during the build. -- Trond. ___ 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: can't build rust -- out of swap space
On Tue, 3 Mar 2020 12:40+0300, Yuri Pankov wrote: > On 03.03.2020 11:49, Yuri Pankov wrote: > > With recent pkg fallout, I'm trying to build rust myself first time ever (as > > far as I can remember), and it's failing running out of swap on the > > following step: > > > > Building stage0 std artifacts (x86_64-unknown-freebsd -> > > x86_64-unknown-freebsd) > > running: > > "/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo" > > "build" "-Zconfig-profile" "--target" "x86_64-unknown-freebsd" > > "-Zbinary-dep-depinfo" "-j" "1" "-v" "--release" "--frozen" "--features" > > "panic-unwind backtrace compiler-builtins-c" "--manifest-path" > > "/usr/ports/lang/rust/work/rustc-1.41.1-src/src/libtest/Cargo.toml" > > "--message-format" "json-render-diagnostics" > > ^C^C^C > > Build completed unsuccessfully in 0:00:55 > > > > Here I pressed ^C as the build actually continues despite several rustdoc, > > python, and other processes being killed. > > > > swap_pager: out of swap space > > swp_pager_getswapspace(20): failed > > swap_pager: out of swap space > > swp_pager_getswapspace(11): failed > > > > The system has 32G of RAM and 2GB swap partition (as advised by zfs-auto > > installation option), top shows about 28G of memory free at that moment, so > > I'm wondering why the swap is being used, and if 2G should be enough to > > build rust. > > Looks like I got this wrong, adding a file-backed swap space I was actually > able to run top, and seeing only 100M of memory being "Free", ~20G memory > reported as "Active", and swap usage constantly growing being consumed by > rustdoc process; something is really wrong here. Run top(1), hit the o key, type in size, and hit enter to have top sort the process list according to their virtual size. The culprit will eventually work its way to the top. -- Trond. ___ 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: can't build rust -- out of swap space
On Tue, 3 Mar 2020 11:49+0300, Yuri Pankov wrote: > With recent pkg fallout, I'm trying to build rust myself first time ever (as > far as I can remember), and it's failing running out of swap on the following > step: > > Building stage0 std artifacts (x86_64-unknown-freebsd -> > x86_64-unknown-freebsd) > running: > "/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo" > "build" "-Zconfig-profile" "--target" "x86_64-unknown-freebsd" > "-Zbinary-dep-depinfo" "-j" "1" "-v" "--release" "--frozen" "--features" > "panic-unwind backtrace compiler-builtins-c" "--manifest-path" > "/usr/ports/lang/rust/work/rustc-1.41.1-src/src/libtest/Cargo.toml" > "--message-format" "json-render-diagnostics" > ^C^C^C > Build completed unsuccessfully in 0:00:55 > > Here I pressed ^C as the build actually continues despite several rustdoc, > python, and other processes being killed. > > swap_pager: out of swap space > swp_pager_getswapspace(20): failed > swap_pager: out of swap space > swp_pager_getswapspace(11): failed > > The system has 32G of RAM and 2GB swap partition (as advised by zfs-auto > installation option), top shows about 28G of memory free at that moment, so > I'm wondering why the swap is being used, and if 2G should be enough to build > rust. > > Tried building both as root and user, DISABLE_MAKE_JOBS has no effect. > > Any hints? It's good to see that it's not only me. I suspect choice of hardware might play a role. My laptop's a Lenovo E590 with 32 GiB of memory and 16 GiB of swap space, running fairly recent -CURRENT, booted via UEFI. Activating the laptop's kernel dump partition as a secondary swap device, adding another 16 GiB of swap space, had no positive effect. In my case, I've noticed rustdoc being run as "rustdoc --crate-type proc-macro --help", and this process grows to a virtual size of 10T, grabbing all the memory and swap that it can find. My laptop even locked up on one such occasion. On Sunday, I switched to lang/rust-nightly and I managed to also build bat, exa and hexyl. I was not that lucky with firefox and ripgrep, they both caused rustc to crash in the same fashion. I've tried building lang/rust on a couple of VMs running the latest -CURRENT, only to have these builds succeed. I even added the contents of /var/db/ports from my laptop, and the build still succeeded. Building lang/rust on stable/12 is successful atm. Maybe it's a combination of hardware and changes to the FreeBSD VM subsystem. -- Trond. ___ 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: bootstrap error with make buildworld
On Tue, 18 Feb 2020 11:03+0100, Jochen Neumeister wrote: > Anyone got a tip to solve this problem? > Otherwise I would unfortunately have to reinstall the server. My Poudriere Box > runs on this server > > Am 17.02.20 um 18:14 schrieb Kyle Evans: > > On Mon, Feb 17, 2020 at 11:13 AM Jochen Neumeister > > wrote: > > > after a > > > cd /usr/src > > > svn up It might be helpful if you can tell us which revision your source tree is current at. > > > make clean > > > make -j6 buildworld make buildworld Running make without any parallelism makes it easier to know the exact point of failure. > > > [..] > > > ake[2]: stopped in /usr/src > > > --- _bootstrap-tools-link-test --- > > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/test -> /bin/test > > > --- _bootstrap-tools-link-xz --- > > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/xz -> /usr/bin/xz > > > --- _bootstrap-tools-link-unxz --- > > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/unxz -> /usr/bin/unxz > > > 1 error > > > > > > make[2]: stopped in /usr/src > > > *** [_bootstrap-tools] Error code 2 > > > > > > make[1]: stopped in /usr/src > > > 1 error > > > > > > make[1]: stopped in /usr/src > > > *** [buildworld] Error code 2 > > > > > > make: stopped in /usr/src > > > > > > make: stopped in /usr/src > > > > > > (full log sie Attachment) > > > > > > any Tipps to fix this? > > > > > Hiya, > > > > Can you scroll up and grab a bit more context? This excerpt is still > > in the process of cascading errors, so there's not much telling what > > caused it. > > > > Thanks, > > > > Kyle Evans -- Trond. ___ 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: UEFI and loader.efi in base/head past r355103
On Mon, 16 Dec 2019 10:27+0200, Toomas Soome wrote: > Also make sure you do have updated firmware. 1.22 is the latest one. > r355347 by itself does not really look like it should cause infinite loop on > normal input, but there we would need to check what we do get from keypress > and then we will see. > > Unfortunately I do not have hw to check, so we would need to use your help to > check what is really happening there. > Please poke me directly if you need help about constructing the printf() > statements to extract the information. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242660 -- Trond. ___ 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: UEFI and loader.efi in base/head past r355103
On Sun, 15 Dec 2019 20:41+0100, Trond Endrestøl wrote: > I updated the loader.efi stored in the ESP of my laptop, Lenovo > ThinkPad E590T (20NB), running boot firmware 1.22, as I wanted to try > out base/head r355441. > > As soon as I press a button, say 2 or 3, the loader freezes. > Ctrl+Alt+Delete is being recognized. > r355347 is a good candidate as it affects the reading of keystrokes. > I have therefore CC-ed tsoome@. > > In the meantime, I'll revert to r355346 and try that loader.efi. loader_lua.efi from base/head r355346 is a good one, whereas r355347 introduces a bug/feature incompatible with Lenovo TP E590T (20NB) running boot firmware 1.22. Should I file a PR? -- Trond. ___ 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"
UEFI and loader.efi in base/head past r355103
I updated the loeader.efi stored in the ESP of my laptop, Lenovo ThinkPad E590T (20NB), running boot firmware 1.22, as I wanted to try out base/head r355441. As soon as I press a button, say 2 or 3, the loader freezes. Ctrl+Alt+Delete is being recognized. I have tried loader.efi from the latest official current snapshot, 20191212, r355634, only to get the same result. Luckily, I had the wisdom of keeping the previous loeader.efi on hand. I have since expanded this to include an extra copy of the last known good loader, which will be updated less frequently. loader.efi from r355103 are not affected and is the one I use today. Any of these commits could be the culprit: r355617, r355441, r355392, r355347, r355308, r355168, r355167, or, 355132. r355347 is a good candidate as it affects the reading of keystrokes. I have therefore CC-ed tsoome@. In the meantime, I'll revert to r355346 and try that loader.efi. -- Trond. ___ 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: r355494 buildworld [libprocstat.o] Error code 1 [lib/libprocstat__L] Error code 2
On Sat, 7 Dec 2019 20:05-, Graham Perrin wrote:
> --- lib/libprocstat__L ---
> /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named 'next'
> in 'struct vm_map_entry'
> for (entryp = map->header.next;
> ~~~ ^
> /usr/src/lib/libprocstat/libprocstat.c:622:24: error: no member named 'next'
> in 'struct vm_map_entry'
> entryp = vmentry.next) {
> ~~~ ^
Try r355506.
--
Trond.
___
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: SVN r355491 breaks libprocstat
On Sat, 7 Dec 2019 20:25+0100, Trond Endrestøl wrote:
> On Sat, 7 Dec 2019 12:57-0500, Michael Butler wrote:
>
> > This member removal has other consequences. As follows ..
> >
> > --- lib/libprocstat__L ---
> > Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
> > --- libprocstat.o ---
> > /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
> > 'next' in 'struct vm_map_entry'
> > for (entryp = map->header.next;
> > ~~~ ^
> > /usr/src/lib/libprocstat/libprocstat.c:622:24: error: no member named
> > 'next' in 'struct vm_map_entry'
> > entryp = vmentry.next) {
> > ~~~ ^
> > 2 errors generated.
>
> Now we seem to be missing the prototypes:
>
> --- libprocstat.o ---
>
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:620:17: error: implicit declaration of
> function 'vm_map_entry_first' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
>
>
> for (entryp = vm_map_entry_first(map);
>
>
>
>
> ^
>
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:620:15: error: incompatible
> integer to pointer conversion assigning to 'vm_map_entry_t' (aka
> 'struct vm_map_entry *') from 'int' [-Werror,-Wint-conversion]
>
>
> for (entryp = vm_map_entry_first(map);
>
>
>
>
> ^ ~~~
>
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:622:16: error: implicit declaration of
> function 'vm_map_entry_succ' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
>
>
> entryp = vm_map_entry_succ(&vmentry)) {
>
>
>
>
> ^
>
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:622:16: note: did you mean
> 'vm_map_entry_first'?
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:620:17: note: 'vm_map_entry_first'
> declared here
Re: SVN r355491 breaks libprocstat
On Sat, 7 Dec 2019 12:57-0500, Michael Butler wrote:
> This member removal has other consequences. As follows ..
>
> --- lib/libprocstat__L ---
> Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
> --- libprocstat.o ---
> /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
> 'next' in 'struct vm_map_entry'
> for (entryp = map->header.next;
> ~~~ ^
> /usr/src/lib/libprocstat/libprocstat.c:622:24: error: no member named
> 'next' in 'struct vm_map_entry'
> entryp = vmentry.next) {
> ~~~ ^
> 2 errors generated.
Now we seem to be missing the prototypes:
--- libprocstat.o ---
/usr/src/lib/libprocstat/libprocstat.c:620:17: error: implicit declaration of
function 'vm_map_entry_first' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
for (entryp = vm_map_entry_first(map);
^
/usr/src/lib/libprocstat/libprocstat.c:620:15: error: incompatible
integer to pointer conversion assigning to 'vm_map_entry_t' (aka
'struct vm_map_entry *') from 'int' [-Werror,-Wint-conversion]
for (entryp = vm_map_entry_first(map);
^ ~~~
/usr/src/lib/libprocstat/libprocstat.c:622:16: error: implicit declaration of
function 'vm_map_entry_succ' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
entryp = vm_map_entry_succ(&vmentry)) {
^
/usr/src/lib/libprocstat/libprocstat.c:622:16: note: did you mean
'vm_map_entry_first'?
/usr/src/lib/libprocstat/libprocstat.c:620:17: note: 'vm_map_entry_first'
declared here
I'm at r355504.
--
Trond.
___
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: hang up with r352239 and r352386 with i5-7500
On Mon, 16 Sep 2019 20:09+0900, Masachika ISHIZUKA wrote: > My machine (with core i5-7500) is hangup when loading i915kms.ko > on r352239 and r352386 (1300047). > This machine was working good with r351728 (1300044). > > /etc/rc.conf has the following line. > kld_list="i915kms.ko" Pardon the intrusion. What happens if you add drm2.ko and/or switch to absolute paths? This is what I had to put in my /etc/rc.conf for a Dell Latitude E5530 to get rid of the message of drm2 being deprecated: kld_list="/boot/modules/drm2.ko /boot/modules/i915kms.ko" -- Trond. ___ 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: r350484 and ASLR enabled - init died (signal 6, exit 0)
On Mon, 5 Aug 2019 22:32+0200, Trond Endrestøl wrote: > On Mon, 5 Aug 2019 22:23+0300, Konstantin Belousov wrote: > > > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote: > > > > > I'm going home and see if VBox 6.0.10 exhibits the same behaviour. > > > > Try r350608. There was a mis-merge in the committed patch (more serious > > part), and some limits were not applied, which I did not see in my > > testing due to the mismatch between stock FreeBSD and my testing > > environment. > > I'm now at r350609, and booting with ASLR enabled works in VBox. > I'll try the Citrix Hypervisor VM tomorrow Back at $WORK, I noticed a repeat of the initial issue which persisted until I forcefully shutdown this longrunning VM, now running r350624. Upon cold start, the VM behaved as expected, making me think there might be one or more uninitialised variables at play or some odd behaviour by the hypervisors I use. -- Trond. ___ 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: r350484 and ASLR enabled - init died (signal 6, exit 0)
On Mon, 5 Aug 2019 22:23+0300, Konstantin Belousov wrote: > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote: > > > I'm going home and see if VBox 6.0.10 exhibits the same behaviour. > > Try r350608. There was a mis-merge in the committed patch (more serious > part), and some limits were not applied, which I did not see in my > testing due to the mismatch between stock FreeBSD and my testing > environment. I'm now at r350609, and booting with ASLR enabled works in VBox. I'll try the Citrix Hypervisor VM tomorrow Thank you, Konstantin. -- Trond. ___ 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: r350484 and ASLR enabled - init died (signal 6, exit 0)
On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > Hi,
> >
> > Has anyone else noticed the kernel being unable to spawn init lately?
> >
> > All I get is:
> >
> > init died (signal 6, exit 0)
> > panic: Going nowhere without my init!
> >
> > /sbin/init hasn't had any changes in 4 months, and is present in /sbin
> > in the new BE.
> >
> > I've tried and failed in VBox at home this weekend, and in Citrix
> > Hypervisor 8 at $WORK today. I think we can rule out the hypervisors.
> >
> > Last known working revision is r350400.
> >
> > There are numerous kernel changes between r350400 and r350583. I'll
> > try each revision in succession and see if I can identify any
> > culprits.
> > ...
>
> I have not seen the behavior in question; my last update was from
> r350566 to r350584 (and was quite uneventful).
>
> In each case, a "real machine" was used (laptop & a build machine).
After more trial and error, r350484 is the culprit for Citrix
Hypervisor 8.
I have these lines in /boot/loader.conf:
kern.elf32.aslr.enable="1"
kern.elf32.aslr.pie_enable="1"
kern.elf64.aslr.enable="1"
kern.elf64.aslr.pie_enable="1"
r350483 works like a charm, and so does r350484 iff I disable ASLR.
Reenabling ASLR and setting kern.elf{64,32}.aslr.stack_gap to zero has
no effect.
I've cc'd kib@ on this one.
I'm going home and see if VBox 6.0.10 exhibits the same behaviour.
--
Trond.
___
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"
r350583 - init died (signal 6, exit 0)
Hi, Has anyone else noticed the kernel being unable to spawn init lately? All I get is: init died (signal 6, exit 0) panic: Going nowhere without my init! /sbin/init hasn't had any changes in 4 months, and is present in /sbin in the new BE. I've tried and failed in VBox at home this weekend, and in Citrix Hypervisor 8 at $WORK today. I think we can rule out the hypervisors. Last known working revision is r350400. There are numerous kernel changes between r350400 and r350583. I'll try each revision in succession and see if I can identify any culprits. -- Trond. ___ 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: filesystem mount problem
On Sun, 21 Jul 2019 15:07-0400, AN wrote: > I don't understand why the /tmp is being mounted. It is causing problems > because when I try to run portupgrade it fails for lack of space. If I > forcibly unmount it everything breaks. tmpmfs is set to "AUTO" in /etc/defaults/rc.conf. Try setting tmpmfs="NO" in /etc/rc.conf, reboot, and see if this prohibits the creation of /tmp as a tmpfs. You can also set PKG_TMPDIR or TMPDIR to point to, say, /var/tmp. E.g.: export PKG_TMPDIR=/var/tmp or setenv PKG_TMPDIR /var/tmp > # umount -v /tmp > umount: unmount of /tmp failed: Device busy > [root@FreeBSD_13 ~]# umount -vf /tmp > tmpfs: unmount from /tmp > [root@FreeBSD_13 ~]# df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/ada0p3428G245G149G62%/ > devfs 1.0K1.0K 0B 100%/dev > linprocfs 4.0K4.0K 0B 100%/compat/linux/proc > tmpfs 47G4.0K 47G 0%/compat/linux/dev/shm > [root@FreeBSD_13 ~]# vinagre > Unable to init server: Could not connect to 127.0.0.1: Connection refused > > (vinagre:27111): Gtk-WARNING **: 15:04:21.599: cannot open display: :0 This is expected when /tmp/.X11-unix/X0 ceases to exist, among other files within /tmp. -- Trond. ___ 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: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)
On Sun, 16 Jun 2019 17:49+0200, Rainer Hurling wrote: > This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom > II X6 1090T). > > Am I the only one, who observes this breakage? Thanks for any hint. No. This also happens on Intel Core i7 960. I will retry buildworld using -D WITHOUT_TESTS. -- Trond. ___ 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 in fbt_provide_module_function() on head amd64 r347403
On Thu, 9 May 2019 17:23-0500, Larry Rosenman wrote:
> On 05/09/2019 5:19 pm, Trond Endrestøl wrote:
> > Host is Windows 7 x64 SP1.
> > CPU is Core i7 960.
> > Hypervisor is VirtualBox 6.0.6.
> > VM is using UEFI.
> > Kernel config is
> > https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head
> >
> > Crash happens early during boot, right after launching the APs.
> >
> > fault virtual address = 0x0
> > [...]
> > KDB backtrace:
> > db_trace_self_wrapper() at
> > vpanic() at
> > panic() at
> > trap_fatal() at
> > trap_pfault() at
> > trap() at
> > calltrap() at
> > -- trap 0xc, rip = 0x8196d63a, rsp = 0x8198d730, rbp =
> > 0x8198d790 ---
> > fbt_provide_module_function() at 0x8196d63a =
> > fbt_provide_module_function+0x7a/frame 0x8198d790
> > link_elf_each_function_nameval() at 0x80822ae5 =
> > link_elf_each_function_nameval+0x115/frame 0x8198d7e0
> > fbt_provide_module() at 0x8196c33e =
> > fbt_provide_module+0xde/frame 0x8198dc10
> > fbt_linker_file_cb() at 0x8196c242 =
> > fbt_linker_file_cb+0x12/frame 0x8198dc20
> > linker_file_foreach() at 0x807c47b7 =
> > linker_file_foreach+0x67/frame 0x8198dc60
> > mi_startup() at 0x80786de6 = mi_startup+0x216/frame
> > 0x8198dcb0
> > btext() at 0x8030da2c = btext+0x2c
> > Uptime: 1s
> >
> > Previous BE is r346969 and works flawlessly.
> > No dumpdev is enabled to capture the details this early during boot.
> > Suggestions are welcome.
>
> There is a patch:
> From: ma...@freebsd.org (on my Crash loading dtraceall thread):
>
>
> I see, my theory above is not the real problem here. The resolver for
> x86_rng_store() may return NULL, which we do not expect. Can you show
> the CPU info and features lines from the dmesg to confirm?
CPU: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz (3207.36-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x196a5 Family=0x6 Model=0x1a Stepping=5
Features=0x1783fbff
Features=0x180201
AMD Features=0x28100800
AMD Features2=0x1
TSC: P-state invariant
I'll try the patch below when I get home.
Thanks.
> Also see if this patch helps:
>
> diff --git a/sys/dev/random/ivy.c b/sys/dev/random/ivy.c
> index 57f3d0a1d80b..71065d788cf9 100644
> --- a/sys/dev/random/ivy.c
> +++ b/sys/dev/random/ivy.c
> @@ -97,6 +97,13 @@ x86_rdseed_store(u_long *buf)
> return (retry);
> }
>
> +static int
> +x86_dead_store(u_long *buf __unused)
> +{
> +
> +panic("missing hardware PRNG support");
> +}
> +
> DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf), static)
> {
> has_rdrand = (cpu_feature2 & CPUID2_RDRAND);
> @@ -107,7 +114,7 @@ DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf),
> static)
> else if (has_rdrand)
> return (x86_rdrand_store);
> else
> -return (NULL);
> +return (x86_dead_store);
> }
>
> /* It is required that buf length is a multiple of sizeof(u_long). */
--
Trond.
___
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 in fbt_provide_module_function() on head amd64 r347403
Host is Windows 7 x64 SP1. CPU is Core i7 960. Hypervisor is VirtualBox 6.0.6. VM is using UEFI. Kernel config is https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head Crash happens early during boot, right after launching the APs. fault virtual address = 0x0 [...] KDB backtrace: db_trace_self_wrapper() at vpanic() at panic() at trap_fatal() at trap_pfault() at trap() at calltrap() at -- trap 0xc, rip = 0x8196d63a, rsp = 0x8198d730, rbp = 0x8198d790 --- fbt_provide_module_function() at 0x8196d63a = fbt_provide_module_function+0x7a/frame 0x8198d790 link_elf_each_function_nameval() at 0x80822ae5 = link_elf_each_function_nameval+0x115/frame 0x8198d7e0 fbt_provide_module() at 0x8196c33e = fbt_provide_module+0xde/frame 0x8198dc10 fbt_linker_file_cb() at 0x8196c242 = fbt_linker_file_cb+0x12/frame 0x8198dc20 linker_file_foreach() at 0x807c47b7 = linker_file_foreach+0x67/frame 0x8198dc60 mi_startup() at 0x80786de6 = mi_startup+0x216/frame 0x8198dcb0 btext() at 0x8030da2c = btext+0x2c Uptime: 1s Previous BE is r346969 and works flawlessly. No dumpdev is enabled to capture the details this early during boot. Suggestions are welcome. -- Trond. ___ 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: r346025: ZFS filesystems do not mount anymore
On Tue, 9 Apr 2019 10:06+0200, Trond Endrestøl wrote: > On Mon, 8 Apr 2019 19:58+0200, O. Hartmann wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Hello, > > > > after a bunch of updates this weekend, mounting ZFS filesystems on CURRENT > > r346025 doesn't > > work anymore at boot time when ZFS is built-in-kernel. zfs_enable="YES" is > > set in /etc/rc.conf. > > > > After the system has booted, mounting all ZFS filesystems via "zfs mount > > -a" operates as > > expected and all filesystems are available as usual. > > I blame r346017: > > Trying to mount root from zfs:zroot/ROOT/20190409-r346017 [] > Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. > Setting hostid: 0xf9071336. > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > Starting file system checks: > Mounting local filesystems:. > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > 32-bit compatibility ldconfig path: /usr/lib32 > > [...] > > Creating and/or trimming log files. > Starting syslogd. > Apr 9 09:48:32 freebsd-head-zfs syslogd: /var/log/security: No > such file or directory > Setting date via ntp. > 9 Apr 09:48:38 ntpdate[1073]: step time server 2001:W:X:Y::Z offset > -0.992370 sec > No core dumps found. > Clearing /tmp (X related). > Updating motd:. > Mounting late filesystems:mount: /usr/compat/linux: No such file or directory > mount: /usr/compat/linux: No such file or directory > mount: /usr/compat/linux: No such file or directory > mount: /usr/compat/linux: No such file or directory > . > Mounting /etc/fstab filesystems failed, startup aborted > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > Enter full pathname of shell or RETURN for /bin/sh: > root@freebsd-head-zfs:/ # zfs mount -av > root@freebsd-head-zfs:/ # mount -al > root@freebsd-head-zfs:/ # exit > Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. > Setting hostid: 0xf9071336. > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > Fast boot: skipping disk checks. > Mounting local filesystems:. > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg > /usr/local/lib/perl5/5.28/mach/CORE > 32-bit compatibility ldconfig path: /usr/lib32 > > [...] At a later point, this happens: Starting syslogd. usage: protect [-i] command protect [-cdi] -g pgrp | -p pid Setting date via ntp. It looks like syslogd is no longer protected against the OOM killer. > Once I manually mount the remaining filesystems, multiuser boot > proceeds as expected. My kernel has options ZFS, and the boot scripts > doesn't account for this scenario. -- Trond. ___ 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: r346025: ZFS filesystems do not mount anymore
On Mon, 8 Apr 2019 19:58+0200, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > after a bunch of updates this weekend, mounting ZFS filesystems on CURRENT > r346025 doesn't > work anymore at boot time when ZFS is built-in-kernel. zfs_enable="YES" is > set in /etc/rc.conf. > > After the system has booted, mounting all ZFS filesystems via "zfs mount -a" > operates as > expected and all filesystems are available as usual. I blame r346017: Trying to mount root from zfs:zroot/ROOT/20190409-r346017 [] Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. Setting hostid: 0xf9071336. interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs Starting file system checks: Mounting local filesystems:. interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs ELF ldconfig path: /lib /usr/lib /usr/lib/compat 32-bit compatibility ldconfig path: /usr/lib32 [...] Creating and/or trimming log files. Starting syslogd. Apr 9 09:48:32 freebsd-head-zfs syslogd: /var/log/security: No such file or directory Setting date via ntp. 9 Apr 09:48:38 ntpdate[1073]: step time server 2001:W:X:Y::Z offset -0.992370 sec No core dumps found. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:mount: /usr/compat/linux: No such file or directory mount: /usr/compat/linux: No such file or directory mount: /usr/compat/linux: No such file or directory mount: /usr/compat/linux: No such file or directory . Mounting /etc/fstab filesystems failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Enter full pathname of shell or RETURN for /bin/sh: root@freebsd-head-zfs:/ # zfs mount -av root@freebsd-head-zfs:/ # mount -al root@freebsd-head-zfs:/ # exit Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. Setting hostid: 0xf9071336. interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs Fast boot: skipping disk checks. Mounting local filesystems:. interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.28/mach/CORE 32-bit compatibility ldconfig path: /usr/lib32 [...] Once I manually mount the remaining filesystems, multiuser boot proceeds as expected. My kernel has options ZFS, and the boot scripts doesn't account for this scenario. -- Trond. ___ 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: leaked swap?
On Tue, 19 Mar 2019 16:02+0300, Slawa Olhovchenkov wrote: > On Mon, Mar 18, 2019 at 11:00:10PM +0200, Andriy Gapon wrote: > > > On 18/03/2019 20:01, Andrey Fesenko wrote: > > > Not this? ZFS use wired and not clean only reboot? > > > https://reviews.freebsd.org/D7538?id=25108 > > > > Wired memory surely has nothing to do with swap. > > Wired memory can pressure to swapable memory I've noticed setting vm.pageout_update_period=0 in /etc/sysctl.conf eliminated excessive swapping, effectively disabling r334154. Maybe this is irrelevant. I waited a while before mentioning this. Response times of idle services skyrocketed in my case. -- Trond. ___ 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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 13:27+0200, Andriy Gapon wrote: > On 12/03/2019 11:37, Trond Endrestøl wrote: > > # Parallel mounting of ZFS filesystems leaves a chaotic listing of > > # mounted filesystems when viewed by df(1). > > df reports filesystems in the order they were mounted. > If you unmount and remount a filesystem or mount a new filesystem, you can see > it for yourself. Also, if you ever used fstab then you could see that too. > Just because previously the output happened to look like it was sorted does > not > mean that it was or that there was such an intention. I am aware of all of this. I was caught by surprise when my ZFS filesystems appeared partially ordered. I know that / and /dev are mounted by the kernel, and sometime later the remaining UFS/ZFS filesystems, and I also have a few synthetic filesystems mounted late in the boot process, and the latter ones (still) appear at the end of df(1)'s output. Order has somewhat been restored. Maybe it's no biggie. -- Trond. ___ 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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 12:14+0100, Trond Endrestøl wrote:
> On Tue, 12 Mar 2019 11:37+0100, Jan Martin Mikkelsen wrote:
>
> > > On 12 Mar 2019, at 10:37, Trond Endrestøl
> > > wrote:
> > > I concocted a shell script, it looks promising:
> > >
> > > #!/bin/sh
> > > #-
> > > # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> > > # mounted filesystems when viewed by df(1).
> > > # Separating the header from the remaining lines and sorting the
> > > # latter before recombining is a viable solution.
> > > #-
> > >
> > > DF=/bin/df
> > >
> > > ${DF} ${@} | grep^Filesystem
> > > ${DF} ${@} | grep -v ^Filesystem | sort -k 6
> > >
> > > # new-df.sh
> >
> > An alternative sort approach, which handles df arguments which change the
> > number of columns, and only invokes df once:
> >
> > ${DF} "$@" | awk '/^Filesystem/ { print; sort = "sort -k " NF } !
> > /^Filesystem/ { print | sort }’
>
> Well, yes and no, mostly no.
>
> Why are we feeding each line from df(1) separately to sort(1)?
> It defeats the entire purpose. No sorting takes place.
>
> We might be better off accumulating the majority of the lines and
> sorting them in an END block.
How about this?
/bin/df ${@} | /usr/bin/awk '/^Filesystem/ { print; sort = "/usr/bin/sort -sk "
NF-1 } ! /^Filesystem/ { if (length(acc) > 0) acc = acc "\n" $0; else acc = $0;
} END { print acc | sort }'
--
Trond.
___
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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 11:37+0100, Jan Martin Mikkelsen wrote:
> > On 12 Mar 2019, at 10:37, Trond Endrestøl
> > wrote:
> > I concocted a shell script, it looks promising:
> >
> > #!/bin/sh
> > #-
> > # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> > # mounted filesystems when viewed by df(1).
> > # Separating the header from the remaining lines and sorting the
> > # latter before recombining is a viable solution.
> > #-
> >
> > DF=/bin/df
> >
> > ${DF} ${@} | grep^Filesystem
> > ${DF} ${@} | grep -v ^Filesystem | sort -k 6
> >
> > # new-df.sh
>
> An alternative sort approach, which handles df arguments which change the
> number of columns, and only invokes df once:
>
> ${DF} "$@" | awk '/^Filesystem/ { print; sort = "sort -k " NF } !
> /^Filesystem/ { print | sort }’
Well, yes and no, mostly no.
Why are we feeding each line from df(1) separately to sort(1)?
It defeats the entire purpose. No sorting takes place.
We might be better off accumulating the majority of the lines and
sorting them in an END block.
--
Trond.
___
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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 08:54+0200, Andriy Gapon wrote:
> On 12/03/2019 02:12, Rodney W. Grimes wrote:
> >> On 11/03/2019 23:03, Freddie Cash wrote:
> >>> Wouldn't it make more sense to teach df, du, "zfs list", and other things
> >>> that list the mounted filesystems to use sorted output?
> >>
> >> | sort [desired options]
> >
> > Except that df and zfs list have a header that you have to deal with,
> > which is not so easy to get sort to do the right things with out
> > some hoop jumping.
>
> Like "| tail +2" ?
> Or if it's just for visual inspection (as seems to be the case for the
> original
> poster) just mentally filter out that line.
>
> >> P.S.
> >> zfs list already supports sorting by a specific property.
> >
> > Perhaps make zfs list -s mountpoint a default?
>
> Why?
I concocted a shell script, it looks promising:
#!/bin/sh
#-
# Parallel mounting of ZFS filesystems leaves a chaotic listing of
# mounted filesystems when viewed by df(1).
# Separating the header from the remaining lines and sorting the
# latter before recombining is a viable solution.
#-
DF=/bin/df
${DF} ${@} | grep^Filesystem
${DF} ${@} | grep -v ^Filesystem | sort -k 6
# new-df.sh
--
Trond.
___
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: ZFS no longer mounted in alphanumerical order
On Mon, 11 Mar 2019 14:03-0700, Freddie Cash wrote: > On Mon, Mar 11, 2019 at 1:59 PM Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > On Mon, 11 Mar 2019 13:47-0700, Matthew Ahrens wrote: > > > > > On Mon, Mar 11, 2019 at 11:33 AM Trond Endrestøl < > > > trond.endres...@fagskolen.gjovik.no> wrote: > > > > > > > Has anyone else noticed ZFS datasets are no longer mounted in > > > > alphanumerical order in CURRENT? It looks more like they are mounted > > > > in the order in which they are encountered. > > > > > > Wouldn't surprise me if this was caused by the parallel mount changes. > > The > > > filesystems should still be mounted in hierarchical order (parents before > > > children), so everything should still work. What problem are you seeing > > as > > > a result of the changed mount order? > > > > Actually no problems other than it's rather unintuitive when looking > > at the output of "df -ah". Could we have a command line option for > > disabling the parallel mount? > > Wouldn't it make more sense to teach df, du, "zfs list", and other things > that list the mounted filesystems to use sorted output? That's a better alternative. > IOW, is it the mount process itself that's an issue, or just the output of > mounted filesystems list? The latter in my case. -- Trond. ___ 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: ZFS no longer mounted in alphanumerical order
On Mon, 11 Mar 2019 13:47-0700, Matthew Ahrens wrote: > On Mon, Mar 11, 2019 at 11:33 AM Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > Has anyone else noticed ZFS datasets are no longer mounted in > > alphanumerical order in CURRENT? It looks more like they are mounted > > in the order in which they are encountered. > > Wouldn't surprise me if this was caused by the parallel mount changes. The > filesystems should still be mounted in hierarchical order (parents before > children), so everything should still work. What problem are you seeing as > a result of the changed mount order? Actually no problems other than it's rather unintuitive when looking at the output of "df -ah". Could we have a command line option for disabling the parallel mount? -- Trond. ___ 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"
ZFS no longer mounted in alphanumerical order
Has anyone else noticed ZFS datasets are no longer mounted in alphanumerical order in CURRENT? It looks more like they are mounted in the order in which they are encountered. Are there any chance of reverting to the old behaviour? Here's an example: Filesystem SizeUsed Avail Capacity Mounted on zroot/ROOT/20190311-r3450136.8G1.7G5.1G25%/ devfs 1.0K1.0K 0B 100%/dev zroot/usr/obj 5.1G 30K5.1G 0%/usr/obj zroot/usr/src 5.1G 30K5.1G 0%/usr/src zroot/home 5.1G 30K5.1G 0%/home zroot/usr/ports5.1G 30K5.1G 0%/usr/ports zroot/tmp 5.1G 51K5.1G 0%/tmp zroot/usr/ports/packages 5.1G 30K5.1G 0% /usr/ports/packages zroot/usr/ports/workdirs 5.1G 30K5.1G 0% /usr/ports/workdirs zroot/usr/ports/local 5.1G 30K5.1G 0%/usr/ports/local zroot/usr/compat 5.1G 30K5.1G 0%/usr/compat zroot/usr/ports/distfiles 5.1G 30K5.1G 0% /usr/ports/distfiles zroot/var 5.1G 22M5.1G 0%/var zroot/nfs 5.1G 30K5.1G 0%/nfs zroot/media5.1G 31K5.1G 0%/media zroot/usr/local5.9G804M5.1G13%/usr/local zroot/usr/compat/linux 5.1G 31K5.1G 0%/usr/compat/linux zroot/var/db/ports 5.1G 30K5.1G 0%/var/db/ports zroot/var/lib 5.1G 30K5.1G 0%/var/lib zroot/usr/local/etc5.1G924K5.1G 0%/usr/local/etc zroot/var/empty5.1G 30K5.1G 0%/var/empty zroot/usr/local/pgsql 5.1G 30K5.1G 0%/usr/local/pgsql zroot/var/audit5.1G 30K5.1G 0%/var/audit zroot/var/backups 5.1G3.2M5.1G 0%/var/backups zroot/var/mail 5.1G 30K5.1G 0%/var/mail zroot/usr/local/certs 5.1G 30K5.1G 0%/usr/local/certs zroot/var/unbound 5.1G 30K5.1G 0%/var/unbound zroot/var/db/mysql 5.1G 30K5.1G 0%/var/db/mysql zroot/usr/local/www5.1G 30K5.1G 0%/usr/local/www zroot/usr/local/tests 5.1G 30K5.1G 0%/usr/local/tests zroot/var/db/boinc 5.1G 30K5.1G 0%/var/db/boinc zroot/var/Named5.1G 30K5.1G 0%/var/Named zroot/var/db/etcupdate 5.1G993K5.1G 0%/var/db/etcupdate zroot/var/db/hyperv5.1G 30K5.1G 0%/var/db/hyperv zroot/usr/local/var5.1G 30K5.1G 0%/usr/local/var zroot/var/crash5.1G 30K5.1G 0%/var/crash zroot/usr/local/info 5.1G 32K5.1G 0%/usr/local/info zroot/var/tmp 5.1G 30K5.1G 0%/var/tmp zroot/var/spool5.1G 81K5.1G 0%/var/spool zroot/var/log 5.1G8.7M5.1G 0%/var/log zroot/var/db/bacula5.1G 30K5.1G 0%/var/db/bacula zroot/var/run 5.1G 53K5.1G 0%/var/run zroot/var/cache/synth 5.1G801K5.1G 0%/var/cache/synth zroot/var/db/pkg 5.1G7.1M5.1G 0%/var/db/pkg zroot/var/synth5.1G 34K5.1G 0%/var/synth zroot/var/spool/ftp5.1G 30K5.1G 0%/var/spool/ftp zroot/var/synth/builders 5.1G 30K5.1G 0% /var/synth/builders fdescfs1.0K1.0K 0B 100%/dev/fd procfs 4.0K4.0K 0B 100%/proc devfs 1.0K1.0K 0B 100% /usr/compat/linux/dev fdescfs1.0K1.0K 0B 100% /usr/compat/linux/dev/fd linprocfs 4.0K4.0K 0B 100% /usr/compat/linux/proc linsysfs 4.0K4.0K 0B 100% /usr/compat/linux/sys -- Trond. ___ 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: 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled
On Sun, 20 Jan 2019 13:09-0500, David Boyd wrote: > 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled. > > Running in VirtualBox 6.0.2. > > The identical configuration running 12.0-RELEASE-p2, 12.0-STABLE, 11.2- > RELEASE-p8 and 11.2-STABLE do not exhibit this behavior. > > This (VM) is a test machine and I can do anything that will help > identify the root of this problem. Is the VM configured to use UEFI as the boot firmware? I've noticed 13.0-CURRENT fails to poweroff, be it by way of shutdown -p now or halt -p, when using UEFI on VBox 5.2.x and 6.0.y. shutdown -h and plain halt works as intended. Maybe this is completely unrelated to your issue. > I have included screenshots of the debug output and a backtrace. The screenshots got stripped off by the mailman list software. Can you reupload them somewhere else, or transcribe the relevant details? -- Trond. ___ 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: r343111 breaks build
On Thu, 17 Jan 2019 15:53+0100, Trond Endrestøl wrote: > Try the attached patch, [...] I fail to see how r343113 actually fixes r343111. Attached patch augments and corrects the changes done in r343113. -- Trond.Index: contrib/libc++/include/errno.h === --- contrib/libc++/include/errno.h (revision 343114) +++ contrib/libc++/include/errno.h (working copy) @@ -56,6 +56,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -63,6 +64,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EOWNERDEAD +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -70,6 +72,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -76,6 +79,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EOWNERDEAD +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -83,6 +87,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -89,6 +94,7 @@ #if defined(ELAST) #undef ELAST #define ELAST ENOTRECOVERABLE +#endif #elif defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EINTEGRITY __elast1 @@ -95,6 +101,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #endif // !defined(OWNERDEAD) && !defined(NOTRECOVERABLE) && !defined(INTEGRITY) ___ 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: r343111 breaks build
On Thu, 17 Jan 2019 04:49-0800, David Wolfskill wrote: > On Thu, Jan 17, 2019 at 03:37:16PM +0300, Lev Serebryakov wrote: > > > > I can not build CURRENT r343111 on r343022 world. Looks like r343111 > > itself cause problems (r343110 builds): > > > > In file included from /data/src/contrib/libc++/src/algorithm.cpp:11: > > In file included from /data/src/contrib/libc++/include/random:1646: > > In file included from /data/src/contrib/libc++/include/istream:163: > > In file included from /data/src/contrib/libc++/include/ostream:138: > > In file included from /data/src/contrib/libc++/include/ios:216: > > In file included from /data/src/contrib/libc++/include/__locale:18: > > In file included from /data/src/contrib/libc++/include/mutex:191: > > In file included from /data/src/contrib/libc++/include/__mutex_base:16: > > In file included from /data/src/contrib/libc++/include/system_error:146: > > In file included from /data/src/contrib/libc++/include/__errc:106: > > In file included from /data/src/contrib/libc++/include/cerrno:27: > > /data/src/contrib/libc++/include/errno.h:70:2: error: unterminated > > conditional directive > > #ifdef ELAST > > ^ > > /data/src/contrib/libc++/include/errno.h:63:2: error: unterminated > > conditional directive > > #ifdef ELAST > > ^ > > ... > > Confirmed (though in my case, I'm building on r343088, and I did not try > building r343110). I did see the above failure on both my build machine > and my laptop. Try the attached patch, repeated here in case it gets munched by mailman: Index: contrib/libc++/include/errno.h === --- contrib/libc++/include/errno.h (revision 343111) +++ contrib/libc++/include/errno.h (working copy) @@ -56,6 +56,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -63,6 +64,7 @@ #ifdef ELAST #undef ELAST #define ELAST EOWNERDEAD +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -70,6 +72,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -76,6 +79,7 @@ #ifdef ELAST #undef ELAST #define ELAST EOWNERDEAD +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -83,6 +87,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -89,6 +94,7 @@ #ifdef ELAST #undef ELAST #define ELAST ENOTRECOVERABLE +#endif #elif defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EINTEGRITY __elast1 @@ -95,6 +101,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #endif // !defined(OWNERDEAD) && !defined(NOTRECOVERABLE) && !defined(INTEGRITY) -- Trond.Index: contrib/libc++/include/errno.h === --- contrib/libc++/include/errno.h (revision 343111) +++ contrib/libc++/include/errno.h (working copy) @@ -56,6 +56,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -63,6 +64,7 @@ #ifdef ELAST #undef ELAST #define ELAST EOWNERDEAD +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -70,6 +72,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -76,6 +79,7 @@ #ifdef ELAST #undef ELAST #define ELAST EOWNERDEAD +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -83,6 +87,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -89,6 +94,7 @@ #ifdef ELAST #undef ELAST #define ELAST ENOTRECOVERABLE +#endif #elif defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EINTEGRITY __elast1 @@ -95,6 +101,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #endif // !defined(OWNERDEAD) && !defined(NOTRECOVERABLE) && !defined(INTEGRITY) ___ 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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On Fri, 12 Oct 2018 09:59+0200, Raúl wrote: > (also deleted obj) I do that whenever sys/sys/param.h changes. My builder wipes obj unconditionally every Monday in addition to the above. -- Trond. ___ 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: kernel build failure
On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote: > Sorry guys, last time I touched ZFS I tried to push to make it an option to > statically link and was actually told that it wasn't something anyone else > wanted. The issue comes from ZFS not being in NOTES and thus not in LINT. If consensus is that "options ZFS" is no longer valid, then maybe UPDATING should reflect the fact. I can live with loading zfs.ko and opensolaris.ko at boot time, but I think this is a step backwards. -- Trond. ___ 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: kernel build failure
On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote: > On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote: > > > Is anyone else seeing this when building a new kernel with ZFS compiled in? > > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel > > --- kernel --- > > linking kernel > > ld: error: undefined symbol: dbuf_stats_init > > >>> referenced by dbuf.c > > >>> dbuf.o:(dbuf_init) > > > > ld: error: undefined symbol: dbuf_stats_destroy > > >>> referenced by dbuf.c > > >>> dbuf.o:(dbuf_fini) > > *** [kernel] Error code 1 > > I was just about to create a thread of my own. > > I suspect r337670 didn't add everything > cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See > lines 652 and 697. > > Meanwhile, I'll attempt to revert to r337669. r337669 builds and runs. Looking further into r337670, it seems cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dbuf.h added prototypes for dbuf_stats_init() and dbuf_stats_destroy(), but no implementation can be found in any of the files affected by r337670. -- Trond. ___ 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: kernel build failure
On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote: > Is anyone else seeing this when building a new kernel with ZFS compiled in? > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel > --- kernel --- > linking kernel > ld: error: undefined symbol: dbuf_stats_init > >>> referenced by dbuf.c > >>> dbuf.o:(dbuf_init) > > ld: error: undefined symbol: dbuf_stats_destroy > >>> referenced by dbuf.c > >>> dbuf.o:(dbuf_fini) > *** [kernel] Error code 1 I was just about to create a thread of my own. I suspect r337670 didn't add everything cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See lines 652 and 697. Meanwhile, I'll attempt to revert to r337669. -- Trond. ___ 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: r334533 renders head unbootable on XenServer 7.4
On Fri, 8 Jun 2018 02:51+0200, Mateusz Guzik wrote: > Thanks for the report. Next time if you identify the culprit please cc: > the committer - not everyone watches mailing lists too closely. Wilco. > I set it up on FreeBSD as dom0 and verified the problem exists. > I fixed it with the following: > https://svnweb.freebsd.org/changeset/base/334820 Thanks. I'll try to build r334820+. -- Trond. ___ 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"
r334533 renders head unbootable on XenServer 7.4
After trial and error, I found r334533 to be responsible for rendering head unbootable on XenServer 7.4. Neither of the two available XenServer patches has been applied on the host server. Normal and verbose boot messages stops non-deterministically at: hpet0: iomem 0xfed0-0xfed003ff on acpi0 Or at: granttable0: on xenpv0 This is on a non-critical VM, but I think this issue should be resolved by the time stable/12 becomes available, or if stable/11 will be impacted by a MFH of r334533 in the near future. The host server will be upgraded to XenServer 7.5 by the end of the week, in case that makes the issue go away. -- Trond. ___ 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: ZFS i/o error in recent 12.0
On Tue, 20 Mar 2018 08:00+0900, KIRIYAMA Kazuhiko wrote: > Hi, > > I've been encountered suddenly death in ZFS full volume > machine(r330434) about 10 days after installation[1]: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS of pool zroot > gptzfsboot: failed to mount default pool zroot > > FreeBSD/x86 boot > ZFS: i/o error - all block copies unavailable > ZFS: can't find dataset u > Default: zroot/<0x0>: > boot: > > Partition is bellow: > > # gpart show /dev/mfid0 > => 40 31247564720 mfid0 GPT (15T) >40 409600 1 efi (200M) >409640 1024 2 freebsd-boot (512K) >410664 984 - free - (492K) >411648268435456 3 freebsd-swap (128G) > 268847104 30978715648 4 freebsd-zfs (14T) > 31247562752 2008 - free - (1.0M) > > # > > But nothing had beed happend in old current ZFS full volume > machine(r327038M). According to [2] the reason is boot/zfs/zpool.cache > inconsistent. I've tried to cope with this by repairing > /boot [3] from rescue bootable USB as follows: > > # kldload zfs > # zpool import >pool: zroot > id: 17762298124265859537 > state: ONLINE > action: The pool can be imported using its name or numeric identifier. > config: > > zroot ONLINE > mfid0p4 ONLINE > # zpool import -fR /mnt zroot > # df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/da0p2 14G1.6G 11G13%/ > devfs 1.0K1.0K 0B 100%/dev > zroot/.dake 14T 18M 14T 0%/mnt/.dake > zroot/ds 14T 96K 14T 0%/mnt/ds > zroot/ds/backup 14T 88K 14T 0%/mnt/ds/backup > zroot/ds/backup/kazu.pis 14T 31G 14T 0% > /mnt/ds/backup/kazu.pis > zroot/ds/distfiles 14T7.9M 14T 0%/mnt/ds/distfiles > zroot/ds/obj 14T 10G 14T 0%/mnt/ds/obj > zroot/ds/packages14T4.0M 14T 0%/mnt/ds/packages > zroot/ds/ports 14T1.3G 14T 0%/mnt/ds/ports > zroot/ds/src 14T2.6G 14T 0%/mnt/ds/src > zroot/tmp14T 88K 14T 0%/mnt/tmp > zroot/usr/home 14T136K 14T 0%/mnt/usr/home > zroot/usr/local 14T 10M 14T 0%/mnt/usr/local > zroot/var/audit 14T 88K 14T 0%/mnt/var/audit > zroot/var/crash 14T 88K 14T 0%/mnt/var/crash > zroot/var/log14T388K 14T 0%/mnt/var/log > zroot/var/mail 14T 92K 14T 0%/mnt/var/mail > zroot/var/ports 14T 11M 14T 0%/mnt/var/ports > zroot/var/tmp14T6.0M 14T 0%/mnt/var/tmp > zroot/vm 14T2.8G 14T 0%/mnt/vm > zroot/vm/tbedfc 14T1.6G 14T 0%/mnt/vm/tbedfc > zroot14T 88K 14T 0%/mnt/zroot > # zfs list > NAME USED AVAIL REFER MOUNTPOINT > zroot 51.1G 13.9T88K /mnt/zroot > zroot/.dake 18.3M 13.9T 18.3M /mnt/.dake > zroot/ROOT1.71G 13.9T88K none > zroot/ROOT/default1.71G 13.9T 1.71G /mnt/mnt > zroot/ds 45.0G 13.9T96K /mnt/ds > zroot/ds/backup 30.8G 13.9T88K /mnt/ds/backup > zroot/ds/backup/kazu.pis 30.8G 13.9T 30.8G /mnt/ds/backup/kazu.pis > zroot/ds/distfiles7.88M 13.9T 7.88M /mnt/ds/distfiles > zroot/ds/obj 10.4G 13.9T 10.4G /mnt/ds/obj > zroot/ds/packages 4.02M 13.9T 4.02M /mnt/ds/packages > zroot/ds/ports1.26G 13.9T 1.26G /mnt/ds/ports > zroot/ds/src 2.56G 13.9T 2.56G /mnt/ds/src > zroot/tmp 88K 13.9T88K /mnt/tmp > zroot/usr 10.4M 13.9T88K /mnt/usr > zroot/usr/home 136K 13.9T 136K /mnt/usr/home > zroot/usr/local 10.2M 13.9T 10.2M /mnt/usr/local > zroot/var 17.4M 13.9T88K /mnt/var > zroot/var/audit 88K 13.9T88K /mnt/var/audit > zroot/var/crash 88K 13.9T88K /mnt/var/crash > zroot/var/log 388K 13.9T 388K /mnt/var/log > zroot/var/mail 92K 13.9T92K /mnt/var/mail > zroot/var/ports 10.7M 13.9T 10.7M /mnt/var/ports > zroot/var/tmp 5.98M 13.9T 5.98M /mnt/var/tmp > zroot/vm 4.33G 13.9T 2.75G /mnt/vm > zroot/vm/tbedfc 1.58G 13.9T 1.58G /mnt/vm/tbedfc > # zfs mount zroot/ROOT/default > # cd /mnt/mnt/ > # mv boot boot.bak > # cp -RPp boot.bak boot > # gpart show /dev/mfid0 > => 40 31247564720 mfid0 GPT (15T) >
Re: Strange ARC/Swap/CPU on yesterday's -CURRENT
On Tue, 6 Mar 2018 08:40-0800, Rodney W. Grimes wrote: > > On Mon, 5 Mar 2018 14:39-0600, Larry Rosenman wrote: > > > > > Upgraded to: > > > > > > FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r330385: > > > Sun Mar 4 12:48:52 CST 2018 > > > r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER amd64 > > > +1200060 1200060 > > > > > > Yesterday, and I'm seeing really strange slowness, ARC use, and SWAP use > > > and swapping. > > > > > > See http://www.lerctr.org/~ler/FreeBSD/Swapuse.png > > > > I see these symptoms on stable/11. One of my servers has 32 GiB of > > RAM. After a reboot all is well. ARC starts to fill up, and I still > > have more than half of the memory available for user processes. > > > > After running the periodic jobs at night, the amount of wired memory > > goes sky high. /etc/periodic/weekly/310.locate is a particular nasty > > one. > > I would like to find out if this is the same person I have > reporting this problem from another source, or if this is > a confirmation of a bug I was helping someone else with. > > Have you been in contact with Michael Dexter about this > issue, or any other forum/mailing list/etc? No, it wasn't me. > If not then we have at least 2 reports of this unbound > wired memory growth, if so hopefully someone here can > take you further in the debug than we have been able > to get. > > > Limiting the ARC to, say, 16 GiB, has no effect of the high amount of > > wired memory. After a few more days, the kernel consumes virtually all > > memory, forcing processes in and out of the swap device. > > Our experience as well. -- Trond. ___ 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: Strange ARC/Swap/CPU on yesterday's -CURRENT
On Mon, 5 Mar 2018 14:39-0600, Larry Rosenman wrote: > Upgraded to: > > FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r330385: Sun > Mar 4 12:48:52 CST 2018 > r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER amd64 > +1200060 1200060 > > Yesterday, and I'm seeing really strange slowness, ARC use, and SWAP use and > swapping. > > See http://www.lerctr.org/~ler/FreeBSD/Swapuse.png I see these symptoms on stable/11. One of my servers has 32 GiB of RAM. After a reboot all is well. ARC starts to fill up, and I still have more than half of the memory available for user processes. After running the periodic jobs at night, the amount of wired memory goes sky high. /etc/periodic/weekly/310.locate is a particular nasty one. Limiting the ARC to, say, 16 GiB, has no effect of the high amount of wired memory. After a few more days, the kernel consumes virtually all memory, forcing processes in and out of the swap device. stable/10 never exhibited these symptoms, even with ZFS. I had hoped the kernel would manage its memory usage more wisely, but maybe it's time to set some hard limits on the kernel. Last year, I experienced deadlocks on stable/11 systems running ZFS with only 1 GiB of RAM. periodic(8) and clang jobs would never be rescheduled, they just sat there doing nothing halfway through their mission and with most of their pages on the swap device. I was lucky enough to be able to log in and reboot the damned servers. I installed 8 GiB of memory in each server and I never saw any deadlocks since. Maybe we should try and help by run (virtual) machines with low amounts of memory and high loads to weed out these bugs, if they still persist. -- Trond. ___ 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: pkg does not recognize correct kernel version
On Wed, 21 Feb 2018 20:01+0100, Ronald Klop wrote: > On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl > wrote: > > > On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote: > > > > > Does this mean I always have to do a *clean* buildworld after every > > > version > > > bump? This takes ages. > > > > Yes, I've come to the conclusion that whenever __FreeBSD_version in > > sys/sys/param.h is incremented, then it's time to blow away /usr/obj, > > recreate everything to ensure the correct value of osversion in the > > .note.tag section of each executable, and reinstall base prior to > > updating localbase. See PR 225104 for more details, > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104. > > > > pkg: Newer FreeBSD version for package gnome-menus: > - package: 1200058 > - running kernel: 1200056 > > So it says "running kernel", but it actually checked "version of > FreeBSD_version while building /bin/sh" or something like that. > This sounds over-engineered and (more important) confusing. I tried the simply approach of running "make clean; make build" in /usr/src/bin/sh, hoping it would generate binaries with the correct osversion in the .note.tag section. Boy, I couldn't be more wrong. Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever osversion is increased. I'm probably missing a simpler step. -- Trond. ___ 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: pkg does not recognize correct kernel version
On Wed, 21 Feb 2018 20:49+0100, Andreas Nilsson wrote: > As of pkg-1.10.5 it will ask if you wish to proceed which makes this much > easier to deal with. That's an huge improvement. sys/sys/param.h and base are in agreement on the systems I manage, so I won't see the improvement in action for some time. -- Trond. ___ 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: pkg does not recognize correct kernel version
On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote: > Does this mean I always have to do a *clean* buildworld after every version > bump? This takes ages. Yes, I've come to the conclusion that whenever __FreeBSD_version in sys/sys/param.h is incremented, then it's time to blow away /usr/obj, recreate everything to ensure the correct value of osversion in the .note.tag section of each executable, and reinstall base prior to updating localbase. See PR 225104 for more details, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104. -- Trond. ___ 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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork
On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > > > Note: -r329448 was reverted in -r329461 : racy. > > > > True. I got a crash when compiling r329451 while running r329449. > > I've now booted the r329422 ZFS BE and I'm attempting to build > > r329529. > > > > Looking around strongly suggests r329448 is the culprit. If you can verify > 329447 works fine we are mostly done here. I noticed no errors in r329447. When r329529 is built and installed, I'll try to incrementally build and install r329531. > Note the revision got reverted and different variant got in in r329531. > > That said, if r329447 works then the issue should be already fixed and in > particular fresh head should work fine. -- Trond. ___ 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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork
On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > Note: -r329448 was reverted in -r329461 : racy. True. I got a crash when compiling r329451 while running r329449. I've now booted the r329422 ZFS BE and I'm attempting to build r329529. -- Trond. ___ 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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork
On Sun, 18 Feb 2018 19:08+0100, Mateusz Guzik wrote: > Can you please bisect this? There is another report stating that r329418 > works fine. My problems started yesterday with r329464. I decided to go back to r329101 (ZFS BE), update the source tree, move forward to the latest revision, and so on. I even emptied /usr/obj and /var/cache/ccache and set WITHOUT_SYSTEM_COMPILER=yes in /etc/src.conf to get rid of any bias. I have tried with success r329418, r329419, r329420, and r329422. I'm now at r329448 and have not seen any spin lock problems so far. Sooner or later I'll reach r329464 and by then it should be clear which revision is the likely culprit. -- Trond. ___ 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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork
On Sat, 17 Feb 2018 17:39-0800, Mark Millard wrote:
> This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine.
> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files.
> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen
> Threadripper 1950X). No other Hyper-V use.
>
> This happened during:
>
> #
> ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh
> check-old DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils
> Script started, output file is
> /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-2018-02-17:15:56:20
> >>> Checking for old files
>
>
> (Hand typed from a picture of a window's content
> at slighly different times, expect typos:)
>
> KDB: enter: panic
> [thread pid 42170 tid 100752 ]
> Stopped at kdb_enter+0x3b: movq $0,kdb_why
> db> call doadump
> Dumping 4825 out of 110559 MB: ... (omitted) ...
> Dump complete
> = 0
>
>
> (The "pid 42170" identification as the process reporting the
> issue does not seem to appear in the core.txt.0 file.)
>
>
> # ls -lTdt /var/crash/*
> -rw-r--r-- 1 root wheel 100792 Feb 17 16:09:18 2018
> /var/crash/core.txt.0
> lrwxr-xr-x 1 root wheel 8 Feb 17 16:09:08 2018
> /var/crash/vmcore.last -> vmcore.0
> lrwxr-xr-x 1 root wheel 6 Feb 17 16:09:08 2018
> /var/crash/info.last -> info.0
> -rw--- 1 root wheel 5060296704 Feb 17 16:09:08 2018 /var/crash/vmcore.0
> -rw--- 1 root wheel 392 Feb 17 16:08:59 2018 /var/crash/info.0
> -rw-r--r-- 1 root wheel 2 Feb 17 16:08:59 2018 /var/crash/bounds
> -rw-r--r-- 1 root wheel 5 Nov 22 04:34:36 2017 /var/crash/minfree
>
> >From /var/crash/core.txt.0 :
>
> Unread portion of the kernel message buffer:
> spin lock 0x81b2dcc0 (sched lock 5) held by 0xf8011d936560 (tid
> 100691) too long
> panic: spin lock held too long
> cpuid = 5
> time = 1518911834
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00f10094d0
> vpanic() at vpanic+0x18d/frame 0xfe00f1009530
> panic() at panic+0x43/frame 0xfe00f1009590
> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame
> 0xfe00f10095a0
> thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfe00f1009610
> statclock_cnt() at statclock_cnt+0xdc/frame 0xfe00f1009650
> handleevents() at handleevents+0x113/frame 0xfe00f10096a0
> timercb() at timercb+0xa9/frame 0xfe00f10096f0
> lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfe00f1009730
> timerint_u() at timerint_u+0x96/frame 0xfe00f1009810
> thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfe00f1009880
> fork1() at fork1+0x1b9f/frame 0xfe00f1009930
> sys_vfork() at sys_vfork+0x4c/frame 0xfe00f1009980
> amd64_syscall() at amd64_syscall+0xa48/frame 0xfe00f1009ab0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffcfc0
> KDB: enter: panic
>
> __curthread () at ./machine/pcpu.h:230
> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) #0 __curthread () at ./machine/pcpu.h:230
> #1 doadump (textdump=-2122191464) at /usr/src/sys/kern/kern_shutdown.c:347
> #2 0x8040b42c in db_fncall_generic (addr=,
>rv=, nargs=, args=)
>at /usr/src/sys/ddb/db_command.c:609
> #3 db_fncall (dummy1=, dummy2=,
>dummy3=, dummy4=)
>at /usr/src/sys/ddb/db_command.c:657
> #4 0x8040af79 in db_command (last_cmdp=,
>cmd_table=, dopager=)
>at /usr/src/sys/ddb/db_command.c:481
> #5 0x8040acf4 in db_command_loop ()
>at /usr/src/sys/ddb/db_command.c:534
> #6 0x8040df9f in db_trap (type=, code=)
>at /usr/src/sys/ddb/db_main.c:250
> #7 0x80b370e3 in kdb_trap (type=3, code=-61456, tf=)
>at /usr/src/sys/kern/subr_kdb.c:697
> #8 0x80fa2c5c in trap (frame=0xfe00f1009400)
>at /usr/src/sys/amd64/amd64/trap.c:547
> #9
> #10 kdb_enter (why=0x811f280b "panic", msg=)
>at /usr/src/sys/kern/subr_kdb.c:479
> #11 0x80aef17a in vpanic (fmt=, ap=0xfe00f1009570)
>at /usr/src/sys/kern/kern_shutdown.c:801
> #12 0x80aeefc3 in panic (fmt=0x0)
>at /usr/src/sys/kern/kern_shutdown.c:739
> #13 0x80acfa31 in _mtx_lock_indefinite_check (m=,
>ldap=) at /usr/src/sys/kern/kern_mutex.c:1224
> #14 0x80acfb9b in thread_lock_flags_ (td=0xf818719d1000,
>opts=, file=, line=)
>at /usr/src/sys/kern/kern_mutex.c:913
> #15 0x80a89d6c in statclock_cnt (cnt=1, usermode=)
>at /usr/src/sys/kern/kern_clock.c:768
> #16 0x810d0003 in handleevents (now=43230207690178, fake=0)
>at /usr/src/sys/kern/kern_clocksource.c:196
> #17 0x810d0709 in timercb (et=0x81c528e8 ,
>arg=) at /usr/src/sys/kern/kern_clocksource.c:353
> #18 0x8110dad7 in lapic_handle_timer (frame=0xfe00f1009740)
>at /usr/src/sys/x86/x86/local_apic.c
Re: r324353: boot failure: failed with error 19
On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote: > I run a small appliance on an APU from PCengines. This box is bootet via SD > card, the > image is created by a modified NanoBSD, which creates GPT/UEFI partitioning > and booting > images. > > That worked until two days ago (I do not track the revision numer) when I > wrote (via dd) > the last image out. Today, I tried to boot r324353 and it fails at tthe boot > loader: > > > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > > I can proceed by manually issuing at the loader propmpt > > ufs:/dev/gpt/dsks1a > > and booting proceeds as expected. > > > Something seems wrong with the UFS labeling lately. > > The gpt layout looks like this: > > gpart show -l: > > => 40 60751792 mmcsd0 GPT (29G) > 40 130 1 boot (65K) >170 6 - free - (3.0K) >176 2057288 2 dsks1a [bootme] (1.0G) >2057464 2061725 3 dsks2a (1.0G) >4119189 1048576 4 dsks3 (512M) >5167765 55584067 - free - (27G) For one, these are the GPT labels. Can you verify the UFS labels (volnames)? Try: dumpfs /dev/gpt/dsks1a > From dmesg. I can provide this last output: > > [...] > mmcsd0: 31GB at mmc0 > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a [ro]... > uhub0: 4 ports with 4 removable, self powered > Root mount waiting for: usbus1 > uhub1: 2 ports with 2 removable, self powered > Root mount waiting for: usbus1 > ugen1.2: at usbus1 > uhub2 on uhub1 > uhub2: on > usbus1 > uhub2: 4 ports with 4 removable, self powered > mountroot: waiting for device /dev/ufs/dsks1a... > Mounting from ufs:/dev/ufs/dsks1a failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/ufs/dsks1a > vfs.root.mountfrom.options=ro > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs > []... > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs... > random: unblocking device. > arc4random: no preloaded entropy cache > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19. This surely indicates a mangled UFS volname. Maybe you should rewrite the volname: tunefs -L dsk1a /dev/gpt/dsks1a Or is the volname misspelled? tunefs -L dsks1a /dev/gpt/dsks1a Or is /etc/fstab on the SD card corrupted? > mountroot> Invalid file system specification. > > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... > arc4random: no preloaded entropy cache > GEOM_ELI: Device gpt/swap.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: hardware > Link state changed to up > > [...] > > > Can someone look into this? > > Kind regards, > > Oliver -- Trond. ___ 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: [tzsetup] can't set up local timezone if CMOS is set to UTC
On Mon, 7 Aug 2017 09:51+0300, Boris Samorodov wrote: > So my question is: how to set up local time zone if CMOS is set to UTC? My timezone is Europe/Oslo, adjust to fit your timezone: rm -f /etc/wall_cmos_clock cp -p /usr/share/zoneinfo/Europe/Oslo /etc/localtime echo Europe/Oslo > /var/db/zoneinfo -- Trond. ___ 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: ipfw_netflow in base/head r320944 & r321008
On Sun, 16 Jul 2017 10:43+0200, Trond Endrestøl wrote: > At boot time /etc/rc display this message: > > /etc/rc: WARNING: $ipfw_netflow_enable is not set properly - see rc.conf(5). > > This was introduced in r320944 and corrected to some extent in > r321008. > > Nevertheless, a default value for ipfw_netflow_enable should be > provided: > > Index: etc/defaults/rc.conf > === > --- etc/defaults/rc.conf (revision 321041) > +++ etc/defaults/rc.conf (working copy) > @@ -195,6 +195,7 @@ > # of state tables at shutdown and boot > ipfs_program="/sbin/ipfs"# where the ipfs program lives > ipfs_flags=""# additional flags for ipfs > +ipfw_netflow_enable="NO" # Set yo YES to enable ipfw netflow. Typo fixed: +ipfw_netflow_enable="NO" # Set to YES to enable ipfw netflow. > pf_enable="NO" # Set to YES to enable packet filter > (pf) > pf_rules="/etc/pf.conf" # rules definition file for pf > pf_program="/sbin/pfctl" # where the pfctl program lives -- +---+----+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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"
ipfw_netflow in base/head r320944 & r321008
At boot time /etc/rc display this message: /etc/rc: WARNING: $ipfw_netflow_enable is not set properly - see rc.conf(5). This was introduced in r320944 and corrected to some extent in r321008. Nevertheless, a default value for ipfw_netflow_enable should be provided: Index: etc/defaults/rc.conf === --- etc/defaults/rc.conf(revision 321041) +++ etc/defaults/rc.conf(working copy) @@ -195,6 +195,7 @@ # of state tables at shutdown and boot ipfs_program="/sbin/ipfs" # where the ipfs program lives ipfs_flags="" # additional flags for ipfs +ipfw_netflow_enable="NO" # Set yo YES to enable ipfw netflow. pf_enable="NO" # Set to YES to enable packet filter (pf) pf_rules="/etc/pf.conf"# rules definition file for pf pf_program="/sbin/pfctl" # where the pfctl program lives -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: Current amd64 new error or warning from today's current with ruby r320323
On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > > > This patch made ruby23 happy on my end. Can't say the same for > > > emacs-nox11 or temacs while building the former. > > > > What exactly do you mean ? Explain the behaviour and show the ktrace log. > > It builds now. > > I'm running unpatched r320406, and I'll attempt building and running > r320420 with your patch from yesterday. > > I too suffer from /sbin/zfs' inability to run in singleuser mode, yet > somehow it does its job while in multiuser mode. That patch enables /sbin/zfs to run in singleuser mode. Next, there seems to be a race condition while running installworld in parallel, but that's a story for another time. -- Trond. ___ 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: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > This patch made ruby23 happy on my end. Can't say the same for > > emacs-nox11 or temacs while building the former. > > What exactly do you mean ? Explain the behaviour and show the ktrace log. It builds now. I'm running unpatched r320406, and I'll attempt building and running r320420 with your patch from yesterday. I too suffer from /sbin/zfs's inability to run in singleuser mode, yet somehow it does its job while in multiuser mode. -- Trond. ___ 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: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory
Try running make installworld without -j N. Serial installworld was successful at my end. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, 26 Jun 2017 12:22+0100, Steven Hartland wrote: > Is this related to kib's additional fix over the weekend? > > https://svnweb.freebsd.org/changeset/base/320344 Attempting to run r320348 with no patches applied proved unfruitful earlier today. I had partial success the weekend building r320328 with the vm2.2.patch applied while running r320293. https://people.freebsd.org/~kib/misc/vm2.2.patch You might want to stay at pre-r320316 until the matter is resolved. > Regards > Steve > > On 26/06/2017 09:29, O. Hartmann wrote: > > Over the past week we did not update several 12-CURRENT running development > > hosts, so today is the first day of performing this task. > > > > First I hit the very same problem David Wolfskill reported earlier, a fatal > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > recompiling world and kernel. > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > > INO64 update hasn't performed so far starting from r319971, I installed the > > kernel, rebooted the box in single user mode (this time smoothly), did a > > mergemaster and tried to do "make installworld" - but the box instantanously > > bails out: > > > > [...] > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > file /usr/src/lib/libthread/thr_init.c > > pid 60 (cc) uid0: exited on signal 6 ... > > > > [...] > > > > That way, I obviously can not install a world :-( > > > > What is wrong here? Is the problem resovable? > > > > Kind regards, > > > > Oliver -- Trond. ___ 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: Has gdb been disconnected from make installworld?
On Sun, 25 Jun 2017 14:07-0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 09:03:58PM +0200, Trond Endrestøl wrote: > > > Ah, they wound up in /usr/libexec. Still, that's an odd place for user > > software. > > --- > r317416 | jhb | 2017-04-25 13:08:56 -0500 (Tue, 25 Apr 2017) | 16 lines > > Add a new GDB_LIBEXEC option to install gdb and kgdb to /usr/libexec. > > When this option is enabled, only gdb and kgdb are installed to > /usr/libexec for use by crashinfo(8). Other bits of GDB such as > gdbserver and gdbtui are not installed. For this option to be > effective, GDB must be enabled. > > Rework r317094 to re-enable GDB on all platforms but enable > GDB_LIBEXEC on platforms for which the GDB in ports is a superset of > functionality. > > Reviewed by:emaste, kib > Suggested by: kib > Relnotes: yes > Differential Revision: https://reviews.freebsd.org/D10449 > --- > > > Note specifically that the GDB in ports is a substantial improvement in > functionality on amd64. > > -Ben Good to know. Thanks. -- +---+--------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: Has gdb been disconnected from make installworld?
On Sun, 25 Jun 2017 20:55+0200, Trond Endrestøl wrote: > I was at bit surprised to see gdb missing from /usr/bin this evening. > The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb. > > This is on base/head r320329. > > Do we need to add WITH_GDB=yes to our src.conf files? Ah, they wound up in /usr/libexec. Still, that's an odd place for user software. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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"
Has gdb been disconnected from make installworld?
I was at bit surprised to see gdb missing from /usr/bin this evening. The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb. This is on base/head r320329. Do we need to add WITH_GDB=yes to our src.conf files? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 19:41+0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > > > > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov > > > wrote: > > > > > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: > > >> maybe message got reformatted in mail program (mac mail). > > >> could you send me a tar file of the patch? > > >> also not sure if ???patch -p1 > >> patch > > >> > > >> you could cc r...@pozo.com <mailto:r...@pozo.com> , that way i have copy > > >> on freebsd box and on mac. > > > > > > https://people.freebsd.org/~kib/misc/vm2.1.patch > > > <https://people.freebsd.org/~kib/misc/vm2.1.patch> > > > > OK patched and built new kernel \ > > rebooted, > > same ruby message. So it must be a ruby thing. > > new kdump.txt at http://www.pozo.com/kernel/kdump.txt > > <http://www.pozo.com/kernel/kdump.txt> > > > > also i???ll put a copy of my kernel config in same directory: > > > > http://www.pozo.com/kernel/pozo <http://www.pozo.com/kernel/pozo> > > > > only one module is being loaded at boot: > > (kernel)4908}kldstat > > Id Refs AddressSize Name > > 15 0x8020 10380a8 kernel > > 21 0x8123a000 e13f50 nvidia.ko > > > > I can disable nvidia if it helps as I really only access this machine over > > the net or serial console. > > > No need, I understood why MAP_STACK failed in this case, thanks to the > ktrace log. This is indeed something ruby-specific, or rather, triggered > by ruby special use of libthr. It is not related to the main stack > split. > > It seems that ruby requested very small stack for a new thread, only 5 > pages in size. This size caused the stack gap to be correctly calculated > as having zero size, because the whole stack is allocated by initial grow. > But then there is no space for the guard page, which caused mapping failure > for it, and overall stack mapping failure. > > Try this. > https://people.freebsd.org/~kib/misc/vm2.2.patch This patch made ruby23 happy on my end. Can't say the same for emacs-nox11 or temacs while building the former. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 18:08+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote: > > > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote: > > > > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > > > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov > > > > > > wrote: > > > > > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > > > >> > > > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov > > > > > >>> wrote: > > > > > >>> > > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > > > >>>> New world and kernel r320323 > > > > > >>>> I get a new error or message when using ruby: > > > > > >>>> > > > > > >>>> > > > > > >>>> /usr/local/sbin/portupgrade -av > > > > > >>>> : warning: pthread_create failed for timer: Resource > > > > > >>>> temporarily unavailable, scheduling broken > > > > > >>>> > > > > > >>>> everything works just this message when using ruby. I recompiled > > > > > >>>> ruby , still same message > > > > > >>>> > > > > > >>>> /usr/local/bin/ruby -v > > > > > >>>> : warning: pthread_create failed for timer: Resource > > > > > >>>> temporarily unavailable, scheduling broken > > > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > > >>>> > > > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, > > > > > >>>> maybe thats it. > > > > > >>> > > > > > >>> ktrace your failing ruby invocation, then post output of kdump -H > > > > > >>> somewhere. > > > > > >>> > > > > > >> > > > > > >> Ok not sure if this is right , but this is what i did: > > > > > >> > > > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > > > >> : warning: pthread_create failed for timer: Resource > > > > > >> temporarily unavailable, scheduling broken > > > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > > >> > > > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > > > >> > > > > > >> you can get kdump.txt at: > > > > > >> > > > > > >> http://www.pozo.com/kernel/kdump > > > > > >> <http://www.pozo.com/kernel/kdump>.txt > > > > > >> > > > > > >> It???s not failing, I don???t think , I can do portupgrade and it > > > > > >> works fine. > > > > > >> I just get this new message > > > > > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set > > > > > > in > > > > > > your environment ? > > > > > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility > > > > > > with the > > > > > > old (pre-11) libthr, which tries to split main thread stack into > > > > > > smaller > > > > > > stacks for the new threads. New stack grow code was specifically > > > > > > designed > > > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > > > the main stack gap. > > > > > > > > > > > > > > > > Not running any jails > > > > > all libraries are current as of today > > > > > locate libthr. |xargs ls -l > > > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > > > -r--r--r-- 1
Re: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote: > > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov > > > > > wrote: > > > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > > >> > > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov > > > > >>> wrote: > > > > >>> > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > > >>>> New world and kernel r320323 > > > > >>>> I get a new error or message when using ruby: > > > > >>>> > > > > >>>> > > > > >>>> /usr/local/sbin/portupgrade -av > > > > >>>> : warning: pthread_create failed for timer: Resource > > > > >>>> temporarily unavailable, scheduling broken > > > > >>>> > > > > >>>> everything works just this message when using ruby. I recompiled > > > > >>>> ruby , still same message > > > > >>>> > > > > >>>> /usr/local/bin/ruby -v > > > > >>>> : warning: pthread_create failed for timer: Resource > > > > >>>> temporarily unavailable, scheduling broken > > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > >>>> > > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, > > > > >>>> maybe thats it. > > > > >>> > > > > >>> ktrace your failing ruby invocation, then post output of kdump -H > > > > >>> somewhere. > > > > >>> > > > > >> > > > > >> Ok not sure if this is right , but this is what i did: > > > > >> > > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > > >> : warning: pthread_create failed for timer: Resource > > > > >> temporarily unavailable, scheduling broken > > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > >> > > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > > >> > > > > >> you can get kdump.txt at: > > > > >> > > > > >> http://www.pozo.com/kernel/kdump > > > > >> <http://www.pozo.com/kernel/kdump>.txt > > > > >> > > > > >> It???s not failing, I don???t think , I can do portupgrade and it > > > > >> works fine. > > > > >> I just get this new message > > > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > > > > your environment ? > > > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility with > > > > > the > > > > > old (pre-11) libthr, which tries to split main thread stack into > > > > > smaller > > > > > stacks for the new threads. New stack grow code was specifically > > > > > designed > > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > > the main stack gap. > > > > > > > > > > > > > Not running any jails > > > > all libraries are current as of today > > > > locate libthr. |xargs ls -l > > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > > > > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> > > > > ../../lib/libthr.so.3 > > > > > > > > ldd /usr/local/bin/ruby > > > > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 > > > > /usr/local/lib/libruby23.so.2 > > > > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 > > > > /usr/local/lib/libun
Re: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov > > > > wrote: > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > >> > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov > > > >>> wrote: > > > >>> > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > >>>> New world and kernel r320323 > > > >>>> I get a new error or message when using ruby: > > > >>>> > > > >>>> > > > >>>> /usr/local/sbin/portupgrade -av > > > >>>> : warning: pthread_create failed for timer: Resource > > > >>>> temporarily unavailable, scheduling broken > > > >>>> > > > >>>> everything works just this message when using ruby. I recompiled > > > >>>> ruby , still same message > > > >>>> > > > >>>> /usr/local/bin/ruby -v > > > >>>> : warning: pthread_create failed for timer: Resource > > > >>>> temporarily unavailable, scheduling broken > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > >>>> > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, maybe > > > >>>> thats it. > > > >>> > > > >>> ktrace your failing ruby invocation, then post output of kdump -H > > > >>> somewhere. > > > >>> > > > >> > > > >> Ok not sure if this is right , but this is what i did: > > > >> > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > >> : warning: pthread_create failed for timer: Resource temporarily > > > >> unavailable, scheduling broken > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > >> > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > >> > > > >> you can get kdump.txt at: > > > >> > > > >> http://www.pozo.com/kernel/kdump <http://www.pozo.com/kernel/kdump>.txt > > > >> > > > >> It???s not failing, I don???t think , I can do portupgrade and it > > > >> works fine. > > > >> I just get this new message > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > > > your environment ? > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility with > > > > the > > > > old (pre-11) libthr, which tries to split main thread stack into smaller > > > > stacks for the new threads. New stack grow code was specifically > > > > designed > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > the main stack gap. > > > > > > > > > > Not running any jails > > > all libraries are current as of today > > > locate libthr. |xargs ls -l > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > > > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> > > > ../../lib/libthr.so.3 > > > > > > ldd /usr/local/bin/ruby > > > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 > > > /usr/local/lib/libruby23.so.2 > > > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 > > > /usr/local/lib/libunwind.so.8.0.1 > > > > > > /usr/local/bin/ruby: > > > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0) > > > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000) > > > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000) > > > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000) > > > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000) > > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000) >
Re: Current amd64 new error or warning from today's current with ruby r320323
; }
>
> /*
> @@ -2003,6 +2024,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start,
> vm_offset_t end,
>*/
> for (current = entry; current != &map->header && current->start < end;
> current = current->next) {
> + if ((current->eflags & MAP_ENTRY_GUARD) != 0)
> + continue;
> if (current->eflags & MAP_ENTRY_IS_SUB_MAP) {
> vm_map_unlock(map);
> return (KERN_INVALID_ARGUMENT);
> @@ -2011,6 +2034,11 @@ vm_map_protect(vm_map_t map, vm_offset_t start,
> vm_offset_t end,
> vm_map_unlock(map);
> return (KERN_PROTECTION_FAILURE);
> }
> + if (current->end < end && (current->next == &map->header ||
> + current->next->start > current->end)) {
> + vm_map_unlock(map);
> + return (KERN_INVALID_ADDRESS);
> + }
> }
>
> /*
> @@ -2712,9 +2740,9 @@ vm_map_wire(vm_map_t map, vm_offset_t start,
> vm_offset_t end,
>* If VM_MAP_WIRE_HOLESOK was specified, skip this check.
>*/
> next_entry:
> - if (((flags & VM_MAP_WIRE_HOLESOK) == 0) &&
> - (entry->end < end && (entry->next == &map->header ||
> - entry->next->start > entry->end))) {
> + if ((flags & VM_MAP_WIRE_HOLESOK) == 0 &&
> + entry->end < end && (entry->next == &map->header ||
> + entry->next->start > entry->end)) {
> end = entry->end;
> rv = KERN_INVALID_ADDRESS;
> goto done;
> diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
> index 4d8f6ad9ed7..09912250d52 100644
> --- a/sys/vm/vm_mmap.c
> +++ b/sys/vm/vm_mmap.c
> @@ -607,6 +607,7 @@ kern_mprotect(struct thread *td, uintptr_t addr0, size_t
> size, int prot)
> case KERN_PROTECTION_FAILURE:
> return (EACCES);
> case KERN_RESOURCE_SHORTAGE:
> + case KERN_INVALID_ADDRESS:
> return (ENOMEM);
> }
> return (EINVAL);
I'm seeing similar fallout on r320327, built from scratch while
running r320293:
Script started on Sun Jun 25 17:03:41 2017
# uname -aKU
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320327: Sun Jun 25 16:35:02 CEST
2017 r...@freebsd-head-uefi-zfs.bsd.net:/usr/obj/usr/src/sys/VBOX amd64
1200035 1200035
# /sbin/zfs mount -va
Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file
/usr/src/lib/libthr/thread/thr_init.c (errno = 12)
Abort trap (core dumped)
# ls -l /lib/libthr*
-r--r--r-- 1 root wheel 153336 Jun 25 16:39 /lib/libthr.so.3
# ls -l /usr/lib/libthr*
-r--r--r-- 1 root wheel 256064 May 28 21:41 /usr/lib/libthr.a
lrwxr-xr-x 1 root wheel 21 Jun 25 16:39 /usr/lib/libthr.so ->
../../lib/libthr.so.3
-r--r--r-- 1 root wheel 270362 May 28 21:41 /usr/lib/libthr_p.a
-r--r--r-- 1 root wheel 45376 Apr 22 10:39 /usr/lib/libthread_db.a
lrwxr-xr-x 1 root wheel 17 Jun 25 16:39 /usr/lib/libthread_db.so ->
libthread_db.so.3
-r--r--r-- 1 root wheel 38776 Jun 25 16:39 /usr/lib/libthread_db.so.3
-r--r--r-- 1 root wheel 49496 Apr 22 10:39 /usr/lib/libthread_db_p.a
# ldd /sbin/zfs
/sbin/zfs:
libjail.so.1 => /lib/libjail.so.1 (0x800247000)
libnvpair.so.2 => /lib/libnvpair.so.2 (0x80024f000)
libuutil.so.2 => /lib/libuutil.so.2 (0x800269000)
libzfs_core.so.2 => /lib/libzfs_core.so.2 (0x800276000)
libzfs.so.3 => /lib/libzfs.so.3 (0x800281000)
libc.so.7 => /lib/libc.so.7 (0x8002cd000)
libmd.so.6 => /lib/libmd.so.6 (0x8006d1000)
libumem.so.2 => /lib/libumem.so.2 (0x8006eb000)
libutil.so.9 => /lib/libutil.so.9 (0x8006f)
libm.so.5 => /lib/libm.so.5 (0x800706000)
libavl.so.2 => /lib/libavl.so.2 (0x800736000)
libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x80073a000)
libgeom.so.5 => /lib/libgeom.so.5 (0x80077)
libz.so.6 => /lib/libz.so.6 (0x800779000)
libthr.so.3 => /lib/libthr.so.3 (0x800793000)
libsbuf.so.6 => /lib/libsbuf.so.6 (0x8007bd000)
# ls -l /sbin/zfs
-r-xr-xr-x 1 root wheel 124296 Jun 25 16:39 /sbin/zfs
# exit
Script done on Sun Jun 25 17:04:32 2017
Although not relevant for this case, neither /usr/lib/libthr.a, nor
/usr/lib/libthr_p.a, nor /usr/lib/libthread_db.a, nor
/usr/lib/libthread_db_p.a has been updated by installworld, nor
removed by delete-old-libs, in a very long time.
Anything else I can contribute? I'll try your patch and see if I can
get any further.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
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: Crash in base/head in abd_put() after r320156
On Wed, 21 Jun 2017 11:18+0300, Andriy Gapon wrote: > On 21/06/2017 00:45, Trond Endrestøl wrote: > > On Tue, 20 Jun 2017 17:31-0400, Allan Jude wrote: > > > >> On 2017-06-20 17:27, Trond Endrestøl wrote: > >>> Has anyone else seen a crash in base/head in abd_put() after r320156? > >>> > >>> One of my experimental VMs at home crashed spectacularly after > >>> upgrading to r320156. I even wiped my /usr/obj, recompiled everything > >>> and got the same result. Everything's back to normal when I boot > >>> r320146. > >>> > >>> Here's the backtrace: > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> cpuid = 3; apic id = 03 > >>> > >>> fault virtual address = 0x8 > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> > >>> cpuid = 2; > >>> Fatal trap 12: page fault while in kernel mode > >>> apic id = 02 > >>> fault virtual address = 0x8 > >>> cpuid = 0; apic id = 00 > >>> fault virtual address = 0x8 > >>> fault code= supervisor read data, page not present > >>> fault code= supervisor read data, page not present > >>> instruction pointer = 0x20:0x803260fa > >>> stack pointer = 0x28:0xfe01b0231860 > >>> frame pointer = 0x28:0xfe01b0231870 > >>> code segment = base 0x0, limit 0xf, type 0x1b > >>> > >>> = DPL 0, pres 1, long 1, def32 0, gran 1 > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> fault code= supervisor read data, page not present > >>> processor eflags = interrupt enabled, resume, IOPL = 0 > >>> current process = 0 (zio_free_issue_5_2) > >>> trap number = 12 > >>> instruction pointer = 0x20:0x803260fa > >>> stack pointer = 0x28:0xfe01b022c860 > >>> frame pointer = 0x28:0xfe01b022c870 > >>> panic: page fault > >>> cpuid = 0 > >>> time = 4 > >>> KDB: stack backtrace: > >>> db_trace_self_wrapper() at 0x8044f93b = > >>> db_trace_self_wrapper+0x2b/frame 0xfe01b0231440 > >>> vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0 > >>> panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520 > >>> trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame > >>> 0xfe01b0231570 > >>> trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame > >>> 0xfe01b02315d0 > >>> trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790 > >>> calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790 > >>> --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = > >>> 0xfe01b0231870 --- > >>> abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870 > >>> vdev_raidz_map_free() at 0x803aa7c2 = > >>> vdev_raidz_map_free+0x82/frame 0xfe01b02318a0 > >>> zio_vdev_io_assess() at 0x803ecc04 = > >>> zio_vdev_io_assess+0x74/frame 0xfe01b02318e0 > >>> zio_execute() at 0x803e913c = zio_execute+0xac/frame > >>> 0xfe01b0231930 > >>> zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame > >>> 0xfe01b0231990 > >>> zio_execute() at 0x803e913c = zio_execute+0xac/frame > >>> 0xfe01b02319e0 > >>> zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame > >>> 0xfe01b0231a20 > >>> vdev_mirror_io_start() at 0x803a744c = > >>> vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70 > >>> zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame > >>> 0xfe01b0231ad0 > >>> zio_execute() at 0x803e913c = zio_execute+0xac/frame > >>> 0xfe01b0231b20 > >>> taskqueue_run_locked() at 0x806d3d27 = > >>> taskqueue_run_locked+0x127/frame 0xfe01b0231b80 > >>> taskqueue_thread_loop() at 0x806d4ee8 = > >>> taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0 > >>> fork_exit() at 0x80640df5 = fork_exit+0x85/frame > >>> 0xfe01b0231bf0 > >>>
Re: Crash in base/head in abd_put() after r320156
On Tue, 20 Jun 2017 17:31-0400, Allan Jude wrote: > On 2017-06-20 17:27, Trond Endrestøl wrote: > > Has anyone else seen a crash in base/head in abd_put() after r320156? > > > > One of my experimental VMs at home crashed spectacularly after > > upgrading to r320156. I even wiped my /usr/obj, recompiled everything > > and got the same result. Everything's back to normal when I boot > > r320146. > > > > Here's the backtrace: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 3; apic id = 03 > > > > fault virtual address = 0x8 > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 2; > > Fatal trap 12: page fault while in kernel mode > > apic id = 02 > > fault virtual address = 0x8 > > cpuid = 0; apic id = 00 > > fault virtual address = 0x8 > > fault code = supervisor read data, page not present > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x803260fa > > stack pointer = 0x28:0xfe01b0231860 > > frame pointer = 0x28:0xfe01b0231870 > > code segment= base 0x0, limit 0xf, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > Fatal trap 12: page fault while in kernel mode > > fault code = supervisor read data, page not present > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process = 0 (zio_free_issue_5_2) > > trap number = 12 > > instruction pointer = 0x20:0x803260fa > > stack pointer = 0x28:0xfe01b022c860 > > frame pointer = 0x28:0xfe01b022c870 > > panic: page fault > > cpuid = 0 > > time = 4 > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0x8044f93b = > > db_trace_self_wrapper+0x2b/frame 0xfe01b0231440 > > vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0 > > panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520 > > trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame > > 0xfe01b0231570 > > trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame > > 0xfe01b02315d0 > > trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790 > > calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790 > > --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = > > 0xfe01b0231870 --- > > abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870 > > vdev_raidz_map_free() at 0x803aa7c2 = > > vdev_raidz_map_free+0x82/frame 0xfe01b02318a0 > > zio_vdev_io_assess() at 0x803ecc04 = zio_vdev_io_assess+0x74/frame > > 0xfe01b02318e0 > > zio_execute() at 0x803e913c = zio_execute+0xac/frame > > 0xfe01b0231930 > > zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame > > 0xfe01b0231990 > > zio_execute() at 0x803e913c = zio_execute+0xac/frame > > 0xfe01b02319e0 > > zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame > > 0xfe01b0231a20 > > vdev_mirror_io_start() at 0x803a744c = > > vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70 > > zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame > > 0xfe01b0231ad0 > > zio_execute() at 0x803e913c = zio_execute+0xac/frame > > 0xfe01b0231b20 > > taskqueue_run_locked() at 0x806d3d27 = > > taskqueue_run_locked+0x127/frame 0xfe01b0231b80 > > taskqueue_thread_loop() at 0x806d4ee8 = > > taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0 > > fork_exit() at 0x80640df5 = fork_exit+0x85/frame 0xfe01b0231bf0 > > fork_trampoline() at 0x8096915e = fork_trampoline+0xe/frame > > 0xfe01b0231bf0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > Uptime: 4s > > > > This seems to be an unintended consequence of some code that was pulled > in from upstream today. > > Try adding: vfs.zfs.trim.enabled=0 > to /boot/loader.conf > > (you can set it manually from the boot loader menu with the set command > to get the system to boot) That worked. Thanks. BTW, the call to abd_put() was given a NULL pointer. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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"
Crash in base/head in abd_put() after r320156
Has anyone else seen a crash in base/head in abd_put() after r320156? One of my experimental VMs at home crashed spectacularly after upgrading to r320156. I even wiped my /usr/obj, recompiled everything and got the same result. Everything's back to normal when I boot r320146. Here's the backtrace: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x8 Fatal trap 12: page fault while in kernel mode cpuid = 2; Fatal trap 12: page fault while in kernel mode apic id = 02 fault virtual address = 0x8 cpuid = 0; apic id = 00 fault virtual address = 0x8 fault code = supervisor read data, page not present fault code = supervisor read data, page not present instruction pointer = 0x20:0x803260fa stack pointer = 0x28:0xfe01b0231860 frame pointer = 0x28:0xfe01b0231870 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 Fatal trap 12: page fault while in kernel mode fault code = supervisor read data, page not present processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (zio_free_issue_5_2) trap number = 12 instruction pointer = 0x20:0x803260fa stack pointer = 0x28:0xfe01b022c860 frame pointer = 0x28:0xfe01b022c870 panic: page fault cpuid = 0 time = 4 KDB: stack backtrace: db_trace_self_wrapper() at 0x8044f93b = db_trace_self_wrapper+0x2b/frame 0xfe01b0231440 vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0 panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520 trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame 0xfe01b0231570 trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame 0xfe01b02315d0 trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790 calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790 --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = 0xfe01b0231870 --- abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870 vdev_raidz_map_free() at 0x803aa7c2 = vdev_raidz_map_free+0x82/frame 0xfe01b02318a0 zio_vdev_io_assess() at 0x803ecc04 = zio_vdev_io_assess+0x74/frame 0xfe01b02318e0 zio_execute() at 0x803e913c = zio_execute+0xac/frame 0xfe01b0231930 zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame 0xfe01b0231990 zio_execute() at 0x803e913c = zio_execute+0xac/frame 0xfe01b02319e0 zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame 0xfe01b0231a20 vdev_mirror_io_start() at 0x803a744c = vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70 zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame 0xfe01b0231ad0 zio_execute() at 0x803e913c = zio_execute+0xac/frame 0xfe01b0231b20 taskqueue_run_locked() at 0x806d3d27 = taskqueue_run_locked+0x127/frame 0xfe01b0231b80 taskqueue_thread_loop() at 0x806d4ee8 = taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0 fork_exit() at 0x80640df5 = fork_exit+0x85/frame 0xfe01b0231bf0 fork_trampoline() at 0x8096915e = fork_trampoline+0xe/frame 0xfe01b0231bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 4s -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: update an older i386 CURRENT system to amd64 CURRENT
r/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > /usr/obj/usr/src/make.i386/bmake KERNEL=kernel install > cc: Exec format error > bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to > determine compiler type for CC=cc -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE. > *** Error code 1 > > > Is there a way to use this /usr/src and pre-compiled /usr/obj on an i386 > host for update? Or do I have to use a complete recompile or even > reinstall, based on a 64-bit memstick system? I have in the past successfully migrated i386 to amd64 by cheating a bit: overwriting select parts of the base system with their amd64 counterparts from a snapshot (CD or memorystick) while exempting a few vital directories, /boot (not when replacing the kernel), /etc, /root, and /var. Since you're running the GENERIC kernel, all you need is the latest -current snapshot. Here are my notes from when I was "researching (and perfecting?)" the methodology: http://ximalas.info/2015/01/17/migrating-freebsd-from-i386-to-amd64/ YMMV, but this was less of a hassle than following https://wiki.freebsd.org/amd64/i386Migration. Last Easter I transformed four systems from 9-stable i386 UFS to 10-stable amd64 ZFS, using hardware I had selected for replacing the old hardware. The old systems were transferred to the new systems using tar and nc. That way the old systems kept humming while I recompiled base, ports, etc, on their replacements. Here are three things I didn't do/tried before "going live" last year: recursively copying /usr/local/lib to /usr/local/lib/compat/lib32, creating /usr/local/libdata/ldconfig/lib32 containing the line "/usr/local/lib/compat/lib32", and running ldconfig -R. When all parts of the new systems was in amd64 shape, I removed /usr/local/lib/compat/lib32 and /usr/local/libdata/ldconfig/lib32. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem compiling akonadi
On Tue, 21 Feb 2017 09:00-, Filippo Moretti wrote: > While trying to compile akonadi I get the following error: > ===> Installing for qtchooser-39===> Checking if qtchooser already > installed===> Registering installation for qtchooser-39 as > automaticInstalling qtchooser-39...pkg-static: qtchooser-39 conflicts with > qt4-dbus-4.8.7 (installs files into the same place). Problematic file: > /usr/local/bin/qdbus*** Error code 70 > Stop.make[5]: stopped in /usr/ports/misc/qtchooser*** Error code > 1Stop.make[4]: stopped in /usr/ports/devel/qt4-qmake*** Error code > 1Stop.make[3]: stopped in /usr/ports/devel/qt4-moc*** Error code > 1Stop.make[2]: stopped in /usr/ports/devel/automoc4*** Error code > 1Stop.make[1]: stopped in /usr/ports/databases/akonadi*** Error code > 1Stop.make: stopped in /usr/ports/databases/akonadi > sincerelyFilippo I had to: pkg delete qt4-linguisttools pkg delete qt4-rcc pkg delete qt4-moc Then I installed qtchooser, and next, I upgraded qt5-core only. Now, you should be able to upgrade the remaining ports. Note, I use ports which I build on my own, not pre-compiled packages. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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"
/usr/share/man/man4/cc.4.gz obsolete?
/usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run make -C /usr/src check-old. make -C /usr/src delete-old removes the file, but make -C /usr/src installworld adds it. System is base/head r309889. Please make up your mind. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: zfs crash on FreeBSD 10.3
On Fri, 14 Oct 2016 00:19-0700, Julian Elischer wrote: > I attempted to add a second partition to an existing FS pool in FreeBSD 10.3 > and the result was a crash.. > > is there anyone out there with a scratch system (10.3) (or two spare drives) > who can show me this working? > > Does it look familiar to anyone? > > The drive 'boot0' is being used as the root drive, but we are in single user > mode, so its' read-only at this stage. > > === cut-n-paste = > > [boot -s] > > [...] > > Trying to mount root from zfs:p8/image1 []... > Enter full pathname of shell or RETURN for /bin/sh: > PS1="# " > # > # > # ls /dev/gpt > boot0boot1 > # zpool attach -f p8 gpt/boot0 gpt/boot1 Do you really need to force zpool to attach the second partition? What happens if you omit the -f flag? > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address= 0x50 > fault code= supervisor read data, page not present > instruction pointer= 0x20:0x81717063 > stack pointer= 0x28:0xfe0169bfc640 > frame pointer= 0x28:0xfe0169bfc9a0 > 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= 3 (txg_thread_enter) > trap number= 12 > Panic:Thought about setting the watchdog to 10 Minutes > panic: page fault > cpuid = 1 > > KDB: stack backtrace: > stack1 db_trace_self_wrapper+0x2a > kdb_backtrace+0x37 vpanic+0xf7 > panic+0x67 trap_fatal+0x264 > trap_pfault+0x1c2 > trap+0x38c > calltrap+0x8 > dsl_scan_sync+0x2f3 > spa_sync+0x328 > txg_sync_thread+0x140 > fork_exit+0x135 > fork_trampoline+0xe > > KDB: enter: panic > [ thread pid 3 tid 100328 ] > Stopped at kdb_enter+0x50: movq$0,0x6bd5cd(%rip) > db> reboot > > I will add that after this, every boot hits this problem. (same stack trace). > the box is effectively bricked > (or would be if it weren't just a bhyve image) -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: CURRENT: "service netif restart" looses default route
On Wed, 5 Oct 2016 19:50+0200, Trond Endrestøl wrote: > Oct 4 13:23:24 [WITHHELD] kernel: add net default: gateway > 2001:x:y:z::1 fib 0: Network is unreachable This problem was due to a typo, sorry for the noise. > Also, why do the startup scripts attempt to add additional routes for > 127.0.0.1 and ::1? I see that behaviour on both head and stable/11. It might be worth investigating this issue further, since this behaviour is absent on stable/10. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: CURRENT: "service netif restart" looses default route
On Wed, 5 Oct 2016 18:47+0200, O. Hartmann wrote: > > Today, I checked on two servers of ours running both a recent CURRENT (i.e. > FreeBSD > 12.0-CURRENT #43 r306701: Wed Oct 5 06:40:40 CEST 2016) via "service netif > restart" the > upcoming network and realised that the default route is lost then! > > I'm able to config the route via "service routing restart" - or manually as I > did > otherwise. But I recall that I did a simple "service netif restart" in > 11-CURRENT > recently and that worked. > > Has there been a change? What is now the official way to restart network? I see something similar on stable/11, r306639. During boot this system can't add its IPv6 default route. I need to add it manually afterwards. Note, this is on XenServer 7.0.0, so maybe the hypervisor play a certain role. Oct 4 13:23:24 [WITHHELD] kernel: add host 127.0.0.1: gateway lo0 fib 0: route already in table Oct 4 13:23:24 [WITHHELD] kernel: add net default: gateway 128.x.y.z Oct 4 13:23:24 [WITHHELD] kernel: Additional inet routing options: gateway=YES. Oct 4 13:23:24 [WITHHELD] kernel: add host ::1: gateway lo0 fib 0: route already in table Oct 4 13:23:24 [WITHHELD] kernel: add net fe80::: gateway ::1 Oct 4 13:23:24 [WITHHELD] kernel: add net ff02::: gateway ::1 Oct 4 13:23:24 [WITHHELD] kernel: add net :::0.0.0.0: gateway ::1 Oct 4 13:23:24 [WITHHELD] kernel: add net ::0.0.0.0: gateway ::1 Oct 4 13:23:24 [WITHHELD] kernel: route: writing to routing socket: Network is unreachable Oct 4 13:23:24 [WITHHELD] kernel: add net default: gateway 2001:x:y:z::1 fib 0: Network is unreachable Also, why do the startup scripts attempt to add additional routes for 127.0.0.1 and ::1? I see that behaviour on both head and stable/11. -- +---+----+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: Weekday missing in date(1) output
On Mon, 4 Jul 2016 08:34+0200, Baptiste Daroussin wrote: > On Sun, Jul 03, 2016 at 10:17:54PM +0200, Thomas Eberhardt wrote: > > % uname -a > > FreeBSD clarence.ocp.lan 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #0 r302324: Sun > > Jul 3 21:27:41 CEST 2016 > > tho...@clarence.ocp.lan:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 > > % env LANG=en_US.UTF-8 date > > Sunday, July 3, 2016 at 10:14:21 PM CEST > > % env LANG=de_DE.UTF-8 date > > 3. Juli 2016 um 22:14:22 CEST > > > > stable10 gives: > > % env LANG=de_DE.UTF-8 date > > So 3 Jul 2016 19:34:18 CEST > > > > Is this intentional? > > > I have readded the weekday in most locales, I will recheck all of them to > ensure > the weekday is readded everywhere it was expected nb_NO.UTF-8 and nb_NO.ISO8859-1 are also affected. -- +---+----+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: console in 11.0-ALPHA4
On Mon, 20 Jun 2016 11:36-0400, Ernie Luzar wrote: > I have installed 11.0-ALPHA4-i386-20160617-r301975. > > The console looks very different from all previous releases. > I find it to be harder to read. This manifests it self with the boot log > messages and the normal behavior of the virtual consoles. > > But the real problem is in the notable hesitation when switching between > virtual consoles. > > From the boot log (ie: dmesg) I see this > VT(vga): resolution 640x480 > > This must be what is making the console display so different from > previous releases. Can VT be configured to default to present the same > console behavior as previous releases before this version of 11.0 gets > published as RELEASE? If you want textmode like in the old days, add this line to /boot/loader.conf: hw.vga.textmode="1" You can also interrupt the final boot loader, and type: set hw.vga.textmode="1" Then type: menu or: boot > About the "hesitation when switching between virtual consoles" I am > thinking that this reduced performance may be caused by WITNESS being > enabled in the ALPHA series of releases. Can anyone verify that this > hesitation will not exist in the published RELEASE? The "hesitation" is sometimes hardware dependent. A GPU with a KMS driver makes it better. It's even worse in some virtualization environments, e.g. Microsoft Hyper-V. > In the boot log I get this message 16 times. > "vicontrol: setting cursor type: Inappropriate ioctl for device" > They don't seem to cause any problems that I have stumbled across. > Is anyone else getting these "NOTICE" type messages? If you decide to continue with the vt console, you should consider the following: With the new VT console in graphics mode, you don't need to load any fonts. Disable or remove any font lines from /etc/rc.conf. I haven't tried the vt console in text mode lately, so maybe you need the fonts in that case. Look for the appropriate keymap file in /usr/share/vt/keymaps/ and update the keymap line in /etc/rc.conf. Here's the Norwegian keyboard layout as an example: keymap="norwegian.iso" # Old Norwegian keymap for the sc console keymap="no"# New Norwegian keymap for the vt console -- +-------++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: wired memory leak at r298785
On Tue, 3 May 2016 08:27-0600, Scott Long wrote: > > > On May 3, 2016, at 12:20 AM, Mark Johnston wrote: > > > > On Mon, May 02, 2016 at 08:55:58PM -0400, Steve Wills wrote: > >> Hi, > >> > >> On 05/ 2/16 09:32 AM, Steve Wills wrote: > >>> Hi, > >>> > >>> Just did my monthly update and r298785 seems to be leaking wired memory > >>> rather rapidly. My system has 8gb of RAM and the amount of wired memory > >>> just goes up and up continuously. It takes about 12 hours before it > >>> exhausts all the RAM and sort of locks up (though shutdown still works). > >>> > >>> I also made one other change to the system at the same time as updating, > >>> which was to add another disk and configure it using ZFS. Perhaps this > >>> is a ZFS on PowerPC64 issue? My amd64 box running the same rev of > >>> CURRENT doesn't have the issue. > >>> > >> > >> I've rebooted the box and started repeatedly logging the output of > >> vmstat -m. It seems to show CAM CCB using a lot of memory and growing > >> rather rapidly. For example, here's a few lines of diff output: > >> > >> - CAM CCB 91418 182836K - 187149 2048 > >> + CAM CCB 447070 894140K - 900292 2048 > >> > >> from two samples that are 60 minutes apart. > >> > >> The box is isn't terribly busy, it's just running the monitoring daemons > >> running (snmpd, collectd), whatever web requests are hitting it (very > >> few if any), this logging process, and my shell, etc. > > > > This was causing problems on one of my amd64 systems, so it's not > > specific to powerpc64. It turns out to be due to r298004: the CCB > > allocated in cam_periph_devctl_notify() never gets freed. The patch > > below seems to fix it. > > Thanks Mark, that looks like the right fix. I’ll put it in today. > > Scott A few of my stable/10 systems simple froze due to this bug. Would it be possible for the kernel to detect when it's running low on (kernel) memory, or when it's completely out of (kernel) memory, and call on panic() only to limp away for a day or so before rebooting again? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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 zfs loader and beadm?
On Thu, 10 Mar 2016 18:38+0300, Andrey Fesenko wrote: > On Thu, Mar 10, 2016 at 6:11 PM, krad wrote: > > As Eric said you cant have /boot on a separate dataset as the whole loader > > bootstrap isnt designed too look for it on the dataset defined by bootfs. > > Remember no other datasets are mounted at that stage of the bootstrap. > > > > You could maybe bodge something by manually playing around with the bootfs > > property, symlinks and rootfs variables in the loader.conf. But why would > > you want to do this? It's more work and non standard, and will break a lot? > > > > > > > > On 10 March 2016 at 12:11, Andrey Fesenko wrote: > >> > >> On Thu, Mar 10, 2016 at 2:55 PM, krad wrote: > >> > presumably it boots now? > >> > > >> > On 10 March 2016 at 11:01, Andrey Fesenko wrote: > >> >> > >> >> On Thu, Mar 10, 2016 at 1:49 PM, krad wrote: > >> >> > Make sure you are running the latest snapshot of current or 10.3 as > >> >> > well, as > >> >> > the MFC commits were in early February for 10-stable > >> >> > > >> >> >> > >> >> >> If remove efiwpool/ROOT/init/boot and copy his content on > >> >> >> efiwpool/ROOT/init my scheme work fine too. > >> >> >> /usr /var /home and other included in BE for consistent boot system > >> >> >> (CURRENT world may not boot with kernel other rev), and old home > >> >> >> snapshot sometimes useful for backup/restore > >> >> >> ___ > >> >> > >> >> % uname -a > >> >> FreeBSD x220.efi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296548: > >> >> Wed Mar 9 01:16:17 MSK 2016 > >> >> root@des.local:/usr/obj/usr/src/sys/X220 amd64 > >> > > >> > > >> > >> My current working config > >> % mount > >> > >> > >> This work fine, booted, beadm create new env, activate them, see boot > >> menu and select BE. > >> > >> % beadm list > >> BEActive Mountpoint Space Created > >> init - - 420.7M 2016-03-09 02:57 > >> init0 NR / 35.9G 2016-03-10 05:00 > >> > >> If i'm add separate dataset for /boot (efiwpool/ROOT/init0/boot) > >> system not booted, efi loader (first stage) see only my pool, not > >> found /boot/loader.efi > > > > > > It probably does not matter, as bootfs have snapshots (BE), just > wanted to make it more clear (having taken significant mountpoint > /boot, /usr, /var... in zfs dataset) and was surprised why the system > does not boot > > It is clear that as long as the functionality is experimental and > under development, but would like to see where the full instructions > on its implementation / restrictions, at least as early as has been > described https://wiki.freebsd.org/RootOnZFS If you keep /boot as a separate dataset/filesystem, with efiwpool/ROOT/init0/boot as the given bootfs, then boot1.efi will not see a /boot directory inside that dataset. The files and directories from /boot will be presented as living in /, the local root directory of that dataset. You could create a /boot/boot symlink pointing to . (dot), but it's better to let /boot be part of the regular boot environment, pretty similar to what you would find on a UFS system using a separate root filesystem. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: keymap set after file system decryption
On Thu, 17 Dec 2015 17:08+0100, Claude Buisson wrote: > As I said above, if you use vt, and kbdmux (which is standard and even > mandatory to be able to use Xorg), specifying the keymap for atkbd and > usbkbd is useless.. > > Have a look at PR 194744 by Oliver Pinter > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744) > > This PR is now more than 1 year old, and nothing has been done: people > using non-US keyboard are not popular here.. > > Claude Buisson Finally, I got it. That patch is quite trivial. Anyone with commit privs willing to commit it? Ed Maste is assigned, so unless you're too busy, Ed, would you commit this patch to CURRENT and MFC/MFH as appropriate? -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: keymap set after file system decryption
On Thu, 17 Dec 2015 13:56+0100, Trond Endrestøl wrote:
> On Thu, 17 Dec 2015 12:51+0100, Claude Buisson wrote:
>
> > On 12/17/2015 12:21, Trond Endrestøl wrote:
> > > On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> > >
> > > > On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> > > >
> > > > > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Trond Endrestøl wrote:
> > > > > >
> > > > > > > I guess we who live outside the US should take into account that
> > > > > > > PCs
> > > > > > > are initialised by firmware to the US keyboard layout and the 437
> > > > > > > code
> > > > > > > page, courtesy of IBM, 1981.
> > > > > >
> > > > > > In 1981 I had accepted this. Now it's simply a bug and I wonder it
> > > > > > has
> > > > > > not been fixed in 22 years. I'll file a bug report.
> > > > > >
> > > > > > > I'm not sure if the creators of (U)EFI has considered other
> > > > > > > keyboard
> > > > > > > layouts and/or code pages at boot time.
> > > > > >
> > > > > > I don't care for the BIOS here, the OS has to take care of it. It
> > > > > > may
> > > > > > be
> > > > > > ok that at the boot prompt only US keymap is set. But when the rc
> > > > > > scripts
> > > > > > are running the keymap must be set correctly (as one of the first
> > > > > > actions).
> > > > > >
> > > > > > > A bad workaround is to copy the suitable keymap from /usr/share...
> > > > > > > to
> > > > > > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to
> > > > > > > one
> > > > > > > or either of /etc/rc.d/geli{,2}, e.g.:
> > > > > > >
> > > > > > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > > > > > >
> > > > > > > kbdcontrol is linked only to libc:
> > > > > > >
> > > > > > > $ ldd `which kbdcontrol`
> > > > > > > /usr/sbin/kbdcontrol:
> > > > > > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> > > > > >
> > > > > > In my case it's simpler since I have /usr in /, but as you
> > > > > > descripted
> > > > > > kbdcontrol must be in /sbin and the maps in /etc in the future.
> > > > > >
> > > > > > Carsten
> > > > > >
> > > > >
> > > > > You can specify your default keymap in your kernel config file.
> > > > > ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> > > > > /boot/loader.conf, as well, but I'm not too sure of this. See
> > > > > atkbd(4).
> > > >
> > > > I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
> > > > SC_DFLT_FONT for that matter, works as intended.
> > > >
> > > > I have never had any success with:
> > > >
> > > > options SC_DFLT_FONT
> > > > makeoptions SC_DFLT_FONT=iso
> > > >
> > > > options UKBD_DFLT_KEYMAP
> > > > makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
> > > >
> > > > options ATKBD_DFLT_KEYMAP
> > > > makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
> > > >
> > > > Please prove me wrong.
> > >
> > > A recent run in stable/10 using r292334, resulted in:
> > >
> > > --- ukbd.o ---
> > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
> > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> > > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
> > > -Wmissing-include-dirs -fdiagnostics-show-option
> > > -Wno-error-tautological-compare -Wno-error-empty-body
> > > -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc
> > > -I.
> > > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
> > > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
>
Re: keymap set after file system decryption
On Thu, 17 Dec 2015 12:51+0100, Claude Buisson wrote:
> On 12/17/2015 12:21, Trond Endrestøl wrote:
> > On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> >
> > > On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> > >
> > > > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> > > > wrote:
> > > >
> > > > > Trond Endrestøl wrote:
> > > > >
> > > > > > I guess we who live outside the US should take into account that PCs
> > > > > > are initialised by firmware to the US keyboard layout and the 437
> > > > > > code
> > > > > > page, courtesy of IBM, 1981.
> > > > >
> > > > > In 1981 I had accepted this. Now it's simply a bug and I wonder it
> > > > > has
> > > > > not been fixed in 22 years. I'll file a bug report.
> > > > >
> > > > > > I'm not sure if the creators of (U)EFI has considered other keyboard
> > > > > > layouts and/or code pages at boot time.
> > > > >
> > > > > I don't care for the BIOS here, the OS has to take care of it. It may
> > > > > be
> > > > > ok that at the boot prompt only US keymap is set. But when the rc
> > > > > scripts
> > > > > are running the keymap must be set correctly (as one of the first
> > > > > actions).
> > > > >
> > > > > > A bad workaround is to copy the suitable keymap from /usr/share...
> > > > > > to
> > > > > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to
> > > > > > one
> > > > > > or either of /etc/rc.d/geli{,2}, e.g.:
> > > > > >
> > > > > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > > > > >
> > > > > > kbdcontrol is linked only to libc:
> > > > > >
> > > > > > $ ldd `which kbdcontrol`
> > > > > > /usr/sbin/kbdcontrol:
> > > > > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> > > > >
> > > > > In my case it's simpler since I have /usr in /, but as you descripted
> > > > > kbdcontrol must be in /sbin and the maps in /etc in the future.
> > > > >
> > > > > Carsten
> > > > >
> > > >
> > > > You can specify your default keymap in your kernel config file.
> > > > ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> > > > /boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
> > >
> > > I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
> > > SC_DFLT_FONT for that matter, works as intended.
> > >
> > > I have never had any success with:
> > >
> > > options SC_DFLT_FONT
> > > makeoptions SC_DFLT_FONT=iso
> > >
> > > options UKBD_DFLT_KEYMAP
> > > makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
> > >
> > > options ATKBD_DFLT_KEYMAP
> > > makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
> > >
> > > Please prove me wrong.
> >
> > A recent run in stable/10 using r292334, resulted in:
> >
> > --- ukbd.o ---
> > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
> > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
> > -Wmissing-include-dirs -fdiagnostics-show-option
> > -Wno-error-tautological-compare -Wno-error-empty-body
> > -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I.
> > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
> > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
> > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx
> > -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
> > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2
> > /usr/src/sys/dev/usb/input/ukbd.c
> > /usr/src/sys/dev/usb/input/ukbd.c:1216:18: error: use of undeclared
> > identifier 'key_map'
> > sc->sc_keymap = key_map;
> > ^
> > /usr/src/sys/dev/usb/input/ukbd.c:1217:18: error: use of undeclared
> > identifier 'accent_map'
> > sc->sc_accmap = acce
Re: Re: keymap set after file system decryption
On Thu, 17 Dec 2015 12:21+0100, Trond Endrestøl wrote:
> On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
>
> > On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> >
> > > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> > > wrote:
> > >
> > > > Trond Endrestøl wrote:
> > > >
> > > > > I guess we who live outside the US should take into account that PCs
> > > > > are initialised by firmware to the US keyboard layout and the 437 code
> > > > > page, courtesy of IBM, 1981.
> > > >
> > > > In 1981 I had accepted this. Now it's simply a bug and I wonder it has
> > > > not been fixed in 22 years. I'll file a bug report.
> > > >
> > > > > I'm not sure if the creators of (U)EFI has considered other keyboard
> > > > > layouts and/or code pages at boot time.
> > > >
> > > > I don't care for the BIOS here, the OS has to take care of it. It may
> > > > be
> > > > ok that at the boot prompt only US keymap is set. But when the rc
> > > > scripts
> > > > are running the keymap must be set correctly (as one of the first
> > > > actions).
> > > >
> > > > > A bad workaround is to copy the suitable keymap from /usr/share... to
> > > > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
> > > > > or either of /etc/rc.d/geli{,2}, e.g.:
> > > > >
> > > > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > > > >
> > > > > kbdcontrol is linked only to libc:
> > > > >
> > > > > $ ldd `which kbdcontrol`
> > > > > /usr/sbin/kbdcontrol:
> > > > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> > > >
> > > > In my case it's simpler since I have /usr in /, but as you descripted
> > > > kbdcontrol must be in /sbin and the maps in /etc in the future.
> > > >
> > > > Carsten
> > > >
> > >
> > > You can specify your default keymap in your kernel config file.
> > > ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> > > /boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
> >
> > I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
> > SC_DFLT_FONT for that matter, works as intended.
> >
> > I have never had any success with:
> >
> > options SC_DFLT_FONT
> > makeoptions SC_DFLT_FONT=iso
> >
> > options UKBD_DFLT_KEYMAP
> > makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
> >
> > options ATKBD_DFLT_KEYMAP
> > makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
> >
> > Please prove me wrong.
>
> A recent run in stable/10 using r292334, resulted in:
>
> --- ukbd.o ---
> cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
> -Wmissing-include-dirs -fdiagnostics-show-option
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I.
> -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx
> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2
> /usr/src/sys/dev/usb/input/ukbd.c
> /usr/src/sys/dev/usb/input/ukbd.c:1216:18: error: use of undeclared
> identifier 'key_map'
> sc->sc_keymap = key_map;
> ^
> /usr/src/sys/dev/usb/input/ukbd.c:1217:18: error: use of undeclared
> identifier 'accent_map'
> sc->sc_accmap = accent_map;
> ^
/usr/obj/usr/src/sys/KERNEL/{at,u}kbdmap.h er both empty.
The problem seems to be related to kbdcontrol.
kbdcontrol(8) is run as /usr/sbin/kbdcontrol -L ${ATKBD_DFLT_KEYMAP}
and as /usr/sbin/kbdcontrol -L ${UKBD_DFLT_KEYMAP}, during
buildkernel.
The option -L, unlike option -l (lowercase ell), does not search the
normal directories, e.g. /usr/share/syscons/keymaps.
By removing {at,u}kbdmap.h from /usr/obj/usr/src/sys/KERNEL and
changing to
options ATKBD_DFLT_KEYMAP
makeoptions ATKBD_DFLT_KEYMAP=/usr/share/syscons/keymaps/norwegian.iso.kbd
opt
Re: Re: keymap set after file system decryption
On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
>
> > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> > wrote:
> >
> > > Trond Endrestøl wrote:
> > >
> > > > I guess we who live outside the US should take into account that PCs
> > > > are initialised by firmware to the US keyboard layout and the 437 code
> > > > page, courtesy of IBM, 1981.
> > >
> > > In 1981 I had accepted this. Now it's simply a bug and I wonder it has
> > > not been fixed in 22 years. I'll file a bug report.
> > >
> > > > I'm not sure if the creators of (U)EFI has considered other keyboard
> > > > layouts and/or code pages at boot time.
> > >
> > > I don't care for the BIOS here, the OS has to take care of it. It may be
> > > ok that at the boot prompt only US keymap is set. But when the rc scripts
> > > are running the keymap must be set correctly (as one of the first
> > > actions).
> > >
> > > > A bad workaround is to copy the suitable keymap from /usr/share... to
> > > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
> > > > or either of /etc/rc.d/geli{,2}, e.g.:
> > > >
> > > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > > >
> > > > kbdcontrol is linked only to libc:
> > > >
> > > > $ ldd `which kbdcontrol`
> > > > /usr/sbin/kbdcontrol:
> > > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> > >
> > > In my case it's simpler since I have /usr in /, but as you descripted
> > > kbdcontrol must be in /sbin and the maps in /etc in the future.
> > >
> > > Carsten
> > >
> >
> > You can specify your default keymap in your kernel config file.
> > ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> > /boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
>
> I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
> SC_DFLT_FONT for that matter, works as intended.
>
> I have never had any success with:
>
> options SC_DFLT_FONT
> makeoptions SC_DFLT_FONT=iso
>
> options UKBD_DFLT_KEYMAP
> makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
>
> options ATKBD_DFLT_KEYMAP
> makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
>
> Please prove me wrong.
A recent run in stable/10 using r292334, resulted in:
--- ukbd.o ---
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I.
-I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2
/usr/src/sys/dev/usb/input/ukbd.c
/usr/src/sys/dev/usb/input/ukbd.c:1216:18: error: use of undeclared identifier
'key_map'
sc->sc_keymap = key_map;
^
/usr/src/sys/dev/usb/input/ukbd.c:1217:18: error: use of undeclared identifier
'accent_map'
sc->sc_accmap = accent_map;
^
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
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: Re: keymap set after file system decryption
On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> wrote:
>
> > Trond Endrestøl wrote:
> >
> > > I guess we who live outside the US should take into account that PCs
> > > are initialised by firmware to the US keyboard layout and the 437 code
> > > page, courtesy of IBM, 1981.
> >
> > In 1981 I had accepted this. Now it's simply a bug and I wonder it has
> > not been fixed in 22 years. I'll file a bug report.
> >
> > > I'm not sure if the creators of (U)EFI has considered other keyboard
> > > layouts and/or code pages at boot time.
> >
> > I don't care for the BIOS here, the OS has to take care of it. It may be
> > ok that at the boot prompt only US keymap is set. But when the rc scripts
> > are running the keymap must be set correctly (as one of the first actions).
> >
> > > A bad workaround is to copy the suitable keymap from /usr/share... to
> > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
> > > or either of /etc/rc.d/geli{,2}, e.g.:
> > >
> > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > >
> > > kbdcontrol is linked only to libc:
> > >
> > > $ ldd `which kbdcontrol`
> > > /usr/sbin/kbdcontrol:
> > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> >
> > In my case it's simpler since I have /usr in /, but as you descripted
> > kbdcontrol must be in /sbin and the maps in /etc in the future.
> >
> > Carsten
> >
>
> You can specify your default keymap in your kernel config file.
> ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> /boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
SC_DFLT_FONT for that matter, works as intended.
I have never had any success with:
options SC_DFLT_FONT
makeoptions SC_DFLT_FONT=iso
options UKBD_DFLT_KEYMAP
makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
options ATKBD_DFLT_KEYMAP
makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
Please prove me wrong.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
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: keymap set after file system decryption
On Wed, 16 Dec 2015 11:04+0100, Carsten Kunze wrote:
> Hello,
>
> according to the boot messages the keymap is set after decryption of
> file systems. I consider this as a bug. The geli decryption script
> asks for the passphrase which can't of course be input if the kaymap
> is not set.
>
> Handbook §17.12 does not mention the keymap setup. What can I do to
> make this work? (Of course I can call e.g. kbdmap in
> /etc/rc.d/geli, but this is kind of tinkering.)
I guess we who live outside the US should take into account that PCs
are initialised by firmware to the US keyboard layout and the 437 code
page, courtesy of IBM, 1981.
I'm not sure if the creators of (U)EFI has considered other keyboard
layouts and/or code pages at boot time.
A bad workaround is to copy the suitable keymap from /usr/share... to
/etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
or either of /etc/rc.d/geli{,2}, e.g.:
/etc/kbdcontrol -l /etc/german.iso.kbd
kbdcontrol is linked only to libc:
$ ldd `which kbdcontrol`
/usr/sbin/kbdcontrol:
libc.so.7 => /lib/libc.so.7 (0x800827000)
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
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: Problems with building rescue are solved
On Tue, 7 Jul 2015 19:37+0200, Trond Endrestøl wrote: > Hi, > > I guess both the instructions for enabling DTrace, > https://wiki.freebsd.org/DTrace/KernelSupport and r284356 are to > blame. > > I suggest the wiki be amended with: > > STRIP=: > > or some other innocuous command like 'echo --'. On second thoughts, maybe not. It causes new problems elsewhere in the source tree. Maybe /etc/make.conf should state: STRIP= as suggested by the wiki, but /etc/src.conf or even /etc/src-env.conf should state: STRIP=strip > Otherwise, "$(STRIP) rescue" in > /usr/obj/usr/src/rescue/rescue/rescue.mk will expand to simply > " rescue", and thus halting make buildworld by trying to run a command > not normally found in $(PATH). > > "make -C /usr/src/rescue/rescue -d e" came to the rescue, hah! -- +---+----+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Problems with building rescue are solved
Hi, I guess both the instructions for enabling DTrace, https://wiki.freebsd.org/DTrace/KernelSupport and r284356 are to blame. I suggest the wiki be amended with: STRIP=: or some other innocuous command like 'echo --'. Otherwise, "$(STRIP) rescue" in /usr/obj/usr/src/rescue/rescue/rescue.mk will expand to simply " rescue", and thus halting make buildworld by trying to run a command not normally found in $(PATH). "make -C /usr/src/rescue/rescue -d e" came to the rescue, hah! -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Mon, 22 Jun 2015 18:14-, Mark Johnston wrote: > On Mon, Jun 22, 2015 at 08:00:13PM +0200, Trond Endrestøl wrote: > > > > I concur. DTrace support is b0rken. > > > > I installed a fresh VM at work using Glen's recent base/head snapshot, > > 20150618 r284544. I created an /etc/src.conf file with only > > WITH_CTF=yes. I got hold of base/head r284678, started a -j4 > > buildworld + buildkernel, and immediately ctfconvert started > > complaining about nothing to do, i.e.: > > > > ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] > > > > Same result with -j1. > > These warnings are benign and are the result of compiling with WITH_CTF > and without debug info. Compiling with WITH_DEBUG_FILES or > DEBUG_FLAGS=-g will allow CTF to be generated, but its absence shouldn't > cause any problems (aside from these annoying warnings). Thanks for clarifying. > > I probably forgot to mention earlier, after my problems began last > > week, I always wiped /usr/obj clean before building again. > > > > I haven't activated dtraceall.ko using /boot/loader.conf, but I guess > > those that dare, end up with a kernel panic. I certainly did that last > > week. > > Can you elaborate on this? There don't seem to be any reports of such a > panic, and I certainly dare to load dtraceall.ko on head. :) It was sometime last week. I probably got a bad build due to the use of my highly customised bash environment. The resulting world would take 5.51 times longer to build another clean world and kernel, and fail, with the norm being about one and a half hour on this hardware, i7-960 @ 3.2 GHz. Thus, I reverted to a BE running r284273 from earlier this month, and got away with that. I have now switched to standard FreeBSD csh enviroment, and r284703 doesn't not have a problem loading dtraceall.ko. Sorry for all the noise. -- +-------++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Mon, 22 Jun 2015 09:41-0700, Jason Evans wrote: > On Jun 21, 2015, at 1:05 PM, Garrett Cooper wrote: > > On Jun 21, 2015, at 3:16, Trond Endrestøl > > wrote: > >> Am I the only one who fails to build recent base/head (r284673) on > >> pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. > > > > ... > > > >> CC=clang > >> CXX=clang++ > >> CPP=clang-cpp > > > > You need to remove these lines. They shouldn?t have been set before or > > after the commits from projects/bmake . > > I hit the same build failure, and I don't have any of those lines in my > /etc/make.conf. Mine is: > > STRIP= > > # added by use.perl 2013-01-21 16:11:13 > PERL_VERSION=5.12.4 > WITH_PKGNG=yes > > The STRIP= definition appears to have no impact with regard to the build > failure. > > I routinely do multiple buildworld/installworld cycles when updating, so I am > pretty sure that this is a self bootstrap failure; buildworld/installworld > succeeds the first time, but not the second time. r283923 does not have the > problem, so this was introduced sometime in the past three weeks. I concur. DTrace support is b0rken. I installed a fresh VM at work using Glen's recent base/head snapshot, 20150618 r284544. I created an /etc/src.conf file with only WITH_CTF=yes. I got hold of base/head r284678, started a -j4 buildworld + buildkernel, and immediately ctfconvert started complaining about nothing to do, i.e.: ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] Same result with -j1. I probably forgot to mention earlier, after my problems began last week, I always wiped /usr/obj clean before building again. I haven't activated dtraceall.ko using /boot/loader.conf, but I guess those that dare, end up with a kernel panic. I certainly did that last week. -- +-------++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Sun, 21 Jun 2015 13:05-0700, Garrett Cooper wrote: > > CC=clang > > CXX=clang++ > > CPP=clang-cpp > > Hi Trond, > You need to remove these lines. They shouldn?t have been set before or > after the commits from projects/bmake . > Thanks, Ah. That's good to know. Pilot error, indeed. They were probably leftovers from when we could choose between gcc and clang. I'll remove those lines and see what happens. Thanks. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
Hi, Am I the only one who fails to build recent base/head (r284673) on pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. Under the above circumstances, I got: --- rescue.all__D --- rescue sh: rescue: not found *** [rescue] Error code 127 make[5]: stopped in /usr/obj/usr/src/rescue/rescue 1 error Yes, a ran a four-way build, -j 4. Maybe I should switch to single job builds. Also, I see at lot of: --- gnu/lib/libssp/libssp_nonshared__PL --- ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] The one above happened very early in "stage 4.2: building libraries". Complete build log (23 MiB) is available at http://ximalas.info/~trond/base-head-201506/make-buildworld-buildkernel-20150621-r284673.txt. Using a one month old base/head (r284273) appears to get the job done, and I'm using that BE to build r284675 ATM, using serial jobs. I haven't ruled out any pilot error on my behalf, or maybe my working copy of base/head is on the fritz. My /etc/make.conf looks like this: KERNCONF=VBOX # DTrace for both base and ports. See https://wiki.freebsd.org/DTrace/KernelSupport. STRIP= CFLAGS+=-fno-omit-frame-pointer WITH_CTF=1 WITH_PKGNG=yes WITH_BDB6_PERMITTED=yes WITH_SSP_PORTS=yes WRKDIRPREFIX=/usr/ports/workdirs TEX_DEFAULT=texlive DEFAULT_VERSIONS=apache=2.4 bdb=5 firebird=2.5 gcc=4.8 lua=5.2 mysql=5.6 perl5=5.20 pgsql=9.4 php=5.6 python=2.7 python2=2.7 python3=3.4 ruby=2.2 tcltk=8.6 My /etc/src.conf looks like this: CC=clang CXX=clang++ CPP=clang-cpp NO_WERROR= WERROR= WITH_CLANG_EXTRAS=yes WITH_CLANG_FULL=yes WITH_CTF=yes WITH_GCC=yes WITH_GNUCXX=yes WITH_LIBCPLUSPLUS=yes WITH_LLDB=yes WITH_NAND=yes My /etc/src-env.conf exists, but empty. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Obsolete files in base/head
e's dated Mar 8 2014. /usr/share/man/man8/mount_fusefs.8.gz is installed and is current. Also, I believe these directories should be removed during delete-old: /usr/local/debug/usr/lib/clang/3.5.1 /usr/local/debug/usr/lib/clang/3.6.0 -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build world problem r284331 > r284377
On Sun, 14 Jun 2015 11:48+0300, Ivan Klymenko wrote: > [snip] Try to revert to r284342, e.g. svn up -r284342 /usr/src. That should get you going until things are sorted out with r284345 being the problematic commit. BTW, the commit log for r284345 states: Off by default [...] It doesn't seem to be the case. Correct me if I'm wrong. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r282420 omits /usr/lib/private/libssh_p.a
make delete-old can't finish off the /usr/lib/private directory due to the presence of libssh_p.a. Manual intervention is required UFN. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
/usr/sbin/cron and /usr/sbin/fifolog_{create,reader,writer} winds up in ${DESTDIR}/ during installworld, as of r275212
Something's wrong in base/head when /usr/sbin/cron and
/usr/sbin/fifolog_{create,reader,writer} winds up in ${DESTDIR}/
during installworld.
Seen on amd64 as of r275212, both with and without DESTDIR set.
Is it a pilot error on my part?
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
