Date: Wed, 14 Mar 2018 06:51:15 +0100 From: Andre Albsmeier <andre@fbsd.e4m.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Andre Albsmeier <andre@fbsd.e4m.org>, freebsd-hackers@freebsd.org Subject: Re: UARTs not working on a Supermicro A2SAV / Linux works ;-( Message-ID: <20180314055115.GB96802@gate> In-Reply-To: <20180313181046.GP76926@kib.kiev.ua> References: <20180313171432.GA11972@voyager> <20180313181046.GP76926@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180314055115.GB96802>