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