(n244517-f17fc5439f5) svn stuck forever in /usr/ports?
We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann pgpOHXqEHBAI8.pgp Description: OpenPGP digital signature
(n244517-f17fc5439f5) svn stuck forever in /usr/ports?
We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann pgpin0lvgx68o.pgp Description: OpenPGP digital signature
Re: zpool upgrade to draid feature: does it require updated zfs boot code ?
On 1/28/21 11:00, Kurt Jaeger wrote: > Hi! > > Short question: > > Does a zpool upgrade on 14.0 (current) for the draid feature > require a boot code update ? > > Long version of the same question: [...] > With the draid update, no message was displayed. > > Does it require the bootcode update anyway or, if not, why not ? This sounded like a bug. Is it your boot pool, or just a regular data pool? > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd0 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd1 To answer your short question: do I need to update bootcode? No if draid is the only feature that you have enabled on an existing pool, but personally I don't recommend upgrading boot pool right now. The reason for that "No" answer is 1) the boot code do not currently support draid, and 2) enabling the feature won't activate it until draid vdev is added to the pool, which is quite unlikely in your case; note that if you do add draid vdev, your bootcode won't be able to boot from it anymore. On my personal laptop, old bootcode would boot pool with draid enabled but not activated just fine (note that the loader.efi on -CURRENT won't boot my P51, which I will start a separate discussion; I used FreeBSD-13.0-CURRENT-amd64-20201231-282381aa53a-255460-memstick.img and fixed my EFI loader and it worked fine with the draid-enabled boot ZFS pool). Hope this helps. Cheers, OpenPGP_signature Description: OpenPGP digital signature
Re: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) > It took for a while to investigate, but according to the result of > bisect following commit is the source of problem in my case. > > -- > commit 84eaf2ccc6a > Author: Konstantin Belousov > Date: Mon Dec 21 19:02:31 2020 +0200 > > x86: stop punishing VMs with low priority for TSC timecounter > > I suspect that virtualization techniques improved from the time when we > have to effectively disable TSC use in VM. For instance, it was reported > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > FreeBSD is groundlessly slow on AWS with some loads. > > Remove the check and start watching for complaints. > > Reviewed by:emaste, grehan > Discussed with: cperciva > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27629 > -- > > I confirmed the problem still happens with 5c325977b11 but reverting > above commit fixes it. I submitted this problem to Bugzilla. Timeout of bufdaemon happens at shutdown time with -CURRENT amd64 and VirtulaBox VM https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253087 --- Yasuhiro Kimura ___ 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: i915kms and chip resets on rsc0?
On Thu, Jan 28, 2021 at 02:20:40PM -0800, Steve Kargl wrote: > This is all likely academic as I just saw John Baldwin's email > that stated i386 support is being dropped in FreeBSD-current. s/dropped/downgraded/ The only difference seems to be that security upgrades that _only_ affect i386 will no longer be prioritized. This will put it mostly on a par with arm64, armv7, and powerpc64. That's all it means. mcl ___ 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: drm-fbsd13-kmod pkg-descr
heh I got worried because my ryzen vega needs 4.17 and up On 1/29/21 5:05 AM, Emmanuel Vadot wrote: On Fri, 29 Jan 2021 04:59:27 -0500 monochrome wrote: correct me if I'm wrong, but shouldn't it say: Currently corresponding to Linux 5.4.62 DRM. instead of: Currently corresponding to Linux 4.16 DRM. got caught by this while trying to update drm-devel-kmod from ports on stable/13, and took a chance that it was just an oversight :) Indeed, just fixed this. Thanks, ___ 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: drm-fbsd13-kmod pkg-descr
On Fri, 29 Jan 2021 04:59:27 -0500 monochrome wrote: > correct me if I'm wrong, but shouldn't it say: > > Currently corresponding to Linux 5.4.62 DRM. > > instead of: > > Currently corresponding to Linux 4.16 DRM. > > got caught by this while trying to update drm-devel-kmod from ports on > stable/13, and took a chance that it was just an oversight :) Indeed, just fixed this. Thanks, -- 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"
drm-fbsd13-kmod pkg-descr
correct me if I'm wrong, but shouldn't it say: Currently corresponding to Linux 5.4.62 DRM. instead of: Currently corresponding to Linux 4.16 DRM. got caught by this while trying to update drm-devel-kmod from ports on stable/13, and took a chance that it was just an oversight :) ___ 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"
