qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Serial: possible hang during intensive interaction over


From: Andrey Korolyov
Subject: Re: [Qemu-devel] Serial: possible hang during intensive interaction over the console
Date: Tue, 9 Sep 2014 19:44:09 +0400

On Tue, Sep 9, 2014 at 7:28 PM, Kirill Batuzov <address@hidden> wrote:
> On Fri, 5 Sep 2014, Andrey Korolyov wrote:
>
>> >
>> > Heh, it is kernel- (defaults-) dependent after all. Debian hangs
>> > always, on 3.10, 3.14 and 3.16, Fedora 20 works fine on 3.15. I`ll
>> > check if there are any 82550-specific patches in Fedora tree a bit
>> > later.
>>
>>
>> It is a setting-dependent issue, checked this. Though I am still
>> searching which option causing such a huge difference, vast majority
>> of distros with default kernels hanged completely during test. Stock
>> SuSE/CentOS/Debian kernels can be used for testing.
>>
>
> I managed to reproduce it finally with debian live image. Resulting
> command line was:
>
> qemu-system-x86_64 -enable-kvm -m 512 -smp 12  \
>           -cdrom debian-live-7.6.0-amd64-standard.iso
>
> Commands to run in guest console:
> # yes > /dev/ttyS0 &
> # yes > /dev/ttyS0 &
>
> Looks like it is the old "serial8250: too much work for irq4" bug.

Exactly, may be I made this unclear earlier. The only problem is that
the current emulator is very happy to hang on certain guest kernel
settings (I postponed searching for magic options which allowed Fedora
kernel to work after trying some obvious like defaults in the timer
subsystem).

>
> In short: QEMU serial port transmits data as fast as it can ignoring
> baud rate completely. As a result we are stuck in serial8250_interrupt
> ISR in kernel most of the time.

It`s hardly explains how more than one threads are getting locked, at
least for me. You may see in surviving Fedora case that the just one
core is eaten up, as it should be. May be after a couple of NMI was
fired it is possible to lock multiple cores, but I don`t have better
explanation.

>
> Overall we have a large issue with rate control and flow control for
> virtual serial port implementations. In QEMU we have over dozen different
> UARTs for different platforms. Among them only one uses baud rate
> (strongarm) and only one implements flow control (16550A).
>
> CC'ing some people to discuss general course of action in regards to
> serial implementation.
>
> We probably want some abstract "serial" which is able to transmit one
> character with fixed baud rate and maximum retry count. The actual
> serial port implementations should implement interrupts, control
> registers and FIFO around it. With such design we will not need to
> implement the same bits of rate control and retry logic for every UART
> in QEMU.
>
> Any thoughts on this?
>
> --
> Kirill



reply via email to

[Prev in Thread] Current Thread [Next in Thread]