| 2014-02-05 10:26:02 |
Alfonso Sanchez-Beato |
description |
When ofono is stopped ("stop ofono"), some messages that are supposed to be sent to rild to clean up resources are not really sent. This happens due to the asynchronous nature of g_ril_send(): ofono never returns to glib's main loop after having started the termination stage of the process. The message that is not sent is
RIL_REQUEST_DEACTIVATE_DATA_CALL
In some modems, this leaks call-id resources and no data call can be established after a few start/stop ofono iterations. |
When ofono is stopped ("stop ofono"), some messages that are supposed to be sent to rild to clean up resources are not really sent. This happens due to the asynchronous nature of g_ril_send(): ofono never returns to glib's main loop after having started the termination stage of the process. The message that is not sent is
RIL_REQUEST_DEACTIVATE_DATA_CALL
In some modems, this leaks call-id resources and no data call can be established after a few start/stop ofono iterations.
To reproduce:
# stop ofono
# export OFONO_RIL_HEX_TRACE=""
# export OFONO_RIL_TRACE=""
# ofonod -n -d -p ril,rilmodem,provision,mbpi,nettime,mnclength,smshistory >& /tmp/ofono_log.txt&
* Check that we have an active data connection
# pkill ofonod
Taking a look at the log, we should see near the end:
ofonod[XXXX]: Terminating
...
ofonod[XXXX]: [XXXX]> RIL_REQUEST_DEACTIVATE_DATA_CALL (0,0)
...
ofonod[XXXX]: [XXXX]> RIL_REQUEST_RADIO_POWER (0)
DEACTIVATE_DATA_CALL and RADIO_POWER are the two messages that we are trying to send to rild, but that are not really sent. We know that because a message like:
ofonod[XXXX]: Device: > (... some hex data ...)
should have been printed after the request trace because we have set the environment variable OFONO_RIL_HEX_TRACE. The trace is printed right after sending data in grilio.c::g_ril_io_write(). |
|
