On Sat, Dec 19, 2015 at 01:49:04AM +0000, edward wandasiewicz wrote:
Is it a technically a manufacturer messing up the USB spec definitions it should be following?
That's a great question, and I don't know the answer to it. It would be great if there was some guidance in the USB3 spec to help here as that would help point out if this is a controller, device, or software issue.
Of all the USB drives I've come across, this Philips one is the only one that behaves like this.
It's like its saying "hey, I'm a USB 2.0 spec device, no wait a moment, I'm really a USB 3.0 spec device." and we turn around and say "make ya mind up", by which time it's too late.
We've seen this USB2/3 confusion pop up a few times before - for example, see: http://www.seabios.org/pipermail/seabios/2015-November/009907.html http://www.seabios.org/pipermail/seabios/2015-August/009626.html http://www.seabios.org/pipermail/seabios/2014-June/008151.html
This is the first time I've seen a report of a device/controller having the confusion long enough for the USB2 instance to survive through full drive detection. (FYI, some of the issues in the emails above I think were resolved with other fixes.)
Sometimes we just can't fix every problem.
Granted this one is a tough one to solve.
I don't think it's that difficult to address your particular hardware - for example, see the patch below on top of the testing branch. It's unclear to me, however, what implications a change like the one below would have on other people's hardware. :-(
-Kevin
--- a/src/hw/usb.c +++ b/src/hw/usb.c @@ -441,10 +441,14 @@ usb_hub_port_setup(void *data) mutex_unlock(&hub->cntl->resetlock);
// Make sure device is still present (catches some weird USB3 devices) - ret = hub->op->detect(hub, port); - if (ret <= 0) { - hub->op->disconnect(hub, port); - goto done; + if (hub->cntl->type == USB_TYPE_XHCI && usbdev->speed == USB_HIGHSPEED) { + while (!timer_check(hub->detectend)) + yield(); + ret = hub->op->detect(hub, port); + if (ret <= 0) { + hub->op->disconnect(hub, port); + goto done; + } }
// Configure the device
On Sat, Dec 19, 2015 at 2:12 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Sat, Dec 19, 2015 at 01:49:04AM +0000, edward wandasiewicz wrote:
Is it a technically a manufacturer messing up the USB spec definitions it should be following?
That's a great question, and I don't know the answer to it. It would be great if there was some guidance in the USB3 spec to help here as that would help point out if this is a controller, device, or software issue.
I think this is a device issue.
Running OpenBSD on the Pixel 2015, I can confirm the controller is XHCI - there is no EHCI hardware on the Pixel.
See http://marc.info/?l=openbsd-misc&m=144804232014901&w=2 to verify
The drive specs are USB 3
See http://www.philips.co.uk/c-p/FM64FD145B_10/usb-flash-drive/specifications
We can't rule out the possibility of a manufacturing defect either, for early release USB devices, with such a long / delayed drive detection time, versus the rest of the population of devices, which seem to do so in a more realistic / manageable time delay.
It's good we were able to find out the cause of the problem, and how to resolve it, but it highlights what manufactures can be up to.
I'd be tempted to not solve the issue, if the behaviour can be undefined with other people's working hardware.
I could be wrong...
Edward.
Of all the USB drives I've come across, this Philips one is the only one that behaves like this.
It's like its saying "hey, I'm a USB 2.0 spec device, no wait a moment, I'm really a USB 3.0 spec device." and we turn around and say "make ya mind up", by which time it's too late.
We've seen this USB2/3 confusion pop up a few times before - for example, see: http://www.seabios.org/pipermail/seabios/2015-November/009907.html http://www.seabios.org/pipermail/seabios/2015-August/009626.html http://www.seabios.org/pipermail/seabios/2014-June/008151.html
This is the first time I've seen a report of a device/controller having the confusion long enough for the USB2 instance to survive through full drive detection. (FYI, some of the issues in the emails above I think were resolved with other fixes.)
Sometimes we just can't fix every problem.
Granted this one is a tough one to solve.
I don't think it's that difficult to address your particular hardware
- for example, see the patch below on top of the testing branch. It's
unclear to me, however, what implications a change like the one below would have on other people's hardware. :-(
-Kevin
--- a/src/hw/usb.c +++ b/src/hw/usb.c @@ -441,10 +441,14 @@ usb_hub_port_setup(void *data) mutex_unlock(&hub->cntl->resetlock);
// Make sure device is still present (catches some weird USB3 devices)
- ret = hub->op->detect(hub, port);
- if (ret <= 0) {
hub->op->disconnect(hub, port);goto done;
if (hub->cntl->type == USB_TYPE_XHCI && usbdev->speed == USB_HIGHSPEED) {
while (!timer_check(hub->detectend))yield();ret = hub->op->detect(hub, port);if (ret <= 0) {hub->op->disconnect(hub, port);goto done;}}
// Configure the device
-
edward wandasiewicz -
Kevin O'Connor