<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.linux.power-management.general">
    <title>gmane.linux.power-management.general</title>
    <link>http://blog.gmane.org/gmane.linux.power-management.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12215"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12214"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12209"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12208"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12203"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12200"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12197"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12191"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12190"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12168"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12148"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12137"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12127"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12123"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12122"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12121"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12118"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12114"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12057"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.power-management.general/12056"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12215">
    <title>[RFC] Tying sysfs "wakeup" file to platform-level handler</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12215</link>
    <description>

Hi,

On the OLPC XO laptop, we want a way to enable/disable wakeup events for 
a device from userspace at suspend time depending on the method we are 
using for suspending. For example, if the system auto-suspends, we want 
to wake up on input from the PS2 device; if the user shuts the lid, we 
want to wakeup on lid state change events; if the user presses the power 
button to suspend, we only want to wakeup on another power button event.

We have currently exported a set of files via sysfs in 
/sys/power/wakeup_events as such:

bash-3.2# ls /sys/power/wakeup_events/
ac_power  battery_error  battery_state      ps2event
all       battery_soc    ebook_mode_change  wlan

Writing a 1 to one of these files will enable that device as a wake up 
source in the Embedded Controller (EC). Writing a 0 will disable it. See 
[1] for code. This interface works but I would like to replace it with 
something that can be pushed upstream.

Each of the devices we care about already has an entry in the sysfs tree 
or could hav</description>
    <dc:creator>Deepak Saxena</dc:creator>
    <dc:date>2008-11-24T20:01:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12214">
    <title>2.6.28-rc6-git1: Reported regressions from 2.6.27</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12214</link>
    <description>This message contains a list of some regressions from 2.6.27, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.27, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-11-22       93       25          15
  2008-11-16       89       32          18
  2008-11-09       73       40          27
  2008-11-02       55       41          29
  2008-10-25       26       25          20


Unresolved regressions
----------------------

Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=12064
Subject: [regression] Measured 688 cycles TSC warp; </description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-22T20:24:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12209">
    <title>Crash during suspend to disk</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12209</link>
    <description>Hi

I hope this information is sufficient to debug my problem, though it
unfortunately is somewhat incomplete. I took two pictures of the OOPS
with my mobile phone, but unfortunately the picture of the upper part is
so blurred that it is unreadable. Apparently I have to be in a hurry
getting out of the door for this to happen. Here is what I got from the
lower part

Call Trace:
  __blkdev_put
  swsusp_write
  hibernate
  state_store
  state_store
  state_store
  kobj_attr_store
  sysfs_write_file
  sysfs_write_file
  vfs_write
  sys_write
  sysenter_do_call
Code: ......
EIP: [&lt;...&gt;] iput
---[ end trace ........................... ]---

There is a lot of blanks here that I should be able provide on request
as well.

The problem occured in my third attempt in quick succession to suspend
to disk. The first two did not succeed due to insufficient free swap. I
got 768 MB ram and a ~1 GB swap partition. I believe top said something
like Mem: 3xxxxxk used and Swap: 6xxxxxk used before the third attempt
to suspend t</description>
    <dc:creator>Simon Holm Thøgersen</dc:creator>
    <dc:date>2008-11-20T12:41:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12208">
    <title>New comer in the linux-pm list</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12208</link>
    <description/>
    <dc:creator>David GIGUET</dc:creator>
    <dc:date>2008-11-20T12:40:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12203">
    <title>Info on hibernation swap space requirement</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12203</link>
    <description>Hi all.

I added the hibernation support on a sh4 based platform and it works fine,
 but I don't understand how big the swap space has to be.

My system has 64Mb and I was assuming, I can freeze ~32 Mb therefore
 I was creating a swap space of 40/50 Mb.

But it seems it isn't enough, the system is requiring more space.

Could you say me how evaluate the right (minimal) swap space required
 when I know the DRam memory size.

Regards
 Francesco

</description>
    <dc:creator>Francesco VIRLINZI</dc:creator>
    <dc:date>2008-11-18T08:59:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12200">
    <title>[PATCH] ACPI suspend: Blacklist boxes that require us toset SCI_EN directly on resume</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12200</link>
    <description>From: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt;
Subject: ACPI suspend: Blacklist boxes that require us to set SCI_EN directly on resume

Some Apple boxes evidently require us to set SCI_EN on resume
directly, because if we don't do that, they hung somewhere in the
resume code path.  Moreover, on these boxes it is not sufficient to
use acpi_enable() to turn ACPI on during resume.  All of this is
against the ACPI specification which states that (1) the BIOS is
supposed to return from the S3 sleep state with ACPI enabled
(SCI_EN set) and (2) the SCI_EN bit is owned by the hardware and we
are not supposed to change it.

