Apmsleep Freeze On Resume

[clofland]

Has anyone else found that upon resume, apmsleep (apmsleep is only called if you give the Z a "maximum sleep time" by puting a file in /etc/apm/wakeup.d) hangs for a while upon resume, which, in turn, causes matchbox to freeze?

I see it discussed in a few threads, but they all seem to indicate that it is fixed.

It doesn't seem to hang the system itslef, I can still SSH into it, and if I suspend from the console, the problem isn't even noticeable (though apmsleep is still hung in the background upon resume, it doesn't affect the console, only X). Also, all keystrokes are cached and as soon as apmsleep "let's go" they hit matchbox.

The only way out is to wait (up to 3 to 5 minutes it seems) after I resume or to SSH in and "kill -HUP" the apmlseep process, which unfreezes everything instantly.

Any idea what is causing this? Why does apmsleep hang upon resume, and why is X (or matchbox, I'm not sure where one ends and the other begins) held at a standstill by apmsleep, while everything in the background (network services, SSH, the console) are not?

What is really troublesome, is that it didn't seem to really start happening until after I installed ntpd. I removed ntpd, but the problem persists.

I had similar issues if I issued an ntpdate command from within X. The system would immediately suspend, and then, when I brougth it back up (if it didn't immediately suspend again) it woud hang for 3 to 5 minutes before becoming responsive.

Maybe apmsleep just has a very strong aversion to correct system time?

I tried putting a & at the end of the apmsleep line in /usr/bin/apm, which works well in console mode, allowing apm to finish upon resume, just leaving apmsleep in the background to do its thing or be killed later. However, if you suspend from within X, everything is in slow motion upon resume, with X taking up 99% of the CPU. X stays that way forever, long after apmsleep has finally gone away.

So, again, why won't apmsleep go away upon resume, and, regardless, why does X freeze until apmsleep goes away, while the console and background services keep on working fine?

Here is what I get if I put the --debug option onto apmsleep in the /usr/bin/apm file:

Good suspend resume cycle:

Current RTC time is 16:28:39.
Current local time is 11:28:38.
Setting RTC alarm time to 16:58:39.
RTC alarm time now set to 16:58:39.
Waiting until clock jumps
(system suspends)
(resume system with on/off button)
Time leap detected

Bad cycle (apmsleep hangs:

Current RTC time is 16:28:39.
Current local time is 11:28:38.
Setting RTC alarm time to 16:58:39.
RTC alarm time now set to 16:58:39.
Waiting until clock jumps
(system suspends)
(resume system with on/off button)
(apmsleep hangs for a while, hanging the apm script and X)
Time out -- no time leap happened

From reading the man page for apmsleep, it appears that the timeout is 60 seconds, so for some reason, sometimes when I manually resume, apmsleep gets the hint and takes that as a "time leap," but sometimes it doesn't take the hint, and just waits for a built in timeout. That is my guess anyway.

[albertr]

Good suspend resume cycle:

Current RTC time is 16:28:39.
Current local time is 11:28:38.
Setting RTC alarm time to 16:58:39.
RTC alarm time now set to 16:58:39.
Waiting until clock jumps
(system suspends)
(resume system with on/off button)
Time leap detected

Bad cycle (apmsleep hangs:

Current RTC time is 16:28:39.
Current local time is 11:28:38.
Setting RTC alarm time to 16:58:39.
RTC alarm time now set to 16:58:39.
Waiting until clock jumps
(system suspends)
(resume system with on/off button)
(apmsleep hangs for a while, hanging the apm script and X)
Time out -- no time leap happened

I noticed that openbox doesn't really like when localtime is changed. You can easily test it by changing localtime when running X. You don't seem to keep your hardware clock in UTC time, do you? I would suggest to switch hardware clock to UTC, this way you can make life alittle bit easier.
-albertr

[clofland]

After removing ntpd and a couple of reboots, it seems happier again. Although, for most of the day yesterday, it never woke up on it's own (like apmsleep should).

Seems ntpd does something that apmsleep does not like. I wonder if it has to do with time slewing in the kernel? (wild guess, i don't know) That or maybe it is just related to the fact that X generally has a cow anytime you update the clock while it is running.

It will still crash if I suspend it and then wake it up too soon after suspending it. I think it did this from the start though, and explains the only crashes that I've had with RC11.

I could report a "bug," but I'm not 100% sure what to post as the problem. I'll probably juts post about the fact that things die if you update the time with ntpdate (and the fact that the clock loses SO much time under pdaXrom, when it kept good time under SHARP).

Does anyone else who uses the "wake up in X minutes" feature, like say, with kopi, have any trouble with the system freezing when you wake it up?

[albertr]

Well, I have a C1K and the kernel code is a little bit different for PXA270. Anyway, here's my experience:
1. I don't run ntpd, but use ntpdate quite often. Haven't had any problem.
2. Clock accuracy : my C1K doesn't get off more than a couple of seconds  a week.
3. To make RTC alarm work the kernel needs to be patched (I posted the patch on the other thread).

I'm keeping my hardware clock in UTC time, BTW.
-albertr

[huu]

Does anyone else who uses the "wake up in X minutes" feature, like say, with kopi, have any trouble with the system freezing when you wake it up?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99139\"][{POST_SNAPBACK}][/a][/div]

Yes, this seems to have bitten me as well (although it was a bit difficult to debug, as there was another problem with a faulty battery that also resulted in my c750 hanging on resume every once in a while, with different symptoms).

It appears that when I resume the Zaurus immediately (say, less than half a minute or so) after suspending, apmsleep hangs, which results in X freezing as well. This happens with apmsleep but not regular apm(.x) -- that is, for instance with kopi alarm wakeups enabled. As a quick and dirty solution I patched /usr/bin/apm:

Code: [Select]

 if [ "$TIME_LOW" = "0" ];then
    $APM --suspend
  else
    $APMSLEEP +0:$TIME_LOW &
    sleep 2
    kill -HUP %1
  fi
That is, run apmsleep in background, wait for a couple of seconds (during which time the Z is supposed to be suspended) and then kill the hung apmsleep.

[gab74]

i try this solution on My C-3100 but it doesent work....matchbox is still frized when i resume from a long period.....!!!