gmane.linux.swsusp.devel

Freeing memory

Harald Judt — 2012-05-21T06:46:53

Hi Nigel,

I've updated to current git in the hope the memory freeing problems 
would be solved. Unfortunately, they are still there and I've been 
trying to narrow the issue down. Actually, there are two issues:

First, the memory eating process seems to lock up the machine when it 
requests too much memory. Commmit 
f8262d476823a7ea1eb497ff9676d1eab2393c75 "PM / Hibernate: fix the number 
of pages used for hibernate/thaw buffering" doesn't help with that. 
Maybe tuxonice needs to play catch up on that? Using smaller values and 
more tries seems to help with the freezes, but I don't know what a safe 
value would be.

Next, there seems to be a limit to what amount of the pagecache is 
freeable using the tuxonice memory eater method. Having a total of 16 
GiB, I increased the max tries and set a limit of max 4096MiB to free 
per try so that it would not freeze, but the memory eater hit some limit 
(at that time 4973MiB) where it could not free more memory. Dropping the 
caches manually via "echo 1 > /proc/sys

BUG() during restore

Antonio Quartulli — 2012-05-01T09:16:18

Hello,

I'm using pf-sources-3.3.3 (vanilla patched with last toi I think..) and during
resume I'm getting a lot of

[  512.314188] BUG: using smp_processor_id() in preemptible [00000000] code:
ktoi_io/2/4196
[  512.314209] caller is worker_rw_loop+0x408/0xbe0
[  512.314212] Pid: 4196, comm: ktoi_io/2 Tainted: G        W    3.3.3-pf #4
[  512.314215] Call Trace:
[  512.314221]  [<ffffffff811f8978>] ? debug_smp_processor_id+0xd8/0xf0
[  512.314224]  [<ffffffff8105ed68>] ? worker_rw_loop+0x408/0xbe0
[  512.314228]  [<ffffffff8104d390>] ? add_wait_queue+0x60/0x60
[  512.314230]  [<ffffffff8105e960>] ? attempt_to_parse_resume_device2+0x20/0x20
[  512.314234]  [<ffffffff8104ca25>] ? kthread+0x85/0x90
[  512.314239]  [<ffffffff81488f94>] ? kernel_thread_helper+0x4/0x10
[  512.314242]  [<ffffffff8104c9a0>] ? kthread_freezable_should_stop+0x60/0x60
[  512.314245]  [<ffffffff81488f90>] ? gs_change+0xb/0xb

I tried to change one onvocation of smp_processor_id() in worker_rw_loop() to
get_cpu() but the result is the sa

Unable to free memory with current tuxonice-git

Harald Judt — 2012-04-26T09:06:44

Hi,

Actually the following error has already been there since >3.2-rc7, but 
until now I simply worked around it using echo 1 > /proc/sys/vm/drop_caches.

In short, tuxonice can't free enough memory:

