Date: Tue, 28 Jan 2025 12:23:45 +0100 From: Milan Obuch <freebsd-current@dino.sk> To: freebsd-current@freebsd.org Subject: Re: UFS bad inode, mangled entry on Alder Lake-N(100) Message-ID: <20250128122345.74075269.25648751.10101138@dino.sk> In-Reply-To: <6530f044-486d-4128-9e23-ee03e6686aa9@yamagi.org> References: <ab27e2fa-d798-47f8-876b-b79a54a36003@gmail.com> <6530f044-486d-4128-9e23-ee03e6686aa9@yamagi.org>
index | next in thread | previous in thread | raw e-mail
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, Milanhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250128122345.74075269.25648751.10101138>