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

Linus Torvalds
2009-01-16T17:08:18Z

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).

Linus