11:38 p.m.
This patch is to fix the issue that can't attach GPRS after detach it.
Cause:
When start detaching GPRS, driver_attched value is set to FALSE, if
device registered to GPRS network during GPRS detaching, driver_attched is set to TURE.
After that, GPRS attaching will always be ignored because driver_attched is always TURE.
It seems the definition of driver_attched is confused.
Scenario:
When device is unregistered(+CREG: 2), GPRS is detached. During GPRS detaching, device
registered to network again(+CREG: 1, xxx, xxx).
Solution:
variable attached represents the GPRS attach status, it only be TRUE, when CGATT=1 and
CGREG is registered or roaming(roaming allowed). variable driver_attached represents
CGATT
status of the driver. its value will only be changed after set_attached successfully or
GPRS detached notified. variable pending_attached represents the pending status of CGATT.
---
src/gprs.c | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/gprs.c b/src/gprs.c
index deffeb8..e221741 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -74,8 +74,9 @@ enum packet_bearer {
struct ofono_gprs {
GSList *contexts;
- ofono_bool_t attached;
+ ofono_bool_t attached; /*CGATT=1 and CGREG is registered or roaming*/
ofono_bool_t driver_attached;
+ ofono_bool_t pending_attached;
ofono_bool_t roaming_allowed;
ofono_bool_t powered;
ofono_bool_t suspended;
@@ -1499,8 +1500,8 @@ static void gprs_attach_callback(const struct ofono_error *error,
void *data)
gprs->flags &= ~GPRS_FLAG_ATTACHING;
- if (error->type != OFONO_ERROR_TYPE_NO_ERROR)
- gprs->driver_attached = !gprs->driver_attached;
+ if (error->type == OFONO_ERROR_TYPE_NO_ERROR)
+ gprs->driver_attached = gprs->pending_attached;
if (gprs->driver->attached_status) {
gprs->driver->attached_status(gprs, registration_status_cb,
@@ -1539,18 +1540,23 @@ static void gprs_netreg_update(struct ofono_gprs *gprs)
attach = attach && gprs->powered;
- if (gprs->driver_attached == attach)
- return;
-
if (gprs->flags & GPRS_FLAG_ATTACHING) {
+ if (gprs->pending_attached == attach) {
+ gprs->flags &= ~GPRS_FLAG_RECHECK;
+ return;
+ }
+
gprs->flags |= GPRS_FLAG_RECHECK;
return;
+ } else {
+ if (gprs->driver_attached == attach)
+ return;
}
gprs->flags |= GPRS_FLAG_ATTACHING;
gprs->driver->set_attached(gprs, attach, gprs_attach_callback, gprs);
- gprs->driver_attached = attach;
+ gprs->pending_attached = attach;
}
static void netreg_status_changed(int status, int lac, int ci, int tech,
@@ -2103,7 +2109,6 @@ void ofono_gprs_status_notify(struct ofono_gprs *gprs, int status)
status == NETWORK_REGISTRATION_STATUS_ROAMING)
goto detach;
- gprs->driver_attached = TRUE;
gprs_attached_update(gprs);
return;
--
1.7.5
12:51 a.m.
Hi Caiwen,
On 05/10/2011 01:38 AM, Caiwen Zhang wrote:
This patch is to fix the issue that can't attach GPRS after
detach it.
I'd like to see a complete AT log of this situation if possible. It
sounds like there's something else going on here...
Cause:
When start detaching GPRS, driver_attched value is set to FALSE, if
device registered to GPRS network during GPRS detaching, driver_attched is set to TURE.
After that, GPRS attaching will always be ignored because driver_attched is always TURE.
It seems the definition of driver_attched is confused.
Scenario:
When device is unregistered(+CREG: 2), GPRS is detached. During GPRS detaching, device
registered to network again(+CREG: 1, xxx, xxx).
Really sounds like your firmware is too twitchy. Why does it report
CREG: 2 and then immediately finds registration? Is this related to
cell roaming or technology switch?
Solution:
variable attached represents the GPRS attach status, it only be TRUE, when CGATT=1 and
CGREG is registered or roaming(roaming allowed). variable driver_attached represents
CGATT
status of the driver. its value will only be changed after set_attached successfully or
GPRS detached notified. variable pending_attached represents the pending status of
CGATT.
Can you try the attached patch and tell me if this fixes your problem?
Regards,
-Denis
7:15 p.m.
Hi Denis,
On 05/10/2011 01:38 AM, Caiwen Zhang wrote:
> This patch is to fix the issue that can't attach GPRS after detach it.
>
I'd like to see a complete AT log of this situation if possible. It
sounds like there's something else going on here...
Attached the whole log. Please refer to line 6793:
ofonod[619]: src/gprs.c:ofono_gprs_status_notify() /huawei0 status 1
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
> Cause:
> When start detaching GPRS, driver_attched value is set to FALSE, if
> device registered to GPRS network during GPRS detaching,
driver_attched is set to TURE.
> After that, GPRS attaching will always be ignored because
driver_attched is always TURE.
> It seems the definition of driver_attched is confused.
>
> Scenario:
> When device is unregistered(+CREG: 2), GPRS is detached. During
GPRS
> detaching, device registered to network again(+CREG: 1, xxx, xxx).
Really sounds like your firmware is too twitchy. Why does it report
CREG: 2 and then immediately finds registration? Is this related to
cell roaming or technology switch?
>
> Solution:
> variable attached represents the GPRS attach status, it only be
> TRUE, when CGATT=1 and CGREG is registered or roaming(roaming
> allowed). variable driver_attached represents CGATT status of the
> driver. its value will only be changed after set_attached
successfully or GPRS detached notified. variable pending_attached
represents the pending status of CGATT.
>
Can you try the attached patch and tell me if this fixes your problem?
Yes, it works.
best regards
Caiwen
8:42 p.m.
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).
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.
best regards
Caiwen
5:22 a.m.
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
12:24 a.m.
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.
gprs_netreg_update() is the only place to change CGATT automatically.
Following are the code of gprs_netreg_update().
ofono_bool_t attach;
attach = gprs->netreg_status == NETWORK_REGISTRATION_STATUS_REGISTERED;
attach = attach || (gprs->roaming_allowed &&
gprs->netreg_status == NETWORK_REGISTRATION_STATUS_ROAMING);
attach = attach && gprs->powered;
if (gprs->driver_attached == attach)
return;
As my comment above, because gprs->netreg_status is
1(NETWORK_REGISTRATION_STATUS_REGISTERED)
and gprs->driver_attached is TRUE. So (gprs->driver_attached == attach). This
function always
return here, unless, the value of gprs->netreg_status or gprs->driver_attached is
changed.
As gprs_netreg_update() always returns here, so gprs->driver_attached won't be
changed.
So unless the network registration status changes to unregistered then registered again,
it won't attach GPRS again.
>
> 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.
best regards
Caiwen
7 p.m.
Hi Caiwen,
gprs_netreg_update() is the only place to change CGATT
automatically.
Following are the code of gprs_netreg_update().
ofono_bool_t attach;
attach = gprs->netreg_status == NETWORK_REGISTRATION_STATUS_REGISTERED;
attach = attach || (gprs->roaming_allowed &&
gprs->netreg_status == NETWORK_REGISTRATION_STATUS_ROAMING);
attach = attach && gprs->powered;
if (gprs->driver_attached == attach)
return;
As my comment above, because gprs->netreg_status is
1(NETWORK_REGISTRATION_STATUS_REGISTERED)
and gprs->driver_attached is TRUE. So (gprs->driver_attached == attach). This
function always
return here, unless, the value of gprs->netreg_status or gprs->driver_attached is
changed.
This is by design, I don't see anything inherently wrong here.
Remember, gprs_netreg_update is called from many places and this sanity
check is needed.
As gprs_netreg_update() always returns here, so
gprs->driver_attached won't be changed.
So unless the network registration status changes to unregistered then registered again,
it won't attach GPRS again.
But the CREG status is being toggled like crazy. Once CREG goes to
unregistered / searching we detach and set driver_attached to FALSE. It
sounds like your explanation isn't correct.
Regards,
-Denis
3629
days inactive
3656
days old
7 comments
3 participants
participants (3)
-
Caiwen Zhang -
Denis Kenzior -
Zhang, Caiwen