Xen devel - Dec 2009 - [PATCH 0 of 1] Deal with Serial Over LAN (SOL) IPMI interfaces.

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. 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

# HG changeset patch
# User konrad@phenom.dumpdata.com
# Date 1260803272 18000
# Node ID 37cb71cbe3b4c02c2ea435b752eef888760ee2a6
# Parent  e75c840d7e7bb2bbbd6fdbabead529c5ad36d106
Handle bogus serial ports that appear normal, but don''t generate
interrupts e.g. the "remote serial console" on Blades.

Authored-by: Gary Grebus <Gary.Grebus@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com

diff -r e75c840d7e7b -r 37cb71cbe3b4 xen/drivers/char/ns16550.c
--- a/xen/drivers/char/ns16550.c	Fri Dec 11 11:12:10 2009 -0500
+++ b/xen/drivers/char/ns16550.c	Mon Dec 14 10:07:52 2009 -0500
@@ -39,6 +39,7 @@
     /* UART with no IRQ line: periodically-polled I/O. */
     struct timer timer;
     unsigned int timeout_ms;
+    int probing, intr_works;
 } ns16550_com[2] = { { 0 } };
 
 /* Register offsets */
@@ -127,6 +128,13 @@
     struct serial_port *port = dev_id;
     struct ns16550 *uart = port->uart;
 
+    if (uart->intr_works == 0)
+    {
+        uart->probing = 0;
+        uart->intr_works = 1;
+        stop_timer(&uart->timer);
+    }
+
     while ( !(ns_read_reg(uart, IIR) & IIR_NOINT) )
     {
         char lsr = ns_read_reg(uart, LSR);
@@ -143,6 +151,15 @@
     struct ns16550 *uart = port->uart;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
 
+    if ( uart->intr_works )
+        return;     /* Interrupts work - no more polling */
+
+    if ( uart->probing ) {
+        uart->probing = 0;
+        if ( (ns_read_reg(uart, LSR) & 0xff) == 0xff )
+            return;     /* All bits set - probably no UART present */
+    }
+
     while ( ns_read_reg(uart, LSR) & LSR_DR )
         serial_rx_interrupt(port, regs);
 
@@ -230,15 +247,14 @@
 
     serial_async_transmit(port);
 
+    init_timer(&uart->timer, ns16550_poll, port, 0);
+    /* Calculate time to fill RX FIFO and/or empty TX FIFO for polling. */
+    bits = uart->data_bits + uart->stop_bits + !!uart->parity;
+    uart->timeout_ms = max_t(
+        unsigned int, 1, (bits * port->tx_fifo_size * 1000) /
uart->baud);
+
     if ( uart->irq == 0 )
-    {
-        /* Polled mode. Calculate time to fill RX FIFO and/or empty TX FIFO. */
-        bits = uart->data_bits + uart->stop_bits + !!uart->parity;
-        uart->timeout_ms = max_t(
-            unsigned int, 1, (bits * port->tx_fifo_size * 1000) /
uart->baud);
-        init_timer(&uart->timer, ns16550_poll, port, 0);
         set_timer(&uart->timer, NOW() + MILLISECS(uart->timeout_ms));
-    }
     else
     {
         uart->irqaction.handler = ns16550_interrupt;
@@ -252,6 +268,12 @@
 
         /* Enable receive and transmit interrupts. */
         ns_write_reg(uart, IER, IER_ERDAI | IER_ETHREI);
+
+        /* Do a timed write to make sure we are getting interrupts. */
+        uart->probing = 1;
+        uart->intr_works = 0;
+        ns_write_reg(uart, THR, 0xff);
+        set_timer(&uart->timer, NOW() + MILLISECS(uart->timeout_ms));
     }
 }
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Dec 14, 2009 at 04:38:33PM +0000, Keir Fraser
wrote:
> On 14/12/2009 15:10, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com> 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
We (Virtual Iron) were confident enough to make it turned on in our production
builds.
I do not have the list of machines we certified anymore (the web-page went
bye-bye) so I can''t give you the test scope data :-(
> 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.
I am going to defer to Gary on the implementation details.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 14/12/2009 15:10, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com> 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.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Dec 14, 2009 at 11:36:09AM -0500, Konrad Rzeszutek Wilk
wrote:
> On Mon, Dec 14, 2009 at 04:38:33PM +0000, Keir Fraser wrote:
> > On 14/12/2009 15:10, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com> 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
> 
> We (Virtual Iron) were confident enough to make it turned on in our
production builds.
> I do not have the list of machines we certified anymore (the web-page went
> bye-bye) so I can''t give you the test scope data :-(
> 
Not sure if the Virtual Iron HCL helps.. it seems to be here:
http://www.oracle.com/technology/products/vm/virtual-iron-documentation.html

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 14/12/2009 15:10, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel