Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core

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