Bug 235016 - ASIX AX99100 based uart controllers broken on 12.0
Summary: ASIX AX99100 based uart controllers broken on 12.0
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2019-01-16 23:51 UTC by rozhuk.im
Modified: 2021-02-24 18:11 UTC (History)
5 users (show)

See Also:


Attachments
Patch to fix uart_bus_pci.c (604 bytes, patch)
2021-01-16 23:04 UTC, david
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rozhuk.im 2019-01-16 23:51:19 UTC
I have ASIX AX99100 uart/serial controller with 2 ports, it works on 11.2 and don't work on 12.0 - no data received.
It used for communicate with old APC smart, by sysutils/apcupsd.

Also, I'm not sure that FreeBSD bug, but on ryzen platform (x370 taichi + 1300x) system freeze (and not respond until reset) with this controller after 10-20 minutes.
On AM1 based platform no freeze.
Comment 1 david 2021-01-16 01:50:36 UTC
I have this problem too (12.2); I did a diff between the 11.2 and 12.0 branches and I noticed that 12.0 introduced MSI interrupts for all drivers in this class, I commented that out via an #if 0  and recompiled and ran, and everything works currently.

I loaded the design specs for this and confirmed this does support MSI, so I don't think this is a long term solution.  I do have a spare one of these cards (I think it is the same chip), and some kernel development experience, but none with PCIe..  I am willing and able to work on the correct solution, I will just need some guidance.

(I will first experiment with removing the limit on the number of MSI interrupts)
Comment 2 david 2021-01-16 23:04:36 UTC
Created attachment 221648 [details]
Patch to fix uart_bus_pci.c

This is my working patch.  After consulting with the pci_alloc_msi and freebsd MSI page as well as looking at other drivers I think this is probably the 'best' patch at this point.

Given: https://people.freebsd.org/~grehan/msi_api.txt  (yes, it looks a bit dated), that makes it explicitly clear that if you get back fewer MSI resources than the device expects the driver is responsible for ensuring the device doesn't generate MSI greater than has been allocated.. There is no such code in the UART space.  Additionally there are numerous other drivers that expect a single MSI count and if they get it establish MSI for that, and if not fall back to legacy IRQ.

I couldn't get anything resembling "real" documentation out of ASIX for what is going on, but given a few facts: That MSI interrupts must be allocated in powers of 2, that NO MSI interrupts are visible on this device when it is enabled (that I have ben able to find), and there are 5 UART interrupt registers (tx, rx, sigchange, overrun, break) I am *guessing* they map 5 MSI interrupts to each of those individual serial interrupt registers.  I briefly contemplated attempting to wire these directly to the uart_intr_* calls, or all of them to uart_intr itself, but there were too many questions about the right way to pass this along, to abstract it, and the concurrency (multiple interrupts firing at once on different cores).. given that, i think this is the best patch.

Thanks!
Comment 3 Jan Martin Mikkelsen 2021-02-17 13:33:22 UTC
We saw similar problems on 12.0 with eight port Moxa SmartIO CP-168EL devices in the middle of last year. No characters in, one character out and then the port stalled.

The issue was worked around by adding "hw.puc.msi_disable=1" to loader.conf.

I don't have time to go looking in the driver, but the problem was certainly MSI related.
Comment 4 commit-hook freebsd_committer 2021-02-17 22:12:50 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=955b6109bb36036e9357006be42dfa89cd7cb0f2

commit 955b6109bb36036e9357006be42dfa89cd7cb0f2
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2021-02-17 22:08:19 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2021-02-17 22:08:19 +0000

    uart: only use MSI on devices that advertise 1 MSI vector

    This updates r311987/fb1d9b7f4113d which allowed any number of vectors to be
    used. Since we're just attaching one instance, the meaning of more than one
    vector is not clear and seems to cause problems. Fall back to old methods for
    these cards.

    PR: 235016
    Submitted by: David Cross

 sys/dev/uart/uart_bus_pci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
Comment 5 commit-hook freebsd_committer 2021-02-24 18:11:20 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=ef1f2056084202c554d5482af9586a8995e604d5

commit ef1f2056084202c554d5482af9586a8995e604d5
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2021-02-17 22:08:19 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2021-02-24 17:57:07 +0000

    uart: only use MSI on devices that advertise 1 MSI vector

    This updates r311987/fb1d9b7f4113d which allowed any number of vectors to be
    used. Since we're just attaching one instance, the meaning of more than one
    vector is not clear and seems to cause problems. Fall back to old methods for
    these cards.

    PR: 235016
    Submitted by: David Cross

    (cherry picked from commit 955b6109bb36036e9357006be42dfa89cd7cb0f2)

 sys/dev/uart/uart_bus_pci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)