Date: Mon, 7 Mar 2022 07:57:32 +0000 From: "Chen, Alvin W" <Weike.Chen@Dell.com> To: Konstantin Belousov <kostikbel@gmail.com>, Alexander Motin <mav@freebsd.org> Cc: Mike Karels <mike@karels.net>, Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, "freebsd-current@freebsd.org" <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: <PH0PR19MB493846209E7E0F7598E395E69E089@PH0PR19MB4938.namprd19.prod.outlook.com> In-Reply-To: <YhbeJ%2B5KvGt9sr9U@kib.kiev.ua> References: <YhE1rWoA%2BhMfebq/@kib.kiev.ua> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <YhVnsB5ZwLYmpAFP@kib.kiev.ua> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <YhVyFIFA5XnbGHej@kib.kiev.ua> <06768ef6-c88e-b6c7-0db3-f61eb4230937@FreeBSD.org> <YhV0waCqFLfBy8s7@kib.kiev.ua> <470db559-7e7d-1af7-5983-2858814329d2@FreeBSD.org> <YhV5LOCJMuumTJZw@kib.kiev.ua> <bd125a09-3b72-92dd-fcb1-466a9a81fe43@FreeBSD.org> <YhbeJ%2B5KvGt9sr9U@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi guys, Any progresses for this issue? Regards, Alvin Chen Dell | Comercial Client Group office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506 weike_chen@d= ell.com Internal Use - Confidential -----Original Message----- From: Konstantin Belousov <kostikbel@gmail.com>=20 Sent: 2022=1B$BG/=1B(B2=1B$B7n=1B(B24=1B$BF|=1B(B 9:24 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 c= ause data corrupt due to P-Core&E-Core [EXTERNAL EMAIL]=20 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_enabl= ed=3D0. > > > > >=20 > > > > > Do you mean it to be a workaround for TrueNAS 12, or it should=20 > > > > > provide some information? The system is at the office and has=20 > > > > > 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. > > >=20 > > > I'll try that on the 12 tomorrow, if applicable. > >=20 > > Yes should be relevant still. >=20 > It did the trick. I repeated several times successful boots with the=20 > pcid disabled, and failed ones with default enabled. In attachment=20 > you may find verbose serial console output captures with pcid disabled=20 > and enabled, though without the cpuinfo patch. During the testing I=20 > had only one P and one E cores enabled to reduce noise. Only after=20 > that I found P core having SMT enabled, but I then repeated without=20 > SMT also, so it is indeed irrelevant. >=20 > I'm curios, what in pcid could differentiate the P and E cores, and=20 > have it got fixed in latest stable/13, or I am just "unlucky" to not=20 > reproduce it there? I am curious as well. PCID works on both big Intel cores, and on small cor= es 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 f= rom 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 cha= nges 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <PH0PR19MB493846209E7E0F7598E395E69E089>