Re: TuxOnIce 3.3 for Linux 3.4.

Am Mittwoch, 18. Juli 2012 schrieb Nigel Cunningham:
> Hi Martin.

Hi Nigel.

> On 07/18/2012 07:53 PM, Martin Steigerwald wrote:
> > Still does not work for me.
> > 
> > Just one attempt with two KDE session yielded seeking to free 1136 MB
> > of memory, it accesses SSD wildly, possibly swapping out, and then
> > it hung. Thats different from before where hibernation attempts just
> > failed an got me back to a working system.
> > 
> > When pressing escape on tuxonice userui it said it would abort but
> > the kernel did not seem to react anymore.
> > 
> > Thus back to non-toi kernel at the moment.
> > 
> > Ciao,
> 
> The userspace user interface runs in a separate thread, and can only
> send a message to the kernel saying "Please abort". In your case, it
> sounds like the kernel is stuck somewhere, presumably waiting for a
> lock that it's never going to get, and so it doesn't see that message
> and can't respond.

Yes, I know from your previous teachings on these lists ;)

> If you can reliably reproduce the issue, would you send me your
> .config? Better still, would you be able to compile KDB in and then
> use it to see what's going on when the hang occurs?

I reproduced it. 

Then I tried with disabled user interface and got just a black screen.

Then I put "1" into debug, debug_sections and log_everything in 
/sys/power/tuxonice/user_interface. Then it worked several times out of 
the box. Odd. I started stress -m1 --vm-bytes 2G. It still worked. It 
never displayed seeking to free memory in these cases. I was puzzled, 
cause I had the exact two KDE sessions open as before. I wondered whether 
something is different with debug enabled.

Then I used stress -m4 --vm-bytes 4G which used up almost all remaining 
memory. Then even with debug enabled it failed on seeking to free about 
3500 MiB of memory. Anyway that seems to be a good reproducer for me. 
TuxOnIce should either (understandably) fail in that case or still work, 
but not hang.

I send you the kernel configuration privately to not clog the list with it.

Other than back then I am now able to switch to default in-kernel suspend 
without using a non-toi kernel. That makes it easier to debug anything.

I am not familiar with KDB and how to use it. There seem to be some 
howto¹, but I still would not know in what outputs you would be interested 
in. "bt"? Anyway, it may take some time till I would take time for that.

Other than that it might be important that when I have my work KDE session 
up that its home directory it encrypted via ecryptfs. But that does not 
create any problems with default in-kernel suspend either.


[1] http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Inside-
the-kernel-debugger-KDB/

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
TuxOnIce-devel mailing list
[email protected]
http://lists.tuxonice.net/listinfo/tuxonice-devel