On Intel AlderLake-N platforms where there are Ecores only, the Ecore Module topology is enumerated via CPUID.1F Module level, which has not been supported by Linux kernel yet. This exposes two issues in current CPUID.1F handling code. 1. Linux interprets the Module ID bits as package ID and erroneously reports a multi module system as a multi-package system. 2. Linux excludes the unknown Module ID bits from the core ID, and results in duplicate core ID’s shown in a package after the first issue solved. Plus that, a third problem is observed on Intel Hybrid ADL-S/P platforms. The return value of CPUID.1F SMT level EBX (number of siblings) differs on Pcore CPUs and Ecore CPUs, and results in inconsistent smp_num_siblings value based on the Pcore/Ecore CPU enumeration order. This could bring some potential issues although we have not observed any functionalities issues so far. This patch series fixes these three problems in CPUID.1F handling code, together with some related fixes and document updates. thanks, -rui --- Changes since V2: - changelog improvements based on Peter' feedback - Remove combined tags Changes since V1: - fix/improve changelog/comment wording issues - reorder the patches to eliminate bisection breakage window - add a new patch for coretemp driver variable renaming - update coretemp driver patch to fix a case of ida_free(&ida, -2)
> Changes since V2: > - changelog improvements based on Peter' feedback > - Remove combined tags I fixed those up and started testing your v2 yesterday. Can you double-check that this: https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpuid1f Looks the same as your v3?
Hi, Dave, On Thu, 2022-09-22 at 09:53 -0700, Dave Hansen wrote: > > Changes since V2: > > - changelog improvements based on Peter' feedback > > - Remove combined tags > > I fixed those up and started testing your v2 yesterday. Thanks for doing this. > Can you > double-check that this: > > > https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpuid1f > > Looks the same as your v3? There is no code difference. Just that I have updated the subject and changelog of patch 1/8 per Peter' suggestion https://lore.kernel.org/lkml/8496afee057d63b83a7ff02ec7f1de8c2d0e97ae.camel@intel.com/ thanks, rui
This series of BUG FIXES needs to be marked for -stable. What testing is it waiting for? I don't see upstream, in linux-next or in tip -- which means that nobody is testing it. Are we supposed to be pulling from the URL below to get the latest??? The latest Intel Hybrid CPUs are sort of a mess without this series. Distros will need to back-port it. thanks, -Len On Fri, Sep 23, 2022 at 10:40 AM Zhang Rui <rui.zhang@intel.com> wrote: > > Hi, Dave, > > On Thu, 2022-09-22 at 09:53 -0700, Dave Hansen wrote: > > > Changes since V2: > > > - changelog improvements based on Peter' feedback > > > - Remove combined tags > > > > I fixed those up and started testing your v2 yesterday. > > Thanks for doing this. > > > Can you > > double-check that this: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpuid1f > > > > Looks the same as your v3? > > There is no code difference. > Just that I have updated the subject and changelog of patch 1/8 per > Peter' suggestion > https://lore.kernel.org/lkml/8496afee057d63b83a7ff02ec7f1de8c2d0e97ae.camel@intel.com/ > > thanks, > rui > -- Len Brown, Intel
On 10/13/22 03:58, Len Brown wrote: > This series of BUG FIXES needs to be marked for -stable. Hi Len, That would have been great feedback to include with your review when your provided your acks. It's also not clear where the bug fixes stop and the "related fixes" begin. Is the entire series bug fixes that need to be marked for -stable?
Hi, Dave, On Thu, 2022-10-13 at 08:56 -0700, Dave Hansen wrote: > On 10/13/22 03:58, Len Brown wrote: > > This series of BUG FIXES needs to be marked for -stable. > > Hi Len, > > That would have been great feedback to include with your review when > your provided your acks. It's also not clear where the bug fixes > stop > and the "related fixes" begin. Is the entire series bug fixes that > need > to be marked for -stable? Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and 3/8 to avoid possible regressions. So patch 2/8 ~ 5/8 should be stable material. patch 6/8 is also a bugfix, but we have not observed any functionality issues so far. thanks, rui
On 10/13/22 19:06, Zhang Rui wrote: > Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and 3/8 to > avoid possible regressions. So patch 2/8 ~ 5/8 should be stable > material. > > patch 6/8 is also a bugfix, but we have not observed any functionality > issues so far. If you want to make this really easy on me, you could take the changelog and comment revisions that I made in that testing branch that I shared, integrate them, and send it out again, and *only* include the bugfixes.
On Thu, Oct 13, 2022 at 08:19:03PM -0700, Dave Hansen wrote: > On 10/13/22 19:06, Zhang Rui wrote: > > Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and 3/8 to > > avoid possible regressions. So patch 2/8 ~ 5/8 should be stable > > material. > > > > patch 6/8 is also a bugfix, but we have not observed any functionality > > issues so far. > > If you want to make this really easy on me, you could take the changelog > and comment revisions that I made in that testing branch that I shared, > integrate them, and send it out again, and *only* include the bugfixes. It's really simple; if it don't have a Fixes tag, it ain't a fix :-)
On Fri, 2022-10-14 at 10:17 +0200, Peter Zijlstra wrote: > On Thu, Oct 13, 2022 at 08:19:03PM -0700, Dave Hansen wrote: > > On 10/13/22 19:06, Zhang Rui wrote: > > > Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and > > > 3/8 to > > > avoid possible regressions. So patch 2/8 ~ 5/8 should be stable > > > material. > > > > > > patch 6/8 is also a bugfix, but we have not observed any > > > functionality > > > issues so far. > > > > If you want to make this really easy on me, you could take the > > changelog > > and comment revisions that I made in that testing branch that I > > shared, > > integrate them, and send it out again, and *only* include the > > bugfixes. > > It's really simple; if it don't have a Fixes tag, it ain't a fix :-) Thanks for pointing this out. Patches updated with Fixes tag in V4 series. thanks, rui
On Thu, 2022-10-13 at 20:19 -0700, Dave Hansen wrote: > On 10/13/22 19:06, Zhang Rui wrote: > > Patch 4/8 ~ 5/8 are real fixes and they depends on patch 2/8 and > > 3/8 to > > avoid possible regressions. So patch 2/8 ~ 5/8 should be stable > > material. > > > > patch 6/8 is also a bugfix, but we have not observed any > > functionality > > issues so far. > > If you want to make this really easy on me, you could take the > changelog > and comment revisions that I made in that testing branch that I > shared, > integrate them, and send it out again, and *only* include the > bugfixes. Sure, will do this and resend. thanks, rui
© 2016 - 2026 Red Hat, Inc.