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

[Jan Kiszka]

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

signature.asc
Description: OpenPGP digital signature