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. 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. 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