For this reason, blacklist the affected systems so that the SCI_EN
bit is set during resume on them.

[NOTE: Unconditional setting SCI_EN for all system on resume doesn't
 work, because it makes some other systems crash (that's to be
 expected).  Also, it is not entirely clear right now if all of the
 Apple boxes require this workaround.]

This patch fixes the recent regression tracked as
http://bugzilla.k</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-17T22:33:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12197">
    <title>[PATCH] Fix misspellings in pm.h macros</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12197</link>
    <description>This patch (as1167) fixes some misspellings in various recently-added
macros in pm.h.  Fortunately these macros are not yet used anywhere.

Signed-off-by: Alan Stern &lt;stern&lt; at &gt;rowland.harvard.edu&gt;
CC: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt;

---

Index: usb-2.6/include/linux/pm.h
===================================================================
--- usb-2.6.orig/include/linux/pm.h
+++ usb-2.6/include/linux/pm.h
&lt; at &gt;&lt; at &gt; -252,7 +252,7 &lt; at &gt;&lt; at &gt; struct dev_pm_ops {
 #define PM_EVENT_SLEEP(PM_EVENT_SUSPEND | PM_EVENT_HIBERNATE)
 #define PM_EVENT_USER_SUSPEND(PM_EVENT_USER | PM_EVENT_SUSPEND)
 #define PM_EVENT_USER_RESUME(PM_EVENT_USER | PM_EVENT_RESUME)
-#define PM_EVENT_REMOTE_WAKEUP(PM_EVENT_REMOTE | PM_EVENT_RESUME)
+#define PM_EVENT_REMOTE_RESUME(PM_EVENT_REMOTE | PM_EVENT_RESUME)
 #define PM_EVENT_AUTO_SUSPEND(PM_EVENT_AUTO | PM_EVENT_SUSPEND)
 #define PM_EVENT_AUTO_RESUME(PM_EVENT_AUTO | PM_EVENT_RESUME)
 
&lt; at &gt;&lt; at &gt; -265,15 +265,15 &lt; at &gt;&lt; at &gt; struct dev_pm_ops {
 #define PMSG_THAW((struct pm_message){ .event = PM_EVENT_THAW, })
 #def</description>
    <dc:creator>Alan Stern</dc:creator>
    <dc:date>2008-11-17T16:14:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12191">
    <title>2.6.28-rc5: Reported regressions from 2.6.27</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12191</link>
    <description>[NOTES:
 (1) Due to some recent controversies, in future I will only use 'Handled-By'
     tags for people who actually submit a patch or provide substantial help to
     the reporter (like advising him which commits to revert etc.).
 (2) We have almost as many regressions with patches as unresolved ones and
     the majority of these patches have not been merged for over two weeks
     (for almost three weeks in many cases and for over a _month_ in one case).
     IMO, this is insane.]

This message contains a list of some regressions from 2.6.27, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.27, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


List</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-16T16:24:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12190">
    <title>Suspend regression in 2.6.25.18</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12190</link>
    <description>Hi Thomas,

Your commit

commit ffa4da2a25bb4ac08f710ac99827baf48a8f8d57
Author: Thomas Gleixner &lt;tglx&lt; at &gt;linutronix.de&gt;
Date:   Wed Sep 3 21:37:08 2008 +0000

    clockevents: prevent multiple init/shutdown

    commit 9c17bcda991000351cb2373f78be7e4b1c44caa3 upstream

    Signed-off-by: Thomas Gleixner &lt;tglx&lt; at &gt;linutronix.de&gt;
    Signed-off-by: Ingo Molnar &lt;mingo&lt; at &gt;elte.hu&gt;
    Signed-off-by: Greg Kroah-Hartman &lt;gregkh&lt; at &gt;suse.de&gt;

is reported to cause a resume regression on Lenovo x60, x41 and x61 (probably
other Lenovo boxes are affected as well) with 2.6.25.18.  At the same time, the
2.6.27.y kernels are reported to work correctly for the affected users.

Can you please try to identify the updstream commits that fix the problem on
these boxes?

Thanks,
Rafael
</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-16T13:04:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12168">
    <title>pm support</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12168</link>
    <description/>
    <dc:creator>Peter Reid</dc:creator>
    <dc:date>2008-11-12T11:30:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12148">
    <title>Suspend to disk broken in latest 2.6.28-rc3</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12148</link>
    <description>Hello Pavel and Rafael,

I've just finished compiling a recent snapshot of rc3 (namely gfed4d59
[1]) on a F9 distro (gcc 4.3.0 20080428) and suspend to disk doesn't
work anymore.  My config is attached below [2].

It just freezes my laptop (an old Thinkpad T30) while it works with
kernel version 2.6.26 (I've never tried 2.6.27).

I've tried playing with the pm_test facility, and while the "freezer"
test works, the "devices" test fails like the real suspend...

When that happens, the console still works (ie I can switch VTs and
type) but the whole system doesn't respond: I can't login for example...
Guess the disk driver is already off at that point.

I don't have another computer to capture a serial trace so I guess I'm
going to try to bisect it (which is going to take while on this slow
computer).  If I reconfigure my syslog could I get the output of the
suspend process on the screen (for some reason I used to get it during
suspend but now I only get it during resume)?

Any ideas or pointers to fix this ap</description>
    <dc:creator>Mathieu Chouquet-Stringer</dc:creator>
    <dc:date>2008-11-09T19:50:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12137">
    <title>2.6.28-rc3-git6: Reported regressions from 2.6.27</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12137</link>
    <description>This message contains a list of some regressions from 2.6.27, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.27, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-11-09       73       40          27
  2008-11-02       55       41          29
  2008-10-25       26       25          20


Unresolved regressions
----------------------

Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=11996
Subject: Tracing framework regression in 2.6.28-rc3
Submitter: Pekka Paalanen &lt;pq&lt; at &gt;iki.fi&gt;
Date: 2008-11-09 10:13 (1 days old)
Reference</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-09T17:53:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12127">
    <title>Wakeup events?</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12127</link>
    <description/>
    <dc:creator>Peter Reid</dc:creator>
    <dc:date>2008-11-08T14:50:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12123">
    <title>[PATCH -next] Hibernate: Do not oops on resume if imagedata are incorrect</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12123</link>
    <description>Hi Len,

Please add this patch to the suspend branch.

Thanks,
Rafael


---
From: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt;
Subject: Hibernate: Do not oops on resume if image data are incorrect

During resume from hibernation using the userland interface image
data are being passed from the used space process to the kernel.
These data need not be valid, but currently the kernel sometimes
oopses if it gets invalid image data, which is wrong.  Make the
kernel return error codes to the user space in such cases.

Signed-off-by: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt;
Cc: Pavel Machek &lt;pavel&lt; at &gt;suse.cz&gt;
---
 kernel/power/snapshot.c |   43 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 32 insertions(+), 11 deletions(-)

Index: linux-2.6/kernel/power/snapshot.c
===================================================================
--- linux-2.6.orig/kernel/power/snapshot.c
+++ linux-2.6/kernel/power/snapshot.c
&lt; at &gt;&lt; at &gt; -529,6 +529,14 &lt; at &gt;&lt; at &gt; static int memory_bm_test_bit(struct mem
 return test_bit(bit, addr);
 }
 
+static bool memory</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-08T12:57:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12122">
    <title>[PATCH -next] Hibernate: Take overlapping zones intoaccount</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12122</link>
    <description>Hi Len,

Please add this patch to the suspend branch.

Thanks,
Rafael


---
From: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt;
Subject: Hibernate: Take overlapping zones into account

It has been requested to make hibernation work with memory
hotplugging enabled and for this purpose the hibernation code has to
be reworked to take the possible overlapping of zones into account.
Thus, rework the hibernation memory bitmaps code to prevent
duplication of PFNs from occuring and add checks to make sure that
one page frame will not be marked as saveable many times.

Additionally, use list.h lists instead of open-coded lists to
implement the memory bitmaps.

Signed-off-by: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt;
Cc: Pavel Machek &lt;pavel&lt; at &gt;suse.cz&gt;
Cc: Dave Hansen &lt;dave&lt; at &gt;linux.vnet.ibm.com&gt;
Cc: Andy Whitcroft &lt;apw&lt; at &gt;shadowen.org&gt;
---
 kernel/power/snapshot.c |  331 ++++++++++++++++++++++++------------------------
 1 file changed, 169 insertions(+), 162 deletions(-)

Index: linux-2.6/kernel/power/snapshot.c
=====================================</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-08T12:56:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12121">
    <title>[PATCH] Fix __pfn_to_page(pfn) for CONFIG_DISCONTIGMEM=y</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12121</link>
    <description>Hi Andrew,

This would be good to have in .28 IMO.

Thanks,
Rafael


---
From: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt;
Subject: Fix __pfn_to_page(pfn) for CONFIG_DISCONTIGMEM=y

Fix macro __pfn_to_page(pfn) so that it doesn't evaluate its
argument twice in the CONFIG_DISCONTIGMEM=y case, because 'pfn' may
be a result of a funtion call having side effects.

For example, the hibernation code applies pfn_to_page(pfn) to the
result of a function returning the pfn corresponding to the next set
bit in a bitmap and the current bit position is modified on each
call.  This leads to "interesting" failures for CONFIG_DISCONTIGMEM=y
due to the current behavior of __pfn_to_page(pfn).

Signed-off-by: Rafael J. Wysocki &lt;rjw&lt; at &gt;sisk.pl&gt;
Cc: Pavel Machek &lt;pavel&lt; at &gt;suse.cz&gt;
---
 include/asm-generic/memory_model.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/include/asm-generic/memory_model.h
===================================================================
--- linux-2.6.orig/include/asm-generic/memory_model.</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-08T12:53:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12118">
    <title>Bugs on aspire one A150</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12118</link>
    <description>I have just bought an Aspire one A150, XP version,
as it was the only available here, and installed ubuntu on it.

Bugs I discovered so far:


** 1 - embedded controler works in polling mode, due to this:

[    0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode
[    1.224043] ACPI: EC: missing confirmations, switch off interrupt mode.


Maybe this is the reason for the fact that gnome power manager freezes when I unplug
the AC, and freezes often when I try to see battery status.


(Note: same is seen on my acer aspire 5720)


** 2 - wireless: not to mention the fact that ath5k wasn't installed by default in ubuntu...
wireless more or less works, but kernel log is full of backtraces.
Was able to connect to my WPA2 access point.
Sometimes wireless fails completely, especially after suspend to ram.
Advanced features like monitor/injection work, but when I changed the card's
mac address it stopped working.
I also noticed that if I then start airodump, then wireless works with new mac.
</description>
    <dc:creator>Maxim Levitsky</dc:creator>
    <dc:date>2008-11-08T03:26:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12114">
    <title>Dynamic Idle?</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12114</link>
    <description/>
    <dc:creator>Peter Reid</dc:creator>
    <dc:date>2008-11-07T13:01:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12057">
    <title>[Regression] Suspend failure on NForce4-based boards dueto chanes in stop_machine</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12057</link>
    <description>Hi,

Current mainline (.28-rc3 at the moment) fails to suspend on at least some
machines with dual-core AMD CPUs and NForce4-based mainboards.  The affected
boxes just hang solid during suspend/hibernation, after suspending devices,
probably while the non-boot CPUs are being stopped (I'm able to reproduce this
on two different machines).

Although this is not reproducible 100% of the time, it is reproducible enough
to allow me to carry out bisection, which turned up the following commit as the
source of the problem:

commit c9583e55fa2b08a230c549bd1e3c0bde6c50d9cc
Author: Heiko Carstens &lt;heiko.carstens&lt; at &gt;de.ibm.com&gt;
Date:   Mon Oct 13 23:50:10 2008 +0200

    stop_machine: use workqueues instead of kernel threads

    Convert stop_machine to a workqueue based approach. Instead of using kernel
    threads for stop_machine we now use a an rt workqueue to synchronize all
    cpus.
    This has the advantage that all needed per cpu threads are already created
    when stop_machine gets called. And therefore a call</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-03T00:28:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12056">
    <title>2.6.28-rc2-git7: Reported regressions from 2.6.27</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12056</link>
    <description>This message contains a list of some regressions from 2.6.27, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.27, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-11-02       55       41          29
  2008-10-25       26       25          20


Unresolved regressions
----------------------

Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=11937
Subject: ext3 __log_wait_for_space: no transactions
Submitter: Meelis Roos &lt;mroos&lt; at &gt;linux.ee&gt;
Date: 2008-10-30 9:49 (4 days old)
References: http://marc.info/?l=linux-kernel&amp;m=122</description>
    <dc:creator>Rafael J. Wysocki</dc:creator>
    <dc:date>2008-11-02T16:04:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.power-management.general/12044">
    <title>[RFC PATCH 0/2] orinoco: Don't keep cached firmwarearound permanently</title>
    <link>http://comments.gmane.org/gmane.linux.power-management.general/12044</link>
    <description>The recent patch to load orinoco firmware correctly on resume simply
kept the firmware in RAM for the entire time the module was loaded, and
only applied to Agere firmware.

The first patch uses the new power management notifiers to load and
release the firmware prior to suspend and after resume (for both Agere
and Symbol). I'm not an expert on where suspend/resume is headed, so I'd
appreciate any advice from linux-pm on whether this is the preferred way
to do things.

The second patch makes the spectrum_cs driver actually invoke this
functionality during resume.

David Kilroy (2):
  orinoco: Use PM notifier to cache firmware for use during resume
  orinoco: Resume spectrum_cs in the same way as orinoco_cs

 drivers/net/wireless/orinoco.c     |  140 ++++++++++++++++++++++++++++--------
 drivers/net/wireless/orinoco.h     |    8 ++-
 drivers/net/wireless/spectrum_cs.c |   21 +++++-
 3 files changed, 135 insertions(+), 34 deletions(-)

</description>
    <dc:creator>David Kilroy</dc:creator>
    <dc:date>2008-10-31T01:15:41</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.linux.power-management.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.power-management.general</link>
  </textinput>
</rdf:RDF>
