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