Re: [PATCH v2] fix can't attach GPRS issue

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]

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@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@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