Date: Sun, 24 Oct 2010 18:12:20 -0600 From: Michael Martin <mgmartin@comcast.net> To: freebsd-usb@freebsd.org Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 Message-ID: <4CC4CB64.5080801@comcast.net> In-Reply-To: <4CC3C04D.9050106@freebsd.org> References: <4CBFEBF5.30203@comcast.net> <4CC2275F.1010201@comcast.net> <201010230823.36449.hselasky@c2i.net> <4CC2F231.7020507@comcast.net> <4CC3C04D.9050106@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/23/2010 23:12, Julian Elischer wrote: > On 10/23/10 7:33 AM, 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. > > the list strips attachements.. > put it at some web site and give the url > >> >> --Michael >> >> _______________________________________________ >> freebsd-usb@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-usb >> To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" >> > usb debug output is available here: http://appliedtechnicalknowledge.com/freebsd/wd_plug_in_fail_debug.txt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CC4CB64.5080801>