Hi Marcus, Thank you for following up.
First re any XHCI bugs: 1. The primary issue I have had is that when I evaluated XHCI around June last year, when connected to a USB 3 (XHCI) port, on 20-30% of boots, my USB NIC would not be automatically detected. However, if after the boot completed I would detach and reattach the USB NIC, it would be detected as it should. USB 2 has worked perfectly for me all the time though. This might have been fixed, I haven't tracked XHCI development recently. My previous reports, please refer to these for details: https://marc.info/?t=149636206700001&r=1&w=2 https://marc.info/?t=149640729500001&r=1&w=2 https://marc.info/?l=openbsd-misc&m=149658807922576&w=2 I based the understanding that XHCI was not perfectly stable on a comment from mpi@ 2017-08-08 last year he emailed me off-list > I didn't do any work on xhci(4) [..] The driver has many small issues > that should be fixed as well. Also regarding the error he responded off-list, just for reference: > Most of the drivers have a debug define. In the case of axen(4) > compiling a kernel with AXEN_DEBUG should help. > > If you wan to fix xhci(4) problems, there's a XHCI_DEBUG switch. > > Randomly testing drivers/host controllers wont help. Some XHCI > controllers might expose more bugs than others. > > You are running in a lot of bugs because nobody have the time to fix > them. Sending emails to misc@ wont fix the bugs. .. >> I learned today that OpenBSD does not implement USB3 fully, >> specifically it doesn't implement the 5gbps SuperSpeed mode, but >> only 1gbps. > > This is irrelevant to the error above. > >> I picture that this could have been because that interface for a split >> second consumed the whole 1gbps frame and then attempting to push just a >> little bit more, and there was some data loss that ended up confusing the >> cdce driver so it (for practical purposes) crashed. > > It could be anything. If you're sure it's an xhci(4) problem, because > you tried the device on ehci(4) and it works, did you try enabling > XHCI_DEBUG? > >> Too bad it doesn't recover and get online again by itself. > > You can fix the watchdog functions, look at how other drivers do it. > >> This is on a patched 6.0, someday I should try getting ureN devices on 6.1. > > This won't fix bugs. > >> Meanwhile I guess that this crash situation should be remedied simply by >> using the NIC:s' USB2 ports only instead. > > So it's an xhci(4) problem? Could you submit a bug report with a dmesg > of a kernel compiled with XHCI_DEBUG and exposing the problems above > motioned? This was on an Asrock motherboard with a Xeon E3 and an Intel C226 chipset. The malbehavior could be because of specifics pertaining to my particular USB controller of course. 2. I also did have one experience with one or a few system freezes, https://marc.info/?t=149601634700002&r=1&w=2 . This was with the Axen driver which is known to be unstable, on XHCI. This freeze could mean anything I guess. I would be glad to order one or a couple Axen:s to anyone who wants to have a look! Second, re superspeed mode: stsp@ pointed out about a year ago that the XHCI driver only supports, I think it is, 1gbps aggregate speed per USB hub presently, 5gbps aka "superspeed". This might not be a very high priority, maybe except on some cheapo ARM64:s that have only USB 3. Thanks, Tinker On July 27, 2018 10:53 PM, Marcus MERIGHI <[email protected]> wrote: > [email protected] (Tinker), 2018.07.27 (Fri) 12:17 (CEST): > > > (Also note that the USB 3 stack separately is unstable, and maybe > > For the archives: > > That statement is wrong, unless all the dozens of terabytes I've moved > over xhci(4) are broken now. > > Do you mean the isochronous transfer thing? CVS log says: ..
