Fwd: Re: RTL8153 stopped-communicating("crashed")-bug. I think because it was USB3 & OBSD doesn't support 5gbit/superspeed mode yet.

(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 <mpi@openbsd.org>
To: Tinker <tinkr@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 :)