Hi, On Fri, May 29, 2020 at 10:45 AM Frank Mori Hess <fmh6jj@xxxxxxxxx> wrote: > > On Fri, May 29, 2020 at 12:37 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > > > I'm not sure I understand. Are you saying that you'll just add > > shutdown callbacks to all the drivers using this IRQ and call > > disable_irq() there? That seems like the best solution to me. > > I don't get it. A hypothetical machine could have literally anything > sharing the IRQ line, right? It's not a real physical line, though? I don't think it's common to have a shared interrupt between different IP blocks in a given SoC. Even if it existed, all the drivers should disable their interrupts? > If it is important to call disable_irq > during shutdown (I have no idea if it is) then shouldn't the kernel > core just disable all irqs after calling all the driver shutdown > callbacks? It seems like a reasonable idea for this to be in the core but I haven't dug into whether the core has enough knowledge or if there would be other problems. > Anyways, my screaming interrupt occurs after a a new kernel has been > booted with kexec. In this case, it doesn't matter if the old kernel > called disable_irq or not. As soon as the new kernel re-enables the > interrupt line, the kernel immediately disables it again with a > backtrace due to the unhandled screaming interrupt. That's why the > dwc2 hardware needs to have its interrupts turned off when the old > kernel is shutdown. Isn't that a bug with your new kernel? I've seen plenty of bugs where drivers enable their interrupt before their interrupt handler is set to handle it. You never know what state the bootloader (or previous kernel) might have left things in and if an interrupt was pending it shouldn't kill you. -Doug
