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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
