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?
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
This has been solved in FreeBSD 10.2 Thanks to the USB developers! -- Martin
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.
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.
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?
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