Hi Felipe, Mathias; I pulled a clean copy of v4.5 and applied the patch suggested by Felipe, and the issue is no longer present. I would like to disable this behavior via changes to my software instead of requiring customers to build a custom kernel. What would be the ideal solution to this issue? Would it be acceptable to wrap the lines of code with an if-else using a new kernel boot parameter? Mathias also provided a suggestion that I could put in to my code: > If that is the issue then adding pm_runtime_get_xxx() will increase the device > usage count before you know you are going to use a device. It prevents runtime suspend. > Then once you know the device is going to be idle, decrease the referece cound > with a pm_runtime_put(). May I please request a short code snippet on how I could get the `struct device*' handle, assuming I have a libusb_device_handle and the bus/dev number of the camera in use? I'm not very familiar with the core USB API, and would just need to know how to do the set/reset logic to prevent runtime suspend. Thank you all for your time and assistance. ============================================================ Matthew Giassa, MASc, BASc, EIT Security and Embedded Systems Specialist linkedin: https://ca.linkedin.com/in/giassa e-mail: matthew@xxxxxxxxxx website: www.giassa.net > -------- Original Message -------- > Subject: Re: USB xHCI regression after upgrading from kernel 3.19.0-51 > to 4.2.0-34.] > From: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> > Date: Sun, April 10, 2016 10:28 pm > To: Matthew Giassa <matthew@xxxxxxxxxx>, linux-usb@xxxxxxxxxxxxxxx, > Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> > > > Hi, > > Matthew Giassa <matthew@xxxxxxxxxx> writes: > > *Migrating from linux-media mailing list. > > > > Good day, > > > > I maintain an SDK for USB2.0 and USB3.0 U3V machine vision cameras, and > > several of our customers have reported severe issues since upgrading > > from > > kernel 3.19.0-51 (Ubuntu 14.04.3 LTS) to kernel 4.2.0-34 (Ubuntu 14.04.4 > > LTS). I've received helpful advice from members of the libusb and > > linux-usb mailing lists on how to generate useful logs to help diagnose > > the issue, and have filed a bug to track this issue at: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=115961 > > > > It seems that with kernels newer than the 3.19 series (I've tested on > > 4.2.0-34, and just repeated the tests on the latest 4.5.0 vanilla > > release), > > the cameras lock up, and cannot stream image data to the user > > application. I > > am able to resolve the issue on 4.2.0-34 by disabling USB power > > management by adding "usbcore.autosuspend=-1". On the 4.5 kernel, this > > "trick" doesn't work at all, and I have no way to get the cameras to > > stream data. I can do simple USB control requests to query things like > > register values and serial numbers, but that's it. Asynchronous bulk > > transfers never succeed. > > > > I am using the libusb library to communicate with the cameras, and have > > a fairly simple minimal working example to test the cameras, which: > > * Creates a default libusb context. > > * Enumerates available USB devices. > > * Filters out a select device based on the vendor/product ID values. > > * Opens the device, claims the bulk interface, and starts requesting > > frames of image data via async bulk transfer requests. > > > > There are select cases where the issue does not arise: > > > > Special Cases: > > * The issue does not occur when using USB2.0 cameras on a USB2.0 port, > > regardless of the kernel in use. > > * The issues occur only on Intel 8 Series and Intel 9 Series USB3.0 > > host controllers with 4.x kernels. > > * Intel 10 Series host controllers have not yet been tested. > > * The issues never occur on Fresco or Renesas host controllers, > > regardless of the kernel in use. > > * From visual inspection of lsusb output, the issue only appears to > > happen when the U1 and U2 options are available to the device. > > okay, this is probably what's happening. Intel hosts are the only ones > actively doing LPM, for all other hosts we don't have support. > > Here are a few question: > > a) Are you sure your cameras implement proper LPM ? > b) I'm assuming the following makes the problem go away, can you test ? > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > index f0640b7a1c42..9c3ead114ad5 100644 > --- a/drivers/usb/host/xhci-pci.c > +++ b/drivers/usb/host/xhci-pci.c > @@ -127,8 +127,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) > xhci->quirks |= XHCI_TRUST_TX_LENGTH; > > if (pdev->vendor == PCI_VENDOR_ID_INTEL) { > - xhci->quirks |= XHCI_LPM_SUPPORT; > - xhci->quirks |= XHCI_INTEL_HOST; > + /* xhci->quirks |= XHCI_LPM_SUPPORT; */ > + /* xhci->quirks |= XHCI_INTEL_HOST; */ > xhci->quirks |= XHCI_AVOID_BEI; > } > if (pdev->vendor == PCI_VENDOR_ID_INTEL && > > c) I remember that I mentioned to Mathias that I'd seen XHCI LPM go a > bit crazy and trigger constant LPM transactions; maybe you're just the > first one to notice an actual functional breakage due to that. > > -- > balbi -- 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
