Re: Mouse works with eHCI, fails with xHCI - can't set config #1, error -110

2015-04-20 Thread Alistair Grant
On Tue, Apr 14, 2015 at 10:52:21AM -0400, Alan Stern wrote: > On Tue, 14 Apr 2015, Alistair Grant wrote: > > > Hi Mathias and Alan, > > > > As Mathias requested, I've included the usbmon output with the patch > > applied. > > > > It didn't ma

Re: Mouse works with eHCI, fails with xHCI - can't set config #1, error -110

2015-04-14 Thread Alistair Grant
On Mon, Apr 13, 2015 at 04:24:50PM -0400, Alan Stern wrote: > On Mon, 13 Apr 2015, Mathias Nyman wrote: > > > Another difference between EHCI and xHCI iss that xHCI needs to reset (the > > host side) > > of a control endpoint if it stalled. > > > > From xHCI 1.0 4.8.3: > > > > "A STALL detect

Re: Mouse works with eHCI, fails with xHCI - can't set config #1, error -110

2015-04-10 Thread Alistair Grant
Hi Alan, On Fri, Apr 10, 2015 at 7:23 PM, Alan Stern wrote: > On Fri, 10 Apr 2015, Alistair Grant wrote: >> On Fri, Apr 10, 2015 at 5:29 PM, Alan Stern >> wrote: >> > On Fri, 10 Apr 2015, Alistair Grant wrote: >> > ... >> >> i.e. the mouse works

Re: xhci_hcd error Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 1

2015-03-26 Thread Alistair Grant
On Mon, Mar 23, 2015 at 10:14 PM, Devin Heitmueller wrote: > > My guess would be that there's some bug in the cx231xx that > exacerbates an edge case in the XHCI core - like prematurely setting > the USB alternate back to zero when stopping streaming and not > canceling all the URBs first. > > ...

Re: xhci_hcd error Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 1

2015-03-23 Thread Alistair Grant
Hi Devin, On Mon, Mar 23, 2015 at 8:16 PM, Devin Heitmueller wrote: > Hi Alistair, > >> There are some small differences in packet ordering, however the first >> major difference is an isochronous in packet where the Live2 returns >> "URB status: No such file or directory (-ENOENT) (-2)". >> >> D

xhci_hcd error Transfer event TRB DMA ptr not part of current TD ep_index 8 comp_code 1

2015-03-23 Thread Alistair Grant
Hi Mathias & Devin, I've changed the subject to avoid any confusion with the patch series that Mathias just posted for inclusion in 4.0-rc. On Tue, Mar 17, 2015 at 4:21 PM, Alistair Grant wrote: >>>>>>> It looks like I may have signed-off a little too soon

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-03-17 Thread Alistair Grant
On Mon, Mar 16, 2015 at 5:29 PM, Mathias Nyman wrote: > On 16.03.2015 17:21, Alistair Grant wrote: >> On Mon, Mar 16, 2015 at 3:47 PM, Mathias Nyman >> wrote: >>> On 16.03.2015 16:31, Alistair Grant wrote: >>>> On Mon, Mar 16, 2015 at 1:55 PM, Mathias Nyman

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-03-16 Thread Alistair Grant
On Mon, Mar 16, 2015 at 3:47 PM, Mathias Nyman wrote: > On 16.03.2015 16:31, Alistair Grant wrote: >> On Mon, Mar 16, 2015 at 1:55 PM, Mathias Nyman >> wrote: >>> On 15.03.2015 21:18, Alistair Grant wrote: >>>> On Sun, Mar 15, 2015 at 3:54 PM, Alistair Gran

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-03-16 Thread Alistair Grant
On Mon, Mar 16, 2015 at 1:55 PM, Mathias Nyman wrote: > On 15.03.2015 21:18, Alistair Grant wrote: >> On Sun, Mar 15, 2015 at 3:54 PM, Alistair Grant >> wrote: >>> On Thu, Mar 12, 2015 at 8:14 PM, Alistair Grant >>> wrote: >>>> On Thu, Ma

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-03-15 Thread Alistair Grant
On Sun, Mar 15, 2015 at 3:54 PM, Alistair Grant wrote: > On Thu, Mar 12, 2015 at 8:14 PM, Alistair Grant wrote: >> On Thu, Mar 12, 2015 at 11:15 AM, Lu Baolu wrote: >>> When a device with an isochronous endpoint is plugged into the Intel >>> xHCI host controller, and

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-03-15 Thread Alistair Grant
On Thu, Mar 12, 2015 at 8:14 PM, Alistair Grant wrote: > On Thu, Mar 12, 2015 at 11:15 AM, Lu Baolu wrote: >> When a device with an isochronous endpoint is plugged into the Intel >> xHCI host controller, and the driver submits multiple frames per URB, >> the xHCI driver wil

