Date: Sat, 7 Jun 2025 07:47:39 +0200 From: freebsd-current@dino.sk To: freebsd-current@freebsd.org Subject: Re: UFS bad inode, mangled entry on Alder Lake-N(100) Message-ID: <20250607074739.31a7116b@gema.dino.sk> In-Reply-To: <6024769d-1cac-439b-874d-c624112d30c9@gmail.com> References: <ab27e2fa-d798-47f8-876b-b79a54a36003@gmail.com> <6530f044-486d-4128-9e23-ee03e6686aa9@yamagi.org> <20250128122345.74075269.25648751.10101138@dino.sk> <6024769d-1cac-439b-874d-c624112d30c9@gmail.com>
index | next in thread | previous in thread | raw e-mail
On Tue, 28 Jan 2025 15:33:30 -0500 Ian FREISLICH <ianfreislich@gmail.com> wrote: > On 2025-01-28 06:23, Milan Obuch wrote: [ snip ] > > It looks like the right thing, in my case adding > > vm.pmap.pcid_enabled=0 to /boot/loader.conf helps. I consider this > > easier than installing port for microcode update... > > > > That being said, could someone add some more pro/cons for those two > > approaches? > > > > Additionally, I am using M.2 SATA drive at the moment. While NVMe > > drive worked to some extent, if fsck was necessary for some reason, > > it was unpleasant - some 'waiting for nvme reset' event occured, > > this led to nvme drive detach, and the only way to fix it was > > unscrew the drive, put it in USB-NVMe converter, do fsck via USB > > drive, then mount it back into box... not acceptable. > > I chose microcode but that was hard to do because I only have one > nvme slot and the installer panicked trying to install the package at > the final part of the install. I had to install onto an SD and then > use another FreeBSD install to do a pkg chroot install onto that > temporary media and then use that to boot with the firmware update > and chroot install the firmware and edit loader.conf on the nvme. > > The microcode update fixed it for me. I inferred from reading that > enable PCID might have a performance advantage. > Well, I run with microcode update and NVMe on my Alder Lake box with no problem. Yesterday, however, the symptoms were back - bad inode error for filesystem, fsck necessary. Probably some data loss... (not a big problem, this was still device under test, and I can easily get the somewhat important things from drive) What may be relevant is it happened after system upgrade to more recent 14.3-STABLE from some a bit older 14.3-PRERELEASE, but I think microcode update binary is OS independent, or is there some dependency? I am going to try reinstall with disabled PCID and test it again. Regards, Milanhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250607074739.31a7116b>