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 _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