Re: [PATCH v3 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-03-15 Thread Alistair Grant
> Signed-off-by: Lu Baolu > Tested-by: Alistair Grant > Tested-by: Devin Heitmueller > Cc: sta...@vger.kernel.org > ... As a workaround until this makes it to the various distributions, would it be possible to create a config file that enables the quirk, something like:

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-03-12 Thread Alistair Grant
REBOOT; > - xhci->quirks |= XHCI_AVOID_BEI; > } > if (pdev->vendor == PCI_VENDOR_ID_INTEL && > pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) { > -- > 2.1.0 > > -- This works for me... Computer: Dell XPS13 9333

Re: Control message failures kill entire XHCI stack

2015-03-05 Thread Alistair Grant
Hi Mathias, On Thu, Mar 5, 2015 at 4:25 PM, Mathias Nyman wrote: > On 04.03.2015 15:27, Alistair Grant wrote: >> On Tue, Mar 3, 2015 at 8:40 PM, Alistair Grant wrote: >>> On Tue, Mar 3, 2015 at 2:21 PM, Mathias Nyman >>> wrote: >>>> On

Re: Control message failures kill entire XHCI stack

2015-03-04 Thread Alistair Grant
Hi Mathias, On Tue, Mar 3, 2015 at 8:40 PM, Alistair Grant wrote: > Hi Mathias, > > On Tue, Mar 3, 2015 at 2:21 PM, Mathias Nyman > wrote: >> On 28.02.2015 09:16, Alistair Grant wrote: >>> ... >>> * 3.19.0 with the following patches: >>> * xhci:

Re: Control message failures kill entire XHCI stack

2015-03-03 Thread Alistair Grant
Hi Mathias, On Tue, Mar 3, 2015 at 2:21 PM, Mathias Nyman wrote: > On 28.02.2015 09:16, Alistair Grant wrote: >> ... >> * 3.19.0 with the following patches: >> * xhci: Allocate correct amount of scratchpad buffers >> * xhci: Don't touch TRBs memory if those ar

Re: Control message failures kill entire XHCI stack

2015-02-27 Thread Alistair Grant
Hi Mathias & Devin, On Thu, Feb 19, 2015 at 3:18 PM, Mathias Nyman wrote: > > Got one more patch added to the for-usb-next-branch. > It makes sure we allocate enough scratchpad memory for xhci. > > It's one possible cause. > Patch will anyway go to 3.20, but you can try it out first to see if it

Re: Control message failures kill entire XHCI stack

2015-02-04 Thread Alistair Grant
Hi Mathias, On Wed, Feb 4, 2015 at 5:26 PM, Mathias Nyman wrote: > On 27.01.2015 00:20, Alistair Grant wrote: >> I've come across what appears to be another xHCI issue - attempting to >> format a disk with gparted is causing a kernel Oops. This may not be >> r

Re: Control message failures kill entire XHCI stack

2015-01-26 Thread Alistair Grant
I've come across what appears to be another xHCI issue - attempting to format a disk with gparted is causing a kernel Oops. This may not be related to the issue you're currently investigating, but wanted to pass it on in case it is (if it isn't let me know and I'll either keep quiet or raise it se

Re: Control message failures kill entire XHCI stack

2015-01-26 Thread Alistair Grant
On Mon, Jan 26, 2015 at 4:37 AM, Devin Heitmueller wrote: > Hi Mathias, > > Here's an interesting development: as a result of a related thread on > linux-media, I came across a patch they are distributing in openelec: > > https://github.com/OpenELEC/OpenELEC.tv/commit/b636927dec20652ff020e54ed783

Re: Control message failures kill entire XHCI stack

2015-01-22 Thread Alistair Grant
Hi Matthias, On Thu, Jan 22, 2015 at 12:22 PM, Mathias Nyman wrote: > On 21.01.2015 21:16, Alistair Grant wrote: >> Hi Matthias, >> >> On Tue, Jan 20, 2015 at 10:22 AM, Mathias Nyman >> wrote: >>> On 19.01.2015 22:02, Devin Heitmueller wrote: >>>&g

Re: Control message failures kill entire XHCI stack

2015-01-21 Thread Alistair Grant
Hi Matthias, On Tue, Jan 20, 2015 at 10:22 AM, Mathias Nyman wrote: > On 19.01.2015 22:02, Devin Heitmueller wrote: >> Hi Mathias, >> >> Thanks for getting back to me. >> >>> There are a couple of xhci bugs triggered by dvb devices: >>> https://bugzilla.kernel.org/show_bug.cgi?id=75521 >>> https: