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.

> 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 <m...@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_c...@dell.com <mailto:weike_c...@dell.com>
>>>
>>> Internal Use - Confidential
>>>
>>
>> -- 
>> Alexander Motin
>>
>
>
> -- 
> 青木 知明  [Tomoaki AOKI]    <junch...@dec.sakura.ne.jp>

Reply via email to