bhyve -G
Any hints on how to use bhyve's -G option to debug a VM kernel? I can connect to it from gdb with "target remote :" & bhyve stops the VM initially but beyond that I am not sure. Ideally this should work just like an in-circuit-emulator, not requiring anything special in the VM or kernel itself. Thanks!
LOR seen on 13.x kernel
Hi All, Seeing the below LOR in the 13.x kernel, is this a known issue ? Could this cause vnode to max out and slow down the system. Is there a patch available?(or can we ignore this ?) kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done kernel: Waiting (max 60 seconds) for system process `syncer' to stop... kernel: Syncing disks, vnodes remaining...114 lock order reversal: kernel: 1st 0xf80003b26068 syncer (syncer) @ kern/vfs_subr.c:1853 kernel: 2nd 0xf800038902d8 devfs (devfs) @ ufs/ffs/ffs_vfsops.c:1632 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x fe022f899630 kernel: witness_checkorder() at witness_checkorder+0xc87/frame 0x fe022f8996c0 kernel: __lockmgr_args() at __lockmgr_args+0x745/frame 0xfe022f8997f0 kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfe022f899810 kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xab/frame 0xfe022f899840 kernel: _vn_lock() at _vn_lock+0x43/frame 0xfe022f8998a0 kernel: ffs_sync() at ffs_sync+0x2f9/frame 0xfe022f899970 kernel: sync_fsync() at sync_fsync+0xfa/frame 0xfe022f8999b0 kernel: VOP_FSYNC_APV() at VOP_FSYNC_APV+0xc4/frame 0xfe022f8999e0 kernel: sched_sync() at sched_sync+0x338/frame 0xfe022f899a70 kernel: fork_exit() at fork_exit+0x71/frame 0xfe022f899ab0 kernel: fork_trampoline() at fork_trampoline+0xe/frame 0xfe022f899ab0 Regards Arun
"make installworld" fails for main-n265819-af5e348c61da
This is for an in-place source update; machine is currently running:
freebeast(15.0-C)[15] uname -aUK
FreeBSD freebeast.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #427
main-n265811-38ecc80b2a4e: Sun Oct 8 17:42:28 UTC 2023
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
amd64 151 151
Sources were updated to main-n265819-af5e348c61da.
Excerpt from the build typescript:
...
>>> Installing everything started on Mon Oct 9 11:26:45 UTC 2023
make[3]: "/common/S4/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1:
Using cached toolchain metadata from build at freebeast.catwhisker.org on Mon
Oct 9 10:49:37 UTC 2023
...
install -o root -g wheel -m 444 rk_grf.4.gz /usr/share/man/man4/
install -o root -g wheel -m 444 rk_i2c.4.gz /usr/share/man/man4/
install -o root -g wheel -m 444 rk_pinctrl.4.gz /usr/share/man/man4/
rm -f /usr/share/man/man4/aarch64/armv8crypto.4
/usr/share/man/man4/aarch64/armv8crypto.4.gz; install -l h -o root -g wheel -m
444 /usr/share/man/man4/armv8crypto.4.gz
/usr/share/man/man4/aarch64/armv8crypto.4.gz
install: link /usr/share/man/man4/armv8crypto.4.gz ->
/usr/share/man/man4/aarch64/armv8crypto.4.gz: No such file or directory
*** Error code 71
Stop.
make[7]: stopped in /usr/src/share/man/man4/man4.aarch64
*** Error code 1
So... a couple of things:
* This is an amd64 machine, building native. I didn't specify anything
with respect to aarch64, and have nothing about aarch64 mentioned in
/etc/*.conf.
* While my build procedure is based on the information in src/UPDATING, I
took the liberty (over a decade ago) to augment those instructions
with a couple of additional steps just prior to issuing "make
installworld":
* One of those is to move /usr/include aside;
* The other is to just completely remove /usr/share/man (recursively).
In each case, this is not because I don't want the hierarchy in
question; rather, it is because I want to be sure there is nothing
extraneous in either. "make hierarchy" has (in the past) been
invoked by "make installworld" and everything has been fine.
Prior to the above-described failure, I had an earlier one:
...
>> etcupdate -p OK
Mon Oct 9 11:10:29 UTC 2023
>> /usr/include.old removed
Mon Oct 9 11:10:29 UTC 2023
>> /usr/include moved aside
Mon Oct 9 11:10:29 UTC 2023
>> /usr/share/man removed
Mon Oct 9 11:10:29 UTC 2023
make[1]: "/common/S4/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1:
Using cached toolchain metadata from build at freebeast.catwhisker.org on Mon
Oct 9 10:49:37 UTC 2023
--
>>> Install check world
--
...
installing DIRS CONFSDIR
install -d -m 0755 -o root -g wheel /etc
installing DIRS NLSDIR
install -d -m 0755 -o root -g wheel /usr/share/nls
install -o root -g wheel -m 444 btree.3.gz /usr/share/man/man3/
install: /usr/share/man/man3/: No such file or directory
*** Error code 71
Stop.
make[5]: stopped in /usr/src/lib/libc
*** Error code 1
I checked src/Makefile.inc1; it was last updated by:
| commit 1a18383a52bc373e316d224cef1298debf6f7e25
| Author: Pierre Pronchery
| Date: Fri Sep 15 17:14:16 2023 +0200
|
| libcrypto: link engines and the legacy provider to libcrypto
Since I didn't see anything obvious that might have caused the observed
failure, I tweaked my procedure so that after removing /usr/share/man,
it then issued:
mkdir -p /usr/share/man/man{1,2,3{,lua},4,5,6,7,8,9}
Which appears to have got me through the initial issue.
I mention this in case there's a chance it might possibly be relevant.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
"I am not a member of any organized political party — I am a Democrat."
- Will Rogers (Huh. Wonder what he'd say given recent events)
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: 14-ALPHA2 panic on cold boot
Just tested 14.0-BETA5 and the issue is no longer present. My gratitude to Mark and all involved. --- Original Message --- On Monday, September 25th, 2023 at 12:12 PM, Mark Johnston wrote: > Yes. I've been traveling for the past couple of weeks and so haven't been > committing patches, but I'll be home tomorrow and plan to commit and merge > D41883. > > On Mon., Sep. 25, 2023, 06:59 cglogic, wrote: > >> Any chance that https://reviews.freebsd.org/D41883 will be merged into 14.0 >> before release? >> >> --- Original Message --- >> On Sunday, September 10th, 2023 at 5:14 PM, cglogic >> wrote: >> >>> For those who interested or affected by this issue. >>> >>> Looks like this regression was introduced by >>> https://reviews.freebsd.org/D34117 >>> Currently active PR is >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268393 >>> It contains a patch proposed by one of users. >>> But the PR can't move forward without committers attention. >>> >>> --- Original Message --- >>> On Tuesday, August 29th, 2023 at 11:09 AM, cglogic >>> wrote: >>> Hello dear FreeBSD community, Recently I tried to boot from FreeBSD 14-ALPHA2 image and got panic on first boot after power on. My hardware is AMD Ryzen 9 5900X on ASUS ROG STRIX B550-E GAMING. It's related to audio chip ALC1220 initialization. If I remember correctly, when I tried FreeBSD 13-STABLE, around 2 years ago, no panic was observed. But at that time my GPU was unsupported by drm-kmod. So I installed Linux and used it for 2 years. On Linux, no such a panic observed. Now drm-kmod supports my GPU and I want move to FreeBSD. Also tried 13.2, got the same panic. Can't try earlier FreeBSD 13 releases, as they are not available for download anymore. I found two related bug reports: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264305 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268393 My backtrace is the same as in reported issues. So I did not write it from a screen to a paper. As I understand, this bug affects all AMD Zen2, Zen3 and Zen4 computers and laptops. We are near FreeBSD 14.0 release now, maybe it will be possible to fix it before release. Thanks.
