Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Feb 2022 12:14:16 -0500
From:      Alexander Motin <mav@FreeBSD.org>
To:        Mike Karels <mike@karels.net>, Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Cc:        "Chen, Alvin W" <Weike.Chen@Dell.com>, 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:  <bc01426a-9750-a161-0bfa-e1acd5299f81@FreeBSD.org>
In-Reply-To: <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net>
References:  <PH0PR19MB4938FC8E343F7AA23F66C7439E349@PH0PR19MB4938.namprd19.prod.outlook.com> <PH0PR19MB4938BC329E905FA3BFC93EBB9E359@PH0PR19MB4938.namprd19.prod.outlook.com> <PH0PR19MB49388A4BC14B16FCEA5F742D9E359@PH0PR19MB4938.namprd19.prod.outlook.com> <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 19.02.2022 12:02, Mike Karels wrote:
> On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote:
>> Just a thought, but can it be the reason with timing (e.g., rendezvous
>> within (i)threads, hardware controlls without using hardware timer)
>> problem?
>>
>> On FreeBSD, IIUC, multi processor (multi core) implementation assumes
>> SMP (differs only clock speed) and end up with difference of
>> performance at same clock speed within P-core and E-core, possibly.
> 
> Another possibility is that the system is confused by having hyperthreading
> on the P cores but not the E cores.

No, I've tried to disable SMT and different number of cores to make it 
look identical and uniform for the scheduler.  The only thing I could 
not test is disabling all P cores to test only E, the motherboard does 
not allow that, requiring at least one P core enabled.

>> BTW, how aarch64 guys implement big.Little support to avoid such a case?
>> Or are they simply disable all Little cores and use big only?
> 
> Are there supported arm64 systems with asymmetric processors yet?
> 
> 		Mike
> 
>> On Fri, 18 Feb 2022 15:36:27 -0500
>> Alexander Motin <mav@FreeBSD.org> wrote:
>>
>>> This looks pretty weird to me, but I don't think it is specific to the
>>> FAT32.  Just today I've first noticed that booting TrueNAS 12.0-U8
>>> (http://download.freenas.org/12.0/STABLE/U8/x64/TrueNAS-12.0-U8.iso)
>>> (based on FreeBSD 12.2 with many backports) from NVMe SSD (I don't
>>> insist on NVMe so far) and ZFS almost never completes successfully,
>>> ending up in hangs or random stack corruption panics in ZFS threads as
>>> soon as at least one E core is enabled of my i7-12700K.  Disabling all E
>>> cores fixes the problem.  Updated to TrueNAS 13.0-BETA1 (based on
>>> FreeBSD 13.0-STABLE from few weeks ago) it does not demonstrate the
>>> problem any more.  The same TrueNAS 12.0-U8 kernel booted from NFS does
>>> not seem to demonstrate the problem with ZFS mounting, but I haven't
>>> stressed it much so far.
>>>
>>> There are seem to be dragons somewhere...
>>>
>>> On 15.02.2022 22:29, Chen, Alvin W wrote:
>>>> Hi Guys,
>>>> Any updates to support Intel P-core + E-core?
>>>> I have filed a bug: PR 261169
>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261169>; , but no updates.
>>>> Does anybody know the progress?
>>>>
>>>> For Intel Adler Lake P core + E core processor (i7-12700T), copying
>>>> files to FAT32 partition, the file corrupted (50%), but ZFS is fine.
>>>> After disabling E core in the code by restrict the max cpu number, this
>>>> issue is gone. And No E core processor has no such issue, like i7-12400.
>>>>
>>>> HW ENV:
>>>> CPU: Intel AlderLake 12th Gen i7-12700T
>>>> Disk: NVME SSD
>>>>
>>>> There are 3 methods to reproduce this issue:
>>>> 1. Make FreeBSD 13 USB disk installer, install FreeBSD with UFS, and
>>>> select install source and ports, the txz package checking will be failed.
>>>>
>>>> 2. Boot to shell by USB disk installer, and mount a FAT32 partition (on
>>>> SSD), and copy a 300MB file to the FAT32, compare the sha256 checksums
>>>> for the source file and the dst file, the checksum are different (50%).
>>>> Or if there is a 300MB file in FAT32 partition, mount the partition, and
>>>> for the first time check the sha256 value by running 'sha256 file.tgz',
>>>> the checksum is wrong, but the second time, the checksum is correct.
>>>>
>>>> 3. Install FreeBSD 13 with ZFS, and it can work well. And boot into
>>>> FreeBSD, disable swap, and format the SWAP partition to FAT32. Do the
>>>> testing as above.
>>>>
>>>> Regards,
>>>>
>>>> Alvin Chen
>>>>
>>>> Dell | Comercial Client Group
>>>>
>>>> office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506
>>>> weike_chen@dell.com <mailto:weike_chen@dell.com>
>>>>
>>>> Internal Use - Confidential
>>>>
>>>
>>> -- 
>>> Alexander Motin
>>>
>>
>>
>> -- 
>> 青木 知明  [Tomoaki AOKI]    <junchoon@dec.sakura.ne.jp>

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bc01426a-9750-a161-0bfa-e1acd5299f81>