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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
