From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47840 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCxZu-0001aT-Nq for qemu-devel@nongnu.org; Fri, 14 May 2010 12:17:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCxZs-0001u5-9K for qemu-devel@nongnu.org; Fri, 14 May 2010 12:17:34 -0400 Received: from goliath.siemens.de ([192.35.17.28]:19554) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCxZr-0001tv-Qf for qemu-devel@nongnu.org; Fri, 14 May 2010 12:17:32 -0400 Message-ID: <4BED778E.4090105@siemens.com> Date: Fri, 14 May 2010 18:17:18 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1271782566-16420-1-git-send-email-agraf@suse.de> <4BE024A9.2040904@codemonkey.ws> <16E7906F-F39B-4121-B540-E2F0E67D405E@suse.de> <4BE0307C.1010305@codemonkey.ws> <0D8C0E80-5325-4E50-A2EF-E73BB95AD8DA@suse.de> <4BE04A78.6070505@codemonkey.ws> <4BE05034.9060803@siemens.com> <4BE11F54.1030900@web.de> <4BE12763.8000809@web.de> <4BE18E60.8070709@siemens.com> <4BE98445.9000203@suse.de> <4BE98600.5030905@siemens.com> <4BE9873C.9050301@suse.de> <4BEAF898.3020001@web.de> <47896AB9-783F-437B-B4E2-81095B78DA2C@suse.de> In-Reply-To: <47896AB9-783F-437B-B4E2-81095B78DA2C@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] char: Flush read buffer in mux_chr_can_read List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Bastian Blank , Jan Kiszka , qemu-devel Developers , Aurelien Jarno Alexander Graf wrote: > On 12.05.2010, at 20:51, Jan Kiszka wrote: > >> Alexander Graf wrote: >>> Jan Kiszka wrote: >>>> Alexander Graf wrote: >>>> >>>>> Jan Kiszka wrote: >>>>> >>>>>> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the >>>>>> latter is called periodically, the former will only be invoked when new >>>>>> characters arrive at the back-end. This caused problems to front-end >>>>>> drivers whenever they were unable to read data immediately, e.g. >>>>>> virtio-console attached to stdio. >>>>>> >>>>>> >>>>> I don't see this patch applied, but also don't see any issues with >>>>> virtio-console anymore on today's git. Odd. >>>>> >>>>> >>>> Hmm, I had a clear before-after experience using virtio console with an >>>> x86 Linux guest. I still think my patch is correct and required. Maybe >>>> you can bisect this positive "regression"? Something might paper over >>>> the core issue now. >>>> >>> I just did a git reset --hard on >>> baf0b55a9e57b909b1f8b0f732c0b10242867418 and it worked! What the ... >> Whatever "worked" now means (I'm slightly confused), I just rechecked >> the situation over current git head ("qemu linux-guest.img -chardev >> stdio,id=cons,mux=on -device virtio-serial -device >> virtconsole,chardev=cons -mon chardev=cons", "cat /dev/hvc0" in the >> guest, typing some chars on the host console): The problem still >> persists, my patch still solves it. Can you confirm this, ideally also >> for s390? > > Now that I can finally reproduce the bug with --enable-io-thread, I can verify that it does *not* fix the issue. I do not trust your tests. :p I just tried to reproduce with --enable-io-thread and the setup I described above - all still fine here. Can you reproduce with an x86 guest? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux