Re: [TuxOnIce-devel] TuxOnIce 3.3 for Linux 3.4.

Hello Nigel,

Is there a TOI patch for kernel3.4?
I saw that the latest official patch at http://tuxonice.net/ was for
Kernel3.0.

I was using the
current-tuxonice-for-3.0.patch.bz2<http://tuxonice.net/files/current-tuxonice-for-3.0.patch.bz2>
patch
on my device running Linux 3.0.22 version. Now we are upgrading to Linux3.4
and would like to keep using TOI.

Thanks,
Yechiel

On Thu, Jul 19, 2012 at 12:58 PM, Martin Steigerwald <[email protected]>wrote:

> 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-users mailing list
> [email protected]
> http://lists.tuxonice.net/listinfo/tuxonice-users
>



-- 

*Take care,*

*Yechiel*

_______________________________________________
TuxOnIce-users mailing list
[email protected]
http://lists.tuxonice.net/listinfo/tuxonice-users