[RESEND -- part of the message got mangled inadvertently] On Mon, 26 Apr 2010, Sarah Sharp wrote: > On Sat, Apr 24, 2010 at 06:30:10PM -0400, Alan Stern wrote: > > On Fri, 23 Apr 2010, Sarah Sharp wrote: > > > > Okay, but what about /sys/kernel/debug/usb/devices? > > > > There's a real, serious reason for asking. Goodness knows where lsusb > > gets its information from -- but the debugfs usb/devices file is a > > direct window into the kernel's data structures. It even includes > > stuff that isn't present in sysfs. > > I don't have debugfs mounted. When I do have it mounted, it doesn't > change lsusb's output. Here's the output from > /sys/kernel/debug/usb/devices anyway, in case it matters: > > T: Bus=09 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=?? MxCh= 4 > B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 > D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 > P: Vendor=1d6b ProdID=0003 Rev= 2.06 > S: Manufacturer=Linux 2.6.34-rc4-ss-desc xhci_hcd > S: Product=xHCI Host Controller > S: SerialNumber=0000:05:00.0 > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=12ms > > T: Bus=09 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=05e3 ProdID=0608 Rev= 9.01 > S: Product=USB2.0 Hub > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms > > T: Bus=09 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=15ca ProdID=00c3 Rev= 5.12 > S: Product=USB Optical Mouse > C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=10ms ... Okay, that looks normal. I feel better about the patch. (The Speed= field could stand some improvement, though. You might submit a patch to fix up usb_device_dump() in core/devices.c. The bandwidth fields on the second line aren't right either, but they might not be so easy to set for xHCI.) > > No, it isn't. Evidently lsusb gets the list of buses from libusb, so > > maybe there's something funky going on inside libusb. Do you know what > > version you've got? > > Looks like version 1.0.1. Possibly a later version would work better. Possibly not... > > Another possibility to check out is /dev/bus/usb/. Does everything > > seem okay in there? > > I get errors when I cat the files that correspond to the roothub and the > high speed hub. I can cat the character device for the mouse: > > sarah@xanatos:~/git/kernels/xhci$ ls /dev/bus/usb/009/ > 001 002 003 > sarah@xanatos:~/git/kernels/xhci$ file /dev/bus/usb/009/* > /dev/bus/usb/009/001: character special > /dev/bus/usb/009/002: character special > /dev/bus/usb/009/003: character special > sarah@xanatos:~/git/kernels/xhci$ ls -l /dev/bus/usb/009/ > total 0 > crw-rw-r-- 1 root root 189, 1024 2010-04-26 10:16 001 > crw-rw-r-- 1 root root 189, 1025 2010-04-26 10:16 002 > crw-rw-r-- 1 root root 189, 1026 2010-04-26 10:17 003 > sarah@xanatos:~/git/kernels/xhci$ sudo cat /dev/bus/usb/009/001 > cat: /dev/bus/usb/009/001: Invalid argument > sarah@xanatos:~/git/kernels/xhci$ sudo cat /dev/bus/usb/009/003 > ^R^A^@^B^@^@^@^H�U�@^R^E^@^B^@^A ^B"^@^A^A^@�1 ^D^@^@^A^C^A^B^ !^P^A^@^A"H^@^G^E^�C^D^@ > sarah@xanatos:~/git/kernels/xhci$ sudo cat /dev/bus/usb/009/002 > cat: /dev/bus/usb/009/002: Invalid argument > > Nothing shows up in dmesg when this happens. If I unplug and replug in > the high speed hub and mouse, then they both show up in lsusb, and I can > cat both the 002 and 003 device files. So it seems the problem is > here. Yes indeed. Can you track it down? A good starting place would be usb_classdev_add() in core/devio.c. Look at the major and minor numbers in dev->dev.devt (I hate it when people use the same name for different things like that... David Brownell once had a statement that looked something like: "dev->dev.dev = pdev->dev" -- try to figure that out!) and make sure they agree with the major and minor numbers shown by "ls -l". Also check out usbdev_read() in the same file. If cat's read call reaches that routine then it must trigger the -EINVAL return code somehow (I can't imagine how). And I can't imagine how changing the descriptor parsing would affect any of this. Alan Stern -- 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
