On Fri, May 31 2024 at 15:08, Christian Heusel wrote:
> On 24/05/31 11:11AM, Thomas Gleixner wrote:
>> On Fri, May 31 2024 at 10:48, Thomas Gleixner wrote:
>>
>> It seems there are two different issues here. The dmesg you provided is
>> from a i7-1255U, which is a hybrid CPU. The i7-7700k has 4 cores (8
>> threads) and there is not necessarily the same root cause.
>
> It seems like I was also below my needed caffeine levels :p The person
> reporting (in the same thread) with the i7-7700k reports the problem
> fixed[1] as well, so this is in line with Peters observerations!
Cool!
> The other person with the i7-1255U in the meantime got back to me with
> the needed outputs:
>> - output of cpuid -r
> 0x0000000b: subleafs:
> 0: EAX=0x00000001, EBX=0x00000001, ECX=0x00000100, EDX=0x00000012
> 1: EAX=0x00000006, EBX=0x0000000c, ECX=0x00000201, EDX=0x00000012
> 0x0000001f: subleafs:
> 0: EAX=0x00000001, EBX=0x00000001, ECX=0x00000100, EDX=0x00000012
> 1: EAX=0x00000007, EBX=0x0000000c, ECX=0x00000201, EDX=0x00000012
So this is inconsistent already. Both leafs should describe the same
topology. See the differing EAX values (6/7) in subleaf 1, which are
exactly the values the kernel complains about :)
But that should not be an issue because the kernel preferres 0x1f over
0xb and will never evaluate both, but this is just from one randomly
picked CPU.
I wonder which variant of the cpuid tool that is. cpuid -r gives you
usually just the plain values and collects them for all CPUs.
I really need to have the values for all CPUs to see whether there are
differences at the relevant places. The above is probably from one of
the E-Cores.
Thanks,
tglx
