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=14963620671&r=1&w=2
https://marc.info/?t=14964072951&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=14960163472&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 wrote:
> t1...@protonmail.ch (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:
..
