Message ID | 20230705145143.40545-1-ldufour@linux.ibm.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp1925511vqx; Wed, 5 Jul 2023 07:57:39 -0700 (PDT) X-Google-Smtp-Source: APBJJlExkb4lpsYqanl3CvVPDNXZDQEyoLAieYZbAjI0GTYO1aOS5aE3OHVxJ670f78nQk2Cy+rl X-Received: by 2002:a17:902:e5cd:b0:1b6:6a14:3734 with SMTP id u13-20020a170902e5cd00b001b66a143734mr3401361plf.29.1688569058753; Wed, 05 Jul 2023 07:57:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688569058; cv=none; d=google.com; s=arc-20160816; b=gcfX8Eksx7yA8boJ/TZAaHvNFMCpeJSgHlX0EgQkqEbcvT2jEZK63Ynsfb+F6DK2n1 1GeqT7pUv89NKMfqx7umvPbJHQzqg8dTJh/ohX8hvbGa9z8yGMKNhdbsM577v5JSpxo/ XG3VDsfAl0GK4D39OiPeC0FI7IG8REsCB7LruvBLkaFB0KquanSVEw4gv4T/M5gZp3Gh t3/BSHYlCBeZXMDUuz66Wz4sZKNj8UK/RHnki15nbZUvRNXOv+ycpOaVXaWEXXymJnAb SuTC4bYrf+ZyL+AjuMPdPBBjwSaQ+TD9eu1ehlBZqKu4bcFg+PMLmtkwwvt6qYgFxCZB iJZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :message-id:date:subject:cc:to:from:dkim-signature; bh=zkE1J8q+iy0ZXdF2gFz55muLXm0WMv33WDOv1sOQgLw=; fh=LGu0STNR4J3BOWwcOl5gnXcsNuPjwgpvALn/rpPskPE=; b=EBN4lIqcpPocVuVKZi9LJgC2QaVK6R/Y7r2DRjm3yyM5n3zKh5qtBJ881fXTft5Hoy vMM+rRNWCa2nKn9c2BgafmzGDMDvjaVjxKlmaNE3f2wgaDk0Gw84sZowXfNTX4pMK5t+ Yz/5zkKOHjtWb4Zrj6EdZGdnm0nkQ0jpHv/59pqjnVs/YihzX6WYuSmhmC5vVNv+4DP0 2aMkvIWSWSYZeiLOhC5vE2imSlDdSfeLWPyyC2czX+gi4x+p1Ye/VW1BjHsxUgX41xar LgGZtAxHrO7ZeKVlYNFJWEjNn6KIpRp0sCE0li/ZxMAwEm/scWsqqn1mLYKBcPOgqFVm 0RbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=itG5mPtz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c8-20020a170902d48800b001b3cf7cb619si5687652plg.62.2023.07.05.07.57.19; Wed, 05 Jul 2023 07:57:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=itG5mPtz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232745AbjGEOwU (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Wed, 5 Jul 2023 10:52:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232426AbjGEOwP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 5 Jul 2023 10:52:15 -0400 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6B871712; Wed, 5 Jul 2023 07:52:13 -0700 (PDT) Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 365EoPVE000512; Wed, 5 Jul 2023 14:51:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : content-transfer-encoding : mime-version; s=pp1; bh=zkE1J8q+iy0ZXdF2gFz55muLXm0WMv33WDOv1sOQgLw=; b=itG5mPtzCEEVrsUSV+AOZT7wssASwzKx3Y1t3zHBNC2ht0+sHnDdV1rmo/WBzWvvVrfe +QWcb1U1bAo+g0EPXuCF2YoBzAhMgJnCHP/W+IvmXMN7exUIqvhf4oo5Yg1/SBErJB4M CRrqwOsYiICUDGXh9yowgqkpC7g8zEZRkLOKy2FG3SFnx49HO7PByCbSvwsHGWoMnmuo YDv/KxDljrQPTQfAOU/j/ssHmpgoIkCGCO6P8PjR8YDWsFdcklZ9+sio38tOc16XwWkK pvivoBFqhr1EwctCYrOfd6fYFqZAL6SSCvut7aoHCkAae6bdb6y0mcSLiWcRvFlWLEu5 Xg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rnabx0nut-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2023 14:51:51 +0000 Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 365EgJjv013773; Wed, 5 Jul 2023 14:51:50 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rnabx0nua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2023 14:51:50 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3652RRYu009805; Wed, 5 Jul 2023 14:51:48 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma04ams.nl.ibm.com (PPS) with ESMTPS id 3rjbs4tnj0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Jul 2023 14:51:48 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 365Epkt743909410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 5 Jul 2023 14:51:46 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0B9612004B; Wed, 5 Jul 2023 14:51:46 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 008C620040; Wed, 5 Jul 2023 14:51:45 +0000 (GMT) Received: from localhost.localdomain (unknown [9.171.79.178]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 5 Jul 2023 14:51:44 +0000 (GMT) From: Laurent Dufour <ldufour@linux.ibm.com> To: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, tglx@linutronix.de, dave.hansen@linux.intel.com, mingo@redhat.com, bp@alien8.de, rui.zhang@intel.com Subject: [PATCH v4 00/10] Introduce SMT level and add PowerPC support Date: Wed, 5 Jul 2023 16:51:33 +0200 Message-ID: <20230705145143.40545-1-ldufour@linux.ibm.com> X-Mailer: git-send-email 2.41.0 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: flHjRsTJgwwkIgOH1wpae1j0NbjDUp3i X-Proofpoint-GUID: Eh1q-CdM5eBF0snqoGpamWwoUMXWJ7un Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-05_06,2023-07-05_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 clxscore=1015 impostorscore=0 phishscore=0 spamscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 suspectscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307050131 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770049154504163369?= X-GMAIL-MSGID: =?utf-8?q?1770592989349129996?= |
Series |
Introduce SMT level and add PowerPC support
|
|
Message
Laurent Dufour
July 5, 2023, 2:51 p.m. UTC
I'm taking over the series Michael sent previously [1] which is smartly reviewing the initial series I sent [2]. This series is addressing the comments sent by Thomas and me on the Michael's one. Here is a short introduction to the issue this series is addressing: When a new CPU is added, the kernel is activating all its threads. This leads to weird, but functional, result when adding CPU on a SMT 4 system for instance. Here the newly added CPU 1 has 8 threads while the other one has 4 threads active (system has been booted with the 'smt-enabled=4' kernel option): ltcden3-lp12:~ # ppc64_cpu --info Core 0: 0* 1* 2* 3* 4 5 6 7 Core 1: 8* 9* 10* 11* 12* 13* 14* 15* This mixed SMT level may confused end users and/or some applications. There is no SMT level recorded in the kernel (common code), neither in user space, as far as I know. Such a level is helpful when adding new CPU or when optimizing the energy efficiency (when reactivating CPUs). When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level (cpu_smt_num_threads) and few callbacks allowing the architecture code to fine control this value, setting a max and a "at boot" level, and controling whether a thread should be onlined or not. v4: Rebase on top of 6.5's updates Remove a dependancy against the X86's symbol cpu_primary_thread_mask v3: Fix a build error in the patch 6/9 v2: As Thomas suggested, Reword some commit's description Remove topology_smt_supported() Remove topology_smt_threads_supported() Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC Remove switch() in __store_smt_control() Update kernel-parameters.txt [1] https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-mpe@ellerman.id.au/ [2] https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-ldufour@linux.ibm.com/ Laurent Dufour (2): cpu/hotplug: remove dependancy against cpu_primary_thread_mask cpu/SMT: Remove topology_smt_supported() Michael Ellerman (8): cpu/SMT: Move SMT prototypes into cpu_smt.h cpu/SMT: Move smt/control simple exit cases earlier cpu/SMT: Store the current/max number of threads cpu/SMT: Create topology_smt_thread_allowed() cpu/SMT: Allow enabling partial SMT states via sysfs powerpc/pseries: Initialise CPU hotplug callbacks earlier powerpc: Add HOTPLUG_SMT support powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs .../ABI/testing/sysfs-devices-system-cpu | 1 + .../admin-guide/kernel-parameters.txt | 4 +- arch/Kconfig | 3 + arch/powerpc/Kconfig | 2 + arch/powerpc/include/asm/topology.h | 15 ++ arch/powerpc/kernel/smp.c | 8 +- arch/powerpc/platforms/pseries/hotplug-cpu.c | 30 ++-- arch/powerpc/platforms/pseries/pseries.h | 2 + arch/powerpc/platforms/pseries/setup.c | 2 + arch/x86/include/asm/topology.h | 4 +- arch/x86/kernel/cpu/common.c | 2 +- arch/x86/kernel/smpboot.c | 8 - include/linux/cpu.h | 25 +-- include/linux/cpu_smt.h | 33 ++++ kernel/cpu.c | 142 +++++++++++++----- 15 files changed, 196 insertions(+), 85 deletions(-) create mode 100644 include/linux/cpu_smt.h
Comments
Hi, Laurent, I ran into a boot hang regression with latest upstream code, and it took me a while to bisect the offending commit and workaround it. Now I have tested this patch series on an Intel RaptorLake Hybrid platform (4 Pcores with HT and 4 Ecores without HT), and it works as expected. So, for patch 1~7 in this series, Tested-by: Zhang Rui <rui.zhang@intel.com> thanks, rui On Wed, 2023-07-05 at 16:51 +0200, Laurent Dufour wrote: > I'm taking over the series Michael sent previously [1] which is > smartly > reviewing the initial series I sent [2]. This series is addressing > the > comments sent by Thomas and me on the Michael's one. > > Here is a short introduction to the issue this series is addressing: > > When a new CPU is added, the kernel is activating all its threads. > This > leads to weird, but functional, result when adding CPU on a SMT 4 > system > for instance. > > Here the newly added CPU 1 has 8 threads while the other one has 4 > threads > active (system has been booted with the 'smt-enabled=4' kernel > option): > > ltcden3-lp12:~ # ppc64_cpu --info > Core 0: 0* 1* 2* 3* 4 5 6 7 > Core 1: 8* 9* 10* 11* 12* 13* 14* 15* > > This mixed SMT level may confused end users and/or some applications. > > There is no SMT level recorded in the kernel (common code), neither > in user > space, as far as I know. Such a level is helpful when adding new CPU > or > when optimizing the energy efficiency (when reactivating CPUs). > > When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT > level > (cpu_smt_num_threads) and few callbacks allowing the architecture > code to > fine control this value, setting a max and a "at boot" level, and > controling whether a thread should be onlined or not. > > v4: > Rebase on top of 6.5's updates > Remove a dependancy against the X86's symbol > cpu_primary_thread_mask > v3: > Fix a build error in the patch 6/9 > v2: > As Thomas suggested, > Reword some commit's description > Remove topology_smt_supported() > Remove topology_smt_threads_supported() > Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC > Remove switch() in __store_smt_control() > Update kernel-parameters.txt > > [1] > https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-mpe@ellerman.id.au/ > [2] > https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-ldufour@linux.ibm.com/ > > > Laurent Dufour (2): > cpu/hotplug: remove dependancy against cpu_primary_thread_mask > cpu/SMT: Remove topology_smt_supported() > > Michael Ellerman (8): > cpu/SMT: Move SMT prototypes into cpu_smt.h > cpu/SMT: Move smt/control simple exit cases earlier > cpu/SMT: Store the current/max number of threads > cpu/SMT: Create topology_smt_thread_allowed() > cpu/SMT: Allow enabling partial SMT states via sysfs > powerpc/pseries: Initialise CPU hotplug callbacks earlier > powerpc: Add HOTPLUG_SMT support > powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs > > .../ABI/testing/sysfs-devices-system-cpu | 1 + > .../admin-guide/kernel-parameters.txt | 4 +- > arch/Kconfig | 3 + > arch/powerpc/Kconfig | 2 + > arch/powerpc/include/asm/topology.h | 15 ++ > arch/powerpc/kernel/smp.c | 8 +- > arch/powerpc/platforms/pseries/hotplug-cpu.c | 30 ++-- > arch/powerpc/platforms/pseries/pseries.h | 2 + > arch/powerpc/platforms/pseries/setup.c | 2 + > arch/x86/include/asm/topology.h | 4 +- > arch/x86/kernel/cpu/common.c | 2 +- > arch/x86/kernel/smpboot.c | 8 - > include/linux/cpu.h | 25 +-- > include/linux/cpu_smt.h | 33 ++++ > kernel/cpu.c | 142 +++++++++++++--- > -- > 15 files changed, 196 insertions(+), 85 deletions(-) > create mode 100644 include/linux/cpu_smt.h >
Le 09/07/2023 à 17:25, Zhang, Rui a écrit : > Hi, Laurent, > > I ran into a boot hang regression with latest upstream code, and it > took me a while to bisect the offending commit and workaround it. > > Now I have tested this patch series on an Intel RaptorLake Hybrid > platform (4 Pcores with HT and 4 Ecores without HT), and it works as > expected. > > So, for patch 1~7 in this series, > > Tested-by: Zhang Rui <rui.zhang@intel.com> Thanks Rui! > thanks, > rui > > On Wed, 2023-07-05 at 16:51 +0200, Laurent Dufour wrote: >> I'm taking over the series Michael sent previously [1] which is >> smartly >> reviewing the initial series I sent [2]. This series is addressing >> the >> comments sent by Thomas and me on the Michael's one. >> >> Here is a short introduction to the issue this series is addressing: >> >> When a new CPU is added, the kernel is activating all its threads. >> This >> leads to weird, but functional, result when adding CPU on a SMT 4 >> system >> for instance. >> >> Here the newly added CPU 1 has 8 threads while the other one has 4 >> threads >> active (system has been booted with the 'smt-enabled=4' kernel >> option): >> >> ltcden3-lp12:~ # ppc64_cpu --info >> Core 0: 0* 1* 2* 3* 4 5 6 7 >> Core 1: 8* 9* 10* 11* 12* 13* 14* 15* >> >> This mixed SMT level may confused end users and/or some applications. >> >> There is no SMT level recorded in the kernel (common code), neither >> in user >> space, as far as I know. Such a level is helpful when adding new CPU >> or >> when optimizing the energy efficiency (when reactivating CPUs). >> >> When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT >> level >> (cpu_smt_num_threads) and few callbacks allowing the architecture >> code to >> fine control this value, setting a max and a "at boot" level, and >> controling whether a thread should be onlined or not. >> >> v4: >> Rebase on top of 6.5's updates >> Remove a dependancy against the X86's symbol >> cpu_primary_thread_mask >> v3: >> Fix a build error in the patch 6/9 >> v2: >> As Thomas suggested, >> Reword some commit's description >> Remove topology_smt_supported() >> Remove topology_smt_threads_supported() >> Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC >> Remove switch() in __store_smt_control() >> Update kernel-parameters.txt >> >> [1] >> https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-mpe@ellerman.id.au/ >> [2] >> https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-ldufour@linux.ibm.com/ >> >> >> Laurent Dufour (2): >> cpu/hotplug: remove dependancy against cpu_primary_thread_mask >> cpu/SMT: Remove topology_smt_supported() >> >> Michael Ellerman (8): >> cpu/SMT: Move SMT prototypes into cpu_smt.h >> cpu/SMT: Move smt/control simple exit cases earlier >> cpu/SMT: Store the current/max number of threads >> cpu/SMT: Create topology_smt_thread_allowed() >> cpu/SMT: Allow enabling partial SMT states via sysfs >> powerpc/pseries: Initialise CPU hotplug callbacks earlier >> powerpc: Add HOTPLUG_SMT support >> powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs >> >> .../ABI/testing/sysfs-devices-system-cpu | 1 + >> .../admin-guide/kernel-parameters.txt | 4 +- >> arch/Kconfig | 3 + >> arch/powerpc/Kconfig | 2 + >> arch/powerpc/include/asm/topology.h | 15 ++ >> arch/powerpc/kernel/smp.c | 8 +- >> arch/powerpc/platforms/pseries/hotplug-cpu.c | 30 ++-- >> arch/powerpc/platforms/pseries/pseries.h | 2 + >> arch/powerpc/platforms/pseries/setup.c | 2 + >> arch/x86/include/asm/topology.h | 4 +- >> arch/x86/kernel/cpu/common.c | 2 +- >> arch/x86/kernel/smpboot.c | 8 - >> include/linux/cpu.h | 25 +-- >> include/linux/cpu_smt.h | 33 ++++ >> kernel/cpu.c | 142 +++++++++++++--- >> -- >> 15 files changed, 196 insertions(+), 85 deletions(-) >> create mode 100644 include/linux/cpu_smt.h >> >
Rui! On Sun, Jul 09 2023 at 15:25, Rui Zhang wrote: > I ran into a boot hang regression with latest upstream code, and it > took me a while to bisect the offending commit and workaround it. Where is the bug report and the analysis? And what's the workaround? Thanks, tglx
Laurent, Michael! On Wed, Jul 05 2023 at 16:51, Laurent Dufour wrote: > I'm taking over the series Michael sent previously [1] which is smartly > reviewing the initial series I sent [2]. This series is addressing the > comments sent by Thomas and me on the Michael's one. Thanks for getting this into shape. I've merged it into: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/core and tagged it at patch 7 for consumption into the powerpc tree, so the powerpc specific changes can be applied there on top: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp-core-for-ppc-23-07-28 Thanks, tglx
Hi, Thomas, On Fri, 2023-07-28 at 09:40 +0200, Thomas Gleixner wrote: > Rui! > > On Sun, Jul 09 2023 at 15:25, Rui Zhang wrote: > > I ran into a boot hang regression with latest upstream code, and it > > took me a while to bisect the offending commit and workaround it. > > Where is the bug report and the analysis? And what's the workaround? As it is an iwlwifi regression, I didn't paste the link here. The regression was reported at https://lore.kernel.org/all/b533071f38804247f06da9e52a04f15cce7a3836.camel@intel.com/ And it was fixed later by below commit in 6.5-rc2. thanks, rui commit 12a89f0177092dbc2a1cb1d05a9790adbcea2309 Author: Johannes Berg <johannes.berg@intel.com> AuthorDate: Mon Jul 10 16:50:39 2023 +0200 Commit: Jakub Kicinski <kuba@kernel.org> CommitDate: Tue Jul 11 20:26:06 2023 -0700 wifi: iwlwifi: remove 'use_tfh' config to fix crash This is equivalent to 'gen2', and it was always confusing to have two identical config entries. The split config patch actually had been originally developed after removing 'use_tfh" and didn't add the use_tfh in the new configs as they'd later been copied to the new files. Thus the easiest way to fix the init crash here now is to just remove use_tfh (which is erroneously unset in most of the configs now) and use 'gen2' in the code instead. There's possibly still an unwind error in iwl_txq_gen2_init() as it crashes if TXQ 0 fails to initialize, but we can deal with it later since the original failure is due to the use_tfh confusion. Tested-by: Xi Ruoyao <xry111@xry111.site> Reported-and-tested-by: Niklāvs Koļesņikovs <pinkflames.linux@gmail.com> Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com> Reported-and-tested-by: Zhang Rui <rui.zhang@intel.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217622 Link: https://lore.kernel.org/all/9274d9bd3d080a457649ff5addcc1726f08ef5b2.camel@xry111.site/ Link: https://lore.kernel.org/all/CAAJw_Zug6VCS5ZqTWaFSr9sd85k%3DtyPm9DEE%2BmV%3DAKoECZM%2BsQ@mail.gmail.com/ Fixes: 19898ce9cf8a ("wifi: iwlwifi: split 22000.c into multiple files") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20230710145038.84186-2-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> > > Thanks, > > tglx
On Fri, Jul 28 2023 at 14:23, Rui Zhang wrote: > On Fri, 2023-07-28 at 09:40 +0200, Thomas Gleixner wrote: >> On Sun, Jul 09 2023 at 15:25, Rui Zhang wrote: >> > I ran into a boot hang regression with latest upstream code, and it >> > took me a while to bisect the offending commit and workaround it. >> >> Where is the bug report and the analysis? And what's the workaround? > > As it is an iwlwifi regression, I didn't paste the link here. > > The regression was reported at > https://lore.kernel.org/all/b533071f38804247f06da9e52a04f15cce7a3836.camel@intel.com/ > > And it was fixed later by below commit in 6.5-rc2. Ah, ok. I was worried that you ran into issues with the parallel bootup muck.
Le 28/07/2023 à 09:58, Thomas Gleixner a écrit : > Laurent, Michael! > > On Wed, Jul 05 2023 at 16:51, Laurent Dufour wrote: >> I'm taking over the series Michael sent previously [1] which is smartly >> reviewing the initial series I sent [2]. This series is addressing the >> comments sent by Thomas and me on the Michael's one. > > Thanks for getting this into shape. > > I've merged it into: > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/core > > and tagged it at patch 7 for consumption into the powerpc tree, so the > powerpc specific changes can be applied there on top: > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp-core-for-ppc-23-07-28 Thanks Thomas!
Thomas Gleixner <tglx@linutronix.de> writes: > Laurent, Michael! > > On Wed, Jul 05 2023 at 16:51, Laurent Dufour wrote: >> I'm taking over the series Michael sent previously [1] which is smartly >> reviewing the initial series I sent [2]. This series is addressing the >> comments sent by Thomas and me on the Michael's one. > > Thanks for getting this into shape. > > I've merged it into: > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/core > > and tagged it at patch 7 for consumption into the powerpc tree, so the > powerpc specific changes can be applied there on top: > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp-core-for-ppc-23-07-28 Thanks. I've merged this and applied the powerpc patches on top. I've left it sitting in my topic/cpu-smt branch for the build bots to chew on: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/cpu-smt I'll plan to merge it into my next in the next day or two. cheers
Le 10/08/2023 à 08:23, Michael Ellerman a écrit : > Thomas Gleixner <tglx@linutronix.de> writes: >> Laurent, Michael! >> >> On Wed, Jul 05 2023 at 16:51, Laurent Dufour wrote: >>> I'm taking over the series Michael sent previously [1] which is smartly >>> reviewing the initial series I sent [2]. This series is addressing the >>> comments sent by Thomas and me on the Michael's one. >> >> Thanks for getting this into shape. >> >> I've merged it into: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/core >> >> and tagged it at patch 7 for consumption into the powerpc tree, so the >> powerpc specific changes can be applied there on top: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp-core-for-ppc-23-07-28 > > Thanks. I've merged this and applied the powerpc patches on top. > > I've left it sitting in my topic/cpu-smt branch for the build bots to > chew on: > > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/cpu-smt > > I'll plan to merge it into my next in the next day or two. Thanks Michael!