lkml.org 
[lkml]   [2008]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
    Date
    On Wednesday, 2 of January 2008, Ingo Molnar wrote:
    >
    > * Rafael J. Wysocki <rjw@sisk.pl> wrote:
    >
    > > Hi,
    > >
    > > Some device drivers register CPU hotplug notifiers and use them to
    > > destroy device objects when removing the corresponding CPUs and to
    > > create these objects when adding the CPUs back.
    > >
    > > Unfortunately, this is not the right thing to do during
    > > suspend/hibernation, since in that cases the CPU hotplug notifiers are
    > > called after suspending devices and before resuming them, so the
    > > operations in question are carried out on the objects representing
    > > suspended devices which shouldn't be unregistered behing the PM core's
    > > back.  Although right now it usually doesn't lead to any practical
    > > complications, it will predictably deadlock if
    > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is
    > > applied.
    > >
    > > The solution is to prevent drivers from removing/adding devices from
    > > within CPU hotplug notifiers during suspend/hibernation using the
    > > FROZEN bit in the notifier's action argument. However, this has to be
    > > done with care, since the devices objects related to the nonboot CPUs
    > > that failed to go online during resume should not be present in the
    > > system. For this reason, it seems reasonable to introduce a mechanism
    > > allowing drivers to ask the PM core to remove device objects
    > > corresponding to suspended devices on their behalf.
    > >
    > > The first patch in the series introduces such a mechanism. The
    > > remaining three patches modify the MSR, x86-64 MCE and cpuid drivers
    > > in accordance with the above approach.
    >
    > btw., it would be really, really cool if there was a scriptable way i
    > could test suspend/resume functionality.

    First, there are patches queued for 2.6.25 that allow you to test various
    phases of suspend (specifically, patches 09-11 in the series at
    http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/patches/).

    With these patches applied you can do something like:
    # echo core > /sys/power/pm_test
    # echo mem > /sys/power/state
    and it will run the suspend code up to, but not including, entering the sleep
    state (it will busy wait for 5 sec. instead). Then, it will run the resume
    code.

    There are 6 testing levels available, documented in patch 11 and in the
    changelogs.

    Second, there's the rtc wakealarm thing that can be used to test the real
    suspend.

    > Pavel has this /dev/rtc thing to set up an alarm (not sure how functional it
    > is) - would it be possible to have it as a "suspend for 10 seconds then
    > resume" debug functionality?

    Well, we have the following test script in the userland suspend package that
    is supposed to work right now:

    #!/bin/bash
    date
    cd /sys/class/rtc/rtc0
    echo $(( $(cat since_epoch) + 20 )) > wakealarm
    s2ram
    date

    provided that the new rtc driver code is compiled (and the old one is not).

    > That way any suspend breakage would be detectable (and bisectable) in
    > automated testing - if the resume does not come back after 10-20 seconds then
    > the test failed.

    Yes, but please note that some systems require user space manipulations of the
    graphics adapter for suspend to work and to detect a breakage of such a system
    you need to boot it into X and use s2ram to suspend.

    Greetings,
    Rafael
    --
    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: 2008-01-02 13:57    [W:2.887 / U:0.284 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site