[Bug 1366] GSM is unresponsive after resume on GTA01

bugzilla-daemon at bugzilla.openmoko.org bugzilla-daemon at bugzilla.openmoko.org
Tue Apr 22 02:58:13 CEST 2008


mwester at dls.net changed:

           What    |Removed                     |Added
                 CC|                            |mwester at dls.net
  BugsThisDependsOn|                            |79
           Severity|normal                      |major

------- Additional Comments From mwester at dls.net  2008-04-22 02:58 -------
Very likely, there are multiple issues happening here.

First, as described in comment 34
(http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=79#c34) of bug
#79, you must have removed "console=ttySAC0,115200" from the bootargs in your
u-boot environment, otherwise spurious resume messages will be spewed into the
GSM during resume, which annoys it rather much and confused both it and gsmd.

Next, there is a problem in the GSM, UART, and suspend/resume logic that results
in an occasional buffer-overrun shortly after resume.  The symptoms are that the
GSM "holds it in" while the Neo resumes, then when the serial driver initializes
the UART, it dumps whatever it has over the serial connection.  This data
transmission is always ok, even if it is larger than the FIFO.  The problem is
the next one -- usually sent some 200ms later, the next transmission overruns
the FIFO.  It is not known if the problem is the GSM ignoring the desperate
attempts by the UART to flow control when the FIFO hits 14 characters, or if the
problem is that flow control never happens for some reason.  In any case, this
transmission is truncated at 16 characters (the size of the FIFO), which usually
causes gsmd to become confused (the GSM is fine; it's waiting for the Neo to
talk to it; the problem is clearly gsmd that is out-to-lunch here).  At some
point, gsmd calls the modem dead (it isn't), and exits.  The application
(dialer? phonekit?) that's on the other end talking to gsmd reports an I/O
error, and it too goes off to the loony bin.  At this point, you have a Neo that
is awake -- and you have no indication why, and the GUI looks like it's still
registered.  But nothing is happening underneath, and a reboot is your only
recovery choice.

There may be other failure modes, but that's what I've been working on lately.

A custom kernel that seems to crash less often, and has much debugging support,
is available.  Additional data-points may help solve this.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the openmoko-kernel mailing list