From nobody Tue Jan 28 11:23:45 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yj2wk486nz5mTmp for ; Tue, 28 Jan 2025 11:23:50 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yj2wj23jfz3wrc for ; Tue, 28 Jan 2025 11:23:49 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd-current@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-current@dino.sk; dmarc=none Received: from dino.sk ([84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by cm0.netlabit.sk with ESMTPSA id 00000000022366B6.000000006798BE42.00002001; Tue, 28 Jan 2025 12:23:46 +0100 Date: Tue, 28 Jan 2025 12:23:45 +0100 From: Milan Obuch 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: <6530f044-486d-4128-9e23-ee03e6686aa9@yamagi.org> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.3) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4Yj2wj23jfz3wrc On Mon, 27 Jan 2025 19:28:28 +0100 Yamagi 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