Re: [Qemu-devel] [PATCH] 8250: more realistic TX-done IRQ rate

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

Paul Brook wrote:
> On Saturday 12 April 2008, Jan Kiszka wrote:
>> The 8250 UART emulation currently raises a TX-done IRQ immediately when the
>> guest writes out some character. This is problematic for guests like Linux
>> which may flush its output buffer in a loop from IRQ context, because they
>> may then enter a tight loop with IRQs disabled. In fact, Linux breaks out
>> of this loop after some iterations and issue the well-known [1] "too much
>> work for irq..." warning. And in case the console output is on the very
>> same serial port, the console output is utterly corrupted.
> 
> Please see previous threads on this topic.

Some keyword or reference at hand? I did try hpa's patch which was also 
posted here, but his fix didn't work in my case (some ARM board 
emulation on recent x86-64 Linux host).

> 
>> Patch below addresses the issue by delaying the TX-done IRQ more
>> realistically, ie. according to the currently set baudrate.
> 
> Unless the serial baud rate is extremely low (<1kbaud) this isn't going to 
> work with any sort of reliability.  You have to fix this in a way that doesn't
> require high resolution realtime response.

OK, having no highres clock underneath may cause much heavier delays 
with this patch than desired or acceptable. I guess I have to think 
about some accumulative approach that throttles every n characters for a 
few miliseconds. Even if that would mean delaying, e.g., 10 ms due to a 
slow host with tick-based timing (thus about 100 characters @115k), that 
should still be fine to address the original issue.

> I'd also expect you to have the same problem with the RX queue. If you don't 
> it's a bug elsewhere in qemu.
> 
>> +            qemu_mod_timer(s->tx_timer, 1000 / (11520 / s->divider));
> 
> This looks bogus. I think you're a few orders of magnitude out in your timing 
> calculations.  As mentioned above, in practice you unlikely to get anywhere
> near the necessary realtime performance out of qemu.

That depends. Current Linux distros typically have 
CONFIG_HIGH_RES_TIMERS enabled. But, of course, not many OSes QEMU works 
on have such support at all, and even Linux may decided to work without 
it for various reasons.

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]