[LTP] LTP: futex_wake04 hangs forever on i386

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> > Doing a simple math if you have serial line on 115200 it can transwer
> > about 11.5 bits in 100uS so yes we can easily overload serial connection
> > if we print messages that fast, so increasing the sleep 10x times sounds
> > only reasonable.
> > 
> > On the other hand I guess that kernel shouldn't produce stalls just
> > because we write to serial too fast. I guess that the task writing to
> > serial should be sleeping in a waitqueue somewhere in kernel if it
> > attempts to write to a full serial buffer, which will effectivelly
> > slow down the writer and the test would work fine in this case...
> 
> That is what happened, no ? Stack trace shows that possibly same process 
> that had its execution interrupted by the time handler in a recent past 
> (with a leftover frame pointer indicated by ? apic_timer_interrupt) also 
> ran the handler for serial8250_interrupt() and that execution caused 
> some dmesg warnings like:
> 
> serial8250: too much work for irq
> 
> which I had. I guess having the terminal with a smaller buffer would 
> help here as well, since the calls to the interrupt handler would be 
> more often and less time consuming (because of baud rate).
> 
> Continuing, there was a software interrupt to flush serial 8250 contents 
> and it took too long to flush to the device, causing the task, waiting 
> on the line, to wait.
> 
> HOWEVER, for this case, for example, every single byte written to a 
> terminal memory mapped I/O register causes a VM_EXIT (in the host: 
> cpu->kvm_run->exit_reason == 2), giving execution back to the QEMU vCPU 
> (that had entered VM mode), that will schedule a function inside the 
> emulation thread to deal with that I/O (for the virtualized serial HW 
> being emulated) and calling the VM_ENTER again at some further point. 
> This could make the interrupt handler even slower.

Ok, I guess that I understand why this is so slow, we emulate PC memory
mapped serial port and we go back and forth for each byte we write. And
I guess that we cannot do much about this.

Also I suppose that it could be "fixed" by switching to virtio serial
driver that should be able to read the whole buffer in one go.

-- 
Cyril Hrubis
chrubis@suse.cz