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:

xh...@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




_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to