Re: Using SCHED_4BSD now leads to a panic during kernel boot

On Thu, 19 Jun 2025 22:44:01 -0400 Olivier Certner wrote: > > > I use SCHED_4BSD as my scheduler and that results in a panic during > > > the kernel boot. > > > > Strange. Looking into it. > > Panic comes in fact from a too stringent assertion. Apar

Re: Using SCHED_4BSD now leads to a panic during kernel boot

> > I use SCHED_4BSD as my scheduler and that results in a panic during > > the kernel boot. > > Strange. Looking into it. Panic comes in fact from a too stringent assertion. Apart from that, everything is working correctly and you should not have seen any problem on a n

Re: Using SCHED_4BSD now leads to a panic during kernel boot

> I downloaded the latest HEAD sources today and compiled world and kernel. > > I use SCHED_4BSD as my scheduler and that results in a panic during > the kernel boot. Strange. Looking into it. Thanks and regards. -- Olivier Certner signature.asc Description: This is a digi

Re: New packages repositories for kernel modules (without typo)

On Fri, 16 May 2025, at 13:51, b...@freebsd.org wrote: > New package repositories available for kernel modules. > > Since 14.2-RELEASE we have been publishing a repository of packages built for > all supported arches. > > With the upcoming 14.3-RELEASE we have extended the infras

Re: New packages repositories for kernel modules (without typo)

> On May 16, 2025, at 9:51 PM, b...@freebsd.org wrote: > > > New package repositories available for kernel modules. > > Since 14.2-RELEASE we have been publishing a repository of packages built for > all supported arches. > > With the upcoming 14.3-R

Re: New packages repositories for kernel modules (without typo)

W dniu 16.05.2025 o 15:51, b...@freebsd.org pisze: New package repositories available for kernel modules. Since 14.2-RELEASE we have been publishing a repository of packages built for all supported arches. With the upcoming 14.3-RELEASE we have extended the infrastructure so it now covers the

Re: New packages repositories for kernel modules (without typo)

On 16/05/25 15:51, b...@freebsd.org wrote: New package repositories available for kernel modules. Since 14.2-RELEASE we have been publishing a repository of packages built for all supported arches. With the upcoming 14.3-RELEASE we have extended the infrastructure so it now covers the

