From nobody Mon Sep 18 21:13:20 2023 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 4RqHZx1tDrz4tm6G for ; Mon, 18 Sep 2023 21:13:29 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RqHZw61ghz4TL8 for ; Mon, 18 Sep 2023 21:13:28 +0000 (UTC) (envelope-from imb@protected-networks.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:content-language:references :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1695071600; bh=Hhzq5iGdnSeH3/G+D+S9qh3GAsNopVPfJ8jG xM7S1/I=; b=T+CM7iYCKYvbwzuWZkW01r3ANs7yIe+EHu5Tj/+TJhMl5R1OQwjw 2zh7E/R0UTOwRl9PKlgs+hvCgMLrYB6eBi0t3BSk1m1aAzryzQ+gRhtzVRlPMUTp 1B1/93d9CJh0tw0rVRcAzm2f2wr0F8juyGooOc68lls/AQiandT2zzU= Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id E5EA73D0C4; Mon, 18 Sep 2023 17:13:20 -0400 (EDT) Message-ID: <31fa46dc-3de3-0bc6-f675-92d2be35eccd@protected-networks.net> Date: Mon, 18 Sep 2023 17:13:20 -0400 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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core To: Mike Karels Cc: freebsd-current@freebsd.org References: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> <20230808063735.e8e1d3ede370a18f200a6f48@dec.sakura.ne.jp> <20230808224612.c3889d6e20b6fc980f5278cc@dec.sakura.ne.jp> <20230808235635.744e0e1c6a72face7fdf6a9b@dec.sakura.ne.jp> <4f0fbb44-eebe-aa8f-f958-dcd678936fe1@protected-networks.net> <946c1f29-dd2a-776d-e88d-7523c103b221@protected-networks.net> <77F5DC92-726E-4F26-ACEA-0AF92E0AF5D2@karels.net> Content-Language: en-NZ From: Michael Butler In-Reply-To: <77F5DC92-726E-4F26-ACEA-0AF92E0AF5D2@karels.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4RqHZw61ghz4TL8 On 9/18/23 14:27, Mike Karels wrote: [ .. snip .. ] >>> avail memory = 16363008000 (15604 MB) >>> CPU microcode: updated from 0xc to 0x10 >> >> With the most recent microcode update, this device reports .. >> >> CPU microcode: updated from 0xc to 0x11 >> >> .. and is now stable with vm.pmap.pcid_enabled=0, vm.pmap.pcid_invlpg_workaround=1, and CPUTYPE?=alderlake set in /etc/make.conf over multiple full system builds. >> >> I have not tested with vm.pmap.pcid_invlpg_workaround=0. .. sorry that was a typo .. I'm actually using .. vm.pmap.pcid_invlpg_workaround: 1 vm.pmap.invpcid_works: 1 vm.pmap.pcid_enabled: 1 > I believe that vm.pmap.pcid_invlpg_workaround does not matter if > vm.pmap.pcid_enabled=0. Enabling the workaround or disabling pcid should > be basically the same for this CPU, so I don't understand why that isn't > true. It might be interesting to test with pcid enabled with the new > microcode, although I don't see why that would affect the results (pcid > should still not be used on any CPU). > > The CPUTYPE for the compiler should not affect the pcid vm issues, just > change the optimization by the compiler. Agreed. However, I was previously using CPUTYPE?=tremont so I just wanted to note that two things had changed in my testing, microcode and CPUTYPE, not just one, Michael