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
_______________________________________________
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