Re: Loader goes to LINES=16 and kernel stays on that :(

On 2025-05-12 22:36, Toomas Soome wrote: On 12. May 2025, at 22:50, Jakob Alvermark wrote: On 2025-05-10 22:13, Adrian Chadd wrote: On Sat, 10 May 2025 at 13:10, Warner Losh wrote: Yea. This is due to the new, larger font and a hidden bug. Hasn't this been fixed in -HEAD? I though

Re: Loader goes to LINES=16 and kernel stays on that :(

> On 12. May 2025, at 22:50, Jakob Alvermark wrote: > > On 2025-05-10 22:13, Adrian Chadd wrote: >> >> >> On Sat, 10 May 2025 at 13:10, Warner Losh > > wrote: >>> Yea. This is due to the new, larger font and a hidden bug. >> >> Hasn't this been fixed in -HEAD? I tho

Re: Loader goes to LINES=16 and kernel stays on that :(

On 2025-05-10 22:13, Adrian Chadd wrote: On Sat, 10 May 2025 at 13:10, Warner Losh wrote: Yea. This is due to the new, larger font and a hidden bug. Hasn't this been fixed in -HEAD? I thought tsoome was working on it. Oh, here: https://reviews.freebsd.org/D50258 Want to try that out

Re: Loader goes to LINES=16 and kernel stays on that :(

world dedicded to rebuild half my obj despite only applied the one change. I thought on main this is all incremental these days. *sigh*. I assume there is no way to fix this manually as a user (change the settings from within loader) at least for the next stage (kernel)? I don't know much abou

Re: Loader goes to LINES=16 and kernel stays on that :(

.. and I use this to get a smaller font, in /etc/rc.conf : # font8x8="/usr/share/vt/fonts/vgarom-8x8.fnt" font8x16="/usr/share/vt/fonts/vgarom-8x16.fnt -adrian

Re: Loader goes to LINES=16 and kernel stays on that :(

#x27;ll reboot as soon as buildworld dedicded to rebuild half my obj > despite only applied the one change. I thought on main this is all > incremental these days. *sigh*. > > I assume there is no way to fix this manually as a user (change the settings > from within loader) at least

Re: Loader goes to LINES=16 and kernel stays on that :(

s all incremental these days. *sigh*. I assume there is no way to fix this manually as a user (change the settings from within loader) at least for the next stage (kernel)? I don't know much about all this; I tried vidcontrol later from the console to at least be able to read a few more lines o

Re: Loader goes to LINES=16 and kernel stays on that :(

the day for a few days. loader.efi (lua) gets loaded;  I see the EFI bits flashing by in a tiny font and then loader sits there being more magestic than on a vt100 with LINES=16 : % kenv LINES; kenv COLUMNS 16 60 Before the kernel starts I see that bit flashing by which says 1920x... but even the kernel th

Re: Loader goes to LINES=16 and kernel stays on that :(

aded; I see the EFI bits flashing by in a tiny >> font and then loader sits there being more magestic than on a vt100 >> with LINES=16 : >> % kenv LINES; kenv COLUMNS >> 16 >> 60 >> >> Before the kernel starts I see that bit flashing by which says 1920x.

Re: Loader goes to LINES=16 and kernel stays on that :(

by in a tiny > font and then loader sits there being more magestic than on a vt100 > with LINES=16 : > % kenv LINES; kenv COLUMNS > 16 > 60 > > Before the kernel starts I see that bit flashing by which says 1920x... > but even the kernel then stays with LINES=16. > >

Re: New kernel doesn?t recognize ufs gpt root filesystem

On 2025-04-21 11:46, Chris wrote: On 2025-04-21 10:47, Dag-Erling Smørgrav wrote: Chris writes: Can I safely move my new kernel to say, kernel.new while running my current kernel as kernel and rebuild the new kernel with the kernconf corrections? If you're booted into kernel.old yo

Re: New kernel doesn?t recognize ufs gpt root filesystem

On 2025-04-21 10:47, Dag-Erling Smørgrav wrote: Chris writes: Can I safely move my new kernel to say, kernel.new while running my current kernel as kernel and rebuild the new kernel with the kernconf corrections? If you're booted into kernel.old you can just build a new kernel and run

Re: New kernel doesn?t recognize ufs gpt root filesystem

Chris writes: > Can I safely move my new kernel to say, kernel.new while running my current > kernel as kernel and rebuild the new kernel with the kernconf corrections? If you're booted into kernel.old you can just build a new kernel and run `make reinstallkernel` to replace the new (

Re: New kernel doesn?t recognize ufs gpt root filesystem

gt;> >> Warner Losh writes: >> >> > Maybe this is a custom kernel without the label code. >> >> It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But >> >> I'm using the same kernconf as before. Was label removed from generic >>

Re: New kernel doesn?t recognize ufs gpt root filesystem

On 2025-04-21 06:42, Warner Losh wrote: Put 'da' back in. I'm pretty sure it's not optional. Well, maybe it is optional, but you'll need nda if you do that and the kernel config doesn't have that. While you have nvd, the default is to prefer nda to nvd, even when nd

Re: New kernel doesn?t recognize ufs gpt root filesystem

On Mon, Apr 21, 2025 at 10:03 AM Chris wrote: > > On 2025-04-21 00:23, Gary Jennejohn wrote: > > On Sun, 20 Apr 2025 12:19:45 -0700 > > Chris wrote: > > > >> On 2025-04-20 01:15, Dag-Erling Smørgrav wrote: > >> > Chris writes: > >> >>

Re: New kernel doesn?t recognize ufs gpt root filesystem

On 2025-04-21 00:23, Gary Jennejohn wrote: On Sun, 20 Apr 2025 12:19:45 -0700 Chris wrote: On 2025-04-20 01:15, Dag-Erling Smørgrav wrote: > Chris writes: >> Warner Losh writes: >> > Maybe this is a custom kernel without the label code. >> It's an upgrade. It

Re: New kernel doesn?t recognize ufs gpt root filesystem

Put 'da' back in. I'm pretty sure it's not optional. Well, maybe it is optional, but you'll need nda if you do that and the kernel config doesn't have that. While you have nvd, the default is to prefer nda to nvd, even when nda isn't in the kernel (so more like

Re: New kernel doesn?t recognize ufs gpt root filesystem

On Sun, 20 Apr 2025 12:19:45 -0700 Chris wrote: > On 2025-04-20 01:15, Dag-Erling Smørgrav wrote: > > Chris writes: > >> Warner Losh writes: > >> > Maybe this is a custom kernel without the label code. > >> It's an upgrade. It's 15 fr

Re: New kernel doesn’t recognize ufs gpt root filesystem

On 2025-04-20 01:15, Dag-Erling Smørgrav wrote: Chris writes: Warner Losh writes: > Maybe this is a custom kernel without the label code. It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But I'm using the same kernconf as before. Was label removed from gene

Re: New kernel doesn’t recognize ufs gpt root filesystem

Chris writes: > Warner Losh writes: > > Maybe this is a custom kernel without the label code. > It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But > I'm using the same kernconf as before. Was label removed from generic > in the last 11 mos.? P

Re: New kernel doesn’t recognize ufs gpt root filesystem

On 2025-04-19 22:23, Chris wrote: On 2025-04-19 20:36, Warner Losh wrote: On Sat, Apr 19, 2025, 8:51 PM Chris wrote: Finally got a build world/kernel to complete. Following a installkernel with a boot -s resulted in the inability to mount root (/dev/gpt/FBSD15) It’s a ufs2 filesystem. I

Re: New kernel doesn’t recognize ufs gpt root filesystem

On 2025-04-19 20:36, Warner Losh wrote: On Sat, Apr 19, 2025, 8:51 PM Chris wrote: Finally got a build world/kernel to complete. Following a installkernel with a boot -s resulted in the inability to mount root (/dev/gpt/FBSD15) It’s a ufs2 filesystem. I booted the 15-CURRENT usb stick. It

Re: New kernel doesn’t recognize ufs gpt root filesystem

On Sat, Apr 19, 2025, 8:51 PM Chris wrote: > Finally got a build world/kernel to complete. Following a > installkernel with a boot -s resulted in the inability > to mount root (/dev/gpt/FBSD15) > It’s a ufs2 filesystem. I booted the 15-CURRENT > usb stick. It recognized it. I pe

Logged Blank at kernel panic (?) (WAS: Re: Kernel panic on HEAD (93cf4310 2025-03-28))

in /etc/rc.conf: kld_list is commented-out - It seems like the cut off is when the kernel starts working with the 'hms' subsystem (see below) I was able to get the panic output from messages -- but there's no "here's where we failed," AFAICT. Have I gotten all the useful d

Re: Heads-up: Kernel module symbol resolution changing

On Mon, 31 Mar 2025 10:57:45 -0400 Ed Maste wrote: > On Fri, 14 Mar 2025 at 23:03, Tomoaki AOKI wrote: > > > > On Wed, 12 Mar 2025 13:07:58 -0400 > > Ed Maste wrote: > > > > > Our in-kernel module linker currently performs symbol resolution > > > ag

/var/crash/vmcore.* not present (was: Kernel panic on HEAD …)

On 29/03/2025 20:46, Steven Harms (High-Security Mail) wrote: … two questions: 1. Why am I not getting any panic dump artifacts? 2. … geli list or (with the port) lsblk /dev/ada0

Kernel panic on HEAD (93cf4310 2025-03-28)

Hey folks, I tried building current from source and when I boot, I get a panic after the final Autoloading module (pchtherm, in my case) loads. Comparing to the stable 14.2 kernel, the next step is for "Setting up harvesting," "Feeding entropy," and starting wpa_supplicant

Heads-up: Kernel module symbol resolution changing

Our in-kernel module linker currently performs symbol resolution against local symbols from other modules, which is a bug. In commits 95c20faf11a1 and ecd8245e0d77 kib introduced support to have the kernel linker stop resolving local symbols from other files, but did not change it by default to

iwlwifi kernel panics, Wireless 7260, main-n275833-136c5e17b61a (2025-03-07)

p header from device: /dev/ada1p2   Architecture: amd64   Architecture Version: 2   Dump Length: 2706395136   Blocksize: 512   Compression: none   Dumptime: 2025-03-08 02:18:33 +   Hostname: mowa219-gjp4-zbook-freebsd   Magic: FreeBSD Kernel Dump   Version String: FreeBSD 15.0-CURRENT main-n27

Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

en solved with git: 2be8b121bf82 - main - mtw(4) remove misplaced DEBUG_FLAGS > > > > Van: A FreeBSD User > Datum: 7 februari 2025 17:12 > Aan: Ronald Klop > CC: FreeBSD CURRENT > Onderwerp: Re: make installkernel: failure: install: > /usr/lib/d

Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

ng most recent CURRENT, but updated (buildworld/buildkernel) within the past two weeks more often does not show this nasty problem, althoug having the very same setup scheme - except the kernel name is different (hardware quite the same ancient crap, brand, model ...). This drives me nuts ... &g

Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

Am Fri, 7 Feb 2025 16:47:14 +0100 A FreeBSD User schrieb: > Am Fri, 7 Feb 2025 14:45:04 +0100 > A FreeBSD User schrieb: > > > Am Fri, 7 Feb 2025 14:08:24 +0100 (CET) > > Ronald Klop schrieb: > > > > > Does it work if you just do > > > > >

Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory Am Fri, 7 Feb 2025 16:53:30 +0100 (CET) Ronald Klop schrieb: > What is in your /etc/make.conf and /etc/src.conf? > > Regards, > Ronald. Remark: I use on all CURRENT boxes a specia

Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

Am Fri, 7 Feb 2025 16:53:30 +0100 (CET) Ronald Klop schrieb: > What is in your /etc/make.conf and /etc/src.conf? > > Regards, > Ronald. Remark: I use on all CURRENT boxes a special scheme for configuring the kernel/world. The kernel config files are located in /etc/config/amd64

Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

What is in your /etc/make.conf and /etc/src.conf? Regards, Ronald. Van: A FreeBSD User Datum: vrijdag, 7 februari 2025 16:47 Aan: Ronald Klop CC: FreeBSD CURRENT Onderwerp: Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory Am Fri, 7 Feb 2025

Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

Am Fri, 7 Feb 2025 14:45:04 +0100 A FreeBSD User schrieb: > Am Fri, 7 Feb 2025 14:08:24 +0100 (CET) > Ronald Klop schrieb: > > > Does it work if you just do > > > > mkdir -p /usr/lib/debug/boot/kernel/ > > > > and restart the make installkernel? > &

Re: make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

Am Fri, 7 Feb 2025 14:08:24 +0100 (CET) Ronald Klop schrieb: > Does it work if you just do > > mkdir -p /usr/lib/debug/boot/kernel/ > > and restart the make installkernel? > > Regards, > Ronald. Hello Ronald. I already did that, but the newly created directory see

make installkernel: failure: install: /usr/lib/debug/boot/kernel: No such file or directory

Hello, Host is actual running 15.0-CURRENT #40 main-n275030-46a9fb7287f4: Sat Jan 25 07:09:38 CET 2025 amd64 Trying to rebuild (from clean/scratch after "make cleanworld") and install kernel/world. make kernel works fine. make installkernel bails out with: [...] ===> usb/rsufw

kernel RPC over netlink(4) and general krpc cleanup

Hi, last year I tried to check-in a new implementation of unix(4) SOCK_STREAM and SOCK_SEQPACKET in d80a97def9a1, but was forced to back it out due to several kernel side abusers of a unix(4) socket. The most difficult ones are the NFS related RPC services, that act as RPC clients talking to

Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed

On Nov 8, 2024, at 04:49, Michal Meloun wrote: > On 08.11.2024 4:15, Mark Millard wrote: >> [I narrowed the artifact kernel range for the change in the type of >> failure that happens.] >> On Nov 7, 2024, at 17:43, Mark Millard wrote: >>> [The change to LLVM 19

Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed

On 08.11.2024 4:15, Mark Millard wrote: [I narrowed the artifact kernel range for the change in the type of failure that happens.] On Nov 7, 2024, at 17:43, Mark Millard wrote: [The change to LLVM 19 is what leads to the Alignment Fault' on write failure. Details later below.] On

Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed

[I narrowed the artifact kernel range for the change in the type of failure that happens.] On Nov 7, 2024, at 17:43, Mark Millard wrote: > [The change to LLVM 19 is what leads to the Alignment > Fault' on write failure. Details later below.] > > On Nov 7, 2024, at 01:42, Ma

Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed

rom: > > # uname -apKU > FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT > main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 > > Installed packages to be UPGRADED: >FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 [

Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed

UPGRADED: FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 [base] FreeBSD-kernel-generic: 15.snap20241011221604 -> 15.snap20241106134422 [base] FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> 15.snap20241106134422 [base] FreeBSD-kernel-generic-m

Re: Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

> > mailto:matthew.l.dai...@dartmouth.edu>> > > wrote: > > > > Hi all, > > > > I posted messages to the this list back in February and March > > > > (https://lists.freebsd.org/archives/freebsd-current/2024-February/005546.html &g

Re: Is INET6 a required option these days? (kernel build failure)

On 9/29/24 16:24, void wrote: On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote: I personally have been using a customized kernel configuration file for 25 years or more and I have no intention of changing it. Just because INET6 shows up in all the boilerplate config files

Re: Is INET6 a required option these days? (kernel build failure)

On 9/29/24 16:02, Rodney W. Grimes wrote: On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote: ... NOT all things need to be network connected! At great risk of tossing yet another coat of paint onto the bikeshed I must agree that a machine with nothing other than serial conn

Re: Is INET6 a required option these days? (kernel build failure)

> On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote: > > >I personally have been using a customized kernel configuration file for > >25 years or more and I have no intention of changing it. > > > >Just because INET6 shows up in all the boilerplate conf

Re: Is INET6 a required option these days? (kernel build failure)

On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote: I personally have been using a customized kernel configuration file for 25 years or more and I have no intention of changing it. Just because INET6 shows up in all the boilerplate config files doesn't change the fact that INE

Re: Is INET6 a required option these days? (kernel build failure)

m ( OpenBSD ), so we need be > > patient with him ... > > > There may have been intermittent breakage, although I always try to avoid > that, but main currently just works. > > >> > >> I don't have INET6 enabled and have reported a number of problems in th

Re: Is INET6 a required option these days? (kernel build failure)

> On 29 Sep 2024, at 04:46, Zhenlei Huang wrote: > >  > >> On Sep 27, 2024, at 6:07 PM, Gary Jennejohn wrote: >> >>> On Thu, 26 Sep 2024 14:58:40 -0400 >>> Ian FREISLICH wrote: >>> >>> Lately there have been a couple of commits that fail to build because v6 >>> being compiled in despite

Re: Is INET6 a required option these days? (kernel build failure)

> On Sep 27, 2024, at 6:07 PM, Gary Jennejohn wrote: > > On Thu, 26 Sep 2024 14:58:40 -0400 > Ian FREISLICH wrote: > >> Lately there have been a couple of commits that fail to build because v6 >> being compiled in despite INET6 being undefined. I think the latest is >> 905db4aa887758650977

Re: Is INET6 a required option these days? (kernel build failure)

On Thu, 26 Sep 2024 14:58:40 -0400 Ian FREISLICH wrote: > Lately there have been a couple of commits that fail to build because v6 > being compiled in despite INET6 being undefined. I think the latest is > 905db4aa88775865097714c170f4503da385747c. > > /usr/src/sys/netpfil/pf/pf.c:8762:38: error

Is INET6 a required option these days? (kernel build failure)

Lately there have been a couple of commits that fail to build because v6 being compiled in despite INET6 being undefined. I think the latest is 905db4aa88775865097714c170f4503da385747c. /usr/src/sys/netpfil/pf/pf.c:8762:38: error: no member named 'icmp6' in 'union p

Kernel panics with Widevine and htop: VNPASS in sys/kern/vfs_cache.c

he "worker" related context for the type of kernel call seems to be what is at issue, likely no matter what process happens to make the same basic kernel call that ends up with "worker" in the context. === Mark Millard marklmi at yahoo.com Built as shown at <https://github.

RE: Chromium with Widevine: kernel panic: condition vp-> v_type == VDIR || VN_IS_DOOMED(vp) not met ⋯vfs_cache.c:34 52 (vn_fullpath_dir)

type = atomic_load_8(&vp->v_type); but mostly just references to vp->v_type . It leaves me wondering if it is all correct. There are gdb based kernel backtraces at that codeberg.org <http://codeberg.org/> web page that are interesting. Note the hrdl_name and binname being: &qu

Re: Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

hives/freebsd-current/2024-February/005546.html > <https://lists.freebsd.org/archives/freebsd-current/2024-February/005546.html>) > regarding kernel panics we were having with nfs clients doing hdf5 file > operations. After a hiatus in troubleshooting, I had more time thi

Re: Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

ges to the this list back in February and March > ( > https://lists.freebsd.org/archives/freebsd-current/2024-February/005546.html) > > regarding kernel panics we were having with nfs clients doing hdf5 file > operations. After a hiatus in troubleshooting, I had more time this > summ

Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

Hi all, I posted messages to the this list back in February and March (https://lists.freebsd.org/archives/freebsd-current/2024-February/005546.html) regarding kernel panics we were having with nfs clients doing hdf5 file operations. After a hiatus in troubleshooting, I had more time this

Re: CURRENT kernel crash beyond git: 02d15215cef2

On 26/05/2024 13:45, Herbert J. Skuhra wrote: … No, idea why the fix hasn't been committed yet: … A few hours earlier: uma: Fix improper uses of UMA_MD_SMALL_ALLOC · freebsd/freebsd-src@d25ed65 HTH

Re: CURRENT kernel crash beyond git: 02d15215cef2

10:56:09 CEST 2024 amd64. Customized > > kernel. > > > > After that commit, booting the kernel dies silently without any trace/core > > or similar and > > resetting the system. > > > > I tried to enable at least the standard debugging features, but that

Re: CURRENT kernel crash beyond git: 02d15215cef2

On Sun, May 26, 2024 at 02:35:16PM +0200, FreeBSD User wrote: > Hello, > > boxes running CURRENT are last good with FreeBSD 15.0-CURRENT #44 > main-n270400-02d15215cef2: > Sat May 25 10:56:09 CEST 2024 amd64. Customized kernel. > > After that commit, booting the kernel dies

Chromium with Widevine: kernel panic: condition vp->v_type == VDIR || VN_IS_DOOMED(vp) not met ⋯vfs_cache.c:3452 (vn_fullpath_dir)

Reproducible at .

Request for non-GENERIC kernel diff

Hello! Who uses their own kernel config, please share the diff between the 14 and 13.x branches Thanks. -- Vladislav V. Prodan System & Network Administrator support.od.ua

Re: TXT Kernel linking failed on -CURRENT

Konstantin, good day! 25.04.2024 0:09, Konstantin Belousov пишет: On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote: linking kernel ld: error: undefined symbol: ktrcapfail referenced by vfs_lookup.c    vfs_lookup.o:(namei) referenced by vfs_lookup.c

Re: TXT Kernel linking failed on -CURRENT

On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote: > linking kernel > ld: error: undefined symbol: ktrcapfail > >>> referenced by vfs_lookup.c > >>>   vfs_lookup.o:(namei) > >>> referenced by vfs_lookup.c > >>>   

TXT Kernel linking failed on -CURRENT

/usr/src state is:  git log -n 1 commit a0d7d68a2dd818ce84e37e1ff20c8849cda6d853 (HEAD -> main, origin/main, origin/HEAD) Author: Cy Schubert kernel building failed with such messa

Kernel linking error on -CURRENT

Hi, FreeBSD Community! I have a teach with FreeBSD and use -CURRENT on my test machine.And some days ago after- git pull- make buildworld- make buildkernel There is /etc/src.conf and BSDSERV below, what can cause that error?Thanks for help! kernel building failed with such messages

CURRENT 220ee18f1964 memstick kernel panic, MacBookPro8,3

Originally posted to Photograph:

kernel build w/o DDB broken after c21bc6f

When a kernel is built without KDB and DDB, it fails with: --- kernel.full --- linking kernel.full ld: error: undefined symbol: db_ctf_lookup_typename >>> referenced by kern_ctf.c:329 (/usr/src/sys/kern/kern_ctf.c:329) >>> link_elf_obj.o:(link_elf_c

kernel= , kern.module_path= , and loader menu selections: how to have it always find the matching, say, nfsd.ko (same directory as the kernel)

I'm using an aarch64 environment as the example context for this note. I have instances of the various PkgBase kernels and one or more personal kernel builds. Currently: # ls -Tlod /boot/kernel*/nfsd* -r--r--r-- 1 root wheel - 401600 Mar 17 18:45:35 2024 /boot/kernel.CA76-NODBG.good/nfsd.

Re: Kernel build broken without "options KTRACE"

On Wed, Mar 06, 2024 at 10:51:05AM -0700, John Nielsen wrote: > Getting a set but not used warning for “td” in sys/kern/kern_condvar.c when > doing a buildkernel for a config file without “options KTRACE”. I failed to > copy the full error message/line numbers but I will reproduce this evening if

Kernel build broken without "options KTRACE"

Getting a set but not used warning for “td” in sys/kern/kern_condvar.c when doing a buildkernel for a config file without “options KTRACE”. I failed to copy the full error message/line numbers but I will reproduce this evening if needed. JN

Re: Fwd: Re: after commit 5e248c2, kernel module build is broken

graded to gcc13 - since this appears to be the most stringent set of checks, to prevent similar issues in the future. Richard Scheffenegger Am 26.02.2024 um 09:32 schrieb Richard Scheffenegger: Weitergeleitete Nachricht Betreff:Re: after commit 5e248c2, kernel module

Re: after commit 5e248c2, kernel module build is broken

> On Feb 25, 2024, at 11:38 PM, Michael Butler > wrote: > > Building > /usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/machine > machine -> /usr/src/sys/amd64/include > Building > /usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/x86 > x86 -

after commit 5e248c2, kernel module build is broken

Building /usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/machine machine -> /usr/src/sys/amd64/include Building /usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/x86 x86 -> /usr/src/sys/x86/include Building /usr/obj/usr/src/amd64.amd64/sys/VM01

Re: kernel crash in tcp_subr.c:2386

machines. Another symptom of this problem is that the NFS share will appear corrupted. And df -htnfs will sometimes not display the mounted NFS share. If not a kernel page fault, random kernel memory can be overwritten resulting in bizarre behaviour prior. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0

Re: kernel crash in tcp_subr.c:2386

In message <625e0ea4-9413-45ad-b05c-500833a1d...@freebsd.org>, tuexen@freebsd.o rg writes: > > On Feb 12, 2024, at 10:36, Alexander Leidinger = > wrote: > >=20 > > Hi, > >=20 > > I got a coredump with sources from 2024-02-10-144617 (GMT+0100): > Hi Alexander, > > we are aware of this problem, but

Kernel Panic sys/netinet/tcp_subr.c 2386

Hi, I just got a kernel panic on my 15.0-CURRENT machine, with an Assertion in sys/netinet/tcp_subr.c 2386 full log: https://people.freebsd.org/~wosch/tmp/kernel-panic-tcp_subr-line-2386.png OS: 15.0-CURRENT main-3e9515846f (10-Feb-2024, github.com/freebsd/freebsd-src) Should I worry

Re: kernel crash in tcp_subr.c:2386

> On Feb 12, 2024, at 10:36, Alexander Leidinger > wrote: > > Hi, > > I got a coredump with sources from 2024-02-10-144617 (GMT+0100): Hi Alexander, we are aware of this problem, but haven't found a way to reproduce it. Do you know how to reproduce this? Best regards Michael > ---snip--- > __

kernel crash in tcp_subr.c:2386

Hi, I got a coredump with sources from 2024-02-10-144617 (GMT+0100): ---snip--- __curthread () at /space/system/usr_src/sys/amd64/include/pcpu_aux.h:57 57 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /space/system/usr_src/sys/amd64/inc

Re: kernel: fatal trap 12 on CURRENT, when using WireGuard

Am 09.01.24 um 21:40 schrieb Gleb Smirnoff: Rainer, On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote: R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very R> recent commit. The build and install went fine. After booting with new R> base, I got a page faul

Re: kernel: fatal trap 12 on CURRENT, when using WireGuard

Rainer, On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote: R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very R> recent commit. The build and install went fine. After booting with new R> base, I got a page fault with the following error: Sorry for that, my

kernel: fatal trap 12 on CURRENT, when using WireGuard

I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very recent commit. The build and install went fine. After booting with new base, I got a page fault with the following error: Kernel page fault with the following non-sleepable locks held: shared rm netlink lock (netlink

Re: kernel: psm: keyboard controller failed at git revision 3334a537ed38

On Wed, Dec 27, 2023, 2:24 PM Juraj Lutter wrote: > > > On 27 Dec 2023, at 21:44, Ruslan Makhmatkhanov wrote: > > Hello, > > I updated my tree to revision 3334a537ed38, made buildworld and kernel as > usual. > Booting with new kernel leads to keyboard not working a

Re: kernel: psm: keyboard controller failed at git revision 3334a537ed38

On Wed, Dec 27, 2023 at 11:44:37PM +0300, Ruslan Makhmatkhanov wrote: >Hello, >I updated my tree to revision 3334a537ed38, made buildworld and kernel >as usual. > >Booting with new kernel leads to keyboard not working at system login >prompt and the me

Re: kernel: psm: keyboard controller failed at git revision 3334a537ed38

> On 27 Dec 2023, at 21:44, Ruslan Makhmatkhanov wrote: > > Hello, > > I updated my tree to revision 3334a537ed38, made buildworld and kernel as > usual. > Booting with new kernel leads to keyboard not working at system login prompt > and the message "ker

kernel: psm: keyboard controller failed at git revision 3334a537ed38

Hello, I updated my tree to revision 3334a537ed38, made buildworld and kernel as usual.Booting with new kernel leads to keyboard not working at system login prompt and the message "kernel: psm: keyboard controller failed" in /var/log/messages. Reverting to boot the old kernel ma

Re: Problem building kernel

Dec 2023 12:18:55 +0100 > tue...@freebsd.org wrote: > >> Dear all, >> >> I just tried to build world and kernel on a 64-bit PPC system. >> >> make -j 32 buildworld >> >> ran without problems. >> However >> >> make kernel KERNCONF=GE

Re: Problem building kernel

Hi Michael, The GENERIC config is for 32-bit powerpc, GENERIC64 is what you want for 64-bit config. - Justin On Sun, 24 Dec 2023 12:18:55 +0100 tue...@freebsd.org wrote: > Dear all, > > I just tried to build world and kernel on a 64-bit PPC system. > > make -j 32 buildworld &

Re: Problem building kernel

On 24.12.2023 15:47, tue...@freebsd.org wrote: On Dec 24, 2023, at 12:27, Vladimir Kondratyev wrote: On 24.12.2023 14:18, tue...@freebsd.org wrote: Dear all, I just tried to build world and kernel on a 64-bit PPC system. make -j 32 buildworld ran without problems. However make kernel KERNCONF

Re: Problem building kernel

> On Dec 24, 2023, at 12:27, Vladimir Kondratyev wrote: > > On 24.12.2023 14:18, tue...@freebsd.org wrote: >> Dear all, >> I just tried to build world and kernel on a 64-bit PPC system. >> make -j 32 buildworld >> ran without problems. >> However >>

  1   2   3   4   5   6   7   8   9   10   >