UARTs not working on a Supermicro A2SAV / Linux works ;-(

[Andre Albsmeier]

On Tue, 13-Mar-2018 at 20:10:46 +0200, Konstantin Belousov wrote:
> On Tue, Mar 13, 2018 at 06:14:32PM +0100, Andre Albsmeier wrote:
> > The UARTs on the brand new Supermicro A2SAV mainboard
> > (https://www.supermicro.com/products/motherboard/Atom/A2SAV.cfm)
> > are detected on 11.1-STABLE as
> > 
> > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
> > 
> > which is consistent with the BIOS settings.
> > 
> > Everything seems to work when it comes to setting of parameters and even
> > the DTR and RTS lines change state when opening cuau0 or cuau1, e.g. with
> > minicom.
> > 
> > But sending or receiving characters fails -- to be exact, no single
> > character will be received and only the very first one will be sent to
> > the remote device.
> > 
> > We remember this behaviour from the good old times when we had to jumper
> > base port addresses and IRQs on ISA cards: If we got the IRQ wrong the
> > same effect happened: The first char could be sent because the TX register
> > was empty but the IRQ telling the kernel that it can send the next char
> > never arrived.
> > 
> > When using debug.uart_force_poll=1 in loader.conf it works (at least if
> > we type in characters slowly, of course).
> > 
> > So it really seems to have to do with interrupts again but I have no
> > idea where to look.
> > 
> > The A2SAV manual talks about the Super I/O being a Nuvoton NCT5523D. Can
> > it be that we miss some support for this? But if the devices really behave
> > like standard 16550s we shouldn't need any specific support at all, I think.
> > 
> > I disabled the corresponding ACPI functions by using
> > 
> > debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"
> > 
> > and the devices were detected properly as
> > 
> > uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0
> > uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0
> > 
> > but this didn't help (same behaviour).
> > 
> > The really bad news are: Using Linux (Ubuntu 16.04) it works. Devices are
> > detected here as:
> > ...
> > [    0.261209] pnp 00:01: [dma 0 disabled]
> > [    0.261295] pnp 00:01: Plug and Play ACPI device, IDs PNP0501 (active)
> > [    0.261774] pnp 00:02: [dma 0 disabled]
> > [    0.261868] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
> > ...
> > [    1.479082] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > [    1.499962] 00:01: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> > [    1.520943] 00:02: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
> > 
> > and we can send and receive characters without problems.
> > 
> > So it really seems FreeBSD does something wrong on the A2SAV board when
> > it comes to interrupts of the serial ports.
> > 
> > Any ideas how to start?
> 
> Bay Trail and later Atoms UARTS are not standard UARTs controllers, AFAIR
> the registers are memory mapped, to start with.  They also support DMA, as
> you can see from the linux dmesg.  Perhaps there are some incompatibilities
> with the new implementation.
> 
> Can you show the vmstat -i output ? Are there any other non-MSI
> interrupts used on the machine, do they work ?

Just to answer this question: I haven't seen any. When using io_apic.c
from -head (inspired by Luiz' suggestion to try -head because of r327314)
I have:

NOHOST:~>vmstat -i
interrupt                                                      total       rate
irq3: uart1                                                       18          0
cpu0:timer                                                      1516         16
irq264: ahci0                                                   1300         14
irq265: igb0:que 0                                              1965         21
irq266: igb0:que 1                                               414          4
irq267: igb0:que 2                                               539          6
irq268: igb0:que 3                                               251          3
irq269: igb0:link                                                  2          0
irq275: ahci1                                                      6          0
irq276: xhci0                                                    367          4
cpu2:timer                                                       950         10
cpu3:timer                                                       866          9
cpu1:timer                                                      1021         11
Total                                                           9215         97

Before the output has been similar but lacking the irq3 line.

> For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the
> loader prompt.

Not needed, since it seems to work with io_apic.c from -head. But
if you want me to try it for whatever reasons I can do it, of course.

	-Andre