Re: UFS bad inode, mangled entry on Alder Lake-N(100)

On Mon, 27 Jan 2025 19:28:28 +0100
Yamagi <lists@yamagi.org> wrote:

> Hi,
> 
> sounds like the Alder Lakes PCID bug in N100 flavor. On the small
> cores the INVLPG instruction is broken, failing to flush all
> (global?) TLP entries leading to cache corruption. FreeBSD has a work
> around for
> that: https://cgit.freebsd.org/src/commit/?id=cde70e312c3fde5b37a29be1dacb7fde9a45b94a
> 
> However that work around never fully solved the problem on the N100 
> series. My own N100 board was never stable with PCID enabled and
> there are several other reports of the same problems. For example 
> https://lists.freebsd.org/archives/freebsd-current/2023-August/004116.html
> 
> Since Linux went with disabling PCID all together on all Alder Lake
> and Raptor LAKE CPUs, I did the same by setting
> vm.pmap.pcid_enabled=0 in loader.conf. Since I did that the system is
> running fine.
> 
> The Linux commit  disabling PCID is here: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae8373a5add4ea39f032563cf12a02946d1e3546
> 
> A microcode update might also help. I didn't test the updates
> released by Intel since early last year so I don't know for sure.
>

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.

Regards,
Milan