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    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean