Fixing the stdio console stuttering.

PATCH In review Rob Landley 2 participants 2 messages Mar 14, 2005 User-mode Linux (UML)

Share & tools

Rob Landley

author

2005-03-14 06:46 UTC #0 lore raw

PATCH 1/1 Fixing the stdio console stuttering.

I spent far too much of the weekend tracking this sucker down through the guts of the tty code. The problem turns out to be that drivers/char/n_tty.c has a write_chan that does buffering and retransmitting data, and arch/um/drivers/chan_kern.c ALSO has a write_chan that buffers and retransmits data, and the first calls the second but the second doesn't always return correct status information for the -EAGAIN case.

When they get confused, both of them try to buffer and retransmit data, hence the stuttering.

The first fix is that if chan_kern's write_chan gets an -EAGAIN, it should NOT gratuitously change that to a 0 before returning. I don't know why that code is in there, but deleting those two lines makes 90% the stuttering go away. But not quite all of it.

The second half of the fix is arch/um/drivers/line.c has a buffer_data() function that adds data to the buffer, tries to flush the buffer out to disk, gets -EAGAIN, and then returns -EAGAIN even though it successfully buffered all the data it was sent. So the upper layer resubmits the last chunk of data it sent when the console unblocks, even though the lower layer buffered it and sent it on by that point.

With this patch, I can't get the UML console to stutter anymore by suspending the process it's writing to. (Add tee to the mix and you can still make it hang by suspending its xterm for a second or two, but I think that tee is hanging, not UML. Hangs with RHEL4 tee, but not busybox tee...)

Signed-off-by Rob Landley <[email protected]>

arch/um/drivers/chan_kern.c +1 -4

diff -ru linux-2.6.11.2/arch/um/drivers/chan_kern.c linux-2.6.11-umlfix/arch/um/drivers/chan_kern.c
@@ -250,11 +250,8 @@
 		n = chan->ops->write(chan->fd, buf, len, chan->data);
 		if (chan->primary) {
 			ret = n;
-			if ((ret == -EAGAIN) || ((ret >= 0) && (ret < len))){
+			if ((ret == -EAGAIN) || ((ret >= 0) && (ret < len)))
 				reactivate_fd(chan->fd, write_irq);
-				if (ret == -EAGAIN)
-					ret = 0;
-			}
 		}
 	}
 	return(ret);

arch/um/drivers/line.c +1 -1

diff -ru linux-2.6.11.2/arch/um/drivers/line.c linux-2.6.11-umlfix/arch/um/drivers/line.c
@@ -128,7 +128,7 @@
 		ret = buffer_data(line, buf, len);
 		err = flush_buffer(line);
 		local_irq_restore(flags);
-		if(err <= 0)
+		if(err <= 0 && (err != -EAGAIN || !ret))
 			ret = err;
 	}
 	else {

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Jeff Dike

2005-03-14 14:26 UTC #1 lore raw

Quoted 7 lines · [email protected] said:

I spent far too much of the weekend tracking this sucker down through the guts of the tty code. The problem turns out to be that drivers/ char/n_tty.c has a write_chan that does buffering and retransmitting data, and arch/um/drivers/chan_kern.c ALSO has a write_chan that buffers and retransmits data, and the first calls the second but the second doesn't always return correct status information for the -EAGAIN case.

Excellent, thanks.

Jeff