Date: Tue, 10 Jun 2025 10:20:19 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: garyj@gmx.de Cc: fs@FreeBSD.org, =?UTF-8?Q?Gerrit_K=C3=BChn?= <gerrit.kuehn@aei.mpg.de> Subject: Re: UFS bad magic number kernel panic on Asus PN43 Message-ID: <1690030283.3031.1749543619043@localhost> In-Reply-To: <20250609184419.3991a27e@ernst.home> References: <20250609125231.5a0bec52@luna> <20250609184419.3991a27e@ernst.home>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Van: Gary Jennejohn <garyj@gmx.de> Datum:maandag, 9 juni 2025 18:44 Aan:"Gerrit Kühn" <gerrit.kuehn@aei.mpg.de> CC:fs@FreeBSD.org Onderwerp:Re: UFS bad magic number kernel panic on Asus PN43 > > On Mon, 9 Jun 2025 12:52:31 +0200 > Gerrit Kühn <gerrit.kuehn@aei.mpg.de> wrote: > > > Hello, > > > > I am not sure if this is an actual filesystem issue, but right now it > > looks like one to me (maybe related to some unknown hardware issue, > > though), so I will try here first. > > I have a newly installed system (14.2) on a newly bought Asus PN43 > > hardware (Intel Alder Lake, N200) using a Samsung SSD 990 EVO 1TB for > > root fs. The settings are pretty much default from the installer, i.e., > > UFS root, softupdates and soft updates journaling were enabled. > > > > The system installed and booted just fine, but when trying to bootstrap > > pkg it panicked like this: > > > > --- > > UFS /dev/nda0p2 (/) cg 809: bad magic number 0x0 should be 0x90255 > > panic: softdep_deallocate_dependencies: dangling deps > > cpuid = 0 > > time = 1749395925 > > KDB: stack backtrace: > > #0 0xffffffff80b8b89d at kdb_backtrace+0x5d > > #1 0xffffffff80b3dc01 at vpanic+0x131 > > #2 0xffffffff80b3dac3 at panic+0x43 > > #3 0xffffffff80e7018a at softdep_deallocate_dependencies+0x6a > > #4 0xffffffff80bff707 at brelse+0x197 > > #5 0xffffffff80e60d8f at ffs_getcg+0x28f > > #6 0xffffffff80e5ed6f at ffs_nodealloccg+0xbf > > #7 0xffffffff80e5e7b3 at ffs_valloc+0x4b3 > > #8 0xffffffff80ea5ab7 at ufs_mkdir+0x107 > > #9 0xffffffff810ec378 at VOP_MKDIR_APV+0x28 > > #10 0xffffffff80c383b6 at kern_mkdirat+0x286 > > #11 0xffffffff810262c5 at amd64_syscall+0x115 > > #12 0xffffffff80ffccab at fast_syscall_common+0xf8 > > Uptime: 2m18s > > --- > > > > This was reproducable. After a few unsuccessful tries I decided to boot > > into single user mode, disabled soft updates journaling, did a manual > > fsck (reported all issues fixed afterwards), and rebooted once more. > > This brought the system into a basically usable state: > > I could bootstrap pkg now and install other software without much of an > > issue. > > However, I still see (rare) messages like this in dmesg, especially when > > doing a lot of disc writes (I think): > > > > --- > > /: bad dir ino 53285122 at offset 0: mangled entry > > /: bad dir ino 104647168 at offset 0: mangled entry > > --- > > > > I see no other hardware-related problems so far, "smartctl -l selftest > > /dev/nvme0" completed without any error. > > There are a few acpi error messages during boot, though (don't know if > > they are related): > > > > --- > > ACPI Error: AE_NOT_FOUND, During name lookup/catalog > > (20221020/psobject-372) > > Firmware Error (ACPI): Could not resolve symbol > > [\134_SB.PC00.TXHC.RHUB.SS02], AE_NOT_FOUND (20221020/dswload2-315) > > ACPI Error: AE_NOT_FOUND, During name lookup/catalog > > (20221020/psobject-372) > > --- > > > > > > Any idea what is causing the UFS issues (and how to fix them > > properly?). > > > > I have a laptop with an Intel Alder Lake-M and I was also seeing errors > with my UFS file system when lots of files were being installed. > > Adding vm.pmap.pcid_enabled=0 to /boot/loader.conf fixed it for me. > > So you could try adding it to your loader.conf. > > -- > Gary Jennejohn > > > > If I remember correctly other reports also mentioned that updating the CPU firmware/microcode using the pkg cpu-microcode resolves this issue. See for example: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261169 Regards, Ronald. [-- Attachment #2 --] <html><head></head><body><br> <p><strong>Van:</strong> Gary Jennejohn <garyj@gmx.de><br> <strong>Datum:</strong>maandag, 9 juni 2025 18:44<br> <strong>Aan:</strong>"Gerrit Kühn" <gerrit.kuehn@aei.mpg.de><br> <strong>CC:</strong>fs@FreeBSD.org<br> <strong>Onderwerp:</strong>Re: UFS bad magic number kernel panic on Asus PN43</p> <blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left: #000000 2px solid; margin-right: 0px"> <div class="MessageRFC822Viewer" id="P"> <div class="TextPlainViewer" id="P.P">On Mon, 9 Jun 2025 12:52:31 +0200<br> Gerrit Kühn <gerrit.kuehn@aei.mpg.de> wrote:<br> <br> > Hello,<br> ><br> > I am not sure if this is an actual filesystem issue, but right now it<br> > looks like one to me (maybe related to some unknown hardware issue,<br> > though), so I will try here first.<br> > I have a newly installed system (14.2) on a newly bought Asus PN43<br> > hardware (Intel Alder Lake, N200) using a Samsung SSD 990 EVO 1TB for<br> > root fs. The settings are pretty much default from the installer, i.e.,<br> > UFS root, softupdates and soft updates journaling were enabled.<br> ><br> > The system installed and booted just fine, but when trying to bootstrap<br> > pkg it panicked like this:<br> ><br> > ---<br> > UFS /dev/nda0p2 (/) cg 809: bad magic number 0x0 should be 0x90255<br> > panic: softdep_deallocate_dependencies: dangling deps<br> > cpuid = 0<br> > time = 1749395925<br> > KDB: stack backtrace:<br> > #0 0xffffffff80b8b89d at kdb_backtrace+0x5d<br> > #1 0xffffffff80b3dc01 at vpanic+0x131<br> > #2 0xffffffff80b3dac3 at panic+0x43<br> > #3 0xffffffff80e7018a at softdep_deallocate_dependencies+0x6a<br> > #4 0xffffffff80bff707 at brelse+0x197<br> > #5 0xffffffff80e60d8f at ffs_getcg+0x28f<br> > #6 0xffffffff80e5ed6f at ffs_nodealloccg+0xbf<br> > #7 0xffffffff80e5e7b3 at ffs_valloc+0x4b3<br> > #8 0xffffffff80ea5ab7 at ufs_mkdir+0x107<br> > #9 0xffffffff810ec378 at VOP_MKDIR_APV+0x28<br> > #10 0xffffffff80c383b6 at kern_mkdirat+0x286<br> > #11 0xffffffff810262c5 at amd64_syscall+0x115<br> > #12 0xffffffff80ffccab at fast_syscall_common+0xf8<br> > Uptime: 2m18s<br> > ---<br> ><br> > This was reproducable. After a few unsuccessful tries I decided to boot<br> > into single user mode, disabled soft updates journaling, did a manual<br> > fsck (reported all issues fixed afterwards), and rebooted once more.<br> > This brought the system into a basically usable state:<br> > I could bootstrap pkg now and install other software without much of an<br> > issue.<br> > However, I still see (rare) messages like this in dmesg, especially when<br> > doing a lot of disc writes (I think):<br> ><br> > ---<br> > /: bad dir ino 53285122 at offset 0: mangled entry<br> > /: bad dir ino 104647168 at offset 0: mangled entry<br> > ---<br> ><br> > I see no other hardware-related problems so far, "smartctl -l selftest<br> > /dev/nvme0" completed without any error.<br> > There are a few acpi error messages during boot, though (don't know if<br> > they are related):<br> ><br> > ---<br> > ACPI Error: AE_NOT_FOUND, During name lookup/catalog<br> > (20221020/psobject-372)<br> > Firmware Error (ACPI): Could not resolve symbol<br> > [\134_SB.PC00.TXHC.RHUB.SS02], AE_NOT_FOUND (20221020/dswload2-315)<br> > ACPI Error: AE_NOT_FOUND, During name lookup/catalog<br> > (20221020/psobject-372)<br> > ---<br> ><br> ><br> > Any idea what is causing the UFS issues (and how to fix them<br> > properly?).<br> ><br> <br> I have a laptop with an Intel Alder Lake-M and I was also seeing errors<br> with my UFS file system when lots of files were being installed.<br> <br> Adding vm.pmap.pcid_enabled=0 to /boot/loader.conf fixed it for me.<br> <br> So you could try adding it to your loader.conf.<br> <br> -- <br> Gary Jennejohn<br> </div> <hr></div> </blockquote> <br> <br> If I remember correctly other reports also mentioned that updating the CPU firmware/microcode using the pkg cpu-microcode resolves this issue.<br> See for example: <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261169">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261169</a><br>; <br> Regards,<br> Ronald.<br> </body></html>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1690030283.3031.1749543619043>