On Wed, 19 Feb 2014, Lu, Baolu wrote: > Thanks for reply and help. I attached an Ajays NET20DC to the USB port. > It seems not help here. > > Below is the dmesg and lsusb output. > > [root@localhost ~]# uname -a > Linux localhost.localdomain 3.12.8 #2 SMP Tue Feb 18 06:09:46 CST 2014 > x86_64 x86_64 x86_64 GNU/Linux > > [root@localhost ~]# lsusb -t > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M > |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, > Driver=usb_debug, 480M > |__ Port 4: Dev 4, If 0, Class=Human Interface Device, > Driver=usbhid, 12M > |__ Port 4: Dev 4, If 1, Class=Human Interface Device, > Driver=usbhid, 12M > |__ Port 7: Dev 5, If 0, Class=Human Interface Device, > Driver=usbhid, 1.5M > |__ Port 7: Dev 5, If 1, Class=Human Interface Device, > Driver=usbhid, 1.5M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M > |__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, > Driver=usb_debug, 480M
This shows that the debug device is not plugged into the right port. In fact it is plugged into _two_ ports, and both of them are wrong. The debug device works only when it is plugged directly into the debug port on the root hub. But above we see that it is plugged into the integrated "rate-matching" hubs -- the parents are Dev 2, not Dev 1. It is quite possible that the debug port on this motherboard is not wired to a USB connector. If that's true, the only way you will get the debug device to work is by connecting it directly to a header on the motherboard. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
