From nobody Mon Jan 27 18:28:28 2025 X-Original-To: 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 4YhcPf1mj8z5m492 for ; Mon, 27 Jan 2025 18:28:54 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YhcPd6lQVz3tbY for ; Mon, 27 Jan 2025 18:28:53 +0000 (UTC) (envelope-from lists@yamagi.org) Authentication-Results: mx1.freebsd.org; none Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1tcTqs-000dhr-KX for current@freebsd.org; Mon, 27 Jan 2025 19:28:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=yamagi.org; s=selector1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID; bh=y/jiLk00OhoxIhgC4vlyGYPS+Ssc5kJxL4o30uCFUys=; b=Qorf9HH3UZn1KbK5mwFn+T3u3A wFT0lNghWvUVYwcS2gvybODr287Qhqn9a/U0/dsYA9m/O6HNII2CvRi9njI8lvoIIO8Jjn9G1Rd6e LDaHnpRwUukOKKvlUwQI2QCtgyig7eLa34nw3IsLG/fV/HH1R3dgA9/IO4QuFhLx8sLX1Xb2zBKAJ nGYx86y2nE+XorHmOZiO/Kg8kA6rkx5cYZAndrmAL70r+zm+nBLoAFahB6u6hvLzp0z22ys0SZD1x zEDa5SuuP2HevvnZ4DCxYnW1K87CIHszIFePq4Y/oFZcT6mhg6S3c4llcki/mh2mTpUdbIL0fXjt4 tZh3r3LA==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1tcTqs-0001cx-43; Mon, 27 Jan 2025 19:28:50 +0100 Received: by submission03.runbox with esmtpsa [Authenticated ID (1103314)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1tcTqX-00CzUI-Qg; Mon, 27 Jan 2025 19:28:29 +0100 Message-ID: <6530f044-486d-4128-9e23-ee03e6686aa9@yamagi.org> Date: Mon, 27 Jan 2025 19:28:28 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: UFS bad inode, mangled entry on Alder Lake-N(100) To: Ian FREISLICH , FreeBSD Current References: Content-Language: de-DE From: Yamagi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YhcPd6lQVz3tbY X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO] 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. Regards, Yamagi Am 27.01.25 um 18:10 schrieb Ian FREISLICH: > I recently bought one of those mini-pc firewall devices (Topton 12th gen > N100 with 4x I226-V, 2x X520) and couldn't get it to install pkg or > buildkernel without getting a slew of these messages, inode number > changing and a panic shortly thereafter. > > kernel: /: bad dir ino 4567815 at offset 0: mangled entry > > I tried the FreeBSD-15.0-CURRENT-amd64-20250124 snapshot and 14.2- > RELEASE, both with and without journal, trim and softupdates in every > permitted permutation without success. The system has an NVME, but I > experience the same problem with the install on a microsd and different > known good NVME drive. Each time I had to reinstall because the > filesystem was so corrupted it wouldn't boot after a fsck. > > The system is now running fine with ZFS so I'm wondering if it's > silently corrupting the ZFS or if there's a bug in UFS2 that's tickled > by this CPU. I'll provide any debugging required. > > Ian -- Homepage: https://www.yamagi.org Github: https://github.com/yamagi GPG: 0xeb1472e71d502515 -- Homepage: https://www.yamagi.org Github: https://github.com/yamagi GPG: 0xeb1472e71d502515