[PATCH] Add USB quirk for HVR-950q to avoid intermittent device resets

startup, in particular when starting up ALSA audio streaming in parallel - the sysfs entries created by snd-usb-audio on streaming startup would result in unsupported control messages being sent during tuning which would put the chip into an unknown state. Signed-off-by: Devin Heitmueller

Re: [PATCH 08/12] Add USB quirk for HVR-950q to avoid intermittent device resets

> I've accepted the other patches in this patch series for the media subsystem, > but this patch should go through the USB subsystem. Cc-ed linux-usb. > > Acked-by: Hans Verkuil I'm not sure who on the linux-usb mailing list would need to deal with this, but would be

Re: [PATCH] em28xx TerraTec Cinergy Hybrid T USB XS with demodulator MT352 is not detect by em28xx

> It's been a long while since I've touched EM28xx stuff, but if I > remember correctly there should be an EEPROM byte which identifies the > demodulator used. There's some EEPROM hashing code in the driver but > it's only used for devices with generic (non-manufacturer > specific/default) USB

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

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). Devin, I'm try to learn a bit about USB and the Live2 protocol, however I'm not sure

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

At the moment I only have access to laptops, not a desktop, so the EHCI testing was on a different machine, with the Ubuntu 3.13 kernel. If you'd like me to test on a more recent kernel, please let me know. Ok. That's a useful data point. It's also worth mentioning that the process you're

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

