From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: serial8250: too much work for irq4 Date: Wed, 18 Feb 2009 13:13:07 +0100 Message-ID: <87ljs4gcz0.fsf@pike.pond.sub.org> References: <87zlglqj8s.fsf@pike.pond.sub.org> <18843.60489.388061.644066@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <18843.60489.388061.644066@mariner.uk.xensource.com> (Ian Jackson's message of "Wed\, 18 Feb 2009 11\:08\:57 +0000") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Ian Jackson writes: > Markus Armbruster writes ("[Xen-devel] serial8250: too much work for irq4"): >> Wild guess: Unlike a real UART, the virtual UART empties as quickly as >> the kernel can stuff in bytes. So, while the kernel has bytes to stuff, >> it doesn't get around to doing much else. > > This is certainly true and would explain the message you see. > > Are there any other adverse symptoms ? In principle it would be > possible to add a rate limit but it seems poor to artificially > rate-limit a virtual device to the wall-clock speed of the physical > object. > > Ian. I see funny effects where serial output stalls until some input happens, but I don't know whether that's related, or whether xen-unstable has the same problem. The 8250 driver makes the (reasonable) assumption that the chip operates at a limited speed. All real UARTs do. The comment next to the printk in drivers/serial/8250.c says "If we hit this, we're dead." Sounds scary, but I figure it's overstating the case. The loop executes holding a spin lock, but is limited to 256 iterations. The printk fires if we hit the limit and take the emergency exit. Still, I'm worried we hog the cpu for longer than is healthy, or that taking the emergency exit isn't as harmless as it looks to me so far.