Ticket #562 (closed defect: fixed)

Opened 12 years ago

Last modified 11 years ago

gsmd init script causes sysrq message

Reported by: alphaone@… Owned by: michael@…
Priority: high Milestone:
Component: gsmd Version: current svn head
Severity: normal Keywords:
Cc: buglog@…, balrogg@…, mwester@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:


After the bootmessage "Starting GSM: success" the console shows the sysrq help
message. Something related to the gsm init script seems to trigger this message.
This only seems to happen if you remove the battery before turning the device on.

Change History

comment:1 Changed 12 years ago by alphaone@…

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

This hasn't happened to me for a while now so I'm marking this as fixed. If you
still see this with recent kernel/rootfs please reopen.

comment:2 Changed 12 years ago by balrogg@…

  • Status changed from closed to reopened
  • Resolution fixed deleted

I'm seeing it happen with the 2007-09-17 rootfs and 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


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

comment:3 Changed 12 years ago by balrogg@…

When testing I still had "console=ttyS0" in the boot parameters. When I removed
it, as suggested by Daniel Willmann, the serial driver now receives two Rx
interrupts and the SysRq? message went away. At the first interrupt it reads a
character 0xe0 from the modem, with no error indicated in UERSTAT - I don't know
where this may be coming from. Then immediately after, a second IRQ comes and
UERSTAT now indicates a Break-condition, a Parity-error and a Frame-error like
before. However, the 'A' character that comes next doesn't trigger the SysRq?
message anymore, maybe the period between the break condition and the 'A' is now
longer (there's a timeout check in the code).

I should note that it only happens after the battery had been removed before
turning the phone on. The behavior was identical all four times I tried booting
after removing the console on ttyS0.

comment:4 Changed 12 years ago by balrogg@…

  • Cc balrogg@… added

comment:5 Changed 11 years ago by mwester@…

  • Cc mwester@… added

comment:6 Changed 11 years ago by tick@…

  • Owner changed from laforge@… to michael@…
  • Status changed from reopened to new

comment:7 Changed 11 years ago by mickey@…

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

Keeping the kernel console quiet seems to fix this condition where we switch the
state of the multiplexed port. I consider this being FIXED.

Note: See TracTickets for help on using tickets.