On Tue, 28 Jan 2025 15:33:30 -0500 Ian FREISLICH <ianfreisl...@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, Milan
