Ticket #176 (closed defect: fixed)

Opened 12 years ago

Last modified 11 years ago

libgsmd need a mechanism to avoid dead waiting.

Reported by: tonyguan@… Owned by: sean_chiang@…
Priority: high Milestone:
Component: libgsmd Version: unspecified
Severity: critical Keywords:
Cc: buglog@…, jserv@…, tick@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:
Reproducible:

Description

When implimenting functions that need the return value to indicating whether
it's properly processed, for example,lgsm_passthrough(). There are chances
that the gsmd just ignore the returned data, and then the user of the api will
then be waiting forever.
Could we figure out some mechanism more stable?
Because there are a lot of need for the dialer app(or some other management
utility) to qurey the status of libgsmd, and the ME it self to give out proper
commands.
I see there are many management AT commands there, but without a countable
mechanism, they are just covered under the surface to applications.

Attachments

bug_176.patch (3.2 KB) - added by tick@… 12 years ago.
for unable to wakeup. (adding a wakeup work around)

Change History

comment:1 Changed 12 years ago by laforge@…

lgsm_passthrough() should not be used by any application. It is merely ment for
testing/debugging.

however, I will add some genal 'alive' checking of the GSM Modem to gsmd by
means of the +CPAS command. I think by tomorrow we will have some functions in
libgsmd that we can use to track GSM Modem availability.

comment:2 Changed 12 years ago by mickey@…

what's the status here?

comment:3 Changed 12 years ago by jserv@…

  • Cc jserv.tw@… added

comment:4 Changed 12 years ago by jserv@…

  • Status changed from new to assigned

Recently, openmoko is about to ship new GSM firmware with power management
enabled. And, it raises the importance to avoid dead waiting by querying the
modem status. Not only AT+CPAS command should be used, but also check GPIO
status as well. OpenMoko? internal software team is attempting to fix the issue
and provide a purificatory approach.

comment:5 Changed 12 years ago by jserv@…

  • Owner changed from laforge@… to jserv@…
  • Status changed from assigned to new

comment:6 Changed 12 years ago by tick@…

  • Cc ticktock35@… added

Changed 12 years ago by tick@…

for unable to wakeup. (adding a wakeup work around)

comment:7 Changed 12 years ago by tick@…

There is a very strong assumption that every sent AT command gets a response.
However the firmware with power saving mode will not response first AT command
until it gets a "\r" when modem is in sleep mode.
That is the AT sent by gsmd when moden is in sleep mode will be block forever.

If not changing firmware and hardware design, there is a work around.
Adding an additional " \r" as a atcmd before each real comman.
If modem is in sleep mode, it will not response but will wake up in 1 sec and
keep awaken for about 10 secs.
If modem is awake, it will reply an "OK" immediately.
Therefore, if modem is in sleep mode, we can set a 3 sec timeout and discard the
additional atcmd and then passthrough the real atcmd.
Because modem been awaken will keep awaken for about 10 secs , we can almost
very sure that the modem is awaken in this moment, and will response
correctly.There is a very strong assumption that every sent AT command gets a
response.
However the firmware with power saving mode will not response first AT command
until it gets a "\r" when modem is in sleep mode.
That is the AT sent by gsmd when moden is in sleep mode will be block forever.

If not changing firmware and hardware design, there is a work around.
Adding an additional " \r" as a atcmd before each real comman.
If modem is in sleep mode, it will not response but will wake up in 1 sec and
keep awaken for about 10 secs.
If modem is awake, it will reply an "OK" immediately.
Therefore, if modem is in sleep mode, we can set a 3 sec timeout and discard the
additional atcmd and then passthrough the real atcmd.
Because modem been awaken will keep awaken for about 10 secs , we can almost
very sure that the modem is awaken in this moment, and will response correctly.

comment:8 Changed 12 years ago by memb_moko_bz@…

Could you confirm whether this modem sleep mode may be the one that causes gsmd
to periodically (haven't got the impression that it happens after a constant
time, though) assess that the modem is dead, when otherwise connected correctly
to network:

Sat Oct 13 10:06:20 2007 <1> gsmd.c:78:alive_tmr_cb() gsmd_alive timer expired
Sat Oct 13 10:06:20 2007 <8> gsmd.c:81:alive_tmr_cb() modem dead!

This happens even though unsolicited messages (signal strength and LAC/CI) keep
beeing received and parsed correctly. I can see that, when this occurs, every at
command sent to the modem is unanswered at gsmd/libgsmd level.

Does the patch cover this case? Or isn't the modem in sleep mode in this situation?

comment:9 Changed 11 years ago by tick@…

  • blocked set to 705

comment:10 Changed 11 years ago by tick@…

  • Owner changed from jserv@… to sean_chiang@…
  • dependson set to 974

comment:11 Changed 11 years ago by sean_chiang@…

  • Status changed from new to assigned

comment:12 Changed 11 years ago by sean_chiang@…

  • Status changed from assigned to new
  • Owner changed from sean_chiang@… to sean_chiang@…

comment:13 Changed 11 years ago by sean_chiang@…

  • Status changed from new to closed
  • Resolution set to fixed

This bug is related to #974, to avoid dead waiting through timeout scheme.

Note: See TracTickets for help on using tickets.