On Mon, 23 Dec 2013, Matthias [ISO-8859-1] Bl�sing 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
