[Bug 562] gsmd init script causes sysrq message

[bugzilla-daemon at bugzilla.openmoko.org]

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

balrogg at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From balrogg at gmail.com  2007-09-21 16:48 -------
I'm seeing it happen with the 2007-09-17 rootfs and 2.6.22.5 and .6 kernels
during boot.  I managed to reproduce it with a very verbose debugging kernel
that showed what the serial driver is doing when it happens.  Starting from the
moment when "/etc/init.d/gsmd start" is issued, chronologically:

- s3c24xx_serial_set_termios is called (CRTSCTS is unset in .c_cflag).

- s3c24xx_serial_set_mctrl is called with mctrl value 6.

- The following three lines are printed in the dmesg:
<6>gta01-pm-gsm gta01-pm-gsm.0: powered down GSM, thus enabling serial console
<6>gta01-pm-gsm gta01-pm-gsm.0: powering up GSM, thus disconnecting serial console
<7>modem wakeup interrupt

- s3c24xx_serial_rx_chars is called to handle an Rx IRQ.  It reads the UART0
UERSTAT and URXH registers. URXH (the character received) is 0x00 and UERSTAT
(Rx error status) is 0xe which means that a Frame-error, a Break-condition and a
Parity-error are present (in the 2410A datasheet version that I have, bits 1 and
3 are reserved, but in the driver they are Break and Parity bits).  The break
condition is remembered by the SysRq mechanism so that the next character
received will be treated as a SysRq.  The 0x00 char is ignored.

- s3c24xx_serial_set_termios is called again (CRTSCTS is unset in .c_cflag).

- s3c24xx_serial_set_termios is called again (CRTSCTS is set in .c_cflag).

- s3c24xx_serial_get_mctrl is called and the CTS bit is one in UART0 UMSTAT
register.

- s3c24xx_serial_rx_chars is called to handle the second Rx IRQ.  This time the
character received is the 'A' (from "AT-Command Interpreter ready") and there's
no error (UERSTAT is 0).  At this point handle_sysrq() is called by the
s3c24xx_serial driver with the 'A' as parameter:
<6>SysRq : HELP : loglevel0-8 reBoot Crashdump tErm Full kIll saK showMem Nice
powerOff showPc show-all-timers(Q) unRaw Sync showTasks Unmount shoW-blocked-tasks

The 'A' is ignored and the remaining "T-Command Interpreter ready" chars are
then received as usually.



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