Date: Fri, 05 Nov 2010 19:18:01 -0600 From: Michael Martin <mgmartin@comcast.net> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 Message-ID: <4CD4ACC9.8040405@comcast.net> In-Reply-To: <201011042037.20274.hselasky@c2i.net> References: <4CBFEBF5.30203@comcast.net> <201010230823.36449.hselasky@c2i.net> <4CC2E533.3010604@comcast.net> <201011042037.20274.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/04/2010 13:37, Hans Petter Selasky wrote:
> On Saturday 23 October 2010 15:37:55 Michael Martin wrote:
>> On 10/23/2010 00:23, Hans Petter Selasky wrote:
>>> On Saturday 23 October 2010 02:07:59 Michael Martin wrote:
>>>> On 10/21/2010 01:29, Michael Martin wrote:
>>>>> Thanks for the new USB 3.0 effort!
>>>>>
>>>>> I'm testing it out on 9.0-CURRENT amd64. The controller seems to find
>>>>> a 2.0 usb stick fine. However, when I plug in a Western Digital 3.0
>>>>> drive, the device fails to attach. The WD drive attaches fine when
>>>>> plugging into a 2.0 port on the motherboard.
>>>>>
>>>>> Controller info:
>>>>>
>>>>> xhci0@pci0:5:0:0: class=0x0c0330 card=0xffffffff chip=0x01941033
>>>>> rev=0x03 hdr=0x00
>>>>>
>>>>> vendor = 'NEC Electronics Hong Kong'
>>>>> class = serial bus
>>>>> subclass = USB
>>>>> bar [10] = type Memory, range 64, base 0xfbbfe000, size 8192,
>>>>>
>>>>> enabled
>>>>>
>>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0
>>>>> cap 05[70] = MSI supports 8 messages, 64 bit
>>>>> cap 11[90] = MSI-X supports 8 messages in map 0x10
>>>>> cap 10[a0] = PCI-Express 2 endpoint max data 128(128) link x1(x1)
>>>>>
>>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
>>>>> ecap 0003[140] = Serial 1 ffffffffffffffff
>>>>> ecap 0018[150] = unknown 1
>>>>>
>>>>> WD 3.0 Drive Info ( while plugged into the 2.0 port ):
>>>>>
>>>>> ugen3.4:<My Book 3.0 Western Digital> at usbus3, cfg=0 md=HOST
>>>>> spd=HIGH (480Mbps) pwr=ON
>>>>>
>>>>> bLength = 0x0012
>>>>> bDescriptorType = 0x0001
>>>>> bcdUSB = 0x0210
>>>>> bDeviceClass = 0x0000
>>>>> bDeviceSubClass = 0x0000
>>>>> bDeviceProtocol = 0x0000
>>>>> bMaxPacketSize0 = 0x0040
>>>>> idVendor = 0x1058
>>>>> idProduct = 0x1123
>>>>> bcdDevice = 0x1010
>>>>> iManufacturer = 0x0001<Western Digital>
>>>>> iProduct = 0x0002<My Book 3.0>
>>>>> iSerialNumber = 0x0003<XXXRemovedXXX>
>>>>> bNumConfigurations = 0x0001
>>>>>
>>>>> Output when plugging in the Western Digital 3.0 into the 3.0 port:
>>>>>
>>>>> Oct 21 01:03:54 gandalf root: Unknown USB device: vendor 0x1058
>>>>> product 0x1123 bus uhub4
>>>>> Oct 21 01:03:54 gandalf kernel: ugen4.2:<Western Digital> at usbus4
>>>>> Oct 21 01:03:54 gandalf kernel: umass0:<Western Digital My Book 3.0,
>>>>> class 0/0, rev 3.00/10.10, addr 1> on usbus4
>>>>> Oct 21 01:03:54 gandalf kernel: umass0: SCSI over Bulk-Only; quirks =
>>>>> 0x0000
>>>>> Oct 21 01:03:55 gandalf kernel: umass0:9:0:-1: Attached to scbus9
>>>>> Oct 21 01:03:57 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1
>>>>> error=28
>>>>> Oct 21 01:03:57 gandalf last message repeated 2 times
>>>>> Oct 21 01:03:57 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path=
>>>>> offset= size= error=
>>>>> Oct 21 01:04:03 gandalf kernel: ugen4.2:<Western Digital> at usbus4
>>>>> (disconnected)
>>>>> Oct 21 01:04:03 gandalf kernel: umass0: at uhub4, port 2, addr 1
>>>>> (disconnected)
>>>>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): lost device
>>>>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): got CAM status
>>>>> 0xa
>>>>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): fatal error,
>>>>> failed to attach to device
>>>>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:
>>>>> Oct 21 01:04:03 gandalf kernel: 0:0): removing device entry
>>>>> Oct 21 01:04:14 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1
>>>>> error=28
>>>>> Oct 21 01:04:14 gandalf last message repeated 2 times
>>>>> Oct 21 01:04:14 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path=
>>>>> offset= size= error=
>>>>>
>>>>> Output when plugging in the WD 3.0 into the 2.0 port:
>>>>>
>>>>> Oct 21 01:15:20 gandalf root: Unknown USB device: vendor 0x1058
>>>>> product 0x1123 bus uhub3
>>>>> Oct 21 01:15:20 gandalf kernel: ugen3.4:<Western Digital> at usbus3
>>>>> Oct 21 01:15:20 gandalf kernel: umass0:<Western Digital My Book 3.0,
>>>>> class 0/0, rev 2.10/10.10, addr 4> on usbus3
>>>>> Oct 21 01:15:20 gandalf kernel: umass0: SCSI over Bulk-Only; quirks =
>>>>> 0x0000
>>>>> Oct 21 01:15:21 gandalf kernel: umass0:9:0:-1: Attached to scbus9
>>>>> Oct 21 01:15:28 gandalf kernel: da0 at umass-sim0 bus 0 scbus9 target
>>>>> 0 lun 0
>>>>> Oct 21 01:15:28 gandalf kernel: da0:<WD My Book 3.0 1123 1010> Fixed
>>>>> Direct Access SCSI-4 device
>>>>> Oct 21 01:15:28 gandalf kernel: da0: 40.000MB/s transfers
>>>>> Oct 21 01:15:28 gandalf kernel: da0: 953867MB (1953519616 512 byte
>>>>> sectors: 255H 63S/T 121600C)
>>>>>
>>>>> Output when plugging in 2.0 device into the 3.0 port:
>>>>>
>>>>> Oct 21 01:09:54 gandalf root: Unknown USB device: vendor 0x090c
>>>>> product 0x1000 bus uhub4
>>>>> Oct 21 01:09:54 gandalf kernel: ugen4.2:<USB> at usbus4
>>>>> Oct 21 01:09:54 gandalf kernel: umass1:<USB Flash Disk, class 0/0,
>>>>> rev 2.00/11.00, addr 1> on usbus4
>>>>> Oct 21 01:09:54 gandalf kernel: umass1: SCSI over Bulk-Only; quirks =
>>>>> 0x0000
>>>>> Oct 21 01:09:55 gandalf kernel: umass1:10:1:-1: Attached to scbus10
>>>>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): TEST UNIT
>>>>> READY. CDB: 0 0 0 0 0 0
>>>>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): CAM status:
>>>>> SCSI Status Error
>>>>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI
>>>>> status: Check Condition
>>>>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI sense:
>>>>> UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have
>>>>> changed)
>>>>> Oct 21 01:09:56 gandalf kernel: da1 at umass-sim1 bus 1 scbus10 target
>>>>> 0 lun 0
>>>>> Oct 21 01:09:56 gandalf kernel: da1:<USB Flash Disk 1100> Fixed
>>>>> Direct Access SCSI-0 device
>>>>> Oct 21 01:09:56 gandalf kernel: da1: 40.000MB/s transfers
>>>>> Oct 21 01:09:56 gandalf kernel: da1: 956MB (1957888 512 byte sectors:
>>>>> 64H 32S/T 956C)
>>>>>
>>>>> --Michael
>>>> ( I never got the last list email to this thread, so replying to my
>>>> own.)
>>>>
>>>> Hans, I added your suggestions and here's what I've found:
>>>>
>>>> There seems to be two issues.
>>>>
>>>> (1)
>>>> The first is initial recognition of the device. If I have umass
>>>> compiled in the kernel or as a module loaded by loader.conf, initial
>>>> load of xhci almost never finds the attached drive as the modules are
>>>> loaded. If I kldunload xhci then load it back in, umass finds the
>>>> drive. Re-loading or delaying the the load of xhci ( manual kldload or
>>>> in rc.local ) almost always finds the drive. Seems like order matters
>>>> here too. umass likes to be loaded first followed by xhci which then
>>>> triggers umass to see the drive.
>>>>
>>>> If both umass and xhci are compiled in the kernel, the drive is never
>>>> initialized.
>>>>
>>>> The good news is I can get the drive to be recognized by a
>>>> kldunload/kldload of xhci.
>>>>
>>>> (2)
>>>> One the drive is recognized I can see it and partition it using gpart.
>>>> However, when I start dumping data to the drive, the drive gets
>>>> disconnected. I was doing a dd if=/dev/zero of=/dev/da0 bs=1M
>>>> count=500. The initial dd would sometimes succeed. Running dd
>>>> imediately after the initial success would cause an error.
>>>>
>>>> Here's the tail output of umass debugging while the dd was running and
>>>> the device stopped:
>>>>
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer
>>>> index = 4
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback:
>>>> max_bulk=131072, data_rem=512
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback:
>>>> max_bulk=131072, data_rem=0
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer
>>>> index = 8
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_csw: CSW 4049: sig
>>>> = 0x53425355 (valid), tag = 0x00000fd1, res = 0, status = 0x00 (good)
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_cam_action:
>>>> 7:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_cbw: CBW 4050: cmd
>>>> = 10b (0x280000000000...), data = 512b, lun = 0, dir = in
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer
>>>> index = 4
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback:
>>>> max_bulk=131072, data_rem=512
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback:
>>>> max_bulk=131072, data_rem=0
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer
>>>> index = 8
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_csw: CSW 4050: sig
>>>> = 0x53425355 (valid), tag = 0x00000fd2, res = 0, status = 0x00 (good)
>>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_cam_action:
>>>> 7:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense
>>>> Oct 22 17:44:23 gandalf kernel: umass0:umass_cam_action:
>>>> 7:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense
>>>> Oct 22 17:44:23 gandalf kernel: umass0:umass_bbb_dump_cbw: CBW 4051: cmd
>>>> = 10b (0x250000000000...), data = 8b, lun = 0, dir = in
>>>> Oct 22 17:44:23 gandalf kernel: ugen4.2:<Western Digital> at usbus4
>>>> (disconnected)
>>>> Oct 22 17:44:23 gandalf kernel: umass0: at uhub4, port 2, addr 1
>>>> (disconnected)
>>>> Oct 22 17:44:23 gandalf kernel: umass0:umass_detach:
>>>> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): AutoSense failed
>>>> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): lost device
>>>> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): removing device
>>>> entry
>>>>
>>>> I've saw there are quirks for the WESTERN MYBOOK . A added a specific
>>>> device into usbdevs and an entry into usb_quirk.c to mimic the same
>>>> quirks:
>>>>
>>>> USB_QUIRK(WESTERN, MYBOOK3, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB,
>>>>
>>>> UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_NO_INQUIRY_EVPD,
>>>> UQ_MSC_NO_SYNC_CACHE),
>>>>
>>>> This didn't help, and I got the disconnect as shown above.
>>>>
>>>> --Michael
>>> Hi,
>>>
>>> Could you compile kernel with "options USB_DEBUG".
>>>
>>> Then run:
>>>
>>> sysctl hw.usb.uhub.debug=16
>>>
>>> Then attach your drive.
>>>
>>> Maybe the USB stack is mistreating some event from the XHCI. Send the
>>> resulting dmesg.
>>>
>>> --HPS
>> I set debug and plugged in the drive. Here's the output.
>>
>> --Michael
> Hi,
>
> Thanks for the debug output. Can you try to "svn up" to r214808.
>
> Then apply the following patch to:
>
> sys/dev/usb/usb_hub.c
>
> ==================================================================
> --- usb_hub.c (revision 214808)
> +++ usb_hub.c (local)
> @@ -609,6 +609,15 @@
> case UPS_PORT_LS_U1:
> is_suspend = 0;
> break;
> + case UPS_PORT_LS_SS_INA:
> + /* Try a warm port reset to recover the port. */
> + err = usbd_req_warm_reset_port(udev, NULL, portno);
> + if (err) {
> + DPRINTF("warm port reset failed.\n");
> + goto done;
> + }
> + is_suspend = 0;
> + break;
> default:
> is_suspend = 1;
> break;
>
> Then build a new kernel. And send new debug output if your device does not
> work.
>
> --HPS
I applied the patch to r214808. The drive is recognized better now--da0
is created most of the time. When I tried to access the drive via zfs
import, the zfs import hung. I have two WD USB 3.0 drives ( same
vendor/product id but different bcdDevice . One drive has better
success being recognized than the other.
I captured several debug outputs here:
http://appliedtechnicalknowledge.com/freebsd/usb3-patch-214808/ . Maybe
something in these can help.
Let me know procedure wise how it's best to capture data for
you--plugged in prior to boot or plugging in after boot. I tried to get
both.
mm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CD4ACC9.8040405>