[Bug 788] Starting or stopping gsmd completely locks up the Neo

bugzilla-daemon at bugzilla.openmoko.org bugzilla-daemon at bugzilla.openmoko.org
Tue Sep 11 07:13:19 CEST 2007


------- Additional Comments From mwester at dls.net  2007-09-11 07:13 -------
The root problem has been determined to be that enabling hardware flow control
on the console (not the GSM modem) will result in the system becoming
unresponsive to user input.

OVERVIEW: Upon starting, gsmd will set the the ttySAC0 port to enable hardware
flow control.  When gsmd exits, or is killed, it leaves the port with hardware
flow control enabled.  In and of itself, this situation is not a problem, as
long as the port remains switched to the GSM modem.  However, as soon as the
/etc/init.d/gsmd script (or the user) turns off the GSM modem, the port is
switched to the console, hardware flow control is left enabled, and the first
kernel message printed to the console port will result in the device locking up
in a loop in the serial driver, presumably waiting for the correct modem control
lines to signal that it is ok to send data -- an event that won't happen on a
standard P1 device.


WORKAROUND:  the simple workaround is to explicitly set the port to disable
hardware flow control before the GSM modem is powered off and switched back to
the console.  This can be accomplished by editing the /etc/init.d/gsmd script,
and changing the startup as follows:

case "$1" in
        stty -F /dev/ttySAC0 -crtscts
        [ -n "$GSM_POW" ] && ( echo "0" >$GSM_POW; sleep 1 )
        [ -n "$GSM_POW" ] && ( echo "1" >$GSM_POW; sleep 1 )

It is also necessary to change the shutdown as follows:

        echo -n "Stopping GSM daemon: "
        start-stop-daemon -K -x /usr/sbin/gsmd
        stty -F /dev/ttySAC0 -crtscts
        [ -n "$GSM_POW" ] && echo "0" >$GSM_POW
        echo "gsmd."

For convenience, a suitably modified (and tested) gsmd script is attached to
this bug.

LONG-TERM SOLUTION: It seems probable that there are multiple issues here.  In
the first place, it seems unreasonable that the device becomes completely
unresponsive in the event that the console is flow-controlled.  This may be a
bug in the console driver, or the serial driver.

However, the contention between the console and gsmd over the port settings is
an issue that needs resolution.  Disabling the console completely is one
solution, but that makes kernel debugging work difficult at best.  Adding logic
to ensure that gsmd resets the flow control on the port before exiting is a poor
solution, as there are numerous failure modes for gsmd that would not permit it
to perform such a reset, resulting in the same problem.  In addition, since gsmd
does not actually do the power-on of the GSM modem, simply starting gsmd without
powering on the GSM modem will result in the same lock-up of the device.  Thus,
it seems logical that the code that switches the gsm modem should also ensure
that the port flow-control settings (at least) are switched as appropriate,
rather than rely on separate user actions, or on gsmd.  This would mean that
powering up the GSM modem would also require that flow control be enabled, and
conversely powering down would disable flow control.


OTHER CONSIDERATIONS: The current console/GSM modem switch code is extremely
limited.  It might be worthwhile considering a more ambitious architecture, one
that would be more flexible.  For example, in the event of a kernel oops, it
would not be unreasonable to forcibly switch the console on and power off the
GSM modem, thus enabling the kernel to display the oops output.

------- 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