Messages in this thread | | | Date | Thu, 10 Dec 2009 14:46:02 -0800 | From | "Justin P. Mattock" <> | Subject | Re: [PATCH] ACPICA: don't cond_resched() when irq_disabled or in_atomic |
| |
On 12/10/09 10:37, Alexey Starikovskiy wrote: > Pavel Machek пишет: >> On Thu 2009-12-10 20:58:45, Alexey Starikovskiy wrote: >> >>> Hi Pavel, >>> >>> Please elaborate... Your comments "ugly as hell" are too often to be >>> specific... >>> There is only one use of ACPI_PREEMPTION_POINT(), and it is in the >>> ACPICA code, >>> which we all agreed to keep OS independent, thus the need for #define. >>> Do you see any other way to add preemption point without introducing >>> Linux-specific >>> code into ACPICA? >>> >> >> I believe we want linux-specific code in acpica at this point. >> >> > The point there we call cond_resched() in ACPICA is an interpreter parse > loop. This parse loop may be executed from within atomic context and even > with interrupts off. In this case, cond_resched() should not be called > to not make > might_sleep() guards angry. > > Please post the code, which will do the above and will not look "ugly as > hell". > I still don't follow your vague comments. >> (Or maybe... I guess other systems have concept of preemption and not >> all actions are permitted from all contexts, so maybe something like >> that would be important for them, too?) >> > None of them cared about it up to this point. > With the macro above we allowed them to follow Linux, but to go or not > is their call. > > Regards, > Alex. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
o.k. I went did a pull to update the kernel, and then changed aclinux.h to the above post.
I'm am not seeing this warning message upon wake-up. but with the acpi merge stuff with acpi_walk_namespace seems to break nvidia (nvidia's problem now)
there is also some thing where the machine takes a good 30 secs or so to wake up (not sure if this is from the updated patch) in dmesg I see:
platform microcode: firmware requesting intel-ucode/06-17-0a firmware microcode: parent mocrocode should not be sleeping.
I'm thinking I need something in /lib/firmare
Justin P. Mattock -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |