Hi Caiwen,
On 06/02/2011 10:42 PM, Zhang, Caiwen wrote:
Hi Denis,
>>>
>>> Can you try the attached patch and tell me if this fixes your
> problem?
>>>
>>
>> Yes, it works.
>
> From the log it isn't clear whether oFono eventually re-attaches
> automatically, does that work as well?
>
It won't re-attach automatically. Following are the log from line 6792 to
6802 and my comment.
ofonod[619]: PCUI: < \r\n+CREG: 1, A807, A72B71\r\n\r\n+CGREG: 1, A807, A72B71\r\n
ofonod[619]: src/gprs.c:netreg_status_changed() 1
gprs->netreg_status is 1 (NETWORK_REGISTRATION_STATUS_REGISTERED).
ofonod[619]: src/cbs.c:cbs_location_changed() 1, 43015, 10955633, -1, (null)(null)
ofonod[619]: src/gprs.c:ofono_gprs_status_notify() /huawei0 status 1
gprs->driver_attached is set to TURE. From now on, unless the modem unregistered,
gprs_netreg_update() will always return before execute
gprs->driver->set_attached()
because (gprs->driver_attached == attach).
So to me it doesn't look like your interpretation is correct:
At line 6754:
ofonod[619]: PCUI: > AT+CGATT=1\r
ofonod[619]: PCUI: < \r\nOK\r\n
ofonod[619]: src/gprs.c:gprs_attach_callback() /huawei0 error = 0
This is issued in the initial gprs_netreg_update called from netreg_watch.
Then we issue a CGREG query from gprs_attach_callback at line 6768:
ofonod[619]: PCUI: > AT+CGREG?\r
ofonod[619]: PCUI: < \r\n+CGREG: 2,1, A807, 2B71\r\n\r\nOK\r\n
So driver_attached is TRUE here
At line 6778 the modem has a nervous tick:
ofonod[619]: PCUI: < \r\n^SRVST:1\r\n\r\n+CREG: 2\r\n\r\n+CGREG:
2\r\n\r\n^SRVST:2\r\n\r\n+CREG: 1, A807, A72B71\r\n\r\n+CGREG: 0\r\n
And the first CREG: 2 causes us to issue another gprs_netreg_update
which issues a detach at line 6797:
ofonod[619]: PCUI: > AT+CGATT=0\r
ofonod[619]: PCUI: < \r\n+CREG: 1, A807, A72B71\r\n\r\n+CGREG:
0\r\n\r\nOK\r\n
The subsequent CGREG should simply update our Attached attribute to
False. The next CREG will trigger another gprs_netreg_update, which
should in turn set the RECHECK flag to TRUE. And the subsequent CGREG
has no effect.
With my earlier patch, you should not have any changes to
driver_attached until the CGATT=0 returns, which should trigger another
CGREG update and assuming the RECHECK flag was set, another call to
gprs_update_netreg.
Can you investigate why this isn't happening? Instrumentation of the
settings of driver_attached and flags would be helpful.
ofonod[619]: PCUI: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
ofonod[619]: PCUI: > AT+CGATT=0\r
ofonod[619]: PCUI: < \r\n+CREG: 1, A807, A72B71\r\n\r\n+CGREG: 0\r\n\r\nOK\r\n
ofonod[619]: src/gprs.c:netreg_status_changed() 1
ofonod[619]: src/cbs.c:cbs_location_changed() 1, 43015, 10955633, -1, (null)(null)
ofonod[619]: src/gprs.c:ofono_gprs_status_notify() /huawei0 status 0
ofonod[619]: src/gprs.c:gprs_attach_callback() /huawei0 error = 0
gprs->driver_attached is used to indicated (CGATT) status, its value shouldn't be
changed before
gprs->driver->set_attached() execute completely.
In this case, its value happen to be changed during gprs->driver->set_attached() is
executed. So
its value is not the same as (CGATT) status.
The value of driver_attached is not about the current CGATT status, but
the pending status of set_attached to the driver. While related, they
are not the same.
Regards,
-Denis