linux-kernel - RE: [PATCH] EDAC/skx_common: Fix potential negative values in DIMM size calculation

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: <CY8PR11MB7134BDC448F3DB558917DFCF8924A@CY8PR11MB7134.namprd11.prod.outlook.com>
Date: Wed, 30 Jul 2025 16:33:37 +0000
From: "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
To: "kao, acelan" <acelan.kao@...onical.com>
CC: "Luck, Tony" <tony.luck@...el.com>, Borislav Petkov <bp@...en8.de>, "James
 Morse" <james.morse@....com>, Mauro Carvalho Chehab <mchehab@...nel.org>,
	Robert Richter <rric@...nel.org>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] EDAC/skx_common: Fix potential negative values in DIMM
 size calculation

Hi AceLan,

> From: AceLan Kao <acelan.kao@...onical.com>
> [...]
> > Which CPU did you test it on?
> It's an on going project, there is no CPU name on it.
> $ lscpu
> Architecture:                x86_64
>  CPU op-mode(s):            32-bit, 64-bit
>  Address sizes:             52 bits physical, 57 bits virtual
>  Byte Order:                Little Endian
> CPU(s):                      172
>  On-line CPU(s) list:       0-171
> Vendor ID:                   GenuineIntel
>  Model name:                Genuine Intel(R) 0000
>    CPU family:              6
>    Model:                   173

This is the CPU with the code name "Granite Rapids".

>    Thread(s) per core:      2
>    Core(s) per socket:      86
>    Socket(s):               1
>    Stepping:                1
>    CPU(s) scaling MHz:      18%
>    CPU max MHz:             4800.0000
>    CPU min MHz:             800.0000
>    BogoMIPS:                3800.00
> 
> > Would you mind taking a complete dmesg log with the kernel option
> > CONFIG_EDAC_DEBUG=y (your current log showed this option had been
> enabled)?
> Sure, here you are.

Thanks so much for your log.

We've encountered the same issue recently due to the BIOS disabling the
memory controller when no DIMMs are populated, leading to invalid values
of the disabled memory controller register and the call trace you reported.

Attached is a patch that skips DIMM enumeration on a disabled memory 
controller to fix the call trace. Could you please test this patch on your machines 
and share the dmesg log?

Thanks!
-Qiuxu

Download attachment "0001-EDAC-i10nm-Skip-DIMM-enumeration-on-a-disabled-memor.patch" of type "application/octet-stream" (2434 bytes)