On Sun, 7 May 2017, Paul Menzel wrote:
> Dear Alan,
>
>
> Thank you for the quick response.
>
>
> Am Donnerstag, den 04.05.2017, 15:43 -0400 schrieb Alan Stern:
> > On Thu, 4 May 2017, Paul Menzel wrote:
>
> > > With commit 85724edec (Merge tag 'leds_for_4.12' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds),
> > > testing the resume time on a Lenovo X60t connected to the docking
> > > station with the script `analyze_suspend.py` [1][2], one USB
> > > controller(?) needs the most time with 376 ms.
> >
> > Well, it's always going to be true that _one_ of the USB controllers
> > needs more time than the others. :-)
> >
> > Where do you get than 376 ms number from? The attached graph and
> > listing show that 0000:00:1d.7 and usb5 (the PCI and USB interfaces of
> > the EHCI controller) take 18.971 ms in resume_noirq and 119.183 ms in
> > resume, for a total of 138.154 ms.
> >
> > > > usb @ 17ef:1000 [5-6] {usb} async_device (Total Suspend: 88.202 ms
> > > > Total Resume: 376.385 ms)
> >
> > 5-6 is not the EHCI controller. It is a USB device plugged into that
> > controller.
>
> I am sorry for mixing that up.
>
> > > Around 270 ms are spent in `generic_resume [usbcore]`.
> >
> > generic_resume doesn't do anything; it just calls usb_port_resume to do
> > the real work.
> >
> > > Please find the compressed HTML result page attached, which was created
> > > with `sudo ./analyze_suspend.py -config config/suspend-callgraph.cfg`.
> > >
> > > Here is some more information about the devices.
> >
> > You didn't include any information about the 5-6 device.
> >
> > > Can there something be done about that?
> >
> > Hard to say without knowing anything about the device. Or what driver
> > it uses.
>
> From the top of my head, no external USB device is connected. I can
> only think of the tablet functionality (Wacom(?)). Hopefully the
> information below is more useful.
>
> ```
> $ lsusb
> Bus 001 Device 002: ID 17ef:1000 Lenovo
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
So here the EHCI controller is on bus 1, as opposed to your earlier log
where it was on bus 5. The 1-6 device is the first entry on this list.
> $ journalctl -k | grep -i usb
...
> Mai 07 13:44:19 gm-debian kernel: ehci_hcd: USB 2.0 'Enhanced' Host
> Controller (EHCI) Driver
> Mai 07 13:44:19 gm-debian kernel: ehci-pci 0000:00:1d.7: new USB bus
> registered, assigned bus number 1
> Mai 07 13:44:19 gm-debian kernel: uhci_hcd: USB Universal Host Controller
> Interface driver
> Mai 07 13:44:19 gm-debian kernel: ehci-pci 0000:00:1d.7: USB 2.0 started,
> EHCI 1.00
> Mai 07 13:44:19 gm-debian kernel: usb usb1: New USB device found,
> idVendor=1d6b, idProduct=0002
> Mai 07 13:44:19 gm-debian kernel: usb usb1: New USB device strings: Mfr=3,
> Product=2, SerialNumber=1
> Mai 07 13:44:19 gm-debian kernel: usb usb1: Product: EHCI Host Controller
> Mai 07 13:44:19 gm-debian kernel: usb usb1: Manufacturer: Linux 4.11.0+
> ehci_hcd
> Mai 07 13:44:19 gm-debian kernel: usb usb1: SerialNumber: 0000:00:1d.7
> Mai 07 13:44:19 gm-debian kernel: hub 1-0:1.0: USB hub found
...
> Mai 07 13:44:19 gm-debian kernel: usb 1-6: new high-speed USB device number 2
> using ehci-pci
> Mai 07 13:44:19 gm-debian kernel: usb 1-6: New USB device found,
> idVendor=17ef, idProduct=1000
> Mai 07 13:44:19 gm-debian kernel: usb 1-6: New USB device strings: Mfr=0,
> Product=0, SerialNumber=0
> Mai 07 13:44:19 gm-debian kernel: hub 1-6:1.0: USB hub found
It is a hub, perhaps part of a dock since the vendor is Lenovo. If you
want to see why it takes so long to resume, a usbmon trace of the EHCI
bus during the suspend/resume transition would be helpful (see
Documentation/usb/usbmon.txt).
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
