RFC: Using NI_MAXSERV and NI_MAXHOST in the kernel
Hi, I have a patch for a bug identified at last week's testing event, where the FreeBSD NFSv4.1/4.2 client needs to rDNS a DS's address to a FQDN so that it can generate a server principal for Kerberos. (The bug only affects the case of a sec=krb5[ip],pnfs mount, so most will never see it.) Since the userspace gssd daemon calls getnameinfo(3) to do the rDNS, it would be nice if the kernel upcall code knew NI_MAXSERV and NI_MAXHOST. However, they currently live in netdb.h. I have put copies of them in sys/kgssapi/gssapi;.h, which works, but means that they are defined in two different places What do others think is the best way to handle this? Thanks, rick
Re: kernel 100% CPU
On 10/14/23, Graham Perrin wrote: > On 03/09/2023 20:25, Mateusz Guzik wrote: > >> … >> >> Sorry mate, neglected to specify: collect sysctl -a once you run into >> the problem. >> >> Once I look at that I'm probably going to ship some debug patches to >> narrow it down. > > > I had what might be the same issue this afternoon, for the first time in > weeks. With the slowdown, it took a few minutes for me to find your > email, unfortunately the symptoms subsided moments before finding it. > > So, I collected the information, but it's probably another missed > opportunity (the information collected too late). > > The busy period lasted for around six minutes: > > root@mowa219-gjp4-8570p-freebsd:~ # poudriere bulk -j main -J 3 -Ctv > devel/pkgconf > [00:00:00] Creating the reference jail... done > [00:00:01] Mounting system devices for main-default > [00:00:02] Warning: Using packages from previously failed, or > uncommitted, build: > /usr/local/poudriere/data/packages/main-default/.building > [00:00:02] Mounting ccache from: /usr/.ccache > [00:00:02] Mounting ports from: /usr/local/poudriere/ports/default > [00:00:02] Mounting packages from: > /usr/local/poudriere/data/packages/main-default > [00:00:02] Mounting distfiles from: /usr/ports/distfiles > [00:00:02] Copying /var/db/ports from: > /usr/local/etc/poudriere.d/main-options > [00:00:02] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf > /etc/resolv.conf -> > /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf > [00:00:02] Starting jail main-default > [00:00:02] Will build as nobody:nobody (65534:65534) > [00:00:05] Logs: > /usr/local/poudriere/data/logs/bulk/main-default/2023-10-14_16h16m30s > [00:00:05] Loading MOVED for > /usr/local/poudriere/data/.m/main-default/ref/usr/ports > [00:00:06] Ports supports: FLAVORS SELECTED_OPTIONS > [00:00:06] Inspecting ports tree for modifications to git checkout... yes > [00:06:39] Ports top-level git hash: e843b8293c (dirty) > … > sysctl output you pasted privately shows you are running a kernel form October 9th, fee14577d590. This predates a slew of fixes to vnlru I committed the day after. They fix some of the problems (not all of them!), but it should be good enough. tl;dr just update to newest main and it should be fine. -- Mateusz Guzik
Re: FreeBSD 14.0-BETA5 Now Available
On 10/16/23 9:54 AM, Ed Maste wrote: On Thu, 12 Oct 2023 at 00:11, Cameron Katri wrote: The FreeBSD-14.0-BETA5-arm64-aarch64-zfs.raw.xz (maybe others, I didn't check) has a rc.conf with a ton of repeated lines. I tried looking at why this would be, but the release scripts to create this image went right over my head. Would you mind submitting a PR for this? Here you go https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274522 - Cameron
Re: FreeBSD 14.0-BETA5 Now Available
On Thu, 12 Oct 2023 at 00:11, Cameron Katri wrote: > > The FreeBSD-14.0-BETA5-arm64-aarch64-zfs.raw.xz (maybe others, I didn't > check) has a rc.conf with a ton of repeated lines. I tried looking at > why this would be, but the release scripts to create this image went > right over my head. Would you mind submitting a PR for this?
Re: FreeBSD 14.0-BETA5 Now Available
On Sat, 7 Oct 2023 at 13:35, György Pásztor wrote: > > Hi Glen, > > The new betas broke the functionality to boot from ventoy. Unfortunately the way Ventoy handles FreeBSD booting is somewhat fragile and this sort of breakage is not surprising. I suspect the Ventoy authors will have to release an update to support 14.0. I am interested in looking for a way to make Ventoy support more reliable, but that will not happen for 14.0.
Re: nvme timeout issues with hardware and bhyve vm's
On Fri, Oct 13, 2023 at 7:34 PM Warner Losh wrote: ... > Let me now if you see similar messages in stable/14. I think I've fixed all > the > issues with timeouts, though you shouldn't ever seem them in a vm setup > unless something else weird is going on. I'd be interested in a repo case too as I haven't seen the NVMe emulation in bhyve do this before. Were there any error messages from bhyve? The guest log messages seem to suggest that the backing storage for the emulated device is timing out. If your comment > I had similar issues on my workstation as well. Scrubbing the NVMe > device on my real-hardware workstation hasn't turned up any issues, but > the system has locked up a handful of times. means the host is seeing NVMe errors on the drives backing the zpool/zvol used by the emulated device, this might explain it. Although, it is curious the emulated controller had trouble resetting (i.e., the error message "controller ready did not become 1 within 30500 ms"). --chuck
