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

Andre Albsmeier andre at fbsd.e4m.org
Wed Mar 14 05:44:33 UTC 2018


On Tue, 13-Mar-2018 at 16:31:07 -0300, Luiz Otavio O Souza wrote:
> On 13 March 2018 at 15:10, Konstantin Belousov <kostikbel at gmail.com> 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.
> 
> The system has both, UARTs and HSUARTs, the later will not work.

AFAIK the HSUARTs are not used on the A2SAV. The manual talks about
using a Nuvoton NCT5523D as IO chip.

> 
> Some recent BIOS have an option to route the system console to the first UART.

Yes, I know this feature from some Atom 38xx BIOSes but on the
A2SAV there is none.

> 
> >
> > Can you show the vmstat -i output ? Are there any other non-MSI
> > interrupts used on the machine, do they work ?
> > For a minor chance, try to set hw.lapic_eoi_suppression to 0 at the
> > loader prompt.
> 
> There was an IOAPIC programming issue affecting these machines, it was
> fixed by r327314.
> 
> Please Andre, can you check if this system boots fine with -head ?

Much better: I copied /sys/x86/x86/io_apic.c from -current to my
11.1-STABLE sources (there were no other differences apart from
the ones of r327314), built a new kernel and now it seems to work!

So this seems to be a MFC candidate and I am happy that I was not
wrong with my interrupt theory.

	-Andre


More information about the freebsd-hackers mailing list