Subject: Re: Serial: bug in 8250.c when handling PCI or other level triggers
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20051214165549.GE7124@flint.arm.linux.org.uk>
References: <1134573803.25663.35.camel@localhost.localdomain>
	 <20051214165549.GE7124@flint.arm.linux.org.uk>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 14 Dec 2005 19:08:08 +0000
Message-Id: <1134587288.25663.61.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1070
Lines: 28

On Mer, 2005-12-14 at 16:55 +0000, Russell King wrote:
> If we trigger this, we can assume that the port is dead anyway, or
> we're in a situation where the host CPU can not keep up with the
> data stream.

Not actually true in some cases.

- When your UART has a large FIFO and pretends to be an 8250 you can get
a 256 byte burst triggered by the box sleeping for a moment or the BIOS
SMI crap going to chat to the battery

- On a virtualised system this trap can trigger because the emulations
don't emulate the bit arrival and baud rate.

In both of those cases recovery is viable. For that matter so is
recovery when the user responds to the complaint message by unplugging
the cable, or where a long burst of framing errors hits you from a
misconfiguration.

Possibly the first two just argue for a larger limit ?

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/