On Fri, Jul 22, 2011 at 02:01:00PM -0400, Don Zickus wrote: > On Thu, Jul 21, 2011 at 02:05:36PM -0700, Sarah Sharp wrote: > > On Thu, Jul 21, 2011 at 04:33:19PM -0400, Don Zickus wrote: > > > Hi Sarah, > > > > > > I am trying to debug a situation where when booting up my system with > > > 3.0.0-rc7, the xhci_hcd detects my usb3 WD disk and usb3 hub. However it > > > doesn't detect my usb3 Buffalo disk behind my hub. > > > > Does it detect other USB 3.0 devices behind the hub? What about USB 2.0 > > devices? > > I didn't have any other behind there. I did re-try my test with usb2.0 > flash stick with no luck. I then switched to the TI prototype hub (you > probably have the same one I do) and had success with the usb3 disk but > not with the usb2 flash. :-/ Ok, I would suggest finding a different power supply for the USB hub. I had a co-worker with a similar experience, who switched out power supplies and then the hub started working properly. > > > On my Panther point system's root hub > > > port 3 has the WD disk > > > port 4 has the VIA 4-port usb3 hub > > > > > > Using lsusb -t, I expected bit0 to represent the actual connect state of > > > the device under the hub port status. It shows a '0', meaning nothing is > > > connected (for the VIA hub). > > > > > > Hub Port Status: > > > Port 1: 0000.02a0 5Gbps power Rx.Detect > > > Port 2: 0000.02a0 5Gbps power Rx.Detect > > > Port 3: 0000.02a0 5Gbps power Rx.Detect > > > Port 4: 0000.02a0 5Gbps power Rx.Detect > > > > > > > > > Of course, if I unplug the disk and re-connect, it works as expected. > > > > > > I am trying to understand the situation in which the hub would not see a > > > device is connected (even when the power is enabled to the port it seems). > > > > SuperSpeed devices have to go through link training with the downstream > > port on their parent hub. So a device can be connected and powered, but > > fail to train at SuperSpeed. At that point, the device is supposed to > > fall back to High Speed. At the next device reset, the device attempts > > to link train to SuperSpeed again. > > > > It's entirely possible the device or the hub is failing to link train > > properly, and the device gets stuck in SuperSpeed mode somehow. > > > > Do you have a hub from a different vendor to try out? If not, I can dig > > up a TI prototype one and try it on my own Panther Point system. > > > > > I am not sure what logs to attach so I haven't attached any. > > > > dmesg would work. > > heh. of course. I attached that below. I believe all the stall and > short transfers at the bottom of the log are the result of numerous 'lsusb > -v' commands (or with -t too). You need at least version 0.91 of lsusb to get the hub descriptors from USB 3.0 hubs. The USB 3.0 hubs use a different length hub descriptor, with a different descriptor type. They'll stall any request for the USB 2.0 hub descriptor. > xhci_hcd 0000:00:14.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 > xhci_hcd 0000:00:14.0: setting latency timer to 64 > xhci_hcd 0000:00:14.0: xHCI Host Controller > xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3 > xhci_hcd 0000:00:14.0: cache line size of 64 is not supported > xhci_hcd 0000:00:14.0: irq 21, io mem 0xb11b0000 > xhci_hcd 0000:00:14.0: Failed to enable MSI-X > xhci_hcd 0000:00:14.0: irq 45 for MSI/MSI-X > usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 > usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb3: Product: xHCI Host Controller > usb usb3: Manufacturer: Linux 3.0.0-rc7tip+ xhci_hcd > usb usb3: SerialNumber: 0000:00:14.0 > xHCI xhci_add_endpoint called for root hub > xHCI xhci_check_bandwidth called for root hub > hub 3-0:1.0: USB hub found > hub 3-0:1.0: 4 ports detected > xhci_hcd 0000:00:14.0: xHCI Host Controller > audit: name_count maxed, losing inode data: dev=00:06, inode=9459 > audit: name_count maxed, losing inode data: dev=00:06, inode=6234 > audit: name_count maxed, losing inode data: dev=00:05, inode=3 > audit: name_count maxed, losing inode data: dev=00:05, inode=3 > xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4 > usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 > usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb4: Product: xHCI Host Controller > usb usb4: Manufacturer: Linux 3.0.0-rc7tip+ xhci_hcd > usb usb4: SerialNumber: 0000:00:14.0 > audit: name_count maxed, losing inode data: dev=00:05, inode=3 > audit: name_count maxed, losing inode data: dev=00:05, inode=6245 > audit: name_count maxed, losing inode data: dev=00:05, inode=6246 > audit: name_count maxed, losing inode data: dev=00:05, inode=6246 > audit: name_count maxed, losing inode data: dev=00:05, inode=9462 > audit: name_count maxed, losing inode data: dev=00:05, inode=9462 > xHCI xhci_add_endpoint called for root hub > xHCI xhci_check_bandwidth called for root hub > hub 4-0:1.0: USB hub found > hub 4-0:1.0: 4 ports detected > iTCO_vendor_support: vendor-support=0 > iTCO_wdt: Intel TCO WatchDog Timer Driver v1.06 > iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) > iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) > i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 > input: PC Speaker as /devices/platform/pcspkr/input/input8 > microcode: CPU0 sig=0x306a2, pf=0x2, revision=0x8 > microcode: CPU1 sig=0x306a2, pf=0x2, revision=0x8 > usb 3-3: new high speed USB device number 2 using xhci_hcd > usb 3-3: Device not responding to set address. Ok, there's one possible cause. The xHCI host is indicating there was an error while trying to set the address for the new device, which could mean there was a transfer error, or something else. I think that would be the high speed portion of the USB 3.0 hub having issues. > microcode: CPU2 sig=0x306a2, pf=0x2, revision=0x8 > microcode: CPU3 sig=0x306a2, pf=0x2, revision=0x8 > microcode: Microcode Update Driver: v2.00 <tigran@xxxxxxxxxxxxxxxxxxxx>, Peter Oruba > sr 0:0:0:0: Attached scsi generic sg0 type 5 > sd 2:0:0:0: Attached scsi generic sg1 type 0 > usb 3-3: Device not responding to set address. > usb 3-3: device not accepting address 2, error -71 > hub 3-0:1.0: unable to enumerate USB device on port 3 > usb 3-4: new high speed USB device number 4 using xhci_hcd > usb 3-4: Device not responding to set address. > usb 3-4: Device not responding to set address. > usb 3-4: device not accepting address 4, error -71 > usb 3-4: new high speed USB device number 5 using xhci_hcd > usb 3-4: Device not responding to set address. > usb 3-4: Device not responding to set address. > usb 3-4: device not accepting address 5, error -71 > usb 3-4: new high speed USB device number 6 using xhci_hcd > usb 3-4: Device not responding to set address. > usb 3-4: Device not responding to set address. > usb 3-4: device not accepting address 6, error -71 > usb 3-4: new high speed USB device number 7 using xhci_hcd > usb 3-4: Device not responding to set address. > EXT4-fs (dm-0): re-mounted. Opts: (null) > usb 3-4: Device not responding to set address. > EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) > SELinux: initialized (dev sda1, type ext4), uses xattr > usb 3-4: device not accepting address 7, error -71 > hub 3-0:1.0: unable to enumerate USB device on port 4 > EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) > SELinux: initialized (dev dm-2, type ext4), uses xattr And then I think this is the USB 3.0 device enumerating that's attached directly to the root hub: > usb 4-3: new SuperSpeed USB device number 2 using xhci_hcd > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > usb 4-3: New USB device found, idVendor=1058, idProduct=0730 > usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 4-3: Product: My Passport 0730 > usb 4-3: Manufacturer: Western Digital > usb 4-3: SerialNumber: 575837314132314434373235 > usb 4-4: new SuperSpeed USB device number 3 using xhci_hcd > Initializing USB Mass Storage driver... > scsi6 : usb-storage 4-3:1.0 > usbcore: registered new interface driver usb-storage > USB Mass Storage support registered. > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep Then the USB 3.0 portion of the USB 3.0 hub enumerates: > usb 4-4: New USB device found, idVendor=2109, idProduct=0810 > usb 4-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 4-4: Product: 4-Port USB 3.0 Hub > usb 4-4: Manufacturer: VIA Labs, Inc. > hub 4-4:1.0: USB hub found > hub 4-4:1.0: 4 ports detected > Adding 6111228k swap on /dev/mapper/vg_intelsugarbaydh04-lv_swap. Priority:-1 extents:1 across:6111228k > SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts > readahead-disable-service: delaying service auditd > scsi 6:0:0:0: Direct-Access WD My Passport 0730 1015 PQ: 0 ANSI: 6 > scsi 6:0:0:1: Enclosure WD SES Device 1015 PQ: 0 ANSI: 6 > sd 6:0:0:0: Attached scsi generic sg2 type 0 > sd 6:0:0:0: [sdb] 976707584 512-byte logical blocks: (500 GB/465 GiB) > sd 6:0:0:0: [sdb] Write Protect is off > scsi 6:0:0:1: Attached scsi generic sg3 type 13 > sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08 > sd 6:0:0:0: [sdb] No Caching mode page present > sd 6:0:0:0: [sdb] Assuming drive cache: write through > sd 6:0:0:0: [sdb] No Caching mode page present > sd 6:0:0:0: [sdb] Assuming drive cache: write through > sdb: sdb1 sdb2 > sd 6:0:0:0: [sdb] No Caching mode page present > sd 6:0:0:0: [sdb] Assuming drive cache: write through > sd 6:0:0:0: [sdb] Attached SCSI disk > ses 6:0:0:1: Attached Enclosure device > xhci_hcd 0000:00:14.0: WARN: Stalled endpoint > NET: Registered protocol family 10 > e1000e 0000:00:19.0: irq 44 for MSI/MSI-X > e1000e 0000:00:19.0: irq 44 for MSI/MSI-X > ADDRCONF(NETDEV_UP): eth0: link is not ready > e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > RPC: Registered named UNIX socket transport module. > RPC: Registered udp transport module. > RPC: Registered tcp transport module. > RPC: Registered tcp NFSv4.1 backchannel transport module. > SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts > SELinux: initialized (dev autofs, type autofs), uses genfs_contexts > SELinux: initialized (dev autofs, type autofs), uses genfs_contexts > SELinux: initialized (dev autofs, type autofs), uses genfs_contexts > readahead-collector: starting delayed service auditd > readahead-collector: sorting > hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj. > readahead-collector: finished > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: Stalled endpoint > xhci_hcd 0000:00:14.0: WARN: Stalled endpoint > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: short transfer on control ep > xhci_hcd 0000:00:14.0: WARN: Stalled endpoint So it looks like the USB 2.0 portion of the USB 3.0 hub had trouble enumerating. It doesn't really look like a driver bug, so it's possible it's just flaky hardware? You can send me the demsg with CONFIG_USB_XHCI_HCD_DEBUGGING turned on just to make sure. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