for me to (tested with an HVR-950q on a 2013 Macbook Pro (Haswell). Tested by: Devin Heitmueller dheitmuel...@kernellabs.com Thanks for your help, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body

Re: Control message failures kill entire XHCI stack

On Tue, Mar 10, 2015 at 8:34 PM, Lu, Baolu baolu...@linux.intel.com wrote: Devin, I'd like you to provide output of lspci -xv. I want to know which xHC devices (PCI vendor and device ID) you are working with. Sorry, I misread your email. The lspci output is below. Devin 00:00.0 Host bridge:

Re: Control message failures kill entire XHCI stack

...@linux.intel.com wrote: Hi Devin, Do you mind to post output of lspci -xv on the machine where you saw this problem? We are facing the same problems in other cases. I could provide a patch for it later. Thanks, Baolu On 01/19/2015 04:55 AM, Devin Heitmueller wrote: Hello, I'm debugging some

Re: URB IRQ fires on URB after usb_kill_urb() already completed

Hi Alan, I think I see what's going on. Permit me to comment on your explanation of urb-use_count first, since it's relevant later on. Here's the story: A new URB has its use_count set to 0 by usb_init_urb. The use_count is incremented when the URB is submitted, in

Re: URB IRQ fires on URB after usb_kill_urb() already completed

Good suggestion. I'll add code to print it out before and after usb_kill_urb(), as well as from within the the IRQ handler and right before the call to usb_free_urb(). Added a quick debug line right before the call to usb_urb_kill(), thinking that perhaps one of the things checked for at the

URB IRQ fires on URB after usb_kill_urb() already completed

Hi there, I've been trying to track down some memory corruption in my driver for the HVR-950q related to dequeueing of ISOC URBs when shutting down the stream. I enabled SLUB poisoning, and I'm seeing a use-after-free condition in the EHCI driver. See below. Based on my read of the stack, it

Re: Control message failures kill entire XHCI stack

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 helps Hi Mathias, Thanks, I'll see if I can get this tested out over the

Re: URB IRQ fires on URB after usb_kill_urb() already completed

But the fact that the call stack passes through qh_completions and ehci_unlink_async means that the URB in question is _not_ isochronous (or interrupt for that matter). Does that help? Doh. My mistake. Of course it's a bulk endpoint. This is the price I pay for working on two different USB

Safe to call usb_kill_urb() against valid URB that hasn't been submitted?

Hi there, I've got a driver which maintains a pool of URBs, properly created via usb_alloc_urb(). Separately I have a cleanup function which destroys the pool by looping through the list and calling usb_kill_urb(), freeing the urb-transfer_buffer, and then calling usb_free_urb(). There are some

Re: Control message failures kill entire XHCI stack

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/b636927dec20652ff020e54ed7838a2e9be51e03 Now I'm not saying that reverting the commit in

Re: Control message failures kill entire XHCI stack

: 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://bugzilla.kernel.org/show_bug.cgi?id=65021 The first one (75521) I believe is mostly

Re: Control message failures kill entire XHCI stack

I've been following this as it somewhat resembles the problems I'm experiencing, which I've just formally reported in Hauppauge USB-Live2 recording fails on USB3 port. Yeah, it happens with the cx231xx as well, although the sequencing of events leading to the failure is a bit different (I

Re: Control message failures kill entire XHCI stack

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://bugzilla.kernel.org/show_bug.cgi?id=65021 The first one (75521) I believe is mostly fixed by patches in 3.18 and early 3.19-rc, so

Control message failures kill entire XHCI stack

Hello, I'm debugging some issues on a couple of different USB TV tuners which boil down to the following error: xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command. This is followed by the XHCI driver disconnecting *all* USB devices from the controller. I've done a bit of

Re: Upgrading just the USB core from 3.7 to tip?

Hi Alan, Thanks for taking the time to respond. On Thu, Feb 6, 2014 at 5:08 PM, Alan Stern st...@rowland.harvard.edu wrote: Is it possible to get any debugging information from the machines in the field? At this point all I know is the usb_submit_urb() is returning -EBIGF. In the 3.7 ehci_hcd

Upgrading just the USB core from 3.7 to tip?

Hi there, So I have a problem in the field on kernel 3.7 which is looking more and more like some sort of EHCI scheduler bug (very occasional usb_submit_urb failures in snd-usb-audio wedge the entire USB stack until reboot). Because it's only happening in the field and I cannot repro locally

Re: [PATCH 36/50] media: usb: em28xx: spin_lock in complete() cleanup

across this a couple of weeks ago, and have had an identical patch running in a local dev tree. Reviewed-by: Devin Heitmueller dheitmuel...@kernellabs.com Tested-by: Devin Heitmueller dheitmuel...@kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from

Re: Video corruption varies by system load

On Thu, Jul 11, 2013 at 4:24 AM, Johannes Stezenbach j...@sig21.net wrote: There are several cases where the isoc descriptor actual length is short ( 2892, e.g. 0, 552 or 1928), yet the actual_length for the whole URB at the end of the line is still 64*2892 -- is that like it should be? Yup,

Re: Video corruption varies by system load

On Thu, Jul 11, 2013 at 11:28 AM, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 11 Jul 2013, Johannes Stezenbach wrote: I took a peek at the usbmon log, and there is one thing I don't get. $ grep C Zi:1:005:2 em28xx_usbmon.log | less -S There are several cases where the isoc

Re: Video corruption varies by system load

On Thu, Jul 11, 2013 at 3:02 PM, Johannes Stezenbach j...@sig21.net wrote: I'm not familiar with musb but a quick glance at the code shows it uses software packet scheduling. If you do too much processing in the URB completion callback (which is called from irq context), then the next bus

Re: Video corruption varies by system load

On Thu, Jul 11, 2013 at 5:02 PM, Alan Stern st...@rowland.harvard.edu wrote: You could try doing the opposite test: Leave the driver otherwise intact, but have it not deliver the video buffers to the userspace client. Interesting. Only one error in 72 frames of video. Suggests the problem is

Re: Video corruption varies by system load

Hi Alan, On Wed, Jul 10, 2013 at 10:48 AM, Alan Stern st...@rowland.harvard.edu wrote: Digging into the scheduling code probably won't help much. However you could try collecting a usbmon trace (see Documentation/usb/usbmon.txt). This would clearly show the timing of URB submissions and

Re: Video corruption varies by system load

On Wed, Jul 10, 2013 at 10:58 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: I bet the problem is related to the usage of the URB_ISO_ASAP flag. em28xx_alloc_urbs() sets URB_ISO_ASAP in urb-transfer_flags, and the value never gets cleared. In fact, that flag bit is supposed to be set

Re: Video corruption varies by system load

On Wed, Jul 10, 2013 at 11:40 AM, Alan Stern st...@rowland.harvard.edu wrote: Nope, that wasn't it. I am now only setting ISO_ASAP in the first packet, and I tried both leaving it as in on resubmit and clearing the flag prior to resubmit. usbmon is the best debugging tool at this point.

Re: Video corruption varies by system load

On Wed, Jul 10, 2013 at 12:30 PM, Alan Stern st...@rowland.harvard.edu wrote: If you use the bus analyzer at the same time, you could compare microframe numbers. Ah, again, good suggestion. I'll get a usbmon trace in parallel to the Beagle. I'll have to move some stuff around though because I

Re: Video corruption varies by system load

Hi Alan, On Wed, Jul 10, 2013 at 2:27 PM, Alan Stern st...@rowland.harvard.edu wrote: You inspired me to take a closer look at the usbmon log you made available. There _is_ an error indication after all; the line with timestamp 397263317 got an error in one of its 64 packets (but this was

Re: Video corruption varies by system load

On Wed, Jul 10, 2013 at 3:37 PM, Alan Stern st...@rowland.harvard.edu wrote: 20-30 times each second? Okay... I didn't realize the errors were that frequent. Yeah, now you see why I'm freaking out. If this were one corrupt line every 20 seconds, I wouldn't care less. But there are lines

Re: Video corruption varies by system load

On Wed, Jul 10, 2013 at 5:21 PM, Alan Stern st...@rowland.harvard.edu wrote: Yeah, I tried that a few days ago. I did a memset() on the transfer_buffer prior to every resubmit, because at one point I thought perhaps I was getting back the buffer without it having been filled in. And you

Re: Video corruption varies by system load

On Sun, Jul 7, 2013 at 9:39 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: I finally dug out my Beagle 480 USB, so I will get that hooked up this week, write a decoder to reassemble the video frames based on the USB trace, and know once and for all whether the device is delivering

[no subject]

Hi all, I've been doing some debugging of a video corruption problem in the em28xx video capture driver, and after a couple of weeks of digging in, I think I might have exposed some sort race condition in the USB core. http://devinheitmueller.com/out17.png I'm submitting URBs of 64 x 3072, I've