RE: Livelock on recent current
> On 09.09.20 06:18, Kevin Oberman wrote: > > I am seeing a problem since I moved to current on my laptop this week. > > It's odd as it is linked to the keyboard. As long as the keyboard is > > active, everything is fine, but if the keyboard is not used, after a > > few minutes, it locks up and gets very hot. The system may be busy or > > idle. The system seems completely locked. It does not respond in the > > network and the display, X or just vt is frozen. The only factor is use of the > keyboard. I'm actually very happy someone else ran into this too! I have a Lenovo T490 (azerty edition, yeah I known ...) I found it incredible hard to describe, but i have the exact same problem. I categorized it as "random system freezes", but now that you say its related to keyboard interaction it makes sense when I observe the lock. System locks up when it happens and the fan ramps up AFTER the dead lock. I'm pretty sure the getting "hot" symptom is caused by the deadlock and not a symptom of the deadlock. > > Reminds me of this bug: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225341 I am also using a non default keyboard layout, as described in the bug above. I'll probably try the patch in the coming weekend to see if it helps. > > I've been experiencing similar hangs when that timer in atkbd is enabled. It > doesn't seem to happen in the default keyboard configuration, though. > > -Jan > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld: "cp: /dev/null: Invalid argument"
On Thu, 10 Sep 2020 10:35:08 -0400 Michael Butler wrote: > Is anyone else seeing failures like this in building world and, in my > case, cron jobs as well? > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > --- all_subdir_sbin --- > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > --- all_subdir_stand --- > --- zfsboot.ldr --- > cp: /dev/null: Invalid argument > *** [zfsboot.ldr] Error code 1 > make[5]: *** zfsboot.ldr removed > --- all_subdir_kerberos5 --- > Building > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > --- all_subdir_stand --- > > make[5]: stopped in /usr/src/stand/i386/zfsboot > .ERROR_TARGET='zfsboot.ldr' > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes > verbose' _ERROR_CMD='cp /dev/null zfsboot.ldr;' > .CURDIR='/usr/src/stand/i386/zfsboot' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > .TARGETS='all' > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20200902' > > ___ > 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" Same here with revision 365625 Regards, oh pgpl5iD5CLlJ0.pgp Description: OpenPGP digital signature
Re: time sysctl kstat.zfs.misc.dbufs | wc (was: OpenZFS and L2ARC)
On Thu, Sep 10, 2020, at 11:50 PM, Brandon Bergren wrote: > On Thu, Sep 10, 2020, at 11:17 PM, Graham Perrin wrote: > > On 09/09/2020 07:46, Stefan Esser wrote: > > > … an annoyance that I had noticed before but now have > > > tracked down: > > > > > > $ time sysctl kstat.zfs.misc.dbufs | wc > > > 55327 2047031 16333472 > > > > > > real 0m16,446s > > > user 0m0,055s > > > sys 0m16,397s > > > > > > … > > > > > > That's nothing: > > root@talos:~/devel/poudriere # /usr/bin/time sysctl kstat.zfs.misc.dbufs | wc > 603.59 real 0.03 user 603.39 sys >63677 2355981 18646506 > > It literally takes ten minutes on my Talos II. FWIW: Tracing command sysctl pid 25337 tid 104535 td 0xc00800010362b600 (CPU 59) 0xc00800015424cba0: at intr_event_handle+0x130 0xc00800015424cc40: at powerpc_dispatch_intr+0x8c 0xc00800015424ccc0: at xive_dispatch+0x94 0xc00800015424cd50: at PIC_DISPATCH+0x78 0xc00800015424cd90: at powerpc_interrupt+0xb8 0xc00800015424ce20: kernel trap 0xea0 by memset+0x10: srr1=0x90009032 r1=0xc00800015424d0d0 cr=0x4244 xer=0 ctr=0xded r2=0xc3a57000 frame=0xc00800015424ce50 0xc00800015424d0d0: at dbuf_stats_hash_table_data+0x1e4 0xc00800015424d180: at kstat_sysctl_raw+0x1e8 0xc00800015424d250: at sysctl_root_handler_locked+0x104 0xc00800015424d2c0: at sysctl_root+0x294 0xc00800015424d3b0: at userland_sysctl+0x174 0xc00800015424d4c0: at sys___sysctl+0x8c 0xc00800015424d5b0: at syscallenter+0x184 0xc00800015424d600: at syscall+0x60 0xc00800015424d640: at trap+0x440 0xc00800015424d750: at powerpc_interrupt+0x110 0xc00800015424d7e0: user SC trap by 0x8102de5d0: srr1=0x9200f032 r1=0xfbfffbfd0 cr=0x44000382 xer=0 ctr=0x8102de5c0 r2=0x810306bf0 frame=0xc00800015424d810 db> show frame 0xc00800015424ce50 trap frame 0xc00800015424ce50 r0: 0xc2566044 (-4611686018388172732) r1: 0xc00800015424d0d0 (-4609434212907036464) r2: 0xc3a57000 (-4611686018366214144) r3: 0xc00ca00cf000 (-4611685964202577920) r4: 0 (0) r5: 0x1000 (4096) r6: 0xc00ca00cf212 (-4611685964202577390) r7: 0x155a0b7 (22388919) r8: 0x1ff (33554431) r9: 0 (0) r10: 0xc35859fe (-4611686018371266050) r11: 0 (0) r12: 0xc26145dc (-4611686018387458596) r13: 0xc00800010362b600 (-4609434214261934592) r14: 0x1003d230 (268685872) r15: 0x1003d230 (268685872) r16: 0x1003d230 (268685872) r17: 0x1003d230 (268685872) r18: 0x810317b08 (34631416584) r19: 0x155a0b7 (22388919) r20: 0 (0) r21: 0xc3b61600 (-4611686018365123072) r22: 0xc35902b0 (-4611686018371222864) r23: 0xc35859fe (-4611686018371266050) r24: 0xc3b21488 (-4611686018365385592) r25: 0xc39ad5b0 (-4611686018366909008) r26: 0xc261480c (-4611686018387458036) r27: 0xc361d05a (-4611686018370645926) r28: 0xc00ca00cf000 (-4611685964202577920) r29: 0x1000 (4096) r30: 0xc3b61600 (-4611686018365123072) r31: 0xc00800015424d0d0 (-4609434212907036464) lr: 0xc26146a0 cr: 0x4244 xer: 0 ctr: 0xded (3565) srr0: 0xc30a5cc0 srr1: 0x90009032 exc: 0xea0 dar: 0xc0080001f2036b23 dsisr:0x200 Every time I've looked in on it, it appears to be zeroing a page of memory. I believe there is something going wrong with the buffer management here. -- Brandon Bergren bdra...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: time sysctl kstat.zfs.misc.dbufs | wc (was: OpenZFS and L2ARC)
On Thu, Sep 10, 2020, at 11:17 PM, Graham Perrin wrote: > On 09/09/2020 07:46, Stefan Esser wrote: > > … an annoyance that I had noticed before but now have > > tracked down: > > > > $ time sysctl kstat.zfs.misc.dbufs | wc > > 55327 2047031 16333472 > > > > real 0m16,446s > > user 0m0,055s > > sys 0m16,397s > > > > … > > That's nothing: root@talos:~/devel/poudriere # /usr/bin/time sysctl kstat.zfs.misc.dbufs | wc 603.59 real 0.03 user 603.39 sys 63677 2355981 18646506 It literally takes ten minutes on my Talos II. -- Brandon Bergren bdra...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
time sysctl kstat.zfs.misc.dbufs | wc (was: OpenZFS and L2ARC)
On 09/09/2020 07:46, Stefan Esser wrote: … an annoyance that I had noticed before but now have tracked down: $ time sysctl kstat.zfs.misc.dbufs | wc 55327 2047031 16333472 real 0m16,446s user 0m0,055s sys 0m16,397s … Here, I get much scrolling but no output from time: root@momh167-gjp4-8570p:~ # date ; uname -v Fri Sep 11 05:11:33 BST 2020 FreeBSD 13.0-CURRENT #64 r365364: Sun Sep 6 01:38:18 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG root@momh167-gjp4-8570p:~ # time sysctl kstat.zfs.misc.dbufs | wc 34699 1283795 10181844 root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh167-gjp4-8570p:~ # root@momh16
Re: tracking -current, using poudriere-devel and the switch to git
On Thu, 10 Sep 2020 at 07:02, tech-lists wrote: > > On Wed, Sep 09, 2020 at 04:34:20PM -0400, Ed Maste wrote: > > [...lots of stuff explaining...] > > thank you Oh, I see I left a word out of my first reply and it could be confusing - added text in brackets below: > At the moment, is svn behind git in terms of most recent updates, or the other > way round? Today the canonical src, doc, and ports [Subversion] repos are ahead; GitHub and cgit-beta are behind to varying degrees. ___ 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: buildworld: "cp: /dev/null: Invalid argument"
On 9/10/20 12:17 PM, Ryan Stone wrote: > I'm curious: does this give a similar issue? > > touch /tmp/foo > cp /tmp/foo /tmo/foo2 > > I'm wondering if the issue is that copy_file_range isn't handling > empty files, or if it's a devfs issue. An empty file doesn't generate the error .. imb@vm01:/home/imb> touch xx imb@vm01:/home/imb> cp xx yy imb@vm01:/home/imb> imb@vm01:/home/imb> cp /dev/null yy cp: /dev/null: Invalid argument imb@vm01:/home/imb> > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > wrote: >> It seems that SVN r365549 broke "cp /dev/null ..." >> >> imb >> >> On 9/10/20 10:35 AM, Michael Butler wrote: >>> Is anyone else seeing failures like this in building world and, in my >>> case, cron jobs as well? >>> >>> >>> Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr >>> --- all_subdir_sbin --- >>> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel >>> --- all_subdir_stand --- >>> --- zfsboot.ldr --- >>> cp: /dev/null: Invalid argument >>> *** [zfsboot.ldr] Error code 1 >>> make[5]: *** zfsboot.ldr removed >>> --- all_subdir_kerberos5 --- >>> Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log >>> --- all_subdir_stand --- >>> >>> make[5]: stopped in /usr/src/stand/i386/zfsboot >>> .ERROR_TARGET='zfsboot.ldr' >>> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' >>> .MAKE.LEVEL='5' >>> MAKEFILE='' >>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' >>> _ERROR_CMD='cp /dev/null zfsboot.ldr;' >>> .CURDIR='/usr/src/stand/i386/zfsboot' >>> .MAKE='make' >>> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' >>> .TARGETS='all' >>> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' >>> LD_LIBRARY_PATH='' >>> MACHINE='amd64' >>> MACHINE_ARCH='amd64' >>> MAKEOBJDIRPREFIX='' >>> MAKESYSPATH='/usr/src/share/mk' >>> MAKE_VERSION='20200902' >>> >>> ___ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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: New FreeBSD snapshots available: main
clay@bsd13:~ $ uname -a FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT #0 1544934ffb2-c253004(main): Thu Sep 10 06:18:34 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Works great, no problems with snapshot, thanks much Glen & everybody. ___ 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: buildworld: "cp: /dev/null: Invalid argument"
It seems that SVN r365549 broke "cp /dev/null ..." imb On 9/10/20 10:35 AM, Michael Butler wrote: > Is anyone else seeing failures like this in building world and, in my > case, cron jobs as well? > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > --- all_subdir_sbin --- > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > --- all_subdir_stand --- > --- zfsboot.ldr --- > cp: /dev/null: Invalid argument > *** [zfsboot.ldr] Error code 1 > make[5]: *** zfsboot.ldr removed > --- all_subdir_kerberos5 --- > Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > --- all_subdir_stand --- > > make[5]: stopped in /usr/src/stand/i386/zfsboot > .ERROR_TARGET='zfsboot.ldr' > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > .CURDIR='/usr/src/stand/i386/zfsboot' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > .TARGETS='all' > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20200902' > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
buildworld: "cp: /dev/null: Invalid argument"
Is anyone else seeing failures like this in building world and, in my case, cron jobs as well? Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr --- all_subdir_sbin --- Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel --- all_subdir_stand --- --- zfsboot.ldr --- cp: /dev/null: Invalid argument *** [zfsboot.ldr] Error code 1 make[5]: *** zfsboot.ldr removed --- all_subdir_kerberos5 --- Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log --- all_subdir_stand --- make[5]: stopped in /usr/src/stand/i386/zfsboot .ERROR_TARGET='zfsboot.ldr' .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='cp /dev/null zfsboot.ldr;' .CURDIR='/usr/src/stand/i386/zfsboot' .MAKE='make' .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' .TARGETS='all' DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20200902' ___ 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 list` permission denied
On Thu, Sep 10, 2020 at 12:46:45PM -0400, Ryan Moeller wrote: > > On 9/10/20 12:33 PM, Shawn Webb wrote: > > I used to be able to run `zfs list` as an unprivileged user. Now I > > can't, even when my user is in the operator group. > > > > BEGIN LOG > > hbsd-current-01[shawn]:/home/shawn $ zfs list > > Operation not permitted > > hbsd-current-01[shawn]:/home/shawn (1) $ id > > uid=1001(shawn) gid=1001(shawn) groups=1001(shawn),0(wheel),5(operator) > > hbsd-current-01[shawn]:/home/shawn $ ls -l /dev/zfs > > crw-rw-rw- 1 root operator 0x52 Sep 10 10:43 /dev/zfs > > END LOG > > > > Thanks, > > > You probably don't have the zfs module loaded. The commands will try to load > it if it isn't, and that will fail if you aren't root. Using root on ZFS: BEGIN LOG hbsd-current-01[shawn]:/scratch/logs (141) $ sudo kldstat Password: Id Refs AddressSize Name 1 150x0 2343700 kernel 210x0 652cb0 zfs.ko 310x0 b778 opensolaris.ko 410x0 2a10 mac_ntpd.ko END LOG I think I see the problem with your hint. Prior to the post-ZoL OpenZFS merge, we had detected whether the user running the command was non-root and only attempted module load if the user was root. We do this because we restrict access to kld*/mod* syscalls to root. And, as you can see from the output above, we scrub sensitive data from being returned from the kldstat syscall. I think I just need to re-apply that logic after this OpenZFS merge. Thanks for the hint! Sometimes I forget having written code from years back. ;) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, Sep 10, 2020 at 06:43:08PM +0200, Emmanuel Vadot wrote: > On Thu, 10 Sep 2020 16:36:44 + > Glen Barber wrote: > > > On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote: > > > On Thu, 3 Sep 2020 16:00:51 + > > > Glen Barber wrote: > > > > > > > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > > > > > > > Hello, > > > > > > > > > > On Thu, 3 Sep 2020 15:02:45 + > > > > > Glen Barber wrote: > > > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > > Hash: SHA256 > > > > > > > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git > > > > > > sources. > > > > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > > > > investigated. > > > > > > > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do > > > > > you > > > > > have more info ? > > > > > > > > > > > > > The ports tree failed to mount within the chroot directory. I think > > > > I see why, and am testing a fix now. > > > > > > > > > > Looks like there was a problem this week too. > > > How can I help ? > > > > > > > Nothing really. I know what the problem is. The ports tree mounting > > issue had been fixed, but two things: 1) the u-boot port failed to > > fetch for at least one of the boards; 2) something got screwed up in the > > environment, due to path changes and how the git checkout structure is > > set up. > > > > The first is basically a timing issue with a ports commit and > > distribution of the distfiles. The second I am working on fixing now, > > which should be Relatively Easy(tm). > > > > Which port commit and which board ? There haven't been a commit in the > u-boot ports or rpi-firmware this a month now so I fails to understand > without more info. > The PINEBOOK fetch failed, but after closer inspection, it looks like a transient "Service not available" error. But I think the build would have failed in this case if the fetch succeeded, based on logs from other boards. Glen signature.asc Description: PGP signature
Re: `zfs list` permission denied
On 9/10/20 12:33 PM, Shawn Webb wrote: I used to be able to run `zfs list` as an unprivileged user. Now I can't, even when my user is in the operator group. BEGIN LOG hbsd-current-01[shawn]:/home/shawn $ zfs list Operation not permitted hbsd-current-01[shawn]:/home/shawn (1) $ id uid=1001(shawn) gid=1001(shawn) groups=1001(shawn),0(wheel),5(operator) hbsd-current-01[shawn]:/home/shawn $ ls -l /dev/zfs crw-rw-rw- 1 root operator 0x52 Sep 10 10:43 /dev/zfs END LOG Thanks, You probably don't have the zfs module loaded. The commands will try to load it if it isn't, and that will fail if you aren't root. -Ryan ___ 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: buildworld: "cp: /dev/null: Invalid argument"
No, it's devfs. I'll fix it. On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone wrote: > I'm curious: does this give a similar issue? > > touch /tmp/foo > cp /tmp/foo /tmo/foo2 > > I'm wondering if the issue is that copy_file_range isn't handling > empty files, or if it's a devfs issue. > > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > wrote: > > > > It seems that SVN r365549 broke "cp /dev/null ..." > > > > imb > > > > On 9/10/20 10:35 AM, Michael Butler wrote: > > > Is anyone else seeing failures like this in building world and, in my > > > case, cron jobs as well? > > > > > > > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > > > --- all_subdir_sbin --- > > > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > > > --- all_subdir_stand --- > > > --- zfsboot.ldr --- > > > cp: /dev/null: Invalid argument > > > *** [zfsboot.ldr] Error code 1 > > > make[5]: *** zfsboot.ldr removed > > > --- all_subdir_kerberos5 --- > > > Building > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > > --- all_subdir_stand --- > > > > > > make[5]: stopped in /usr/src/stand/i386/zfsboot > > > .ERROR_TARGET='zfsboot.ldr' > > > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > > > .MAKE.LEVEL='5' > > > MAKEFILE='' > > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes > verbose' > > > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > > > .CURDIR='/usr/src/stand/i386/zfsboot' > > > .MAKE='make' > > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > > > .TARGETS='all' > > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > > LD_LIBRARY_PATH='' > > > MACHINE='amd64' > > > MACHINE_ARCH='amd64' > > > MAKEOBJDIRPREFIX='' > > > MAKESYSPATH='/usr/src/share/mk' > > > MAKE_VERSION='20200902' > > > > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > ___ 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: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, 10 Sep 2020 16:36:44 + Glen Barber wrote: > On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote: > > On Thu, 3 Sep 2020 16:00:51 + > > Glen Barber wrote: > > > > > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > > > > > Hello, > > > > > > > > On Thu, 3 Sep 2020 15:02:45 + > > > > Glen Barber wrote: > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA256 > > > > > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git > > > > > sources. > > > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > > > investigated. > > > > > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > > > > have more info ? > > > > > > > > > > The ports tree failed to mount within the chroot directory. I think > > > I see why, and am testing a fix now. > > > > > > > Looks like there was a problem this week too. > > How can I help ? > > > > Nothing really. I know what the problem is. The ports tree mounting > issue had been fixed, but two things: 1) the u-boot port failed to > fetch for at least one of the boards; 2) something got screwed up in the > environment, due to path changes and how the git checkout structure is > set up. > > The first is basically a timing issue with a ports commit and > distribution of the distfiles. The second I am working on fixing now, > which should be Relatively Easy(tm). > > Glen > Which port commit and which board ? There haven't been a commit in the u-boot ports or rpi-firmware this a month now so I fails to understand without more info. -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote: > On Thu, 3 Sep 2020 16:00:51 + > Glen Barber wrote: > > > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > > > Hello, > > > > > > On Thu, 3 Sep 2020 15:02:45 + > > > Glen Barber wrote: > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA256 > > > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git sources. > > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > > investigated. > > > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > > > have more info ? > > > > > > > The ports tree failed to mount within the chroot directory. I think > > I see why, and am testing a fix now. > > > > Looks like there was a problem this week too. > How can I help ? > Nothing really. I know what the problem is. The ports tree mounting issue had been fixed, but two things: 1) the u-boot port failed to fetch for at least one of the boards; 2) something got screwed up in the environment, due to path changes and how the git checkout structure is set up. The first is basically a timing issue with a ports commit and distribution of the distfiles. The second I am working on fixing now, which should be Relatively Easy(tm). Glen signature.asc Description: PGP signature
`zfs list` permission denied
I used to be able to run `zfs list` as an unprivileged user. Now I can't, even when my user is in the operator group. BEGIN LOG hbsd-current-01[shawn]:/home/shawn $ zfs list Operation not permitted hbsd-current-01[shawn]:/home/shawn (1) $ id uid=1001(shawn) gid=1001(shawn) groups=1001(shawn),0(wheel),5(operator) hbsd-current-01[shawn]:/home/shawn $ ls -l /dev/zfs crw-rw-rw- 1 root operator 0x52 Sep 10 10:43 /dev/zfs END LOG Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, 3 Sep 2020 16:00:51 + Glen Barber wrote: > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > Hello, > > > > On Thu, 3 Sep 2020 15:02:45 + > > Glen Barber wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git sources. > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > investigated. > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > > have more info ? > > > > The ports tree failed to mount within the chroot directory. I think > I see why, and am testing a fix now. > > Glen > Looks like there was a problem this week too. How can I help ? -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld: "cp: /dev/null: Invalid argument"
I'm curious: does this give a similar issue? touch /tmp/foo cp /tmp/foo /tmo/foo2 I'm wondering if the issue is that copy_file_range isn't handling empty files, or if it's a devfs issue. On Thu, Sep 10, 2020 at 11:45 AM Michael Butler wrote: > > It seems that SVN r365549 broke "cp /dev/null ..." > > imb > > On 9/10/20 10:35 AM, Michael Butler wrote: > > Is anyone else seeing failures like this in building world and, in my > > case, cron jobs as well? > > > > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > > --- all_subdir_sbin --- > > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > > --- all_subdir_stand --- > > --- zfsboot.ldr --- > > cp: /dev/null: Invalid argument > > *** [zfsboot.ldr] Error code 1 > > make[5]: *** zfsboot.ldr removed > > --- all_subdir_kerberos5 --- > > Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > --- all_subdir_stand --- > > > > make[5]: stopped in /usr/src/stand/i386/zfsboot > > .ERROR_TARGET='zfsboot.ldr' > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > > .MAKE.LEVEL='5' > > MAKEFILE='' > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > > .CURDIR='/usr/src/stand/i386/zfsboot' > > .MAKE='make' > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > > .TARGETS='all' > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > LD_LIBRARY_PATH='' > > MACHINE='amd64' > > MACHINE_ARCH='amd64' > > MAKEOBJDIRPREFIX='' > > MAKESYSPATH='/usr/src/share/mk' > > MAKE_VERSION='20200902' > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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: tracking -current, using poudriere-devel and the switch to git
On Wed, Sep 09, 2020 at 04:34:20PM -0400, Ed Maste wrote: [...lots of stuff explaining...] thank you -- J. signature.asc Description: PGP signature
Re: svn commit: r365419 - in head/sys/dev: ath bwi iwm iwn mwl otus usb/wlan wtap
On 9 Sep 2020, at 22:41, Tomoaki AOKI wrote:
This breaks at least iwm. (Other drivers not tested.)
Messages below are repeatedly shown and no carrier detected.
Manually reverting this commit fixes the issue.
iwm0: failed to send antennas before calibration: 35
iwm_run_init_ucode: failed 35
iwm_init_hw failed 35
iwm0: could not initiate scan
and lesser times messages below.
iwm0: iwm_send_phy_db_data: Cannot send HCMD of Phy DB cfg section, 35
iwm_init_hw failed 35
iwm0: could not initiate scan
I’ll try to test iwm as well, in case you are faster, can you please
try this instead of reverting; the previous version never made it past
the first return anymore in the last years it seems, so we can remove
the function entirely to keep the status quo:
Sorry for the oversight.
Index: if_iwm.c
===
--- if_iwm.c(revision 365559)
+++ if_iwm.c(working copy)
@@ -354,7 +354,6 @@ static struct ieee80211_node *
static uint8_t iwm_rate_from_ucode_rate(uint32_t);
static int iwm_rate2ridx(struct iwm_softc *, uint8_t);
static voidiwm_setrates(struct iwm_softc *, struct iwm_node *,
int);
-static int iwm_media_change(struct ifnet *);
static int iwm_newstate(struct ieee80211vap *, enum
ieee80211_state, int);
static voidiwm_endscan_cb(void *, int);
static int iwm_send_bt_init_conf(struct iwm_softc *);
@@ -4417,27 +4416,6 @@ iwm_setrates(struct iwm_softc *sc, struct
iwm_node
}
}
-static int
-iwm_media_change(struct ifnet *ifp)
-{
- struct ieee80211vap *vap = ifp->if_softc;
- struct ieee80211com *ic = vap->iv_ic;
- struct iwm_softc *sc = ic->ic_softc;
- int error;
-
- error = ieee80211_media_change(ifp);
- if (error != 0)
- return (error);
-
- IWM_LOCK(sc);
- if (ic->ic_nrunning > 0) {
- iwm_stop(sc);
- iwm_init(sc);
- }
- IWM_UNLOCK(sc);
- return (0);
-}
-
static void
iwm_bring_down_firmware(struct iwm_softc *sc, struct ieee80211vap
*vap)
{
@@ -6432,8 +6410,8 @@ iwm_vap_create(struct ieee80211com *ic, const char
ieee80211_ratectl_init(vap);
/* Complete setup. */
- ieee80211_vap_attach(vap, iwm_media_change,
ieee80211_media_status,
- mac);
+ ieee80211_vap_attach(vap, ieee80211_media_change,
+ ieee80211_media_status, mac);
ic->ic_opmode = opmode;
return vap;
Author: bz
Date: Mon Sep 7 15:35:40 2020
New Revision: 365419
URL: https://svnweb.freebsd.org/changeset/base/365419
Log:
WiFi: fix ieee80211_media_change() callers
In r178354 with the introduction of multi-bss ("vap") support
factoring
out started and with r193340 ieee80211_media_change() no longer
returned
ENETRESET but only 0 or error.
As ieee80211(9) tells the ieee80211_media_change() function should
not
be called directly but is registered with ieee80211_vap_attach()
instead.
Some drivers have not been fully converted. After fixing the
return
checking some of these functions were simply wrappers between
ieee80211_vap_attach() and ieee80211_media_change(), so remove the
extra
function, where possible as well.
PR: 248955
Submitted by: Tong Zhang (ztong0001 gmail.com) (original)
MFC after:3 days
Sponsored by: The FreeBSD Foundation
Modified:
head/sys/dev/ath/if_ath.c
head/sys/dev/bwi/if_bwi.c
head/sys/dev/iwm/if_iwm.c
head/sys/dev/iwn/if_iwn.c
head/sys/dev/mwl/if_mwl.c
head/sys/dev/otus/if_otus.c
head/sys/dev/usb/wlan/if_run.c
head/sys/dev/wtap/if_wtap.c
Modified: head/sys/dev/ath/if_ath.c
==
--- head/sys/dev/ath/if_ath.c Mon Sep 7 14:40:33 2020(r365418)
+++ head/sys/dev/ath/if_ath.c Mon Sep 7 15:35:40 2020(r365419)
@@ -160,7 +160,6 @@ static int ath_init(struct ath_softc *);
static voidath_stop(struct ath_softc *);
static int ath_reset_vap(struct ieee80211vap *, u_long);
static int ath_transmit(struct ieee80211com *, struct mbuf *);
-static int ath_media_change(struct ifnet *);
static voidath_watchdog(void *);
static voidath_parent(struct ieee80211com *);
static voidath_fatal_proc(void *, int);
(snip)
Modified: head/sys/dev/iwm/if_iwm.c
==
--- head/sys/dev/iwm/if_iwm.c Mon Sep 7 14:40:33 2020(r365418)
+++ head/sys/dev/iwm/if_iwm.c Mon Sep 7 15:35:40 2020(r365419)
@@ -4426,8 +4426,8 @@ iwm_media_change(struct ifnet *ifp)
int error;
error = ieee80211_media_change(ifp);
- if (error != ENETRESET)
- return error;
+ if (error != 0)
+ return (error);
IWM_LOCK(sc);
if (ic->ic_nrunning > 0) {
@@ -4435,7 +4435,7 @@ iwm_media_change(struct ifnet *ifp)
iwm_init(sc);
}
Re: Freeze during early boot
> On 10. Sep 2020, at 03:57, Mason Loring Bliss wrote: > > Hi, all. I'd like to see FreeBSD running on a new class of box I've got > here. Not new hardware. These are Atom chips on Micro-ITX motherboards, and > are interesting in that they are low-power and have dual gigabit NICs. > They're UEFI-only. > > These boxes seem to not like the FreeBSD 12.1 .iso files as written to USB > sticks, but I could boot the installer with an .img. > > That said, the resulting system as installed seems to freeze in precisely > the same place as the .iso-files-written-to-USB froze. I took a photo of > the freeze, and then realized that it was the same as when I was trying to > boot from the USB stick the first time. > > I've got a photo of it in the bug I've just opened to complement this > email, along with dmesg from NetBSD and Linux: > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249226 > > What's different between the .iso and the .img files, and how might that > translate to the installed system, if that's not a red herring? And how > might I get these boxes to boot FreeBSD? If the iso written to stick was able to give you working loader (in a sense that you can navigate and exit menu, enter ls, lsdev etc on loader OK prompt), then the iso, as bootable media, is ok. > > The boxes don't have build-in storage so I'm installing and booting from > USB drives, so making modifications from another system to test things > ought to be fairly straightforward. > > Addendum: To try -current in case it was a known issue, I downloaded the > mini-memstick.img, but it freezes in the same place. > Because your system is freezing while attempting to start the kernel (framebuffer information is printer in loader just before relocating loaded bits to final location and jumping to kernel, the issue can possibly be either in loader preparing to trampoline or in early kernel. If you do not mind one extra test (and as you have already done linux/netbsd tests), I’d be interested to see test results from illumos boot (openindiana or omnios for example), press esc to get out from loader menu, and enter on ok prompt: boot -B prom_debug=true,kbm_debug=true,map_debug=true This is useful because those systems also boot using freebsd loader, but there is a small difference how the kernel start is prepared, and if it does get that far, maybe we can get memory map from early kernel. But to get this issue properly diagnosed and fixed, we would need to build test versions for your system and just see what/where we will get… rgds, toomas ___ 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: OpenZFS and L2ARC
Am 09.09.20 um 21:26 schrieb John Baldwin:> A simple fix might be to use CTLFLAG_SKIP so that you only invoke the expensive sysctls if you request them by name, but not if you request the 'kstat.zfs' tree. I have looked at /sys/contrib/openzfs/module/zfs/dbuf.c where I had assumed that the "kstat.zfs.misc.dbufs" sysctl node was created, but did not spot the location on a quick search. The kstat nodes are created by kstat_install() and AFAICT, there is no parameter that directly allows to create the sysctl node with CTLFLAG_SKIP, currently. This long delay affects sysctl -a and I'd really hope that it can be fixed in a way that suppresses this large debug output unless it is specifically requested by passing the full node name ... Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
