All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Gerd Knorr <kraxel@bytesex.org>, Blaisorblade <blaisorblade@yahoo.it>
Subject: Re: [uml-devel] Re: Fw: [patch] uml: terminal cleanup
Date: Thu, 10 Mar 2005 22:04:08 -0500	[thread overview]
Message-ID: <200503102204.08432.rob@landley.net> (raw)
In-Reply-To: <20050310081340.GC17880@bytesex>

On Thursday 10 March 2005 03:13 am, Gerd Knorr wrote:

> Ouch.  I've never seen that myself though, works perfectly fine for me.
> Could be somehow related to the scrambled compiler logs reported a few
> weeks ago, maybe the tty/line buffer handling is broken ...

I've done some more debugging on that, and I can reproduce it at will on any 
machine now.  The problem is that if the process that is on the other end of 
UML's output pipe gets stopped (like the Xterm consuming the UML output), its 
retry logic is borked.

I have a more detailed analysis with debug info on another machine (I'll try 
to dig that up later tonight), but really briefly, find out the PID of the 
xterm you're running in, I.E. the parent process of the shell you're going to 
run it under ("ps" followed by "ps l" should do it).  Then set up a dumb 
little script ala

while /bin/true
do
	kill -STOP $PID
	sleep 1
	kill -CONT $PID
	sleep 1
done

And now run UML and do and extract a tarball under it or something, and watch 
the output go bananas.

The requeue logic handling -EAGAIN requeues the data that's already on the 
buffer, not the new data that should go ON the buffer.  That's why the 
stuttering.  (What happens when the 4k buffer fills up is anybody's guess.  I 
think data just gets dropped.)

Rob


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

      reply	other threads:[~2005-03-11  4:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20041128010910.1b5478c7.akpm@osdl.org>
2005-03-05 17:58 ` [uml-devel] Re: Fw: [patch] uml: terminal cleanup Blaisorblade
2005-03-08  8:25   ` Gerd Knorr
2005-03-09 18:38     ` Blaisorblade
2005-03-10  8:13       ` Gerd Knorr
2005-03-11  3:04         ` Rob Landley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200503102204.08432.rob@landley.net \
    --to=rob@landley.net \
    --cc=blaisorblade@yahoo.it \
    --cc=kraxel@bytesex.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.