LinuxでRS-232を使用しているときにCTRL + Cが機能しないのはなぜですか？

Question

まず第一に、私はこれがSOに残っているのか、SUに行くべきか分かりません。私に教えてください。その解決策はプログラミングと関係しているかもしれません。

私は組み込み機器でLinuxを実行しており、RS-232 @ 9600ボーを使って通信しています。 Windows上のPuTTYを使ってすべてうまく動作します。シェルを持ち、コマンドを入力して実行できます。

問題は次のとおりです。コマンドを起動すると、Ctrl + Cを押すことができません。たとえば、あるマシンにpingを実行すると、pingは無限ループに入り、CTRL + Cを使用してpingを停止することはできません。しかし、BashプロンプトでCTRL + Cが機能し、次の行に移動します（送信されます）。コマンドを実行しているときにCTRL + Cを押すと、端末が^Cを表示していることに気付きました。 Telnetを介して接続する場合、CTRL + Cはどこでもうまく動作します。

PuTTYの「特殊コマンド」ブレークを試しましたが、動作しません。私も別の端末エミュレータ、同じ問題を試してみました。

だから私はこの問題が何とかカーネルに関係していると思います。これについて私が見ることができるものはありますか？

を編集します。BusyBox v1.13.2を実行しています。 stty -a（RS-232）の出力は次のようになります。stty -a（Telnetの）の出力は

speed 9600 baud; rows 24; columns 80; 
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; 
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; 
lnext = ^V; flush = ^O; min = 1; time = 0; 
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts 
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff 
-iuclc -ixany -imaxbel 
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke 

です

：

speed 38400 baud; rows 24; columns 80; 
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; 
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; 
lnext = ^V; flush = ^O; min = 1; time = 0; 
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts 
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany -imaxbel 
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0 
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke 

は、私はちょうど私がls -la /binをすれば、実行に長いコマンドであることに気づきましたリストは長いので、Ctrl + Cを押すだけでは中断することはできませんが、キーを押したままにすることはできます。それは約1秒後に壊れます。しかし、これはpingでは動作しません。実際に

私はseq 1 1000を行い、その後、CTRL + Cを押した場合、それはいくつかの点でワンショットで多くの行をスキップするように、それはそうは：

93 
94 
95 
^C6 
897 
898 
899 

同じことがls -la /binで発生：

lrwxrwxrwx 1 10042 2223   7 May 6 2012 dmesg -> busybox 
lrwxrwxrwx 1 10042 2223   7 May 6 2012 dos2unix -> busybox 
lrwxrwxrwx 1 10042 2223   7^C   7 May 6 2012 ipcrm -> busybox 
lrwxrwxrwx 1 10042 2223   7 May 6 2012 ipcs -> busybox 
lrwxrwxrwx 1 10042 2223   7 May 6 2012 iplink -> busybox 

Answer 1

組み込みデバイスのシリアルポート設定は、ブレーク文字を無視するか、ブレークの受信時に割り込みを引き起こさない可能性があります。これを変更するには、デバイスのシェル（または起動スクリプト）からsttyプログラムを実行するか、さまざまなioctl（）パラメタを使用してプログラムを作成します。

http://linux.die.net/man/1/stty

stty sane 

最善の策であることがございます。これは、 "通常の"設定の束を設定します。 constrastでは、あなたがデスクトップのLinuxのシェルウィンドウで

stty raw 

をすれば、あなたはおそらく、あなたの組み込みデバイス上で見ているCTRL-Cプリント - しかし-ない - 何も行動の種類を取得します。

引数を指定しないでsttyを実行すると、現在の設定が表示される可能性があります。特に、シリアルとtelnetセッションの結果を比較すると面白いかもしれません。

---

更新：busyboxのとBRKINT上のWeb検索は、おそらく、関連する何かが見つかりました：

Date: Thu, 31 Jan 2002 13:34:34 -0800 
From: Scott Anderson <scott_anderson at [removed]> 
Cc: linuxppc-dev at lists.linuxppc.org 
Subject: Re: why is tty->pgrp set to -1 for console? 

> What is the correct procedure to follow to get around this problem 
> and get ctrl-c working on console? 

It looks like everyone is taking a swing at this one, so I think I'll 
join in. First off, the easiest way I've found to track down why 
ctrl-c doesn't work is to just run "ps -j". For ctrl-c to work, you 
need a controlling terminal (the TTY column) and a process group. If 
you have a '?' in the TTY column, ctrl-c won't work. In the past I 
have seen this happen because of this code in drivers/char/tty_io.c: 
     if (device == SYSCONS_DEV) { 
       struct console *c = console_drivers; 
       while(c && !c->device) 
         c = c->next; 
       if (!c) 
         return -ENODEV; 
       device = c->device(c); 
       filp->f_flags |= O_NONBLOCK; /* Don't let /dev/console block */ 
       noctty = 1; 
     } 
Note that O_NOCTTY (no controlling terminal) is forced on whenever 
/dev/console is opened (noctty = 1). Possible workarounds: 
    1) Run getty on something other than /dev/console. For example, 
    if you console is on the first serial port, run getty on /dev/ttyS0. 
    I believe this is the "correct" answer. 
    2) You could also change getty to do a TIOCSCTTY ioctl explicitly after 
    it has opened the terminal. 
    3) You could remove the forcing of noctty on from tty_io.c