| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: dom0 serial input overruns
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> writes:
> On Sun, Mar 20, 2011 at 12:02:08PM +0100, Ferenc Wagner wrote:
>
>> I'm running a HA Xen cluster, where the dom0s are crosslinked via a
>> null modem serial cable for heartbeat redundancy. This works most of
>> the time, but the serial connection is very unreliable, dropping
>> characters all the time, with lot of messages like "ttyS0: 2 input
>> overrun(s)" in dmesg.
>
> If you use the hypervisor serial connection "console=com1 com1=11152..."
> and re-route the console output in Linux kernel to it (console=hvc0)
> does this problem disappear?
Hi,
That's indeed a valid point which I forgot to discuss above, sorry. I
actually use the second serial port as Xen and Linux console:
"com2=auto,8n1 console=com2L,vga" on the Xen command line and
"console=hvc0 earlyprintk=xen" on the Linux command line. The first
serial port is used by heartbeat (the software) as a safety (parallel)
communication channel in case of a network partition. I'm not sure if
heartbeat would accept /dev/hvcX as a serial device, but even now the
Xen (and Linux) serial console is also lossy as hell (at 57600 baud, as
dictated by the DRAC management card in the machine and configured by
the boot loader). However, this lossage isn't accompanied by any
warning. I hope this answers your question. I also run the exact same
hardware configuration without Xen, and the Linux console is perfectly
solid in that case (like it should under hardware flow control). As an
illustration, here's the serial output of querying ioapic info on the
Xen console:
(XEN) number of MP IRQ sources: 16.
(XEN) number of IO-APIC #8 registers: 16.
(XEN) number of IO-APIC #9 registers: 16.
(XEN) number of IO-APIC #10 registers: 16.
(XEN) testing the IO APIC.......................
(XEN) IO APIC #8......
(XEN) .... register #00: 00000000
(XEN) ....... : physical APIC id: 00
(XEN) ....... : Delivery Type: 0
(XEN) ....... : LTS : 0
(XEN) .... register #01: 000F0011
(XEN) ....... : max redirection entries: 000F
(XEN) ....... : PRQ implemented: 0
(XEN) ....... : IO APIC version: 0011
(XEN) .... register #02: 00000000
(XEN) ....... : arbitration: 00
(XEN) .... IRQ redirection table:
(XEN) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
(XEN) 00 0FF 0F 1 0 0 0 0 0 0 F0
(XEN) 01 001 01 0 0 0 0 0 1 1 28
(XEN) 02 001 01 0 0 0 0 0 1 1 30
(XEN) 03 0FF 0F 0 0 0 0 0 1 1 F2
(XEN) 04 001 01 0 0 0 0 0 1 1 38
(XEN) 05 001 01 0 0 0 0 0 1 1 40
(XEN) 06 001 01 0 0 0 0 0 1 1 48
(XEN) 07 001 01 0 0 0 0 0 1 1 50
(XEN) 08 001 01 0 0 0 0 0 1 1 58
(XEN) 09 001 01 0 0 0 0 0 1 1 60
(XEN) 0a 001 01 0 0 0 0 0 1 1 68
(XEN) 0b 001 01 0 1 0 1 0 1 1 70
(XEN) 0c 001 01 0 0 0 0 0 1 1 78
(XEN) 0d 00F 0F 1 0 0 0 0 1 1 88
(XEN) 0e 001 01 0 0 0 0 0 1 1 90
(XEN) 0f 001 01 0 0 0 0 0 1 1 98
(XEN) IO APIC #9......
(XEN) .... register #00: 00000000
(XEN) ....... : physical APIC id: 00
(XEN) ....... : Delivery Type: 0
(XEN) ....... : LTS : 0
(XEN) .... register #01: 000F0011
(XEN) ....... : max redirection entries: 000F
(XEN) ....... : PRQ implemented: 0
(XEN) ....... : IO APIC version: 0011
(XEN) .... register #02: 00000000
(XEN) ....... : arbitration: 00
(XEN) .... IRQ redirection table:
(XEN) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
(XEN) 00 000 00 1 0 0 0 0 0 0 00
(XEN) 01 000 00 1 0 0 0 0 0 0 00
(XEN) 02 000 00 1 0 0 0 0 0 0 00
(XEN) 03 000 00 1 0 0 0 0 0 0 00
(XEN) 04 000 00 1 0 0 0 0 0 0 00
(XEN) 05 000 00 1 0 0 0 0 0 0 00
(XEN) 06 000 00 1 0 0 0 0 0 0 00
(XEN) 07 00F 0F 1 1 0 1 0 1 1 A0
(XEN) 08 000 00 1 0 0 0 0 0 0 00
(XEN) 09 000 00 1 0 0 0 0 0 0 00
(XEN) 0a 000 00 1 0 0 0 0 0 0 00
(XEN) 0b 000 00 1 0 0 0 0 0 0 00
(XEN) 0c 001 01 0 1 0 1 0 1 1 A8
(XEN) 0d 001 01 0 1 0 1 0 1 1 B8
(XN) 0e 001 01 1 0 1 0 1 1 B0(XEN) 0f 001 0 0 1 0
0 1 1 C0
(XEN) IO AP #10......
(XE .... register 0: 00000000
(X) ....... : ysical APIC id:0
(XEN) ...... : Delivery Te: 0
(XEN) ..... : LTS : 0
(XEN) .. register #01000F0011
(XEN)...... : maredirection entes: 000F
XEN) ....... : IO APIC versi: 0011
(XEN) .. register #02:0000000
(XEN) ..... : arbration: 00
(XE .... IRQ redirtion table:
(X) NR Log Phy Mk Trig IRR Pol at Dest Deli Ve:
(XEN) 0000 00 1 0 0 0 0 0 0 00
(XEN)01 000 00 1 0 0 0 0 0 00
(N) 02 000 00 0 0 0 0 0 0
(XEN) 03 000 1 0 0 0
0 0 00
(XEN) 04 0 00 1 0 0 0 0 0 00
(XEN) 5 000 00 1 0 0 0 0 00
(X) 06 000 00 1 0 0 0 0 0 00(XEN) 07 000 0 1 0 0
0 0 0 00
(XEN) 08 0 00 1 0 0 0 0 00
(XEN) 000 00 1 0 0 0 0 0 00
XEN) 0b 000 001 0 0 0 0 0 0 00
(XEN) 0c 0000 1 0 0 0 0 0 00
(XEN) 0000 00 1 0 0 0 0 0 0 00
(XEN 0e 000 00 1 0 0 0 0 0 0 00
EN) 0f 000 00 1 0 0 0 0 0 0
(XEN) Using veor-based indexi
(XEN) IRQ to n mappings:
(X) IRQ240 -> 0:0(XEN) IRQ40 -> 1
(XEN) IRQ48 0:2
(XEN) IRQ2 -> 0:3
(XEN)RQ56 -> 0:4
XEN) IRQ72 -> 05
(XEN) IRQ80 -0:7
(XEN) IRQ8-> 0:8
(XEN) I96 -> 0:9
XEN) IRQ112 -> 110
(XEN) IRQ12-> 0:12
(XEN) Q136 -> 0:13
(N) IRQ144 -> 0:
(XEN) IRQ152 0:15
(XEN) IR60 -> 1:7
XEN) IRQ184 -> 132
(XEN) IRQ17-> 1:14
(XEN) Q192 -> 1:15
(N) ...........................
After all, this may also result from the lack of flow control under
Xen. And that's why I haven't complain about this console corruption
before: there's no option for flow control amongst the Xen console
settings (like the r on the Linux console= option). But /dev/ttyS0 runs
with crtscts, so flow control should be active on the heartbeat link at
least. But since CTS/RTS flow control is implemented in software, we're
back to interrupt latency problems.
--
Thanks,
Feri.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home