Strange issues with resume on incoming call on FR

Werner Almesberger werner at
Fri Feb 6 21:36:13 CET 2009

Copying this to "devel" since a) I'm not sure if it's a kernel or
user space problem, and b) I'm still processing the recent batch
of WLAN troubles, so if there's a new GSM and/or suspend problem, I
may not be the speediest source of answers.

Resume immediately leading to suspend sounds like this fellow:

You may want to check if  zcat /proc/config.gz | grep WAKELOCK  yields
anything. If it isn't there at all, that's okay. If it's there and
set, then we have the culprit. If it's there but disabled, then new
insights will be gained in the search for the real cause;-)

As far as I know, no patches to fix whatever is wrong with the
wakelocks have been added to our kernel since.

- Werner

-------------------------------- original mail --------------------------------

Paul Fertser wrote:
> Date: Fri, 6 Feb 2009 23:07:28 +0300
> From: Paul Fertser <fercerpav at>
> To: Werner Almesberger <werner at>
> Subject: Strange issues with resume on incoming call on FR
> Hi,
> I hope you can somehow shed some light on this, that's my report on IRC:
> > Ok, i just did the following: killed zhone, ensured that no gsm0710muxd is
> > running.  Then started zhone, waited till it registered.  Then made a bash
> > cycle with mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage
> > org.freesmartphone.Usage.Suspend Then called my FR from a fixed line. I heard
> > ringing tones but my FR didn't resume.  I waited for some 10-20 seconds and
> > pressed power button. FR unsuspended and showed incoming call pending in
> > Zhone. Immediatly re-suspended.  Then it resumed again, then re-suspended,
> > then resumed, then resuspended.  Until my cell operator terminated the call.
> > Can anybody reproduce it? Does it make sense to anybody? I don't see it every
> > time, only sometimes. While in this state where i only hear ringing in my
> > fixed phone, but FR is still suspended, manually asserting calypso's power
> > control line doesn't lead to resume.
> I can reproduce it quite reliably (not every time though) and the funny thing
> about this is that i have acces to hardware testpoint TP1706 that cuts GSM
> power on asserting. In this particular case asserting it doesn't lead to resume
> as well.
> I can assure you that Usage.Suspend does echo 1 > flowcontrolled before
> suspending and echo 0 after resuming.
> Also the power_on sysfs node is still wrong (i didn't fixed the behavior) so
> while it in the 1 state, MODEM_ON push-button is also in permanent 1 state.
> Doesn't explain everything though.
> I also did numerous tests without frameworkd running, just minicom (with
> hardware flow control) in one terminal and echo mem > /sys/power/state in
> another one. And i asserted power control line manually. The results are
> strange, even with 0 in flowcontrolled it usually resumes (probably because
> unpowered modem can easily assert IRQ line). So, that proves nothing :( But the
> problem with calls is real.
> If you want, you can catch me on IRC now or a bit later and we can have an
> interecative debugging session.
> Please CC the ML if you consider that useful.
> -- 
> Be free, use free ( software!
> mailto:fercerpav at

More information about the devel mailing list