lkml.org 
[lkml]   [2009]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH] ACPICA: don't cond_resched() when irq_disabled or in_atomic
Let me know when you guys have finalized any changes to aclinux.h, and I will update this file in the base ACPICA code.

Bob


>-----Original Message-----
>From: Justin P. Mattock [mailto:justinmattock@gmail.com]
>Sent: Thursday, December 10, 2009 2:46 PM
>To: Alexey Starikovskiy
>Cc: Pavel Machek; Xiaotian Feng; lenb@kernel.org; Lin, Ming M; Moore,
>Robert; linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org
>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/

\
 
 \ /
  Last update: 2009-12-10 23:57    [W:0.127 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site