Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core
Date: Mon, 18 Sep 2023 21:13:20 UTC
On 9/18/23 14:27, Mike Karels wrote: [ .. snip .. ] >>> avail memory = 16363008000 (15604 MB) >>> CPU microcode: updated from 0xc to 0x10 >> >> With the most recent microcode update, this device reports .. >> >> CPU microcode: updated from 0xc to 0x11 >> >> .. and is now stable with vm.pmap.pcid_enabled=0, vm.pmap.pcid_invlpg_workaround=1, and CPUTYPE?=alderlake set in /etc/make.conf over multiple full system builds. >> >> I have not tested with vm.pmap.pcid_invlpg_workaround=0. <sigh> .. sorry that was a typo .. I'm actually using .. vm.pmap.pcid_invlpg_workaround: 1 vm.pmap.invpcid_works: 1 vm.pmap.pcid_enabled: 1 > I believe that vm.pmap.pcid_invlpg_workaround does not matter if > vm.pmap.pcid_enabled=0. Enabling the workaround or disabling pcid should > be basically the same for this CPU, so I don't understand why that isn't > true. It might be interesting to test with pcid enabled with the new > microcode, although I don't see why that would affect the results (pcid > should still not be used on any CPU). > > The CPUTYPE for the compiler should not affect the pcid vm issues, just > change the optimization by the compiler. Agreed. However, I was previously using CPUTYPE?=tremont so I just wanted to note that two things had changed in my testing, microcode and CPUTYPE, not just one, Michael