chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

* chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro
@ 2020-07-08  7:18 Jiri Slaby
  2020-07-08  7:47 ` Linus Walleij
  0 siblings, 1 reply; 21+ messages in thread
From: Jiri Slaby @ 2020-07-08  7:18 UTC (permalink / raw)
  To: Linus Walleij, linux-gpio, Mika Westerberg, andy

Hi,

I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
even then it encounters lags, soft lockups:
> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]

spurious interrupts:
> irq 37: nobody cared (try booting with the "irqpoll" option)
> irq 80: nobody cared (try booting with the "irqpoll" option)
> irq 80: nobody cared (try booting with the "irqpoll" option)
> irq 37: nobody cared (try booting with the "irqpoll" option)

and similar. The irq handling is somehow screwed, as:

>  handlers:
>  [<00000000bfbdfc1a>] irq_default_primary_handler threaded [<00000000de877971>] int3496_thread_isr [extcon_intel_int3496]

But irq_default_primary_handler returns WAKE_THREAD and
int3496_thread_isr returns HANDLED. So something must have triggered a
lot of interrupts before the handler was instantiated.

When I run perf top, I see chv_gpio_irq_ack and chv_gpio_irq_handler at
the very top. Monitoring /proc/interrupts shows, that there are ~33000
interrupts/s from:
>   88:    2134217          0          0          0  chv-gpio    8  home
or
>   89:     221232          0          0          0  chv-gpio    3  INT3496:00

depending on what loads first -- the first is from soc_button_array
module, the second from extcon_intel_int3496.

If I blacklist *both* the modules, the system boots and works fine
(except of, I suppose, the vga connector and some buttons).

I tried this: > --- a/drivers/pinctrl/intel/pinctrl-cherryview.c
> +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
> @@ -1469,6 +1469,13 @@ static const struct dmi_system_id chv_no_valid_mask[] = {
>                         DMI_MATCH(DMI_PRODUCT_NAME, "Celes"),
>                 },
>         },
> +       {
> +               .ident = "UMAX VisionBook 10Wi Pro",
> +               .matches = {
> +                       DMI_MATCH(DMI_SYS_VENDOR, "UMAX"),
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "VisionBook 10Wi Pro"),
> +               },
> +       },
>         {}
>  };
>  
> @@ -1578,6 +1585,7 @@ static int chv_gpio_probe(struct chv_pinctrl *pctrl, int irq)
>         if (need_valid_mask) {
>                 chip->irq.init_valid_mask = chv_init_irq_valid_mask;
>         } else {
> +               pr_info("%s: XXX quirk\n", __func__);
>                 irq_base = devm_irq_alloc_descs(pctrl->dev, -1, 0,
>                                                 community->npins, NUMA_NO_NODE);
>                 if (irq_base < 0) {

But it doesn't help (despite the message is logged). Any ideas?

Output of /proc/interrupts and with CONFIG_GENERIC_IRQ_DEBUGFS enabled
# head -100 /sys/kernel/debug/irq/domains/* /sys/kernel/debug/irq/irqs/*
is here:
https://paste.opensuse.org/view/raw/32092261

Note 125 is the stormed interrupt there now.

This is with 5.7.7, but 5.3.18 behaves the same. With the latter, the
module blacklisting doesn't help or I screwed up testing.

thanks,
-- 
js
suse labs

^ permalink raw reply	[flat|nested] 21+ messages in thread