Date:	Sat, 05 Jul 2008 13:58:40 -0600
From:	Joe Peterson <joe@...rush.com>
To:	Elias Oltmanns <eo@...ensachen.de>
CC:	Andi Kleen <andi@...stfloor.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Török Edwin <edwintorok@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists