From nobody Thu Feb 24 01:23:51 2022 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 EC83C19D5A35 for ; Thu, 24 Feb 2022 01:24:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4K3wDd58jSz3jSk; Thu, 24 Feb 2022 01:24:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 21O1NvRi043884 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 24 Feb 2022 03:24:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 21O1Np0Y043881; Thu, 24 Feb 2022 03:23:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Feb 2022 03:23:51 +0200 From: Konstantin Belousov To: Alexander Motin Cc: Mike Karels , Tomoaki AOKI , "Chen, Alvin W" , freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: References: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <06768ef6-c88e-b6c7-0db3-f61eb4230937@FreeBSD.org> <470db559-7e7d-1af7-5983-2858814329d2@FreeBSD.org> 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-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4K3wDd58jSz3jSk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-0.31 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.23)[-0.228]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.917]; NEURAL_SPAM_LONG(0.84)[0.837]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 23, 2022 at 12:25:24PM -0500, Alexander Motin wrote: > On 22.02.2022 19:00, Konstantin Belousov wrote: > > On Tue, Feb 22, 2022 at 06:53:09PM -0500, Alexander Motin wrote: > > > On 22.02.2022 18:41, Konstantin Belousov wrote: > > > > On Tue, Feb 22, 2022 at 06:38:24PM -0500, Alexander Motin wrote: > > > > > On 22.02.2022 18:30, Konstantin Belousov wrote: > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > > > > Do you mean it to be a workaround for TrueNAS 12, or it should provide some > > > > > information? The system is at the office and has no IPMI, so I can't switch > > > > > the boot device from home right now. > > > > I intended to see if it is the cause or related feature. > > > > > > I'll try that on the 12 tomorrow, if applicable. > > > > Yes should be relevant still. > > It did the trick. I repeated several times successful boots with the pcid > disabled, and failed ones with default enabled. In attachment you may find > verbose serial console output captures with pcid disabled and enabled, > though without the cpuinfo patch. During the testing I had only one P and > one E cores enabled to reduce noise. Only after that I found P core having > SMT enabled, but I then repeated without SMT also, so it is indeed > irrelevant. > > I'm curios, what in pcid could differentiate the P and E cores, and have it > got fixed in latest stable/13, or I am just "unlucky" to not reproduce it > there? I am curious as well. PCID works on both big Intel cores, and on small cores like Apollo Lake etc. So the fact that it does not properly interact in P/E settings either mean that there is something I did not accounted for from the spec, or there is a bug in silicon. I have no idea why do we work on stable/13 and HEAD. There were enough changes to PCID code there, but it was mostly restructuring and polishing. So the only way to get more understanding is to bisect to see which commit on HEAD fixed the boot.