Bug 196332 - [usb] Intenso External USB 3.0 not recognized on hotplug
Summary: [usb] Intenso External USB 3.0 not recognized on hotplug
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: FreeBSD USB mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-28 18:20 UTC by Martin Birgmeier
Modified: 2016-11-03 19:06 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2014-12-28 18:20:11 UTC
Scenario:
- running FreeBSD 10.1 release on amd64 on a Lenovo W520
- trying to hotplug an Intenso External USB 3.0 drive to the USB 3.0 port
- the USB controller is recognized as ("grep -i xhci /var/run/dmesg.boot")

xhci0: <NEC uPD720200 USB 3.0 controller> mem 0xd4100000-0xd4101fff irq 18 at device 0.0 on pci14
xhci0: 32 byte context size.
usbus1 on xhci0
uhub2: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1

- pciconf -lv yields

xhci0@pci0:14:0:0:      class=0x0c0330 card=0x21cf17aa chip=0x01941033 rev=0x04 hdr=0x00
    vendor     = 'NEC Corporation'
    device     = 'uPD720200 USB 3.0 Host Controller'
    class      = serial bus
    subclass   = USB

- the Intenso drive is described as

# usbconfig -d ugen1.2 dump_device_desc
ugen1.2: <product 0x0539 vendor 0x152d> at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (2mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0300 
  bDeviceClass = 0x0000 
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0009 
  idVendor = 0x152d 
  idProduct = 0x0539 
  bcdDevice = 0x0205 
  iManufacturer = 0x000a  <Intenso>
  iProduct = 0x000b  <External USB 3.0>
  iSerialNumber = 0x0003  <20120103070B>
  bNumConfigurations = 0x0001 

Result:
- Most of the time, the drive is not recognized at all when hotplugging
- Very seldom, it is just recognized with the message
    ugen1.2: <vendor 0x152d> at usbus1
  but not further recognized as being a umass device
- If it is recognized at all, it may negotiate USB 2.0 mode although being connected to the 3.0 port

Expected result:
- Hotplugging of the drive should work :-)

Notes:
- This (hotplugging) worked better (about 60% of the time) in FreeBSD 9.2; maybe about 30% negotiating USB 3.0 and 30% USB 2.0; in about 40% of the cases the XHCI port just seemed to get stuck.
- If I plug the drive in before booting FreeBSD, it is correctly negotiated by the BIOS and is then always recognized by FreeBSD 10.1 as follows:

ugen1.2: <vendor 0x152d> at usbus1
umass0: <vendor 0x152d product 0x0539, class 0/0, rev 3.00/2.05, addr 1> on usbus1
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
(probe0:umass-sim0:0:0:0): Error 22, Unretryable error
da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0: <Intenso External USB 3.0 0205> Fixed Direct Access SCSI-6 device 
da0: Serial Number 20120103070B    
da0: 400.000MB/s transfers
da0: 2861588MB (732566528 4096 byte sectors: 255H 63S/T 45600C)
da0: quirks=0x2<NO_6_BYTE>

- In general, the drive takes a rather long time to spin up when plugged in

Questions:
- Is there a way to force renegotiation after the drive has already been plugged in?
- In FreeBSD 9.2, whenever I had a USB 2.0 device first plugged into the 3.0 port and afterwards the Intenso drive, it would always negotiate as 2.0. There seemed to be some "memory" of the previous device. In FreeBSD 10.1 this can't be reproduced as the Intenso won't be recognized at all, but if hotplugging worked, would this not happen any more?
Comment 1 Fabian Keil 2015-08-03 10:42:23 UTC
My workaround for a similar disk is running:

usbconfig -d ${device} add_quirk UQ_MSC_NO_INQUIRY
usbconfig -d ${device} reset

shortly after attaching the disk.

If it doesn't help in your case, you could try some of the other quirks shown by: usbconfig dump_quirk_names
Comment 2 Martin Birgmeier 2015-08-16 18:53:28 UTC
This has been solved in FreeBSD 10.2

Thanks to the USB developers!

-- Martin
Comment 3 Martin Birgmeier 2016-06-19 06:23:41 UTC
Unfortunately, my previous success message was premature. Under 10.3, the drive is recognized very sporadically when hotplugging it.

The workaround described by Fabian seems to work, so maybe this quirk should be added for this drive.
Comment 4 Martin Birgmeier 2016-06-20 06:31:31 UTC
Even Fabian's workaround does not guarantee success. Sometimes it helps to also reset the controller itself "usbconfig -d ugen1.1 reset".

The controller exposes two physical ports. Sometimes connecting the disk negotiates USB 2.0 instead of 3.0 on one of these ports, and the port then seems to remember this setting - sometimes forever, sometimes until issuing the controller reset.
Comment 5 Martin Birgmeier 2016-06-20 06:36:19 UTC
Another issue: If the disk is recognized using the UQ_MSC_NO_INQUIRY quirk, it does not go to sleep any more as it did before (when it sometimes just attached without the quirk). What is the reason for this?
Comment 6 Martin Birgmeier 2016-11-03 19:06:18 UTC
I am now at 11.0-RELEASE-p2, and the behavior seems to be o.k. now.

So let's close this issue (again).

-- Martin