From owner-freebsd-hackers@freebsd.org Wed Mar 14 05:44:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11CD7F577E7 for ; Wed, 14 Mar 2018 05:44:33 +0000 (UTC) (envelope-from andre@fbsd.e4m.org) Received: from mail.g66.org (mail.g66.org [85.10.206.112]) by mx1.freebsd.org (Postfix) with ESMTP id 906DC6DBB5 for ; Wed, 14 Mar 2018 05:44:32 +0000 (UTC) (envelope-from andre@fbsd.e4m.org) Received: from x4e35ed3c.dyn.telefonica.de (x4e35ed3c.dyn.telefonica.de [78.53.237.60]) (authenticated bits=128) by mail.g66.org (8.15.2/8.15.2) with ESMTPA id w2E5iU9e041827; Wed, 14 Mar 2018 06:44:30 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: from submit.client ([127.0.0.1]) by gate.local (8.15.2/8.15.2) with ESMTP id w2E5iTE5097073; Wed, 14 Mar 2018 06:44:30 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Received: (from user@localhost) by gate.local (8.15.2/8.15.2/Submit) id w2E5iTg4097072; Wed, 14 Mar 2018 06:44:29 +0100 (CET) (envelope-from andre@fbsd.e4m.org) Date: Wed, 14 Mar 2018 06:44:29 +0100 From: Andre Albsmeier To: Luiz Otavio O Souza Cc: Konstantin Belousov , Andre Albsmeier , freebsd-hackers@freebsd.org Subject: Re: UARTs not working on a Supermicro A2SAV / Linux works ;-( Message-ID: <20180314054429.GA96802@gate> References: <20180313171432.GA11972@voyager> <20180313181046.GP76926@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Virus-Scanned: clamav-milter 0.99.4 at colo X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 05:44:33 -0000 On Tue, 13-Mar-2018 at 16:31:07 -0300, Luiz Otavio O Souza wrote: > On 13 March 2018 at 15:10, 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. > > 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