From: Michael Tokarev <mjt@tls.msk.ru>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: A very old issue: stalling serial ports
Date: Thu, 19 Apr 2012 18:22:33 +0400 [thread overview]
Message-ID: <4F901FA9.90107@msgid.tls.msk.ru> (raw)
This is something that exists since 2.4 kernel I think.
When any regular serial port is written, but no device
is connected to the port, the application which does
write becomes stuck in kernel mode somewhere, and may
be there for a very long time, unkillable.
Just a trivial
echo foo > /dev/ttyS0
will sleep for a long time, unkillable.
This happens on close of the device.
Here's a typical call trace of this:
[ 591.497867] bash S c1218130 0 1457 1453 0x00000000
[ 591.497965] f6c725e0 00000082 c14d77c0 c1218130 00000246 c121a4ed 00000287 f65080f0
[ 591.498229] f7005b40 c145cb40 c145cb40 ec834119 00000087 c145cb40 f65080f0 c145cb40
[ 591.498492] f6feb008 00000000 c1218735 c1216302 00000000 f6feb000 00000000 f65080f0
[ 591.498755] Call Trace:
[ 591.498797] [<c1218130>] ? serial8250_set_mctrl+0x60/0x70
[ 591.498844] [<c121a4ed>] ? serial8250_do_set_termios+0x2ad/0x3c0
[ 591.498891] [<c1218735>] ? serial8250_get_mctrl+0x5/0x40
[ 591.498937] [<c1216302>] ? uart_startup+0xe2/0x190
[ 591.498983] [<c105f850>] ? wake_up_bit+0x60/0x60
[ 591.499028] [<c12edf8a>] ? tty_lock+0x1a/0x33
[ 591.499072] [<c104ffe7>] ? lock_timer_base+0x27/0x50
[ 591.499119] [<c12ec856>] ? schedule_timeout+0x126/0x250
[ 591.499164] [<c10501a0>] ? del_timer+0xa0/0xa0
[ 591.499210] [<c1216fd0>] ? uart_close+0x170/0x2f0
[ 591.499255] [<c105f850>] ? wake_up_bit+0x60/0x60
[ 591.499300] [<c11feba0>] ? tty_release+0xf0/0x4e0
[ 591.499345] [<c12153d4>] ? uart_start+0x24/0x90
[ 591.499391] [<c105fb07>] ? remove_wait_queue+0x17/0x50
[ 591.499436] [<c1034bc2>] ? __wake_up+0x42/0x60
[ 591.499482] [<c10febfd>] ? fput+0xad/0x220
[ 591.499526] [<c10fb41d>] ? filp_close+0x4d/0x80
Now, depending on the kernel and/or on actual sequence of events --
I don't really know yet -- sometimes the app is stuck but is actually
killable, sometimes it "unstucks" by its own after some time (a
minute or two), sometimes it becomes unkillable forever.
To me it does not look like a feature, but I might be wrong.
Is it a rigth behavour?
Thank you!
/mjt
reply other threads:[~2012-04-19 14:22 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F901FA9.90107@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.