Re: [PATCHv12 4/4] watchdog/softlockup: report the most frequent interrupts

Hi, On Mon, Mar 25, 2024 at 2:48 AM Bitao Hu wrote: > > Hi, Thomas > > On 2024/3/24 04:43, Thomas Gleixner wrote: > > On Wed, Mar 06 2024 at 20:52, Bitao Hu wrote: > >> +if (__this_cpu_read(snapshot_taken)) { > >> +for_each_active_irq(i) { > >> +count =

Re: [PATCHv11 4/4] watchdog/softlockup: report the most frequent interrupts

Hi, On Tue, Feb 27, 2024 at 11:22 PM Bitao Hu wrote: > > When the watchdog determines that the current soft lockup is due > to an interrupt storm based on CPU utilization, reporting the > most frequent interrupts could be good enough for further > troubleshooting. > > Below is an example of

Re: [PATCHv11 3/4] genirq: Avoid summation loops for /proc/interrupts

Hi, On Tue, Feb 27, 2024 at 11:22 PM Bitao Hu wrote: > > show_interrupts() unconditionally accumulates the per CPU interrupt > statistics to determine whether an interrupt was ever raised. > > This can be avoided for all interrupts which are not strictly per CPU > and not of type NMI because

Re: [PATCHv11 2/4] genirq: Provide a snapshot mechanism for interrupt statistics

Hi, On Tue, Feb 27, 2024 at 11:22 PM Bitao Hu wrote: > > The soft lockup detector lacks a mechanism to identify interrupt storms > as root cause of a lockup. To enable this the detector needs a > mechanism to snapshot the interrupt count statistics on a CPU when the > detector observes a

Re: [PATCH v3 1/2] nmi_backtrace: Allow excluding an arbitrary CPU

Hi, On Fri, Aug 4, 2023 at 8:02 AM Michal Hocko wrote: > > > > It would have been slightly safer to modify arch_trigger_cpumask_backtrace > > > by switching arguments so that some leftovers are captured easier. > > > > I'm not sure I understand. Oh, you're saying make the prototype of > >

Re: [PATCH v3 1/2] nmi_backtrace: Allow excluding an arbitrary CPU

Hi, On Fri, Aug 4, 2023 at 12:50 AM Michal Hocko wrote: > > On Thu 03-08-23 16:07:57, Douglas Anderson wrote: > > The APIs that allow backtracing across CPUs have always had a way to > > exclude the current CPU. This convenience means callers didn't need to > > find a place to allocate a CPU

Re: [PATCH v2 6/6] watchdog/hardlockup: Define HARDLOCKUP_DETECTOR_ARCH

Hi, On Sat, Jul 1, 2023 at 7:40 AM Guenter Roeck wrote: > > On Fri, Jun 16, 2023 at 05:06:18PM +0200, Petr Mladek wrote: > > The HAVE_ prefix means that the code could be enabled. Add another > > variable for HAVE_HARDLOCKUP_DETECTOR_ARCH without this prefix. > > It will be set when it should be

Re: [PATCH v2 6/6] watchdog/hardlockup: Define HARDLOCKUP_DETECTOR_ARCH

Hi, On Wed, Jun 21, 2023 at 6:08 AM Michael Ellerman wrote: > > Petr Mladek writes: > > The HAVE_ prefix means that the code could be enabled. Add another > > variable for HAVE_HARDLOCKUP_DETECTOR_ARCH without this prefix. > > It will be set when it should be built. It will make it compatible >

Re: [PATCH v2 4/6] watchdog/hardlockup: Make HAVE_NMI_WATCHDOG sparc64-specific

Hi, On Fri, Jun 16, 2023 at 8:07 AM Petr Mladek wrote: > > There are several hardlockup detector implementations and several Kconfig > values which allow selection and build of the preferred one. > > CONFIG_HARDLOCKUP_DETECTOR was introduced by the commit 23637d477c1f53acb > ("lockup_detector:

Re: [PATCH v2 2/6] watchdog/hardlockup: Make the config checks more straightforward

Hi, On Fri, Jun 16, 2023 at 8:07 AM Petr Mladek wrote: > > There are four possible variants of hardlockup detectors: > > + buddy: available when SMP is set. > > + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set. > > + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is

Re: [PATCH v2 1/6] watchdog/hardlockup: Sort hardlockup detector related config values a logical way

Hi, On Fri, Jun 16, 2023 at 8:06 AM Petr Mladek wrote: > > There are four possible variants of hardlockup detectors: > > + buddy: available when SMP is set. > > + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set. > > + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is

Re: [PATCH 2/7] watchdog/hardlockup: Make the config checks more straightforward

Hi, On Wed, Jun 14, 2023 at 3:29 AM Petr Mladek wrote: > > It seems that we have entered into a bike shedding mode. > The following questions come to my mind: > >1. Does this patchset improve the current state? > >2. Maybe, it is not black Is it possible to summarize > what exactly

Re: [PATCH v5 15/18] watchdog/perf: Add a weak function for an arch to detect if perf can use NMIs

Mark, On Mon, Jun 12, 2023 at 3:33 AM Mark Rutland wrote: > > On Fri, May 19, 2023 at 10:18:39AM -0700, Douglas Anderson wrote: > > On arm64, NMI support needs to be detected at runtime. Add a weak > > function to the perf hardlockup detector so that an architecture can > > implement it to

Re: [PATCH 2/7] watchdog/hardlockup: Make the config checks more straightforward

Hi, On Thu, Jun 8, 2023 at 4:02 AM Petr Mladek wrote: > > > > config HARDLOCKUP_DETECTOR > > > bool "Detect Hard Lockups" > > > depends on DEBUG_KERNEL && !S390 > > > - depends on HAVE_HARDLOCKUP_DETECTOR_NON_ARCH || > > > HAVE_HARDLOCKUP_DETECTOR_ARCH > > > +

Re: [PATCH 4/7] watchdog/hardlockup: Enable HAVE_NMI_WATCHDOG only on sparc64

Hi, On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote: > > diff --git a/arch/Kconfig b/arch/Kconfig > index 13c6e596cf9e..57f15babe188 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -404,10 +404,9 @@ config HAVE_NMI_WATCHDOG > depends on HAVE_NMI > bool > help > -

Re: [PATCH 6/7] watchdog/sparc64: Define HARDLOCKUP_DETECTOR_SPARC64

Hi, On Wed, Jun 7, 2023 at 8:26 AM Petr Mladek wrote: > > The HAVE_ prefix means that the code could be enabled. Add another > variable for HAVE_HARDLOCKUP_DETECTOR_SPARC64 without this prefix. > It will be set when it should be built. It will make it compatible > with the other hardlockup

Re: [PATCH 3/7] watchdog/hardlockup: Declare arch_touch_nmi_watchdog() only in linux/nmi.h

Hi, On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote: > > arch_touch_nmi_watchdog() needs a different implementation for various > hardlockup detector implementations. And it does nothing when > any hardlockup detector is not build at all. s/build/built/ > arch_touch_nmi_watchdog() has to be

Re: [PATCH 0/7] watchdog/hardlockup: Cleanup configuration of hardlockup detectors

Hi, On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote: > > Hi, > > this patchset is supposed to replace the last patch in the patchset cleaning > up after introducing the buddy detector, see > https://lore.kernel.org/r/20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@changeid I will

Re: [PATCH 7/7] watchdog/hardlockup: Define HARDLOCKUP_DETECTOR_ARCH

Hi, On Wed, Jun 7, 2023 at 8:26 AM Petr Mladek wrote: > > @@ -1102,6 +1103,14 @@ config HARDLOCKUP_DETECTOR_BUDDY > depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH > select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER > > +config HARDLOCKUP_DETECTOR_ARCH > + bool > + depends on

Re: [PATCH 5/7] watchdog/sparc64: Rename HAVE_NMI_WATCHDOG to HAVE_HARDLOCKUP_WATCHDOG_SPARC64

Hi, On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote: > > The configuration variable HAVE_NMI_WATCHDOG has a generic name but > it is selected only for SPARC64. > > It should _not_ be used in general because it is not integrated with > the other hardlockup detectors. Namely, it does not support

Re: [PATCH 2/7] watchdog/hardlockup: Make the config checks more straightforward

Hi, On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote: > > diff --git a/arch/Kconfig b/arch/Kconfig > index 422f0ffa269e..13c6e596cf9e 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -404,17 +404,27 @@ config HAVE_NMI_WATCHDOG > depends on HAVE_NMI > bool > help > -

Re: [PATCH 1/7] watchdog/hardlockup: Sort hardlockup detector related config values a logical way

Hi, On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote: > > There are four possible variants of hardlockup detectors: > > + buddy: available when SMP is set. > > + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set. > > + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is

Re: [PATCH v8 00/10] arm64: Add framework to turn an IPI as NMI

Hi, On Wed, May 10, 2023 at 9:42 AM Doug Anderson wrote: > > Hi, > > On Wed, May 10, 2023 at 9:30 AM Mark Rutland wrote: > > > > On Wed, May 10, 2023 at 08:28:17AM -0700, Doug Anderson wrote: > > > Hi, > > > > Hi Doug, > > > > > On

Re: [PATCH v5 12/18] watchdog/hardlockup: Rename some "NMI watchdog" constants/function

Hi, On Wed, May 24, 2023 at 6:38 AM Petr Mladek wrote: > > On Fri 2023-05-19 10:18:36, Douglas Anderson wrote: > > Do a search and replace of: > > - NMI_WATCHDOG_ENABLED => WATCHDOG_HARDLOCKUP_ENABLED > > - SOFT_WATCHDOG_ENABLED => WATCHDOG_SOFTOCKUP_ENABLED > > - watchdog_nmi_ =>

Re: [PATCH v5 14/18] watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs

Hi, On Thu, May 25, 2023 at 9:27 AM Petr Mladek wrote: > > On Fri 2023-05-19 10:18:38, Douglas Anderson wrote: > > Implement a hardlockup detector that doesn't doesn't need any extra > > arch-specific support code to detect lockups. Instead of using > > something arch-specific we will use the

Re: [PATCH v5 13/18] watchdog/hardlockup: Have the perf hardlockup use __weak functions more cleanly

Hi, On Wed, May 24, 2023 at 6:59 AM Petr Mladek wrote: > > On Fri 2023-05-19 10:18:37, Douglas Anderson wrote: > > The fact that there watchdog_hardlockup_enable(), > > watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are > > declared __weak means that the configured hardlockup

Re: [PATCH v5 10/18] watchdog/hardlockup: Add a "cpu" param to watchdog_hardlockup_check()

Hi, On Tue, May 23, 2023 at 9:02 AM Petr Mladek wrote: > > On Fri 2023-05-19 10:18:34, Douglas Anderson wrote: > > In preparation for the buddy hardlockup detector where the CPU > > checking for lockup might not be the currently running CPU, add a > > "cpu" parameter to

Re: [PATCH v4 13/17] watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs

Hi, On Mon, May 8, 2023 at 8:52 AM Doug Anderson wrote: > > Hmmm, but I don't think you really need "all-to-all" checking to get > the stacktraces you want, do you? Each CPU can be "watching" exactly > one other CPU, but then when we actually lock up we could che

Re: [PATCH v4 10/17] watchdog/hardlockup: Move perf hardlockup watchdog petting to watchdog.c

Hi, On Thu, May 11, 2023 at 8:46 AM Petr Mladek wrote: > > > @@ -111,6 +125,11 @@ static void watchdog_hardlockup_interrupt_count(void) > > > > void watchdog_hardlockup_check(unsigned int cpu, struct pt_regs *regs) > > { > > + if (__this_cpu_read(watchdog_hardlockup_touch)) { > > +

Re: [PATCH v4 09/17] watchdog/hardlockup: Add a "cpu" param to watchdog_hardlockup_check()

Hi, On Thu, May 11, 2023 at 7:14 AM Petr Mladek wrote: > > On Thu 2023-05-04 15:13:41, Douglas Anderson wrote: > > In preparation for the buddy hardlockup detector where the CPU > > checking for lockup might not be the currently running CPU, add a > > "cpu" parameter to

Re: [PATCH v8 00/10] arm64: Add framework to turn an IPI as NMI

Hi, On Wed, May 10, 2023 at 9:30 AM Mark Rutland wrote: > > On Wed, May 10, 2023 at 08:28:17AM -0700, Doug Anderson wrote: > > Hi, > > Hi Doug, > > > On Wed, Apr 19, 2023 at 3:57 PM Douglas Anderson > > wrote: > > > This is an attemp

Re: [PATCH v8 00/10] arm64: Add framework to turn an IPI as NMI

Hi, On Wed, Apr 19, 2023 at 3:57 PM Douglas Anderson wrote: > > This is an attempt to resurrect Sumit's old patch series [1] that > allowed us to use the arm64 pseudo-NMI to get backtraces of CPUs and > also to round up CPUs in kdb/kgdb. The last post from Sumit that I > could find was v7, so I

Re: [PATCH v4 05/17] watchdog/hardlockup: Rename touch_nmi_watchdog() to touch_hardlockup_watchdog()

Hi, On Sun, May 7, 2023 at 6:35 PM Nicholas Piggin wrote: > > On Sat May 6, 2023 at 2:37 AM AEST, Doug Anderson wrote: > > Hi, > > > > On Thu, May 4, 2023 at 7:51 PM Nicholas Piggin wrote: > > > > > > On Fri May 5, 2023 at 8:13 AM AEST, Doug

Re: [PATCH v4 13/17] watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs

Hi, On Sun, May 7, 2023 at 6:05 PM Nicholas Piggin wrote: > > > No, I wasn't aware of it. Interesting, it seems to basically enable > > both types of hardlockup detectors together. If that really catches > > more lockups, it seems like we could do the same thing for the buddy > > system. > > It

Re: [PATCH v4 11/17] watchdog/hardlockup: Rename some "NMI watchdog" constants/function

Hi, On Thu, May 4, 2023 at 8:07 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > Do a search and replace of: > > - NMI_WATCHDOG_ENABLED => HARD_WATCHDOG_ENABLED > > - watchdog_nmi_ => watchdog_hardlockup_ > > These are just making prefixes

Re: [PATCH v4 08/17] watchdog/hardlockup: Style changes to watchdog_hardlockup_check() / ..._is_lockedup()

Hi, On Thu, May 4, 2023 at 8:02 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > These are tiny style changes: > > - Add a blank line before a "return". > > - Renames two globals to use the "watchdog_hld" prefix. > > Particularly static ones don't

Re: [PATCH v4 07/17] watchdog/hardlockup: Move perf hardlockup checking/panic to common watchdog.c

Hi, On Thu, May 4, 2023 at 7:58 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > The perf hardlockup detector works by looking at interrupt counts and > > seeing if they change from run to run. The interrupt counts are > > managed by the common

Re: [PATCH v4 05/17] watchdog/hardlockup: Rename touch_nmi_watchdog() to touch_hardlockup_watchdog()

Hi, On Thu, May 4, 2023 at 7:51 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > In preparation for the buddy hardlockup detector, rename > > touch_nmi_watchdog() to touch_hardlockup_watchdog() to make it clear > > that it will touch whatever

Re: [PATCH v4 13/17] watchdog/hardlockup: detect hard lockups using secondary (buddy) CPUs

Hi, On Thu, May 4, 2023 at 7:36 PM Nicholas Piggin wrote: > > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote: > > From: Colin Cross > > > > Implement a hardlockup detector that doesn't doesn't need any extra > > arch-specific support code to detect lockups. Instead of using > >

Re: [PATCH 6/7] modules: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC

Hi, On Mon, Jan 24, 2022 at 1:22 AM Christophe Leroy wrote: > > --- a/kernel/debug/kdb/kdb_main.c > +++ b/kernel/debug/kdb/kdb_main.c > @@ -2022,8 +2022,11 @@ static int kdb_lsmod(int argc, const char **argv) > if (mod->state == MODULE_STATE_UNFORMED) >

Re: [PATCH 04/20] Documentation: kgdb: eliminate duplicated word

Hi, On Tue, Jul 7, 2020 at 11:05 AM Randy Dunlap wrote: > > Drop the doubled word "driver". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Jason Wessel > Cc: Daniel Thompson > Cc: Douglas Anderson > Cc: kgdb-bugrep...@lists.sourceforge.net > ---

Re: [REPOST PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()

Hi, On Fri, Dec 7, 2018 at 9:42 AM Catalin Marinas wrote: > > On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote: > > Douglas Anderson (4): > > kgdb: Remove irq flags from roundup > > kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function() > > kgdb: Don't round

Re: [PATCH v6 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()

Hi, On Mon, Dec 3, 2018 at 7:57 AM Daniel Thompson wrote: > > On Tue, Nov 27, 2018 at 09:38:37AM -0800, Douglas Anderson wrote: > > When I had lockdep turned on and dropped into kgdb I got a nice splat > > on my system. Specifically it hit: > > DEBUG_LOCKS_WARN_ON(current->hardirq_context) >

Re: [PATCH v5 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()

Hi, On Mon, Nov 26, 2018 at 9:39 PM kbuild test robot wrote: > > Hi Douglas, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on kgdb/kgdb-next] > [also build test ERROR on v4.20-rc4 next-20181126] > [if your patch is applied to the wrong git tree, please drop us

Re: [PATCH v4 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()

Hi, On Wed, Nov 14, 2018 at 2:07 PM Will Deacon wrote: > > > +void __weak kgdb_call_nmi_hook(void *ignored) > > +{ > > + kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs()); > > +} > > I suppose you could pass the cpu as an argument, but it doesn't really > matter. I probably won't

Re: [PATCH v2 2/2] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()

Hi, On Sat, Nov 3, 2018 at 3:45 AM Daniel Thompson wrote: > > On Wed, Oct 31, 2018 at 02:41:14PM -0700, Doug Anderson wrote: > > > As mentioned in another part of the thread we can also add robustness > > > by skipping a cpu where csd->flags != 0 (and adding an approp

Re: [PATCH v2 2/2] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()

Hi, On Wed, Oct 31, 2018 at 11:40 AM Daniel Thompson wrote: > > On Tue, Oct 30, 2018 at 03:18:43PM -0700, Douglas Anderson wrote: > > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c > > index f3cadda45f07..9a3f952de6ed 100644 > > --- a/kernel/debug/debug_core.c > > +++

Re: [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb

Hi, On Tue, Oct 30, 2018 at 4:56 AM Daniel Thompson wrote: > > On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote: > > Looking back, this is pretty much two series squashed that could be > > treated indepdently. The first is a serial series and the second is a > > kgdb series. > >

Re: [PATCH 7/7] kgdb: Remove irq flags and local_irq_enable/disable from roundup

Hi, On Tue, Oct 30, 2018 at 4:46 AM Daniel Thompson wrote: > > On Mon, Oct 29, 2018 at 11:07:07AM -0700, Douglas Anderson wrote: > > The function kgdb_roundup_cpus() was passed a parameter that was > > documented as: > > > > > the flags that will be used when restoring the interrupts. There is >

Re: [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()

Daniel, On Tue, Oct 30, 2018 at 2:42 AM Daniel Thompson wrote: > > On Mon, Oct 29, 2018 at 11:07:06AM -0700, Douglas Anderson wrote: > > In kgdb_roundup_cpus() we've got code that looks like: > > local_irq_enable(); > > smp_call_function(kgdb_call_nmi_hook, NULL, 0); > >

Re: Mac Mini G4 defconfig ?

Hi, On Sun, Dec 17, 2017 at 2:54 AM, Mathieu Malaterre wrote: > On Fri, Dec 15, 2017 at 10:01 PM, Mathieu Malaterre wrote: >> On Fri, Dec 15, 2017 at 9:52 PM, Mathieu Malaterre wrote: >>> On Fri, Dec 15, 2017 at 8:50 PM, Mathieu Malaterre

[PATCH] i2c: Remove unneeded xxx_set_drvdata(..., NULL) calls

from the i2c subsystem. Reported-by: Wolfram Sang w...@the-dreams.de Reported-by: Stephen Warren swar...@wwwdotorg.org Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/i2c/busses/i2c-au1550.c | 1 - drivers/i2c/busses/i2c-bfin-twi.c | 2 -- drivers/i2c/busses

Re: [PATCH v2] of: Change logic to overwrite cmd_line with CONFIG_CMDLINE

I know this is a long-dead thread, but I was a little curious about the motivation here. I'm looking at trying to support CONFIG_CMDLINE_EXTEND (an ARM Kconfig) in this function and don't know in which cases I should look at the CONFIG_CMDLINE and in which cases I should use whatever happened to