From owner-freebsd-hackers@freebsd.org Tue Mar 13 19:31:10 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 D8427F49617 for ; Tue, 13 Mar 2018 19:31:09 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 457197051F for ; Tue, 13 Mar 2018 19:31:09 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id i194so43874wmg.1 for ; Tue, 13 Mar 2018 12:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KneaHTe+yHpA0sgL7BqnaEUVoH60QJzQJjH7xC5IOGk=; b=rH0vEB1VQ8m4ogAKVdkCVd3AfV5bpdzcsNdz+//Lgymm6kINzEYzPMZxjAp4nqn/3B 8NijdygeIcXlqs3pSwGCXVLTDrdy8JJNkailD44Tl9Z5io34RWxhH3jvD+xKWa+mh8CF Qg5cVRTuSNeQklRY0Z4W7auR2mnK+qAy4+7tBaIqpHdpQ+uSZyct6TTLglUPpXtzr8K1 LQ69fXnBEAPFYN08JSHpz15ZIIuM4QzowlmoKbqlAd2KnyOXBUc+4u4dXSvHVg3ob3yx RtBRPVS/Z4qM+Pfaym5B5BVewMqBbnspQ4zXUD9gXzex4eb6j/SwSiSGe+//xom8h+uG b5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KneaHTe+yHpA0sgL7BqnaEUVoH60QJzQJjH7xC5IOGk=; b=tBVds4V23nCfS6mAGqCde6qV/2ynTXCJ/aZqGI2EMEE80xayD07ObxIh+a9g1sac20 8W57ZAuMHl6q3qqWfXQN7vSNUmt1fon6cB0yqH8OVYdmloIA8UA2xZrJHRyfTmTPsUjm gI3gMbuT0IhKL2Vys+JK0+AKPUldUZGjR/pWGbZbuVxrHuPYBKRBeBgT0h8KLG9tGbLB iqKI8HBnOsHNQTzx/AEYDsdHJ1c5/jqVnNG7ASkrto0ZvxyA2ZpjW93Sw+74un4YAZpK p4zyb6CAvd9d+a92J3/dH6Q5bcl15bGVezC8bncMGq2e5DBKx+Q6xyiSya0TlGxDY5ve YRSA== X-Gm-Message-State: AElRT7GX3s2Igd/2arnj5sSl/r0ZpC0/5WyflvlY4ZxcO8mYN5d/JyAz EewkrGA+ToXqHOOsILHDO6rTTWbPkCPJ7qGz4JY= X-Google-Smtp-Source: AG47ELvH9M9CTkoAjqZyXjNRTUl1PhfHIMYRqcVnjSTMIMzs2hO84O3GRhqm3THYiJvycFIKHL/MEdZXlp6DW+WOIfE= X-Received: by 10.80.177.179 with SMTP id m48mr2004264edd.94.1520969467853; Tue, 13 Mar 2018 12:31:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.202.67 with HTTP; Tue, 13 Mar 2018 12:31:07 -0700 (PDT) In-Reply-To: <20180313181046.GP76926@kib.kiev.ua> References: <20180313171432.GA11972@voyager> <20180313181046.GP76926@kib.kiev.ua> From: Luiz Otavio O Souza Date: Tue, 13 Mar 2018 16:31:07 -0300 Message-ID: Subject: Re: UARTs not working on a Supermicro A2SAV / Linux works ;-( To: Konstantin Belousov Cc: Andre Albsmeier , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" 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: Tue, 13 Mar 2018 19:31:10 -0000 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. Some recent BIOS have an option to route the system console to the first UART. > > 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 ? Luiz