WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Hang on boot when using IPMI 2.0 SoL console

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Hang on boot when using IPMI 2.0 SoL console
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 10 Dec 2009 11:34:39 -0800
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Thu, 10 Dec 2009 11:35:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C7463EC6.410A%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C7463EC6.410A%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091125 Fedora/3.0-3.12.rc1.fc12 Lightning/1.0pre Thunderbird/3.0
On 12/09/09 21:59, Keir Fraser wrote:
So the interrupt line isn't working for your com3, for some reason.

The Linux driver has two SoL-specific hacks (below). But I don't think either of these are coming into play in this case; the first only applies with a serial break, and the second is only enabled if it detects specific Intel PCI devices (which don't exist on this particular machine; the SoL is part of the integrated IPMI BMC, not an AMT ethernet device).

Presumably the Linux driver is managing to work around the problems - either accidentally or deliberately - in some more subtle way.

    J

static void
receive_chars(struct uart_8250_port *up, unsigned int *status)
{
        struct tty_struct *tty = up->port.info->port.tty;
        unsigned char ch, lsr = *status;
        int max_count = 256;
        char flag;

        do {
                if (likely(lsr&  UART_LSR_DR))
                        ch = serial_inp(up, UART_RX);
                else
                        /*
                         * Intel 82571 has a Serial Over Lan device that will
                         * set UART_LSR_BI without setting UART_LSR_DR when
                         * it receives a break. To avoid reading from the
                         * receive buffer without UART_LSR_DR bit set, we
                         * just force the read character to be 0
                         */
                        ch = 0;

and

static int serial8250_startup(struct uart_port *port)
{
...
        /* Serial over Lan (SoL) hack:
           Intel 8257x Gigabit ethernet chips have a
           16550 emulation, to be used for Serial Over Lan.
           Those chips take a longer time than a normal
           serial device to signalize that a transmission
           data was queued. Due to that, the above test generally
           fails. One solution would be to delay the reading of
           iir. However, this is not reliable, since the timeout
           is variable. So, let's just don't test if we receive
           TX irq. This way, we'll never enable UART_BUG_TXEN.
         */
        if (up->port.flags&  UPF_NO_TXEN_TEST)
                goto dont_test_tx_en;
...


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