Re: Video corruption varies by system load

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 containing corruption and the previously
> received microframe was 250us, and not 125us as expected.  My
> speculation is that the failure of the host controller to ask for that
> missing microframe causes some confusion in the em28xx, which results
> in it sending the wrong bytes in the next microframe.  Alternatively
> the em28xx has some sort of circular buffer, and failing to ask for
> the microframe causes the circular buffer to wrap around (so the next
> microframe sent contains bad data).

This is what I've been trying to get at.  The usbmon timing data shows
that the host controller thinks a packet was sent and received during
the "missing" microframe.  The data you saw in the buffer proves that
the controller did write _something_ to memory during the "missing"
microframe -- where did that something come from?

> Wireshark appears to be showing the URB timing, but really what we're
> interested in is the microframe timing.  That said, it would be good
> to know what is in the microframe that is immediately prior to the
> microframe containing corruption.  Is it a zero length microframe?  Is

That's why I suggested you zero the buffer before resubmission and have
the driver check the packet descriptor's actual_length value.

> it the frame that was received 250us earlier?

That's why I suggested you examine the wireshark data in detail.

>  That might help
> understand whether the host controller believes that the IN
> transaction occurred.

The host controller undoubtedly _does_ believe this.  Or at least,
that's what it indicates to the CPU, by setting the iTD's transaction
status to 0.

Unless for reason the iTD data structure was set up wrongly in the
first place...

> I'll work on seeing if I can correlate the data between the Beagle
> trace and the usbmon trace, so I can see what the host *thinks*
> happened immediately prior to the corrupt microframe.

Good.

Alan Stern

--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux