Re: em28xx: Too many ISO frames scheduled when starting stream

[Antti Palosaari <crope@iki.fi>]

On 09/28/2014 10:57 PM, Mauro Carvalho Chehab wrote:
> Em Sun, 28 Sep 2014 21:13:59 +0300
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 09/28/2014 08:25 PM, Antti Palosaari wrote:
>>> I want raise that bug:
>>> Too many ISO frames scheduled when starting stream
>>> https://bugzilla.kernel.org/show_bug.cgi?id=72891
>>>
>>> Is there anyone who cares to study it? It looks like em28xx driver bug
>>> or USB host controller driver or both.
>>>
>>> According to comments bug appeared on kernel 3.13.
>>
>> em28xx didn't even get any notable changes at that time... I looked all
>> the 3.13 em28xx patches and there is no patch that could cause issues
>> listed. So root of cause is somewhere else or there is reports which has
>> kernel with media_build installed.
>> Also, em28xx uses ISOC to data transferred, whilst most devices are
>> using BULK. No other reports from other ISOC DVB devices so far though.
>> I suspect it may be some compatibility issue with em28xx chip / em28xx
>> driver / USB stack / USB host controller.
>>
>> There were em28xx patches went to 3.13 (stable patches not included):
>> bdee6bd [media] em28xx-video: Swap release order to avoid lock nesting
>> 6dbea9f [media] Add support for KWorld UB435-Q V2
>> be353fa [media] V4L2: em28xx: tell the ov2640 driver to balance clock
>> enabling internally
>> fc5d0f8 [media] V4L2: em28xx: register a V4L2 clock source
>> 032f1dd [media] em28xx: fix error path in em28xx_start_analog_streaming()
>> b68cafc [media] em28xx: fix and unify the coding style of the GPIO
>> register write sequences
>> de0fc46 [media] em28xx: MaxMedia UB425-TC change demod settings
>> b6c7abb [media] em28xx: MaxMedia UB425-TC switch RF tuner driver to another
>> 8d100b2 [media] em28xx: MaxMedia UB425-TC offer firmware for demodulator
>
> None of the above patches seem to be related. Also, I use a lot em28xx
> here without any issues on an eHCI USB port. Even on a xHCI USB port,
> I was unable to reproduce this bug with just one em28xx device plugged.
>
> I _suspect_ that this issue is related to ISOC transfers, and the
> return code is EFBIG.
>
> The EFBIG return code happens if there's not enough space in a given
> USB bus to reserve traffic for ISOC transfers when submitting the
> URBs. Changing the URB size helps to reduce the amount of ISOC
> transfers, making more unlikely for this bug to happen. However, the
> em28xx driver already tries to use the max supported size, using the
> USB descriptors.
>
> There's one easy way to reproduce it: plug two em28xx devices with
> analog TV and try to start both. The first analog TV stream will
> allocate about 60% of the bus traffic, and the Kernel will return
> EFBIG when trying to stream at the second one.
>
> That's said, on a USB bus where there's just one device connected,
> this error shouldn't happen, especially for DVB, where the bandwidth
> requirements are generally lower.
>
> It used to be possible to check how much was allocated for ISOC
> traffic via:
>
> # cat /sys/kernel/debug/usb/devices
>
> T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=5000 MxCh= 1
> B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
> D:  Ver= 3.00 Cls=09(hub  ) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
> P:  Vendor=1d6b ProdID=0003 Rev= 3.17
> S:  Manufacturer=Linux 3.17.0-rc6+ xhci_hcd
> S:  Product=xHCI Host Controller
> S:  SerialNumber=0000:00:14.0
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms
>
> The "Alloc" above would indicate how many slots were allocated.
> However, at least here on an Atom NUC I'm testing and latest
> upstream Kernel + media patches, no matter if I start some traffic
> or not there, it still shows 0/800. It seems that there's a bug
> somewhere on the USB stack that it is preventing it to show.
>
> In any case, the return of EFBIG doesn't imply that there's a bug at
> em28xx driver or at the usb stack. It is just an indication that the
> bus has reached its maximum hardware capacity.
>
> That's said, I was never ever be able to get EFBIG when there's
> just one isoc device connected into an USB bus. Not sure if
> this is the case of the reporter of BZ#72891.
>
> I suggest you to double check if this is the only one device
> connected at the bus that could be using ISOC traffic.
>
> If there's just one device connected, and no other weird setup
> (like trying to run the driver inside a VM, or some USB hubs
> connected internally or externally), then we should seek for this
> bug at the USB stack.
>
> Btw, Hans de Goede faced with this issue a lot with his works with
> gspca. I think he sent some patches to the USB stack to try to
> reduce the changes of this error to happen.
>
> Another possibility is that maybe the USB descriptors are broken
> on some versions of the silicon, with makes the USB core to return
> such error because em28xx is overriding the physical limits due to
> a bad descriptor at the device's ROM. Never saw this on em28xx,
> but I have some other USB devices with bad descriptors.
>
> I hope that helps.

Some related things I have noticed:
* It happens very often when you scan channels. This is due to scan 
starts and stops stream for every channel scanned.
* It is not USB bw issue as I don't have any other devices. Also, it 
occurs during scan which indicates same.
* I have feeling it happens more often with newer em28xx devices, but it 
could be due to reason I usually work with new devices.

I have been scanning DVB-C channels in a loop one hour now using old 
PCTV 520e. Kernel is 3.11.10 and drivers are from latest media tree. No 
error seen so far...

regards
Antti

-- 
http://palosaari.fi/