Re: swsusp/pmdisk status on ppc?
> Hm, sadly it's not that stable yet: there are at least three ways it
> can break currently:
I never said it was stable. I said it works for me on the same hardware
even). Plus someone said it's a dead end solution anyway.
> (- processes can't be stopped: that's the known "problem" with swsusp
> I've read about, someone seems to have worked out a scheme to find
> out the hierarchy of system calls to stop the processes in the right
> order to make it more stable. In my case, about every second time I
> suspend while xmms is running, it complains about 1 process not being
> stopped and that's xmms; I've also seen one of the multiple xmms
> threads being T the others not, funny. Note that xmms is always
Something with threading and xmms, perhaps - maybe there's a problem with
threads sleeping uninterruptibly or other signal delivery trouble. No idea
if a more recent libc has fixes for that. I've not tried xmms myself BTW.
> - during suspension, it takes a veeeerryy long time to write
> processes to disk (iirc), I see the dots coming up one about every 20
> seconds or so. I give up and just reset the machine.
Doesn't happen for me - maybe lots to swap out, or freeing memory takes
long for some other reason. I see short pauses between dots on occasion,
but not for the whole write phase. Memory free being slow has been rumored
before, though I haven't seen it myself.
> - another time, suspension worked but it took a long time in the
> "waiting phase" between writing processes to disk and writing the
> rest to disk (as far as I understand that). It took about a minute
> just waiting iirc. Then it finished. Resume first seemed to work, but
> then it will (just before switching the console to the old state)
> just sit there and do nothing. After about 3 minutes I gave up and
> did reset the machine.
The suspend image must've gotten corrupted - I've not seen that happen
though. If there's not enough space in the swap partition, suspend will
just abort.
> It would help if someone explained the different phases, when happens
> what. Should I try to do that (begin something like a howto)?.
I found the log output to be quite self explanatory (after getting used
to it, admittedly). But not everyone takes the time to look up log
messages in the source if things are unclear. A short description of the
suspend phases plus potential errors would be useful.
> What should I look out for in such failure cases? How can I help the
> developers?
Maybe make a note of running processes and memory usage before suspend
(plus loaded modules) to track down problems. In case of tight memory I'd
add a log message to the code that shows the kernel's view of memory and
swap usage before freeing memory, and before writing the suspend image,
maybe there's a problem with free space calculation.
> (Hm, should I have cross posted this to linuxppc-devel?)
Yes indeed.
Michael
Reply to: