FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F12.3.0 2021-09-28T17:26:34Z 2021-09-28T17:26:34Z Sean Bruno sbruno@FreeBSD.org 2021-09-25T22:23:08Z urn:sha1:9f451734952a52a90a89865e7668e944804a756b Reviewed by: kib Tested by: kbowling Differential Revision: https://reviews.freebsd.org/D32146 (cherry picked from commit fb640be4e9443f1890680c27b213825300bc65f4) 2021-05-30T01:10:48Z Konstantin Belousov kib@FreeBSD.org 2021-05-23T16:38:54Z urn:sha1:5d6806ffd66e1b028f19e5c87fc601566be7906c PR: 256101 (cherry picked from commit eaf00819bcfa90ab7ac8af324826eb985197d8c8) 2021-05-10T00:58:25Z Jose Luis Duran jlduran@gmail.com 2021-05-02T21:20:25Z urn:sha1:765f31a86876aae85e3ba1da95ea6053720e9b31 PR: 255556 (cherry picked from commit 8f1562430fbb83f6cedff6450e1aa1b593e3d7e7) 2021-05-10T00:58:25Z Jose Luis Duran jlduran@gmail.com 2021-05-02T21:20:25Z urn:sha1:87781d3962a8f22a8fef5e1c13dd4a8c36bed220 PR: 255556 (cherry picked from commit 5b8b6b26e40a81320f02a46df98b96bd8e93295a) 2021-03-16T17:56:03Z Mitchell Horne mhorne@FreeBSD.org 2021-03-10T14:57:12Z urn:sha1:a54c346ff3e80ff8f2f3d0ec56b5374a7dc34429 It has been observed that some systems are often unable to resume from ddb after entering with debug.kdb.enter=1. Checking the status further shows the terminal is blocked waiting in tty_drain(), but it never makes progress in clearing the output queue, because sc->sc_txbusy is high. I noticed that when entering polling mode for the debugger, IER_TXRDY is set in the failure case. Since this bit is never tracked by the softc, it will not be restored by ns8250_bus_ungrab(). This creates a race in which a TX interrupt can be lost, creating the hang described above. Ensuring that this bit is restored is enough to prevent this, and resume from ddb as expected. The solution is to track this bit in the sc->ier field, for the same lifetime that TX interrupts are enabled. PR: 223917, 240122 Sponsored by: The FreeBSD Foundation (cherry picked from commit 7e7f7beee732810d3afcc83828341ac3e139b5bd) 2020-10-22T17:31:41Z Marcin Wojtas mw@FreeBSD.org 2020-10-22T17:31:41Z urn:sha1:028b7c704b7f429a834ca85daf7262ac782502d0 Fix AccessWidth and BitWidth parsing in SPCR table The ACPI Specification defines a Generic Address Structure (GAS), which is used to describe UART controller register layout in the SPCR table. The driver responsible for parsing it (uart_cpu_acpi) wrongly associates the Access Size field to the uart_bas's regshft and the register BitWidth to the regiowidth - according to the definitions it should be opposite. This problem remained hidden most likely because the majority of platforms use 32-bit registers (BitWidth) which are accessed with the according size (Dword). However on Marvell Armada 8k / Cn913x platforms, the 32-bit registers should be accessed with Byte granulity, which unveiled the issue. This patch fixes above by proper values assignment and slightly improved parsing. Note that handling of the AccessWidth set to EFI_ACPI_6_0_UNDEFINED is needed to work around a buggy SPCR table on EC2 x86 "bare metal" instances. Reviewed by: manu, imp, cperciva, greg_unrelenting.technology Obtained from: Semihalf 2020-09-09T22:54:09Z Warner Losh imp@FreeBSD.org 2020-09-09T22:54:09Z urn:sha1:470538bad3cd053a4b9d499f298033f996d0c839 r364430 | imp | 2020-08-20 11:19:40 -0600 (Thu, 20 Aug 2020) | 6 lines Tag pccard drivers with gone in 13. MFC After: 3 days Reviewed by: emaste, brooks, adrian (on twitter) Differential Revision: https://reviews.freebsd.org/D26095 2020-09-08T22:50:24Z John Baldwin jhb@FreeBSD.org 2020-09-08T22:50:24Z urn:sha1:13ccf661f6633628bf977612b86b6b638f0b5273 uart(4) backends currently detect RX FIFO overrun errors and report them to the uart(4) core layer. They are then reported to the generic TTY layer which promptly ignores them. As a result, there is currently no good way to determine if a uart is experiencing RX FIFO overruns. One could add a generic per-tty counter, but there did not appear to be a good way to export those. Instead, add a sysctl under the uart(4) sysctl tree to export the count of overruns. 2020-09-08T22:19:06Z John Baldwin jhb@FreeBSD.org 2020-09-08T22:19:06Z urn:sha1:db246688667a2c3c38030f20b3f85739071d8950 Shifting right by 1 is not the same as dividing by 2 for signed values. In particular, dividing a signed value by 2 gives the integer ceiling of the (e.g. -5 / 2 == -2) whereas shifting right by 1 always gives the floor (-5 >> 1 == -3). An embedded board with a 25 Mhz base clock results in an error of -30.5% when used with a baud rate of 115200. Using division, this truncates to -30% and is permitted. Using the shift, this fails and is rejected causing TIOCSETA requests to fail with EINVAL and breaking getty(8). Using division gives the same error range for both over and under baud rates and also makes the code match the behavior documented in the existing comment about supporting boards with 25 Mhz clocks. 2020-03-02T16:56:32Z Justin Hibbits jhibbits@FreeBSD.org 2020-03-02T16:56:32Z urn:sha1:a37c30de3c00db0e6198f66eaf639f35d933c57e Add Denverton UART PCI ID Sponsored by: Juniper Networks, Inc