From nobody Sat Jun 7 05:47:39 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 4bDnJv2zSDz5x8bf for ; Sat, 07 Jun 2025 05:47:43 +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 4bDnJt0QCmz3GMg for ; Sat, 07 Jun 2025 05:47:41 +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 gema.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 00000000007A76A1.000000006843D27C.00008C18; Sat, 07 Jun 2025 07:47:40 +0200 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: <6530f044-486d-4128-9e23-ee03e6686aa9@yamagi.org> <20250128122345.74075269.25648751.10101138@dino.sk> <6024769d-1cac-439b-874d-c624112d30c9@gmail.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.49; amd64-portbld-freebsd14.2) 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 [0.15 / 15.00]; NEURAL_SPAM_LONG(0.99)[0.994]; NEURAL_HAM_SHORT(-0.95)[-0.946]; NEURAL_SPAM_MEDIUM(0.40)[0.402]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCPT_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4bDnJt0QCmz3GMg X-Spamd-Bar: / On Tue, 28 Jan 2025 15:33:30 -0500 Ian FREISLICH 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