I could use some power management help, please.
I like to suspend my system with Software Suspend 2 (or Tux on Ice, as it seems to be rebranding itself) when I'm not using it.
However, since I upgraded my kernel from 2.6.20.6 to 2.6.22.5, the system sometimes (perhaps 25% of the time) fails to resume after a suspend.
I've got suspend2 logging very verbosely. A successful suspend/resume cycle writes ~11kB of stuff to /var/log/messages, whereas a failed suspend/resume cycle writes ~1.4MB.
The first place the two sets of logs differ is that, where the successful cycle writes
Stopping tasks ... done. Preparing Image. Try 1. Preparing Image. Try 1. Stopping tasks ... done. Starting to save the image.. Starting to save the image.. - Final values: 23908 and 102848.
Writing caches... Writing caches... 20%...40%...60%...80%...100%...done.
The failed cycle writes (I've snipped out instances of IPtables logging rejected packets, and some messages from gpm and sleepd.)
Stopping tasks ... geset+0x11d/0x1a9 [<c01391b7>] do_suspend2_step+0x2d7/0x649 [<c0139816>] _suspend2_try_suspend+0xab/0xe1 [<c0138678>] suspend2_attr_store+0x180/0x1c6 [<c0193100>] sysfs_write_file+0xa8/0xd1 [<c0193058>] sysfs_write_file+0x0/0xd1 [<c015c58f>] vfs_write+0x8a/0x10c [<c015ca25>] sys_write+0x41/0x67 [<c0103ace>] sysenter_past_esp+0x5f/0x85 [<c0720000>] ieee80211_process_probe_response+0x122/0xe4d ======================= Mem-info: DMA per-cpu: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Normal per-cpu: CPU 0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 13 Active:0 inactive:0 dirty:0 writeback:0 unstable:0 free:724 slab:2680 mapped:21865 pagetables:670 bounce:0 DMA free:1968kB min:88kB low:108kB high:132kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 483 Normal free:928kB min:2764kB low:3452kB high:4144kB active:0kB inactive:0kB present:494668kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 DMA: 0*4kB 0*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1968kB Normal: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 928kB Swap cache: add 78, delete 77, find 18/27, race 0+0 Free swap = 505444kB Total swap = 1015800kB Free swap: 505444kB 128736 pages of RAM 0 pages of HIGHMEM 4191 reserved pages 171366 pages shared 1 pages swap cached 0 pages dirty 0 pages writeback 21865 pages mapped 2680 pages slab 670 pages pagetables 20%...40%...60%...80%...100%...done.
Any ideas, please?
On Wed, Sep 05, 2007 at 03:07:42PM +0100, Dan Hatton wrote:
I could use some power management help, please.
I like to suspend my system with Software Suspend 2 (or Tux on Ice, as it seems to be rebranding itself) when I'm not using it.
Personally I use the mainstream kernel stuff, which seems to do the trick ok.
However, since I upgraded my kernel from 2.6.20.6 to 2.6.22.5, the system sometimes (perhaps 25% of the time) fails to resume after a suspend.
I've got suspend2 logging very verbosely. A successful suspend/resume cycle writes ~11kB of stuff to /var/log/messages, whereas a failed suspend/resume cycle writes ~1.4MB.
The first place the two sets of logs differ is that, where the successful cycle writes
Stopping tasks ... done. Preparing Image. Try 1. Preparing Image. Try 1. Stopping tasks ... done. Starting to save the image.. Starting to save the image..
- Final values: 23908 and 102848.
Writing caches... Writing caches... 20%...40%...60%...80%...100%...done.
The failed cycle writes (I've snipped out instances of IPtables logging rejected packets, and some messages from gpm and sleepd.)
Stopping tasks ... geset+0x11d/0x1a9 [<c01391b7>] do_suspend2_step+0x2d7/0x649 [<c0139816>] _suspend2_try_suspend+0xab/0xe1 [<c0138678>] suspend2_attr_store+0x180/0x1c6 [<c0193100>] sysfs_write_file+0xa8/0xd1 [<c0193058>] sysfs_write_file+0x0/0xd1 [<c015c58f>] vfs_write+0x8a/0x10c [<c015ca25>] sys_write+0x41/0x67 [<c0103ace>] sysenter_past_esp+0x5f/0x85 [<c0720000>] ieee80211_process_probe_response+0x122/0xe4d ======================= Mem-info: DMA per-cpu: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Normal per-cpu: CPU 0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 13 Active:0 inactive:0 dirty:0 writeback:0 unstable:0 free:724 slab:2680 mapped:21865 pagetables:670 bounce:0 DMA free:1968kB min:88kB low:108kB high:132kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 483 Normal free:928kB min:2764kB low:3452kB high:4144kB active:0kB inactive:0kB present:494668kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 DMA: 0*4kB 0*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1968kB Normal: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 928kB Swap cache: add 78, delete 77, find 18/27, race 0+0 Free swap = 505444kB Total swap = 1015800kB Free swap: 505444kB 128736 pages of RAM 0 pages of HIGHMEM 4191 reserved pages 171366 pages shared 1 pages swap cached 0 pages dirty 0 pages writeback 21865 pages mapped 2680 pages slab 670 pages pagetables 20%...40%...60%...80%...100%...done.
Any ideas, please?
Your backtrace appears to be related to wireless. Has your wireless driver changed from the old to new kernels? (eg moved in tree)
J.
Jonathan McDowell noodles@earth.li wrote:
Personally I use the mainstream kernel stuff, which seems to do the trick ok. [...] Your backtrace appears to be related to wireless.
That reminds me: the wireless driver is one of the few modules I still have to rmmod in my suspend script before the kernel suspend is called, then bring the wireless interface back up afterwards. Maybe a similar trick would work for the OP.
Regards,
On Sat, 8 Sep 2007, Jonathan McDowell wrote:
Your backtrace appears to be related to wireless. Has your wireless driver changed from the old to new kernels? (eg moved in tree)
"make oldconfig" asked me about it ("it" being ipw2200,) so I guess so.
Is that an important clue?
On Sun, 9 Sep 2007, Dan Hatton wrote:
"make oldconfig" asked me about it ("it" being ipw2200,) so I guess so.
Is that an important clue?
BTW, before anyone spends too much time and effort answering that, note that the folks over on suspend2's own mailing list have suggested my problem is a known memory allocation issue.
-
Dan Hatton -
Jonathan McDowell -
MJ Ray