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.
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)
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!
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.
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(-)
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(-)
A commit in branch releng/13.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=eb62c494bfa0771581dae96f6ae6bdcf4d3f21b9 commit eb62c494bfa0771581dae96f6ae6bdcf4d3f21b9 Author: Warner Losh <imp@FreeBSD.org> AuthorDate: 2021-02-17 22:08:19 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2021-03-01 18:59:30 +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 Approved by: re@ (gjb) (cherry picked from commit 955b6109bb36036e9357006be42dfa89cd7cb0f2) (cherry picked from commit ef1f2056084202c554d5482af9586a8995e604d5) sys/dev/uart/uart_bus_pci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Fixed a while ago by imp.