On Mon, 23 Dec 2013, Matthias [ISO-8859-1] Bl�ng wrote: > I went ahead and did some runs (once I was able to reproduce the general > protection fault). The ehci port worked pretty fast (4 seconds from > start to GUI display), the xhci port took 7s in the best case to more > than one minute in the worst case. > > The straces were taken with the "-T" Option. > > Attached to this mail you find the gzipped log of one ehci run. > > For the xhci case I attach the usbmon trace of 3 consecutive starts, > where the strace is the result of the last start. This is the case that > took more than one minute, which I stopped. > > Looking at the strace alone, I see, that the USBDEVFS_SETCONFIGURATION > ioctl calls take excessive time. > > The version I used to test was 3.13-rc5 with both patches applied. > > Maybe this can shed some light onto the problem. You're right; those calls took an excessively long time. The usbmon traces show that the communication with the device was very quick. I don't know where the rest of the time was spent. The most likely possibility is locking the bandwidth mutex. But that wouldn't require much time either, unless something else was going on at the same time. You could try adding a few statements of the form dev_info(&dev->dev, "[Your message here]\n"); at various spots inside drivers/usb/core/message.c's usb_reset_configuration() routine. Maybe you'll be able to see where everything slows down. (Be sure to set CONFIG_PRINTK_TIME when you build the kernel.) 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
