Bug 472511

do me a favor and tell me if the following command gets ctrl-c to work:
stty intr ^C
Thanks!

It seems not work.

dropping to initramfs shell
exiting this shell will reboot your system
root:/> stty intr ^C
stty: intr requires an argument
C: not found

root:/> stty intr '^C'
root:/> stty -a
speed 115200 baud; rows 0; columns 0;
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
root:/> sleep 5
<unable to interrupt>

I'm reserving hp-sw9300-01 to try fix this

Cai, I was initially thinking that I needed to capture a controlling tty to fix this (and I still do think that), but even when I manually set that up, it still fails to work.  I'm wondering if conmux is somehow swallowing or mangling ctrl-c and other control characters.  Do you have a system with an honest to gooness serial port you can try this on?

Just drop to a shell in kdump and issue this command:
getty -l /bin/msh -n 115200 /dev/console

Thanks!

also, Cai, you may want to try issuing this command after you get a prompt
stty intr ^C
I cant remember if the interrupt character was set on the system I tried on.

I have tried to setup a serial console locally without using commux, but using "cu -l /dev/ttyS0 -n 19200". However, the Ctrl-C was still impossible to interrupt commands. Because it was an IA-64 box using 19200 serial speed, so I was running the following command,

root:/> getty -l /bin/msh -n 19200 /dev/console
<it output nothing...>

root:/> dd
<ctrl-c is not working anymore.>

root:/> stty intr ^C
stty: intr requires an argument
C: not found
<this command looks like give some errors.>

root:/> stty intr '^C'
<it output nothing if I quote ^C.>

The more I look at this the more I become convinced that this is a controlling tty issue, and one that we can't solve while we're operating on /dev/console.  I'll see if I can change mkdumprd to establish a controlling tty automatically during operation, but this might be a can'tfix at the moment.

yeah, I'm sorry, I'm doing some reading here, and busybox init (which needs to run to set the ttys up) can only be run from the kernel (can't exec it from /init), so I can't fix this without including the real /sbin/init, which I think is more bloat than its worth at the moment.  I'll try to get this into my mkdumprd rewrite, but I'm afraid this is cantfix for the current implementation

I just found this and figured I'd contribute this response.  If it isn't what you're looking for, I appologize.  To get an interactive shell using busybox so that you have a controlling tty (to make use of control-c), execute the following in the shell (note, you'll need the proper /dev entries of course):

/sbin/getty -l /bin/sh -n 38400 tty1