lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sexy6qt9.ffs@tglx>
Date: Fri, 31 May 2024 15:42:26 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Christian Heusel <christian@...sel.eu>
Cc: Peter Schneider <pschneider1968@...glemail.com>, LKML
 <linux-kernel@...r.kernel.org>, x86@...nel.org, stable@...r.kernel.org,
 regressions@...ts.linux.dev
Subject: Re: Kernel 6.9 regression: X86: Bogus messages from topology detection

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