Ctrl+C doesn't interrupt process waiting for I/O - Kernel

This is a discussion on Ctrl+C doesn't interrupt process waiting for I/O - Kernel ; > > Actually, I'm not to sure whether this really fixes the root cause of > the problem Ok. > > on your screen when you keep pressing Ctrl+Z until the prompt appears; > in 2.6.24, for instance, there would ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 46 of 46

Thread: Ctrl+C doesn't interrupt process waiting for I/O

  1. Re: Ctrl+C doesn't interrupt process waiting for I/O


    >
    > Actually, I'm not to sure whether this really fixes the root cause of
    > the problem


    Ok.

    >
    > on your screen when you keep pressing Ctrl+Z until the prompt appears;
    > in 2.6.24, for instance, there would just be a short delay but no
    > irritating output on the screen that makes you wonder.
    >
    > Quite frankly, I'm a bit at a loss as to how I should go about debugging
    > this and what kind of data might be useful to others to do so. In
    > another email Alan talked about latency traces which is something new to
    > me. Since the OP talked about latencytop,


    I don't think latencytop would help to be frankly.

    > I hope that this tool provides
    > the data Alan requires and will install and make use of it accordingly
    > (expect some results later today or tomorrow). Of course, I'm always
    > open to other / additional suggestions.


    The way to do latency traces is to install the -rt patchkit, don't
    actually enable any of the RT features there, but enable CONFIG_FUNCTION_TRACE.

    The interface is unfortunately quite user unfriendly and it takes
    significant effort to set it up in a way and trigger
    at the right point and on the right CPU that you can actually
    get usable traces in my experience.

    The advantage is that once you have the trace for the right
    place (in this case from Ctrl-C to process exit) it is usually
    clear what the problem is. You'll have done all the work
    for Alan then.

    Also the work to do this is likely similar in effort to just bisecting
    it.

    -Andi


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Elias Oltmanns wrote:
    > Now, the situation has become even more delicate. Joe has reported that
    > my patch breaks echoing in the xterm and, rather to my embarrassment, I
    > have to report that it doesn't even fix the issue I claumed it would.
    > All it apparently does is making the problem slightly harder to
    > reproduce which is why it didn't occur in my tests at the time.


    Elias, thanks for your report. I could not reproduce the originally
    posted test case, but I wrote a small program that continuously produces
    output as a test. One thing I noticed was that the ease of breaking out
    of this program is affected quite a bit by other system/CPU activity.
    For example, if I was compiling the kernel, it became *easier* to break
    out (presumably because the I/O from the test program was getting less
    continuous CPU and so therefore the interrupt get "get in"). Similarly,
    if I moved the xterm window around on the screen (causing other activity
    by doing that) while waiting for the I/O program to terminate after
    hitting ^C, it would often break out at that point.

    So I do believe that one's subjective impression of how easy it is to
    break out of such an I/O-bound program can be affected by the general
    state of the system, and therefore it becomes fairly hard to draw a
    certain conclusion.

    > Since I have been concentrating on other things over the last days, it's
    > been only today that I discovered this. Moreover, some more testing lead
    > me to believe that the root issue has been present in mainline at least
    > since 2.6.19 and Joe's change in 2.6.25 only made it visible because you
    > now occasionally get something like
    > ^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z


    Ah! Yes, this makes a lot of sense, actually, and is a good example of
    a problem masquerading as something else. Thanks much for this insight.
    Knowing that the problem could have been around pre-2.6.25 is very
    useful info as well, and does indeed agree with Alan's thoughts that the
    issue is likely caused by something else (VM, scheduler, etc.).

    > Quite frankly, I'm a bit at a loss as to how I should go about debugging
    > this and what kind of data might be useful to others to do so.


    If you can, please try the new patch I attached to the post:

    http://marc.info/?l=linux-kernel&m=121520229900676&w=2

    It removes the call to tty_driver_flush_buffer(), which comes right
    after n_tty_flush_buffer() in n_tty.c. It will probably make no
    difference, but it would be good to hear either way. I am not sure if
    both calls are needed (if anyone reading this knows why both are called
    from n_tty.c, let me know), but I do know that the latter
    (tty_driver_flush_buffer) call ends up calling n_tty_flush_buffer as
    well, causing two flushes in a row.

    And also, if you can, try doing 'stty noflsh' and then the test case
    again to see if this alters behavior. This may be good to know as well,
    even if the flush is not centrally involved in the issue.

    Thanks, Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Joe Peterson wrote:
    > Elias Oltmanns wrote:

    [...]
    >> Quite frankly, I'm a bit at a loss as to how I should go about debugging
    >> this and what kind of data might be useful to others to do so.

    >
    > If you can, please try the new patch I attached to the post:
    >
    > http://marc.info/?l=linux-kernel&m=121520229900676&w=2


    Sorry, I just forgot to mention that I had already done that. It doesn't
    make any difference as far as I can see (not that I'm surprised about
    it).

    [...]
    > And also, if you can, try doing 'stty noflsh' and then the test case
    > again to see if this alters behavior. This may be good to know as well,
    > even if the flush is not centrally involved in the issue.


    No, that didn't make any difference either.

    Regards,

    Elias
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: Ctrl+C doesn't interrupt process waiting for I/O

    O> seems that the following two calls do the same thing in n_tty.c:
    >
    > n_tty_flush_buffer(tty);
    > tty_driver_flush_buffer(tty);


    Sorry missed this originally - they don't do the same thing. The first
    clears out anything in the ldisc internally the second clears out
    anything in the tty driver itself.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Alan Cox wrote:
    >> seems that the following two calls do the same thing in n_tty.c:
    >> n_tty_flush_buffer(tty);
    >> tty_driver_flush_buffer(tty);

    >
    > Sorry missed this originally - they don't do the same thing. The first
    > clears out anything in the ldisc internally the second clears out
    > anything in the tty driver itself.


    Alan, before I wrote this, I had put a printk() in n_tty_flush_buffer()
    and noticed it was called twice when ^C was hit in an xterm. Then I did
    some investigating into this a few days ago, putting a dump_stack() in
    n_tty_flush_buffer() so I could see how it is being called.

    I realized the calls indeed have different purposes at that point. I
    still wonder, though, why when processing a ^C in an xterm/pty,
    n_tty_flush_buffer() does get called again from the driver call. See
    the two traces below from the ldisc and driver flushes:

    *********** CTRL-C received
    Pid: 4669, comm: xterm Not tainted 2.6.26-rc8-git3 #1
    [] n_tty_flush_buffer+0xd/0x67
    [] n_tty_receive_buf+0x398/0xd87
    [] ? sock_aio_read+0xed/0xfb
    [] ? do_sync_read+0xab/0xe9
    [] ? hrtimer_forward+0xd6/0xec
    [] pty_write+0x2d/0x3b
    [] write_chan+0x21b/0x28f
    [] ? default_wake_function+0x0/0xd
    [] tty_write+0x14e/0x1be
    [] ? write_chan+0x0/0x28f
    [] ? rw_verify_area+0x8a/0xad
    [] ? tty_write+0x0/0x1be
    [] vfs_write+0x8c/0x133
    [] sys_write+0x3b/0x60
    [] sysenter_past_esp+0x78/0xb1
    =======================
    Pid: 4669, comm: xterm Not tainted 2.6.26-rc8-git3 #1
    [] ? pty_unthrottle+0x15/0x21
    [] n_tty_flush_buffer+0xd/0x67
    [] pty_flush_buffer+0x20/0x67
    [] ? _spin_unlock_irqrestore+0x1b/0x2f
    [] tty_driver_flush_buffer+0x13/0x15
    [] n_tty_receive_buf+0x39f/0xd87
    [] ? sock_aio_read+0xed/0xfb
    [] ? do_sync_read+0xab/0xe9
    [] ? hrtimer_forward+0xd6/0xec
    [] pty_write+0x2d/0x3b
    [] write_chan+0x21b/0x28f
    [] ? default_wake_function+0x0/0xd
    [] tty_write+0x14e/0x1be
    [] ? write_chan+0x0/0x28f
    [] ? rw_verify_area+0x8a/0xad
    [] ? tty_write+0x0/0x1be
    [] vfs_write+0x8c/0x133
    [] sys_write+0x3b/0x60
    [] sysenter_past_esp+0x78/0xb1
    =======================

    In a Linux virtual console/tty, however, the tty driver flush doesn't
    call the ldisc flush again in my tests:

    *********** CTRL-C received
    Pid: 6, comm: events/0 Not tainted 2.6.26-rc8-git3 #1
    [] n_tty_flush_buffer+0xd/0x67
    [] n_tty_receive_buf+0x398/0xd87
    [] ? _spin_lock_irqsave+0x27/0x41
    [] ? _spin_lock_irqsave+0x27/0x41
    [] ? _spin_unlock_irqrestore+0x1b/0x2f
    [] ? tty_ldisc_try+0x2f/0x35
    [] flush_to_ldisc+0xde/0x14d
    [] run_workqueue+0x78/0x102
    [] ? flush_to_ldisc+0x0/0x14d
    [] ? worker_thread+0x0/0xbf
    [] worker_thread+0xb4/0xbf
    [] ? autoremove_wake_function+0x0/0x33
    [] kthread+0x3b/0x64
    [] ? kthread+0x0/0x64
    [] kernel_thread_helper+0x7/0x10
    =======================


    -Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: Ctrl+C doesn't interrupt process waiting for I/O

    > In a Linux virtual console/tty, however, the tty driver flush doesn't
    > call the ldisc flush again in my tests:


    PTY/TTY is a pair - the driver flush of one side causes an ldisc flush of
    the other.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3