TuxOnIce 3.2.1, with support for usm, compression, block i/o, swap 
storage, userui.
Initiating a hibernation cycle.
Using configuration file /etc/splash/tuxonice/1920x1080.cfg.
No silent picture specified in the theme config.
Framebuffer support initialised successfully.
Starting other threads.Freezing user space processes ... (elapsed 0.01 
seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Restarting kernel threads ... done.
Asked shrink_all_memory for 2028770 low pages & 610379 pages from 
anywhere, got 0.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Restarting kernel threads ... done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Restarting kernel threads ... done.
Asked shrink_all_memory for 2013849 low pages & 595383 pages from

BFS vs Tuxonice issue

Harald Judt — 2012-04-23T18:08:21

Hi Nigel,

Did you have time to look into the BFS compatibility issue when 
multi-threaded compression is enabled?

With the current tuxonice 3.2.1 linux-3.3.2 from git I get the following 
error now (it's the same message repeated many many many times):

BUG: scheduling while atomic: BFS/2/0/0x00000002
Modules linked in: tun ehci_hcd w83627ehf hwmon_vid coretemp ipt_REJECT 
ipt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
xt_multiport ipv6 iptable_filter ip_tables x_tables vboxdrv(O) loop 
joydev gspca_pac207 gspca_main videodev v4l2_compat_ioctl32 usbhid 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_emu10k1 
snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi 
snd_seq_device snd_hda_codec sr_mod xhci_hcd usbcore 8250_pnp 8250 
serial_core emu10k1_gp gameport snd_pcm processor snd_page_alloc 
snd_timer snd soundcore usb_common i2c_i801 thermal_sys button [last 
unloaded: ehci_hcd]
Pid: 0, comm: BFS/2 Tainted: G      D    O 3.3.2+ #24
Call Trace:
  [<ffffffff813f

Cannot hibernate using tuxonice

Niren Sinha — 2012-04-20T11:28:57

Hi,

I have been trying to hibernate my desktop (AMD, Ubuntu 11.10, Nvidia
Graphic Drivers) and so far I am not able o successfully do it. Ubuntu
kernel was always a problem, but in earlier tuxonice use to work perfectly
alright. Every since I upgrade to 11.10, I can't hibernate using TOI.

Please help me in debugging this issue. Attached are the files.

Thanks,
Niren Sinha | nirensinha< at >gmail.com
_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel

ifdefs fixes for TOI

Oleksandr Natalenko — 2012-04-12T19:28:31

Hi. Nigel.

The following changes since commit ce3052791e80fd1cab87da52dd6e4d675b33ede5:

  add ifdefs to handle CONFIG_FREEZER properly (2012-04-12 22:14:42 +0300)

are available in the git repository at:

  git://github.com/pfactum/pf-kernel.git toi-fixes-for-3.3-1

for you to fetch changes up to ce3052791e80fd1cab87da52dd6e4d675b33ede5:

  add ifdefs to handle CONFIG_FREEZER properly (2012-04-12 22:14:42 +0300)

Regards,
  post-factum

_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel

userspace ui doesn't work with latest tuxonice-head

François Valenduc — 2012-04-08T10:05:40

Hello everybody,

I have tried the latest tuxonice-head git tree and I notice that the
userspace interface doesn't work. I get this message in the logs:
 pc-francois kernel: [   48.132314] userspace ui: Failed to contact
userspace process.
I don't encounter this problem with tuxonice on the 3.3 kernel.

Does anybody knows what's happening ?
Thanks in advance for your help.

TOI fails with 3.3

Oleksandr Natalenko — 2012-04-06T12:27:31

Hi!

I've experienced bunch of problems with TOI branch for Linux 3.3. First,
kernel oopsed on b43 driver during hibernation, then I repeated
hibernation and got kernel panic. Third try was broken because TOI
didn't find storage…

Are those problem well-known? What should I try to report about first?

Regards,
  post-factum

_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel

duplicate boot_kernel_data_buffer

2012-03-20T04:42:01

Hi all,

I'm doing porting development of the TuxOnIce to ARM/BeagleBoard. 
I'm investigating the phenomenon (The board freezes at the time of RESUME) where RESUME is not stabilized, 
and I have a question about boot_kernel_data_buffer. 

The debugging code for displaying restore_pblist was added. (below)

When the phenomenon to freeze occurs, orig_address of boot_kernel_data_buffer is displayed(printk output) twice. 

Please tell me whether it is a bug that there is a duplicate to pblist boot_kernel_data_buffer.


tuxonice_pagedir.c:
int add_boot_kernel_data_pbe(void)
{
this_low_pbe->address = (char *) __toi_get_nonconflicting_page();
if (!this_low_pbe->address) {
printk(KERN_INFO "Failed to get bkd atomic restore buffer.");
return -ENOMEM;
}

toi_bkd.size = sizeof(toi_bkd);
memcpy(this_low_pbe->address, &toi_bkd, sizeof(toi_bkd));

*last_low_pbe_ptr = this_low_pbe;
this_low_pbe->orig_address = (char *) boot_kernel_data_buffer;
this_low_pbe->next = NULL;

/*********************** DEBUG CODE ****

task kworker/1:0:9 blocked for more than 120seconds after resume

nai.xia — 2012-03-20T01:30:21

Hi all,


Today I tried tuxonice 3.2.1 (I got from git and merged it with ubuntu's 3.2 kernel).
Tuxonice can hibernate easily, but after it resumes, I saw this:

---
Mar 20 09:06:44 raynor kernel: [  182.064578] TuxOnIce debugging info:
Mar 20 09:06:44 raynor kernel: [  182.064578] - TuxOnIce core  : 3.2.1
Mar 20 09:06:44 raynor kernel: [  182.064578] - Kernel Version : 3.2.0-19-generic-tuxonice
Mar 20 09:06:44 raynor kernel: [  182.064579] - Compiler vers. : 4.6
Mar 20 09:06:44 raynor kernel: [  182.064579] - Attempt number : 1
Mar 20 09:06:44 raynor kernel: [  182.064579] - Parameters     : 0 667656 0 1 -2 5
Mar 20 09:06:44 raynor kernel: [  182.064580] - Overall expected compression percentage: 0.
Mar 20 09:06:44 raynor kernel: [  182.064580] - Checksum method is 'md4'.
Mar 20 09:06:44 raynor kernel: [  182.064580]   0 pages resaved in atomic copy.
Mar 20 09:06:44 raynor kernel: [  182.064581] - Compressor is 'lzo'.
Mar 20 09:06:44 raynor kernel: [  182.064581]   Compressed 1007841280 bytes into 349281655

Back to BFS+TOI issue

Oleksandr Natalenko — 2012-03-08T23:20:48

Hi all.

I mailed Con Kolivas about TOI+BFS issue and he answered that won't fix
it as BFS is written to get mainline hibernation work but not TOI. He is
surprised that BFS+TOI works *somehow*.

The only quote about technical reason is:

"I suspect that something to do with the way the
compression threads are woken up on resume is broken when run on BFS."

So the last hope is Nigel.

As BFS+TOI users community is large enough, I expect it to help solving
the issue at least by providing debug info. We really need these
3rd-party patches work together.

For now, I discovered that LZO fails as well as LZF does, but with
different error.

In case of LZF it fails at tuxonice_compress.c:257 (outlen != PAGE_SIZE).

In case of LZO it fails at tuxonice_compress.c:254 (ret), and also at
tuxonice_io.c:645 (io_pageset == 1).

So crypto_comp_decompress call at tuxonice_compress.c:245 fails. Why —
no idea. I cannot investigate it deeper because of lack of knowledge
about kernel internals.

Nigel, help us if you can. Hop

TOI inactivity

Oleksandr Natalenko — 2012-03-06T09:35:48

Hey!

What happened to TOI web-site? When we should expect git tree update?

Regards,
  post-factum

_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel

[ARM hibernation ] How to deal with PMem in android during hibernation ?

wang leileis — 2012-02-13T16:01:09

HI ,



I'm working on hibernation of android in i.MX53 platform.
And I add this patch into kernel source from this link:
http://www.spinics.net/lists/arm-kernel/msg108560.html

At last, I find that this patch can not resume all of alloced memory
form PMem after resume for disk.
As we know, android add the new driver PMem into kernel. And android's
MM(memory manager) can not find and control alloced memory of PMem.


Maybe TOI's patch  can deal with this issue. is it really?
And how to implement ?






Thanks,
Ryan

Hello to the list - and Ubuntu Lucid, 2 luks partitions, 2 VGs, resume fails with "resume: device not found"

gurunixx — 2012-02-13T04:34:56

Hi.  First post :-)

This is a laptop, a W500, and with a new client, I need it to 
hibernate and resume quickly - which means TuxOnIce...... there's a 
guy with a MBP who often sits next to me, and he's making me look bad :-D

I have Ubuntu Lucid, 32-bit.  Two hard drives.  There's a luks 
partition on each drive - each of which has lvm on it.  /etc/crypttab 
reflects the second luks partition, which of course has a different 
volume group on it --- vg #2 uses a key file, in /etc/ on root LV on 
the first vg.

So, on boot, I see the prompt for the pass phrase for luks #1, for vg 
#1.  Then, immediately, I get an error from tuxonice:

Key slot 0 unlocked.
    8 logical volume(s) in volume group "wallevg0" now active
udevd-work[611]: inotify_add_watch(6, /dev/dm-8, 10) failed: No such 
file or directory
Done.
Begin: Running /scripts/local-premount ...
resume: libgcrypt version: 1.4.4
resume: Could not stat the resume device file '/dev/disk/by-uuid/UUID1'
      Please type in the full path name to try again

G

Hello to the list - and Ubuntu Lucid, 2 luks partitions, 2 VGs, resume fails with "resume: device not found"

gurunixx — 2012-02-13T04:30:41

Hi.  First post :-)

This is a laptop, a W500, and with a new client, I need it to 
hibernate and resume quickly - which means TuxOnIce...... there's a 
guy with a MBP who often sits next to me, and he's making me look bad :-D

I have Ubuntu Lucid, 32-bit.  Two hard drives.  There's a luks 
partition on each drive - each of which has lvm on it.  /etc/crypttab 
reflects the second luks partition, which of course has a different 
volume group on it --- vg #2 uses a key file, in /etc/ on root LV on 
the first vg.

So, on boot, I see the prompt for the pass phrase for luks #1, for vg 
#1.  Then, immediately, I get an error from tuxonice:

Key slot 0 unlocked.
    8 logical volume(s) in volume group "wallevg0" now active
udevd-work[611]: inotify_add_watch(6, /dev/dm-8, 10) failed: No such 
file or directory
Done.
Begin: Running /scripts/local-premount ...
resume: libgcrypt version: 1.4.4
resume: Could not stat the resume device file '/dev/disk/by-uuid/UUID1'
      Please type in the full path name to try again

Up to date trees.

Nigel Cunningham — 2012-02-11T10:24:58

Hi all.

Just to let you know that there are now up-to-date trees on Github:

https://github.com/NigelCunningham/tuxonice-kernel/branches

What's more, I'm happy with the stability of them - I've found the cause
of file system corruption I was getting (threads calling try_to_freeze
but not having invoked set_freezable), and am now working on getting
updated patches being automatically generated again.

Thanks to everyone for your patience and encouragement. The wheels fell
off for a while there, but I think I'm getting back on track. (I'll
leave you to wonder about mixed metaphors!)

Nigel

function thaw_kernel_threads introduced by newkernel stable patch

Jordi Pujol — 2012-02-07T10:18:56

Hi all,

the kernel stable patch 

pm-hibernate-fix-s2disk-regression-related-to-freezing-workqueues

has introduced another version of the function "thaw_kernel_threads"
that conflicts with this one from TuxOnIce,

Regards,

Jordi Pujol

Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com

Proposed git tree changes.

Nigel Cunningham — 2012-01-26T02:35:59

Hi all.

I'm considering making some changes to the way I arrange the git trees,
partly in fulfillment of suggestions posted on this list already and
would like your input. Proposed changes are:
- Make one big git tree instead of separate ones for each branch
- For each vanilla kernel version, have a upstream and a tuxonice
branch, hence upstream-3.0, tuxonice-3.0, upstream-3.1, tuxonice-3.1,
upstream-head, tuxonice-head and so on
- Tags for tuxonice branches will be in the format
tuxonice-<tuxonice-version>-for-<upstream-version> so that there will be
no namespace difficulties
- At any time, only the 2 most recent upstream releases will get
TuxOnIce updates. This will reduce the amount of testing I need to do
before releases. Until now, I've only tended to drop old releases when
more recent changes make backporting too much effort.

If these changes sound good to people, I'll start implementing them.
Hopefully I'll then be able to fix up my long neglected scripts and get
regular updates and patches going ag

Web Git down?

Ignas Anikevicius — 2012-01-10T01:32:34

Hello list,

I was wondering if the gitweb interface is down or not, or is it just my 
browser of choice (luakit) screwing around?

Cheers,
Ignas A.

Web Git down?

Ignas Anikevicius — 2012-01-10T01:32:34

Hello list,

I was wondering if the gitweb interface is down or not, or is it just my 
browser of choice (luakit) screwing around?

Cheers,
Ignas A.

First cut of catch up patch... Still frozen onrestore...

Woody Suwalski — 2011-12-30T21:12:22

Nigel, Merry Christmas,

Thanks for updating the git tree - I could use TOI once again, now on 
3.2 kernels...

I keep reading that it works for most of people, however on EeePC with 
i915 it is crashing 100% on restore, the last messages are:

Reading kernel & process data...
Atomic restore.
Doing atomic copy/restore.

I have tried on 2 different devices, it is 100% repeatable.
I tried from normal X-session, then from a single mode, then even from 
single mode with nomodeset, without text-gui - can not be simpler than 
that - yet it still crashes... Tried to disable all 
no-[flusher_thread/pageset2/readahead/multithreded_io] - not much help...

Is there a trick to debug it?

Thanks, Woody