function thaw_kernel_threads introduced by new kernel stable patch

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

Re: function thaw_kernel_threads introduced by new kernel stable patch

Hi Jordi.

On 07/02/12 21:18, Jordi Pujol wrote:
> 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,

Here's a patch generated from my git tree. I'm assuming you're using the
3.2 series. If that's not the case, let me know and I'll do one from
another branch.

Regards,

Nigel
--

-- 
Evolution (n): A hypothetical process whereby improbable
events occur with alarming frequency, order arises from chaos, and
no one is given credit.

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

Re: function thaw_kernel_threads introduced by new kernel stable patch

A Dimarts, 7 de febrer de 2012 12:05:34, Nigel Cunningham va escriure:
> Hi Jordi.
> 
> On 07/02/12 21:18, Jordi Pujol wrote:
> > 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,
> 
> Here's a patch generated from my git tree. I'm assuming you're using the
> 3.2 series. If that's not the case, let me know and I'll do one from
> another branch.
> 

Hi Nigel,

yes, I use the latest 3.2 and the stable patches,
Thank you Nigel for this update, but it does not modify the code for the 
function "thaw_kernel_threads" that conflicts with the kernel's stable patch,

I did the attached modification, which works for me because the computer 
hibernates and resumes, but I don't know if it is correct,

Regards,

Jordi Pujol

Up to date trees.

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
--

-- 
Evolution (n): A hypothetical process whereby improbable
events occur with alarming frequency, order arises from chaos, and
no one is given credit.

Re: Up to date trees.

On Sat, Feb 11, 2012 at 09:24:58PM +1100, Nigel Cunningham wrote:
> Hi all.
> 
> Just to let you know that there are now up-to-date trees on Github:
> 
> https://github.com/NigelCunningham/tuxonice-kernel/branches
On tuxonice-head:
ERROR: "pm_freezing" [drivers/md/md-mod.ko] undefined!

--

-- 
WBR, wRAR

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

Re: Up to date trees.

Hi.

On 11/02/12 22:09, Andrey Rahmatullin wrote:
> On Sat, Feb 11, 2012 at 09:24:58PM +1100, Nigel Cunningham wrote:
>> Hi all.
>>
>> Just to let you know that there are now up-to-date trees on Github:
>>
>> https://github.com/NigelCunningham/tuxonice-kernel/branches
> On tuxonice-head:
> ERROR: "pm_freezing" [drivers/md/md-mod.ko] undefined!

Ok; thanks.

Nigel
--

-- 
Evolution (n): A hypothetical process whereby improbable
events occur with alarming frequency, order arises from chaos, and
no one is given credit.

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

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

Google comes back with a huge list of hits on this, but the ones I 
checked are not even close to my 'advanced config'.  It sure looks to 
me like tuxonice is firing after the first entry in crypttab, but 
it's not waiting for the others to be activated.  Else the partition 

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

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

Google comes back with a huge list of hits on this, but the ones I 
checked are not even close to my 'advanced config'.  It sure looks to 
me like tuxonice is firing after the first entry in crypttab, but 
it's not waiting for the others to be activated.  Else the partition 
with that UUID would be available.

Re: Up to date trees.

On Sat, Feb 11, 2012 at 09:24:58PM +1100, Nigel Cunningham wrote:
> Hi all.
> 
> Just to let you know that there are now up-to-date trees on Github:
> 
> https://github.com/NigelCunningham/tuxonice-kernel/branches
Yesterday I've got an OOPS right after suspend start. Unfortunately
pause_on_oops ended just at the moment I made the photo so the stack is
not very readable but looks like the stack of the second OOPS contains the
first one (below invalid_op) so I made a photo of it too:

http://img-eburg.fotki.yandex.ru/get/5507/5627162.58/0_5f513_817cc797_XXXL
http://img-eburg.fotki.yandex.ru/get/5009/5627162.58/0_5f514_2359300d_XXXL

I've just made a suspend attempt and it started writing so the OOPS is not
100% reproducible.

--

-- 
WBR, wRAR

_______________________________________________
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 ?

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