[Bug 766] gsmd misbehaves on back-to-back AT+CFUN=1/AT+COPS=0

bugzilla-daemon at bugzilla.openmoko.org bugzilla-daemon at bugzilla.openmoko.org
Sat Sep 8 07:57:25 CEST 2007


http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=766





------- Additional Comments From cesarb at cesarb.net  2007-09-08 07:57 -------
I think I understand now why does gsmd submit two commands back-to-back, even
when there's a break on atcmd_select_cb() commented as /* we only send one cmd
at the moment */, which should make it send only one command at a time.

After the break, select() is told to not generate a write event on the socket:

/* Either pending_atcmds is empty or a command has to wait */
g->gfd_uart.when &= ~GSMD_FD_WRITE;

However, g->pending_atcmds is now empty (the command was moved from it to
g->busy_atcmds just before the break). When it is empty, atcmd_submit() enables
GSMD_FD_WRITE, which makes the command be sent immediately, without waiting for
the command to receive its response.

So, if we want to enforce one-command-at-a-time behaviour for every command, we
should also check for llist_empty(&g->busy_atcmds) on atcmd_submit() (the patch
I attached to this bug should not be needed then). I will test it later today.


While looking at this, I found another potential bug: the return value for the
write(fd, "\r", 1) on atcmd_select_cb() is never checked, which could result on
a CR being dropped on a short write.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the buglog mailing list