(fw very clarifying answer from mpi@)
-------- Original Message --------
Subject: Re: RTL8153 stopped-communicating("crashed")-bug. I think
because it was USB3 & OBSD doesn't support 5gbit/superspeed mode yet.
Date: 2017-06-04 07:49
From: Martin Pieuchot <m...@openbsd.org>
To: Tinker <ti...@openmailbox.org>
On 04/06/17(Sun) 00:46, Tinker wrote:
On 2017-06-02 13:53, Martin Pieuchot wrote:
..
> 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?
Will do!
Meanwhile to understand how USB3 is expected to work currently, save
for due
to any unexpected bugs:
* Should USB devices always come up when you boot?
Yes they should. If they don't that's 1 bug. Possibly related to
uhub(4). In that case you could install the "usbutils" packages and
compare the output of 'lsusb -v' when:
- you booted without device connected
- you booted with a device connected
- after you connected a device
What's interesting us are the Port Status of the parent hub to the
device. They look like:
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Port 7: 0000.0100 power
Port 8: 0000.0100 power
Of course this could also be an xhci(4) bug. So booting a kernel with
XHCI_DEBUG and/or UHUB_DEBUG can give us more informations
* Total bandwidth per controller will be 1gbps currently?
I don't remember, you can look at xhci.c. But honestly what's your
problem?
I doubt this matters.
* At how many / how bandwidth-demanding devices plugged in to a
controller,
should failure to attach more devices start happening?
I don't know, but once again I doubt it matters. What's your problem?
* All of this is supposed to work without any config tweaking by user
right?
Of course, that's one of OpenBSD goal ;)
* ..And then per-USB device ioerror, timeout, watchdog timeout etc.
errors
should be handled transparently by the respective device driver, i.e.,
there
are expected situations where USB will fail to push data through for a
moment, so a good driver should have the logics to restore device
function
transparently by whatever means necessary. (E.g. even device reset
should be
fine for a USB NIC as the device not has any substantial state.)
Yes, but driver authors aren't perfect and they don't write perfect
drivers ;)
However anybody is welcome to improve them :)
