From owner-freebsd-usb@FreeBSD.ORG Sat Oct 23 06:22:27 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AE8D1065672 for ; Sat, 23 Oct 2010 06:22:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id F180D8FC08 for ; Sat, 23 Oct 2010 06:22:26 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yevn+QCjI6xy199BDvBOOiO14qYvyLq62he9tTtU3M8= c=1 sm=1 a=teY7EFdY6K0A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=3AF_jjmrgWurMXyvWl0A:9 a=pdnFhMQuCWgvfkgPqhcA:7 a=quQ7vxgo3ktsR0reuIRJGSUhwd0A:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 38854183; Sat, 23 Oct 2010 08:22:24 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 23 Oct 2010 08:23:36 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <4CBFEBF5.30203@comcast.net> <4CC2275F.1010201@comcast.net> In-Reply-To: <4CC2275F.1010201@comcast.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010230823.36449.hselasky@c2i.net> Cc: Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2010 06:22:27 -0000 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: 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 > > iProduct = 0x0002 > > iSerialNumber = 0x0003 > > 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: at usbus4 > > Oct 21 01:03:54 gandalf kernel: umass0: > 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: 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: at usbus3 > > Oct 21 01:15:20 gandalf kernel: umass0: > 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: 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: at usbus4 > > Oct 21 01:09:54 gandalf kernel: umass1: > 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: 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: 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