4

まず第一に、これがSOにとどまるのか、SUに行くのかわかりません。教えてください。解決策はプログラミングに関係している可能性があります。

組み込みデバイスでLinuxを実行し、RS-232@9600ボーを使用してLinuxと通信しています。WindowsでPuTTYを使用すると、すべてが正常に機能します。シェルがあり、コマンドを入力して実行できます。

問題は、コマンドを起動したときにCTRL+Cができないことです。たとえば、あるマシンにpingを実行すると、pingは無限ループに入り、CTRL+Cを使用して停止できません。ただし、Bashプロンプトでは、CTRL + Cが機能し、次の行に移動します(送信されます)。^Cまた、コマンドの実行中にCTRL + Cを実行すると、ターミナルが表示されていることに気付きました。Telnet経由で接続する場合、CTRL+Cはどこでも正常に機能します。

PuTTYの「特殊コマンド」ブレークを使用してみましたが、機能しません。同じ問題で、別のターミナルエミュレータも試しました。

ですから、問題はどういうわけかカーネルに関連していると思います。これに関して私が調べることができるものはありますか?

編集:私はBusyBoxv1.13.2を実行しています。stty -a(RS-232)の出力は次のとおりです。

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

stty -a(Telnet)の出力は次のとおりです。

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
4

2 に答える 2

3

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

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

stty sane 

最善の策かもしれません。これにより、一連の「通常の」設定がセットアップされます。対照的に、あなたがするなら

stty raw 

デスクトップLinuxのシェルウィンドウでは、組み込みデバイスで見られるようなctrl-Cprints-but-does-nothing動作が発生する可能性があります。

引数なしで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
于 2012-05-06T02:59:00.540 に答える