From nobody Mon Sep 18 15:38:01 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 4Rq8831tkHz4tN14 for ; Mon, 18 Sep 2023 15:38:11 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (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 4Rq8815cwkz3KLS for ; Mon, 18 Sep 2023 15:38:09 +0000 (UTC) (envelope-from imb@protected-networks.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=JGUhaLvE; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net; dmarc=pass (policy=reject) header.from=protected-networks.net 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:content-language:references:from:from :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1695051481; bh=svRmjjWaTwNO+bbrXRBg4cS+F6qGDkhODr98 qAVPkkg=; b=JGUhaLvEJKQbVXGjTH2DOGbo0kQf+3QB0pEfl43V/2fT9/Xvbkxx OqQbgadl8LsUTk/bcJD0jT9U4ooxvxmnWw9v0BbXZVlPfQDV5fM/mfg5KDkGI2o5 G//o4ofBqfT2p11RsNchJLt4ODhStAuqHmdA7wvIP341ptM1wQR3/i4= 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 B5AFE72E60 for ; Mon, 18 Sep 2023 11:38:01 -0400 (EDT) Message-ID: <946c1f29-dd2a-776d-e88d-7523c103b221@protected-networks.net> Date: Mon, 18 Sep 2023 11:38:01 -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 From: Michael Butler To: 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> Content-Language: en-NZ In-Reply-To: <4f0fbb44-eebe-aa8f-f958-dcd678936fe1@protected-networks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4Rq8815cwkz3KLS On 8/8/23 13:50, Michael Butler wrote: > On 8/8/23 10:56, Tomoaki AOKI wrote: >> On Tue, 8 Aug 2023 17:02:32 +0300 >> Konstantin Belousov wrote: > >  [ .. snip .. ] > >>> The workaround is switched on automatically, when kernel detects >>> 'small cores' >>> reported by CPUID. >> >> If I read the code correctly, vm.pmap.pcid_invlpg_workaround >> (precicely, the corresponding variable) is set to non-zero when the >> workaround is enabled. Not sure it was detected correctly at the >> original reporter's environment, but forcibly setting the tunable to 1 >> didn't reported to help sufficiently. >> Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help. > > I'm seeing similar stability problems on an N95-based device. This too > is an Alderlake-N device with only E-cores although I'm running it with > a compilation with CPUTYPE=tremont .. from an older, verbose start-up .. > > PPIM 0: PA=0x4000000000, VA=0xffffffff82710000, size=0x1d5000, mode=0x1 > pmap: large map 8 PML4 slots (4096 GB) > VT(efifb): resolution 800x600 > Preloaded elf kernel "/boot/kernel.new/kernel" at 0xffffffff8234e000. > Preloaded boot_entropy_cache "/boot/entropy" at 0xffffffff82357d08. > Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at > 0xffffffff82357d60. > Preloaded hostuuid "/etc/hostid" at 0xffffffff82357dc0. > Preloaded TSLOG data "TSLOG" at 0xffffffff82357e10. > CPU: Intel(R) N95 (1689.60-MHz K8-class CPU) >   Origin="GenuineIntel"  Id=0xb06e0  Family=0x6  Model=0xbe  Stepping=0 > > Features=0xbfebfbff > > Features2=0x7ffafbbf >   AMD Features=0x2c100800 >   AMD Features2=0x121 >   Structured Extended > Features=0x239ca7eb >   Structured Extended > Features2=0x98c007bc >   Structured Extended > Features3=0xfc184410 >   XSAVE Features=0xf >   IA32_ARCH_CAPS=0x180fd6b >   VT-x: Basic Features=0x3da0500 >         Pin-Based Controls=0xff >         Primary Processor > Controls=0xfffbfffe >         Secondary Processor > Controls=0x75d7fff >         Exit Controls=0x3da0500 >         Entry Controls=0x3da0500 >         EPT Features=0x6f34141 >         VPID Features=0xf01 >   TSC: P-state invariant, performance statistics > 64-Byte prefetching > L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > real memory  = 17179869184 (16384 MB) > Physical memory chunk(s): > 0x0000000000010000 - 0x000000000009dfff, 581632 bytes (142 pages) > 0x000000000009f000 - 0x000000000009ffff, 4096 bytes (1 pages) > 0x0000000000100000 - 0x000000005fffffff, 1609564160 bytes (392960 pages) > 0x0000000062401000 - 0x000000007264dfff, 270848000 bytes (66125 pages) > 0x0000000075fff000 - 0x0000000075ffffff, 4096 bytes (1 pages) > 0x0000000100001000 - 0x0000000462497fff, 14533881856 bytes (3548311 pages) > 0x000000047fa00000 - 0x000000047fb68fff, 1478656 bytes (361 pages) > 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. > On start-up, vm.pmap.pcid_invlpg_workaround=1 but seemingly random > faults still occurred under load, for example, 'make buildworld'. > Apparent misreads of source-files resulting in syntax errors were the > most common symptom. Compilation reattempts (mostly) succeed. > > Initially, I put this down to an inadequate power-supply but setting > vm.pmap.pcid_enabled=0 seems to have stabilised it. > > I guess there's another dragon in there .. :-( > >     Michael