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
On Thu, 11 Jul 2013, Devin Heitmueller wrote:
> Funny - I had the same thought a few hours ago about moving the actual
> URB processing to a tasklet. However I don't think it will help.
> Here's why:
>
> Expanding on the test where I cut out everything in the URB handler
> except for the submit,
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 02:12:08PM -0400, Alan Stern wrote:
> On Thu, 11 Jul 2013, Devin Heitmueller wrote:
>
> > Another strange thing: If I change the completion handler on the 8147
> > to comment out the actual processing of the URB (such that all the
> > completion handler does is resubmit th
On Thu, 11 Jul 2013, Devin Heitmueller wrote:
> It looks like I may have created some confusion by attempting to
> correlate the usbmon trace against the Beagle data. I've got two
> environments I'm debugging on: an x86 box with the stock Intel EHCI
> HCD, and a Davinci TI8147 ARM system which h
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 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:38AM -0400, Alan Stern wrote:
> On Thu, 11 Jul 2013, Johannes Stezenbach wrote:
>
> > Can you confirm that in the error case there is no IN token at all?
>
> That's what the analyzer log showed. Of course, it's possible that the
> analyzer itself was faulty, but I d
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 length is
> short (< 2892, e.g. 0, 552 or 1928), yet the act
On Wed, Jul 10, 2013 at 09:13:09PM -0400, Alan Stern wrote:
> On Wed, 10 Jul 2013, Devin Heitmueller wrote:
>
> > So one might ask: why is the em28xx device sending a microframe with
> > corrupt bytes? One thing I've noticed is immediately prior to any
> > microframe containing corruption, there
On Wed, 10 Jul 2013, Devin Heitmueller wrote:
> So one might ask: why is the em28xx device sending a microframe with
> corrupt bytes? One thing I've noticed is immediately prior to any
> microframe containing corruption, there was a missing microframe - the
> time between the microframe containi
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
On Wed, 10 Jul 2013, Devin Heitmueller wrote:
> > It's rather disturbing that they don't show up at all in the usbmon
> > trace. This suggests two possibilities:
> >
> > The ehci-hcd driver is so messed up that not only did it fail
> > to tell the hardware to send those missing pa
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, 10 Jul 2013, Devin Heitmueller wrote:
> 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
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, 10 Jul 2013, Devin Heitmueller wrote:
> > I don't see any problems in the usbmon trace, but they might not show
> > up there. In particular, the trace includes the status values only for
> > the first 5 packets in each URB. Does the driver encounter any packets
> > with a nonzero status?
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
On Wed, 10 Jul 2013, Devin Heitmueller wrote:
> 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
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, 10 Jul 2013, Devin Heitmueller wrote:
> 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,
On Wed, 10 Jul 2013, 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 be set
> > only in the first URB of a
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 be set
>> only in the first
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 Tue, 9 Jul 2013, Devin Heitmueller wrote:
> So I hooked up the video and wrote a bit of Perl to parse the ISOC
> stream and render the underlying video frames. I can see definitively
> that the video returned from the device contains the corruption. This
> rules out any sort of DMA or memory
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 or not. If
On Mon, Jul 8, 2013 at 9:39 AM, Devin Heitmueller
wrote:
> 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
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
28 matches
Mail list logo
