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