On Thu, 29 Aug 2013, Martin MOKREJŠ wrote: > > This really isn't necessary. All the information you want is already > > in the system log. It's merely a matter of locating it. > > > > I can show you how. If you post a complete dmesg log, starting from > > boot and running up to one of these errors, I'll point out the messages > > containing the relevant information. > > > >> I understand, the parent could be a PCI device or another USB device so it gets > >> more complicated quickly but the relevant information must be gathered immediately. > > > > It is a mistake to put too much functionality in the kernel. Today you > > want device IDs to be printed. Tomorrow somebody will want something > > else. Before you know it, the kernel will end up printing out the > > complete state of the system whenever anything happens! :-) > > I understand your point but don't think this is the case. OK, please show me why > is LPM not available. If USB is complaining about that being disabled it could > tell me based on what attribute at least. And printing the PCI device ID at least > would be helpful. Yeah, will look what that journald does. Actually, it looks like the missing LPM functionality is caused by a bug in drivers/usb/core/hcd.c. The register_root_hub() routine does this: if (usb_dev->speed == USB_SPEED_SUPER) { retval = usb_get_bos_descriptor(usb_dev); if (retval < 0) { mutex_unlock(&usb_bus_list_lock); dev_dbg(parent_dev, "can't read %s bos descriptor %d\n", dev_name(&usb_dev->dev), retval); return retval; } } Compare this to the code in hub.c: if (udev->wusb == 0 && le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0201) { retval = usb_get_bos_descriptor(udev); if (!retval) { udev->lpm_capable = usb_device_supports_lpm(udev); usb_set_lpm_parameters(udev); } } You can see that register_root_hub() doesn't set udev->lpm_capable. The missing call to usb_set_lpm_parameters() doesn't matter, because root hubs don't have parent hubs. Ksenia, can you send Martin patch to set udev->lpm_capable for root hubs? Note that this will require you to fix usb_device_supports_lpm() as well; that routine dereferences udev->parent, but for root hubs udev->parent is NULL. Martin, the information you asked about can be found as follows in your log. Here are the parts to look at: [ 4.228257] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [ 4.228906] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 4.229571] usb usb4: Product: xHCI Host Controller [ 4.230197] usb usb4: Manufacturer: Linux 3.10.9-default-pciehp xhci_hcd [ 4.230823] usb usb4: SerialNumber: 0000:0b:00.0 [ 5.291321] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd [ 5.313219] usb 4-2: Parent hub missing LPM exit latency info. Power management will be impacted. [ 5.319428] usb 4-2: New USB device found, idVendor=2109, idProduct=0811 [ 5.321417] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 5.323353] usb 4-2: Product: 4-Port USB 3.0 Hub [ 5.325272] usb 4-2: Manufacturer: VIA Labs, Inc. [14502.272269] usb 4-2.1: new SuperSpeed USB device number 3 using xhci_hcd [14502.292302] usb 4-2.1: Parent hub missing LPM exit latency info. Power management will be impacted. [14502.301158] usb 4-2.1: New USB device found, idVendor=174c, idProduct=5106 [14502.301171] usb 4-2.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [14502.301173] usb 4-2.1: Product: AS2105 [14502.301174] usb 4-2.1: Manufacturer: ASMedia [14502.301176] usb 4-2.1: SerialNumber: 3QD0AHHA This tells you exactly what the usb4, 4-2, and 4-2.1 devices are (including the PCI address of the controller for usb4; it is given as the SerialNumber string). The parent-child relations are evident from the device names. 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