|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Hang on boot when using IPMI 2.0 SoL console
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
|
|
|
|
|