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 ; David Newall wrote: > Elias Oltmanns wrote: > >> - if (!L_NOFLSH(tty)) { >> - n_tty_flush_buffer(tty); >> - tty_driver_flush_buffer(tty); >> - } >> if (L_ECHO(tty)) >> echo_char(c, tty); >> - if (tty->pgrp) >> - kill_pgrp(tty->pgrp, signal, 1); >> + isig(signal, ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 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

    David Newall wrote:
    > Elias Oltmanns wrote:
    >
    >> - if (!L_NOFLSH(tty)) {
    >> - n_tty_flush_buffer(tty);
    >> - tty_driver_flush_buffer(tty);
    >> - }
    >> if (L_ECHO(tty))
    >> echo_char(c, tty);
    >> - if (tty->pgrp)
    >> - kill_pgrp(tty->pgrp, signal, 1);
    >> + isig(signal, tty, 0);
    >>

    >
    > My first reaction is that tty->pgrp must be null. Perhaps the patch
    > could be simplified...
    >
    > if (tty->pgrp)
    > kill_pgrp(tty->pgrp, signal, 1);
    > + else
    > + isig(signal, tty, 0);
    >
    >
    > Thoughts?
    >


    isig has the same check, if it is NULL, isig won't deliver the signal
    either:

    if (tty->pgrp)
    kill_pgrp(tty->pgrp, sig, 1);

    --Edwin

    --
    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

    Török Edwin wrote:
    > David Newall wrote:
    >
    >> Elias Oltmanns wrote:
    >>
    >>
    >>> - if (!L_NOFLSH(tty)) {
    >>> - n_tty_flush_buffer(tty);
    >>> - tty_driver_flush_buffer(tty);
    >>> - }
    >>> if (L_ECHO(tty))
    >>> echo_char(c, tty);
    >>> - if (tty->pgrp)
    >>> - kill_pgrp(tty->pgrp, signal, 1);
    >>> + isig(signal, tty, 0);
    >>>
    >>>

    >> My first reaction is that tty->pgrp must be null. Perhaps the patch
    >> could be simplified...
    >>
    >> if (tty->pgrp)
    >> kill_pgrp(tty->pgrp, signal, 1);
    >> + else
    >> + isig(signal, tty, 0);
    >>
    >>
    >> Thoughts?
    >>
    >>

    >
    > isig has the same check, if it is NULL, isig won't deliver the signal
    > either
    >


    That is odd. We did see the control-key echoed, so, other than not
    flushing output, what's funcitonally different?
    --
    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

    Török Edwin wrote:
    > Elias Oltmanns wrote:

    [...]
    >> Since commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961, users have been
    >> unable to interrupt interactive processes reliably by pressing CTRL+C.
    >> This patch reverts the original commit except for the most important
    >> part: actually echoing ^C is preserved.
    >>

    >
    > Thanks for the patch , the process seems to respond faster to Ctrl-C,
    > but I'll have to find a way to measure that reliably.
    > However ^C is not echoed anymore for me.


    Very odd, it most definitely is echoed here. Are you quite sure you
    haven't inadvertently changed anything else in the meantime?

    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

    Török Edwin wrote:
    > Thanks for the patch , the process seems to respond faster to Ctrl-C,
    > but I'll have to find a way to measure that reliably.
    > However ^C is not echoed anymore for me.


    I found the same thing when I originally did the ^C echo patch. If isig() was
    used instead of the order specified (flush, echo, signal), the ^C did not echo
    reliably (i.e., it echoed on a tty console, but not in an xterm). isig() does
    the kill, then the flush.

    Note that ^Z uses the same logic, so the fact that you are seeing this take
    effect more quickly is interesting.

    I will try a few things today, but please experiment with various orderings of
    the calls and let me know what you find (and test the ^C echo in both tty
    console and xterm).

    -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/

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



    Elias Oltmanns wrote:
    > The following patch to 2.6.26-rc8 fixes the issue for me. Perhaps we
    > really want to do something else, but since I'm not all that familiar
    > with the standard behaviour on other Unices and since the comment
    > describing the changed order of function calls in the original commit
    > didn't give the reason for that change, I leave that to more
    > knowledgeable people.
    >
    > drivers/char/n_tty.c | 13 +------------
    > 1 files changed, 1 insertions(+), 12 deletions(-)
    >
    > diff --git a/drivers/char/n_tty.c b/drivers/char/n_tty.c
    > index 8096389..74018ef 100644
    > --- a/drivers/char/n_tty.c
    > +++ b/drivers/char/n_tty.c
    > @@ -759,20 +759,9 @@ static inline void n_tty_receive_char(struct tty_struct *tty, unsigned char c)
    > signal = SIGTSTP;
    > if (c == SUSP_CHAR(tty)) {
    > send_signal:
    > - /*
    > - * Echo character, and then send the signal.
    > - * Note that we do not use isig() here because we want
    > - * the order to be:
    > - * 1) flush, 2) echo, 3) signal
    > - */
    > - if (!L_NOFLSH(tty)) {
    > - n_tty_flush_buffer(tty);
    > - tty_driver_flush_buffer(tty);
    > - }
    > if (L_ECHO(tty))
    > echo_char(c, tty);
    > - if (tty->pgrp)
    > - kill_pgrp(tty->pgrp, signal, 1);
    > + isig(signal, tty, 0);
    > return;
    > }
    > }


    I noticed the original post in this thread mentioned that the problem
    has been seen since 2.6.21 or 2.6.23:

    > I use 2.6.25-2 and 2.6.26-rc8 now; I don't recall seeing this
    > behaviour with old kernels (IIRC I see this since 2.6.21 or 2.6.23).
    >
    > Is this intended behaviour, or should I report a bug?


    The echo patch that is altered in the patch above only appeared recently
    (in 2.6.25). Is there a way for you try try the test case on a
    pre-2.6.25 kernel and see if the issue exists there? If so, it is
    strange that the above fixes it.

    -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

    Joe Peterson wrote:
    > Elias Oltmanns wrote:
    >> The following patch to 2.6.26-rc8 fixes the issue for me. Perhaps we
    >> really want to do something else, but since I'm not all that familiar
    >> with the standard behaviour on other Unices and since the comment
    >> describing the changed order of function calls in the original commit
    >> didn't give the reason for that change, I leave that to more
    >> knowledgeable people.
    >>
    >> drivers/char/n_tty.c | 13 +------------
    >> 1 files changed, 1 insertions(+), 12 deletions(-)
    >>
    >> diff --git a/drivers/char/n_tty.c b/drivers/char/n_tty.c
    >> index 8096389..74018ef 100644
    >> --- a/drivers/char/n_tty.c
    >> +++ b/drivers/char/n_tty.c
    >> @@ -759,20 +759,9 @@ static inline void n_tty_receive_char(struct tty_struct *tty, unsigned char c)
    >> signal = SIGTSTP;
    >> if (c == SUSP_CHAR(tty)) {
    >> send_signal:
    >> - /*
    >> - * Echo character, and then send the signal.
    >> - * Note that we do not use isig() here because we want
    >> - * the order to be:
    >> - * 1) flush, 2) echo, 3) signal
    >> - */
    >> - if (!L_NOFLSH(tty)) {
    >> - n_tty_flush_buffer(tty);
    >> - tty_driver_flush_buffer(tty);
    >> - }
    >> if (L_ECHO(tty))
    >> echo_char(c, tty);
    >> - if (tty->pgrp)
    >> - kill_pgrp(tty->pgrp, signal, 1);
    >> + isig(signal, tty, 0);
    >> return;
    >> }
    >> }

    >
    > I noticed the original post in this thread mentioned that the problem
    > has been seen since 2.6.21 or 2.6.23:
    >
    >> I use 2.6.25-2 and 2.6.26-rc8 now; I don't recall seeing this
    >> behaviour with old kernels (IIRC I see this since 2.6.21 or 2.6.23).
    >>
    >> Is this intended behaviour, or should I report a bug?

    >
    > The echo patch that is altered in the patch above only appeared recently
    > (in 2.6.25). Is there a way for you try try the test case on a
    > pre-2.6.25 kernel and see if the issue exists there? If so, it is
    > strange that the above fixes it.


    Due to my tests, 2.6.24 responds much faster to Ctrl+C than 2.6.25 does.
    The patch above makes them *feel* alike again (no hard numbers, mind).
    However, I haven't checked anything as early as 2.6.21 or before so I
    don't know whether there may have been another regression since then.

    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/

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

    Elias Oltmanns wrote:
    > Due to my tests, 2.6.24 responds much faster to Ctrl+C than 2.6.25 does.
    > The patch above makes them *feel* alike again (no hard numbers, mind).
    > However, I haven't checked anything as early as 2.6.21 or before so I
    > don't know whether there may have been another regression since then.


    OK, thanks for checking. Can you try the patch below? It is almost the
    same as your patch, except it reverses the order of the isig and the echo.

    This causes ^C echo to work for me in both console and xterm. Back when
    I did the original patch, I was concerned this ordering could result in
    the ^C echoing late, but this may not be an issue.

    Let me know if the patch below fixes the issue with interrupting
    processes waiting for I/O.

    Thanks, Joe


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

    Elias Oltmanns wrote:
    > - /*
    > - * Echo character, and then send the signal.
    > - * Note that we do not use isig() here because we want
    > - * the order to be:
    > - * 1) flush, 2) echo, 3) signal
    > - */
    > - if (!L_NOFLSH(tty)) {
    > - n_tty_flush_buffer(tty);
    > - tty_driver_flush_buffer(tty);
    > - }
    > if (L_ECHO(tty))
    > echo_char(c, tty);
    > - if (tty->pgrp)
    > - kill_pgrp(tty->pgrp, signal, 1);
    > + isig(signal, tty, 0);
    > return;


    I've been doing some experimenting with the order of the three
    operations (flush, echo, and signal), and the behavior is slightly
    different with each.

    The way I have it in the code now matches the order used by FreeBSD, so
    there may actually be a good reason to flush the tty buffers *before*
    issuing the signal. Here is their snippet of code:

    if (ISSET(lflag, ISIG)) {
    if (CCEQ(cc[VINTR], c) || CCEQ(cc[VQUIT], c)) {
    if (!ISSET(lflag, NOFLSH))
    ttyflush(tp, FREAD | FWRITE);
    ttyecho(c, tp);
    if (tp->t_pgrp != NULL) {
    PGRP_LOCK(tp->t_pgrp);
    pgsignal(tp->t_pgrp,
    CCEQ(cc[VINTR], c) ? SIGINT : SIGQUIT, 1);
    PGRP_UNLOCK(tp->t_pgrp);
    }
    goto endcase;
    }
    if (CCEQ(cc[VSUSP], c)) {
    if (!ISSET(lflag, NOFLSH))
    ttyflush(tp, FREAD);
    ttyecho(c, tp);
    if (tp->t_pgrp != NULL) {
    PGRP_LOCK(tp->t_pgrp);
    pgsignal(tp->t_pgrp, SIGTSTP, 1);
    PGRP_UNLOCK(tp->t_pgrp);
    }
    goto endcase;
    }
    }

    The first section handles ^C and ^\ (and flushes read and write), and
    the second handles ^Z (only flushes read).

    In any case, we should consider if the flush in Linux should precede the
    signal. Perhaps interrupting before the flush can happen is bad?
    Perhaps this has something to do with anomalies observed (below) with
    other ordering, or maybe I'm seeing other latent bugs not involved with
    this at all.


    Now to the results of the ordering...

    flush, echo, signal (the way it is now)
    -------------------
    * Follows FreeBSD's ordering
    * works on both console and xterm
    * seems to delay interrupt when process is IO bound

    echo, signal, flush (proposed in Elias' patch)
    -------------------
    * seems to fix IO bound issue
    * echo works in console but not xterm

    signal, flush, echo
    -------------------
    * works in both console and xterm
    * may cause late echo (and does not match BSD order)
    * I tested inserting an artificial delay between flush and echo:
    strange result: in console, echo does not appear; in xterm,
    ^C appears right before next prompt, but sometimes
    echo does not appear, along with final program output
    (something eats the output)

    signal, echo, flush
    -------------------
    * same as above


    So changing the order seems to always introduce some bugs or issues.
    I'm still experimenting; feedback welcome!

    -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/

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

    Elias Oltmanns wrote:
    >> I have encountered the following situation several times, but I've been
    >> unable to come up with a way to reproduce this until now:
    >> - some process is keeping the disk busy (some cron job for example:
    >> updatedb, chkrootkit, ...)
    >> - other processes that want to do I/O have to wait (this is normal)
    >> - I have a (I/O bound) process running in my terminal, and I want to
    >> interrupt it with Ctrl+C
    >> - I type Ctrl+C several times, and the process is not interrupted for
    >> several seconds (10-30 secs)
    >> - if I type Ctrl+Z, and use kill %1 the process dies faster than
    >> waiting for it to react to Ctrl+C

    >
    > The following patch to 2.6.26-rc8 fixes the issue for me. Perhaps we
    > really want to do something else, but since I'm not all that familiar
    > with the standard behaviour on other Unices and since the comment
    > describing the changed order of function calls in the original commit
    > didn't give the reason for that change, I leave that to more
    > knowledgeable people.


    I have tried to reproduce the original poster's issue on
    2.6.26-rc8-git3 without success. In around 100 attempts (restarting the
    disk activity process over each time it completed), it always broke out
    after one ^C - one time took an extra second or two. Note that I did
    not run latencytop (did not have it compiled in my kernel) - if that is
    required for the test, let me know, but I assume it is just for
    gathering info when the issue occurs.

    Can you please try something for me? For one, apply the attached patch,
    which removes what seems to be a redundant flush (since both calls end
    up calling the same n_tty routine). This made no difference for me, but
    I am curious if it might help you.

    If you still see the problem, please try typing "stty noflsh" and try
    again. This disables the flush step, which may be affecting you.
    Again, this did not make a difference for me.

    It will really help me to know the results of these steps for you.

    As far as moving the flush after the signal, I have tried this (in the
    patch I posted earlier), and it ends up causing various anomalies in
    output, so I do not think that is the right solution.

    -Joe



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

    > disk activity process over each time it completed), it always broke out
    > after one ^C - one time took an extra second or two. Note that I did
    > not run latencytop (did not have it compiled in my kernel) - if that is
    > required for the test, let me know, but I assume it is just for
    > gathering info when the issue occurs.


    I really don't think this is tty related looking at the code involved and
    also the lack of actual measurements presented. More likely scheduler and
    VM related changes.

    Alan
    --
    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/

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

    Alan Cox wrote:
    >> disk activity process over each time it completed), it always broke out
    >> after one ^C - one time took an extra second or two. Note that I did
    >> not run latencytop (did not have it compiled in my kernel) - if that is
    >> required for the test, let me know, but I assume it is just for
    >> gathering info when the issue occurs.

    >
    > I really don't think this is tty related looking at the code involved and
    > also the lack of actual measurements presented. More likely scheduler and
    > VM related changes.


    Alan, many thanks for your assessment - it's greatly appreciated. Now
    that I've looked into it, the only peculiar thing I see is the redundant
    flush_buffer call. Do you think that should be removed anyway? It
    seems that the following two calls do the same thing in n_tty.c:

    n_tty_flush_buffer(tty);
    tty_driver_flush_buffer(tty);

    If this looks redundant, let me know, and I can submit a patch to just
    call n_tty_flush_buffer(tty).

    -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/

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

    Alan Cox writes:

    >> disk activity process over each time it completed), it always broke out
    >> after one ^C - one time took an extra second or two. Note that I did
    >> not run latencytop (did not have it compiled in my kernel) - if that is
    >> required for the test, let me know, but I assume it is just for
    >> gathering info when the issue occurs.

    >
    > I really don't think this is tty related looking at the code involved and
    > also the lack of actual measurements presented. More likely scheduler and
    > VM related changes.


    Why should the scheduler or VM behave differently for Ctrl-Z+kill
    versus Ctrl-C?

    Doesn't make sense to me. And yes I see this here regularly and it started
    at some point.

    -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/

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

    > Doesn't make sense to me. And yes I see this here regularly and it started
    > at some point.


    Lets have some profiles and TSC numbers then. I'm happy to believe some
    specific combination of hardware/timing shows up a real problem but
    looking at the tiny amount of code involved I can see no sane explanation
    as to why at this point.

    I'm not going to look further into it without real serious data from
    people seeing it.
    --
    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/

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

    Alan Cox wrote:
    >> Doesn't make sense to me. And yes I see this here regularly and it started
    >> at some point.

    >
    > Lets have some profiles and TSC numbers then. I'm happy to believe some
    > specific combination of hardware/timing shows up a real problem but
    > looking at the tiny amount of code involved I can see no sane explanation
    > as to why at this point.


    Well Elias showed that changing the order made a visible difference.

    > I'm not going to look further into it without real serious data from
    > people seeing it.


    So you're saying multiple independent people suffer from some kind of
    hallucination?

    -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/

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

    > > I'm not going to look further into it without real serious data from
    > > people seeing it.

    >
    > So you're saying multiple independent people suffer from some kind of
    > hallucination?


    I'm saying provide some data.
    --
    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/

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

    Alan Cox wrote:
    >>> I'm not going to look further into it without real serious data from
    >>> people seeing it.

    >> So you're saying multiple independent people suffer from some kind of
    >> hallucination?

    >
    > I'm saying provide some data.


    It sounds more like the ostrich approach to bug handling to me.

    So what kind of data do you want? Someone watching a wallclock while
    comparing Ctrl-Z+kill versus Ctrl-C on a IO intensive process?

    -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/

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

    > So what kind of data do you want? Someone watching a wallclock while
    > comparing Ctrl-Z+kill versus Ctrl-C on a IO intensive process?


    Latency traces with timestamps might be quite useful, they'd probably
    also tell you why it happened. I can't reproduce it, nobody has provided
    numbers so even if I wanted to work on it I couldn't do much.

    Instead I have lots of real tty, ATA and other work that needs doing
    which has quantified data, is reproducable and needs doing, so that will
    get done.

    Alan
    --
    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/

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

    Alan Cox wrote:
    >> So what kind of data do you want? Someone watching a wallclock while
    >> comparing Ctrl-Z+kill versus Ctrl-C on a IO intensive process?

    >
    > Latency traces with timestamps might be quite useful, they'd probably
    > also tell you why it happened.


    Ok so you're asking someone else to debug it.

    I can't reproduce it, nobody has provided
    > numbers so even if I wanted to work on it I couldn't do much.


    Well we had a patch (although I haven't tried it yet)

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

    Is that not concrete enough?

    > Instead I have lots of real tty, ATA and other work that needs doing
    > which has quantified data,


    All the reporters provided time stamp traces? @)

    -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/

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

    > Well we had a patch (although I haven't tried it yet)
    >
    > http://marc.info/?l=linux-kernel&m=121489861508496&w=2
    >
    > Is that not concrete enough?


    No. Apply a little engineering to this instead of running around acting
    on random unexplained proposals people don't agree works. Right now you
    look like a politician - mindlessly squawking about things you've not
    tried and proposing anything and everything which might improve matters
    without working out if they would and why.

    The tty layer is getting improved and fixed by applying proper
    engineering methods not by random flapping.

    So:

    observe, and if need be experiment to get further data
    produce a model of the behaviour which explains the data
    make the changes the explanation requires
    test
    repeat

    > > Instead I have lots of real tty, ATA and other work that needs doing
    > > which has quantified data,

    >
    > All the reporters provided time stamp traces?


    No they provided relevant data or enough info I can reproduce it here.

    Alan
    --
    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/

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

    The discussion seems to have become a little heated, so allow me to step
    in here ...

    Andi Kleen wrote:
    > Alan Cox wrote:

    [...]
    > I can't reproduce it, nobody has provided
    >> numbers so even if I wanted to work on it I couldn't do much.

    >
    > Well we had a patch (although I haven't tried it yet)
    >
    > http://marc.info/?l=linux-kernel&m=121489861508496&w=2
    >
    > Is that not concrete enough?


    Actually, I'm not to sure whether this really fixes the root cause of
    the problem -- I never have been and I meant to indicate as much in my
    email. It's been the first time I looked at the tty code and the patch
    was mainly guess work; all it does is reverting parts of a previous
    patch. My hope was to direct other people's (read: those who no the tty
    code) attention to a change that seemed to cause the problem. Perhaps I
    didn't make it clear enough at the time that I didn't really know *why*
    this change should cause any problem in the first place.

    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.

    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

    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 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.

    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/

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