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
Hi Alan,
Thanks for taking the time to provide feedback. I'm just noticing now
that I left off the subject line, which all the more reason makes me
thankful that you bothered to read an email with as uninteresting a
subject line as is possible. :-)
On Tue, Jul 2, 2013 at 11:21 AM, Alan Stern w
On Sun, Jul 7, 2013 at 9:39 PM, Devin Heitmueller
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
> correct video
Hi Alan,
On Wed, Jul 10, 2013 at 10:48 AM, Alan Stern 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 completions.
Good suggestio
On Wed, Jul 10, 2013 at 10:58 AM, Devin Heitmueller
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
On Wed, Jul 10, 2013 at 11:40 AM, Alan Stern 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.
http://www.devinheitm
On Wed, Jul 10, 2013 at 12:30 PM, Alan Stern 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
don't want to run the B
Hi Alan,
On Wed, Jul 10, 2013 at 2:27 PM, Alan Stern 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 the only error in the en
On Wed, Jul 10, 2013 at 3:37 PM, Alan Stern 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 every few
frames of video (
On Wed, Jul 10, 2013 at 5:21 PM, Alan Stern 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 found that the buff
be linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I actually stumbled across this a couple of weeks ago, and have had an
identical patch running in a local dev tree.
Reviewed-by: Devin Heitmueller
On Thu, Jul 11, 2013 at 4:24 AM, Johannes Stezenbach 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, as Alan s
On Thu, Jul 11, 2013 at 11:28 AM, Alan Stern 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 descriptor actual l
On Thu, Jul 11, 2013 at 3:02 PM, Johannes Stezenbach 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 transaction
>
On Thu, Jul 11, 2013 at 5:02 PM, Alan Stern 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 somewhere that is anyw
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 (and
Hi Alan,
Thanks for taking the time to respond.
On Thu, Feb 6, 2014 at 5:08 PM, Alan Stern 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 driver that can come fr
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 d
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
> n
> 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 y
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
> 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
hat's going on.
Devin
On Thu, Jan 22, 2015 at 6:32 AM, Alistair Grant wrote:
> 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, 201
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 questio
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
> 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 wee
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 lo
> 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 U
> 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 th
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,
>
, Baolu 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:
On Tue, Mar 10, 2015 at 8:34 PM, Lu, Baolu 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: Intel Corporation Has
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
>
Looks good for me to (tested with an HVR-950q on a 2013 Macb
> 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 IDs.
> 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 great if we could get this
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
36 matches
Mail list logo
