From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Grebus Subject: Re: Re: [PATCH 0 of 1] Deal with Serial Over LAN (SOL) IPMI interfaces. Date: Mon, 14 Dec 2009 19:03:29 -0500 Message-ID: <4B26D251.8000000@oracle.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 14/12/2009 15:10, "Konrad Rzeszutek Wilk" wrote: > >> During the testing of Intel blades we found that the Serial Over LAN >> does not generate IRQs that well. Gary came up with a patch that >> figures out if it needs to poll or just work as before (IRQ). The benefit >> of this patch is that you don't need to do: >> >> com1=115200,8n1,0 >> >> but instead can just do com1=115200,8n1 which is great in the field >> where you don't want the bootup file to change. > > Kinda gross, and I'm not sure it's straightforward enough that I trust it on > all systems that currently work fine (vast majority). I *might* consider it > if it's a non-default boot option to turn it on. I don't believe that Linux > does such things either, at least by default. The Linux 8250.c driver does something vaguely similar when initializing a UART. It explicitly transmits a character to force an interrupt to test that the THRE bit is handled correctly. I thought it a bit more risky to add an explicit sequence to test for the interrupt.... just start with polling enabled, and if the interrupt shows up it's ok to stop polling. But as you say, it's a small minority of systems that have this problem anyway (IIRC, we saw this for an Intel Clearbay platform). /gary