Re: [PATCH] irq: provide debug_poll_all_shared_irqs() method under CONFIG_DEBUG_SHIRQ

Ingo Molnar
2009-01-16T17:11:49Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, 16 Jan 2009, Ingo Molnar wrote:
> >
> > The sooner we start seeing these kinds of problems the better -
> > delaying debug patches to after feature work is never a good idea -
> > delaying feature changes works much better ;-)
>
> The problem with this particular debug feature is that when it finds
> something, the machine usually just hangs because the interrupt handler
> is just looping over reading some status register that returns 0xff, and
> thinks that means "interrupt pending".
>
> Or maybe it's not looping, it's using some value as an index, or just
> isn't ready to be called at all because it shut down things and as a
> result it actually crashes with a NULL pointer dereference or something.
>
> And if you are in the middle of a resume, the result is not pretty. The
> crash is often totally undebuggable. You can test it by using the
> 'no_console_suspend' and 'acpi_sleep=s3_bios' kernel parameters, and
> _maybe_ it will get things working. You're probably more likely to get a
> working setup if you use VGA text mode rather than FBCON, though.
>
> In other words: the actual problems you hit tend to be very similar to
> the nasty problems that DEBUG_SHIRQ can uncover - but with the _normal_
> DEBUG_SHIRQ you at least usually have a console, so you can add printk's
> to see where it happened, and you get oopses etc.
>
> So I do think this is worth doing as a "make it easier to _see_ all the
> nasty suspend/resume problems", but at the same time it's going to be
> really really painful to debug, and it's not an option we can likely
> ever enable in some distro kernel - because a regular user can't even
> send a bug-report (just a "resume used to work, now it stopped working"
> thing).

Yeah, indeed. Perhaps a sysctl that turns it off by default might help?
Under CONFIG_PM_DEBUG or so.

Ingo