Ticket #1366 (closed defect: fixed)

Opened 11 years ago

Last modified 10 years ago

GSM is unresponsive after resume on GTA01

Reported by: kevin@… Owned by: openmoko-kernel
Priority: high Milestone:
Component: kernel Version: current svn head
Severity: major Keywords:
Cc: buglog@…, mwester@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

When resuming from suspend, GSM is unresponsive. Wake-on-call, for instance,
wakes the device to the finger-lock screen but doesn't begin ringing. Sending an
SMS message to the device after resume does nothing. Panel applets show the
device is registered on the network but is still unresponsive.

Change History

comment:1 Changed 11 years ago by mwester@…

  • Cc mwester@… added
  • Severity changed from normal to major
  • dependson set to 79

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.

comment:2 Changed 11 years ago by roh

  • Owner changed from openmoko-kernel@… to openmoko-kernel

comment:3 Changed 10 years ago by mickey

  • Status changed from new to closed
  • HasPatchForReview unset
  • Resolution set to fixed

This seems to work reasonably well with FSO now.

Note: See TracTickets for help on using tickets.