> > Now I know why I had strange "scheduling in atomic" problems: > > acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC > > : GFP_KERNEL)... which is (of course) broken. > > That is kinda weird. When did this all start happening? > > There's no way to reliably tell if we need GFP_ATOMIC or not from > > code, this one for example fails to detect spinlocks held. > Len, this looks like 2.6.28 material. But given the poor quality of > the changelog it is hard to be sure about this. Why isn't everyone > seeing these warnings? What did Pavel do to provoke these alleged > warnings? Nobody knows... I don't know know why pavel sees this and nobody else -- maybe something unusual he's doing with suspend? The reason that the ACPI code is littered with bogus irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL) is because, like boot, resume starts life with interrupts off. I would prefer that resume and boot handle this the same way, with system_state. However, a few years ago when I suggested using system_state for resume, Andrew thought that was a very bad idea. Andrew, do you still feel that way? -Len ps. I'll put this particular fix in my tree now. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
