[PATCH 0 of 1] Deal with Serial Over LAN (SOL) IPMI interfaces.

[PATCH 0 of 1] Deal with Serial Over LAN (SOL) IPMI interfaces.

[Konrad Rzeszutek Wilk]

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. 

[PATCH 1 of 1] Handle bogus serial ports that appear normal, but don't generate

[Konrad Rzeszutek Wilk]

# 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));
     }
 }

Re: Re: [PATCH 0 of 1] Deal with Serial Over LAN (SOL) IPMI interfaces.

[Konrad Rzeszutek Wilk]

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.

Re: [PATCH 0 of 1] Deal with Serial Over LAN (SOL) IPMI interfaces.

[Keir Fraser]

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

Re: Re: [PATCH 0 of 1] Deal with Serial Over LAN (SOL) IPMI interfaces.

[Pasi Kärkkäinen]

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

Re: Re: [PATCH 0 of 1] Deal with Serial Over LAN (SOL) IPMI interfaces.

[Gary Grebus]

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