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

[Mauro Carvalho Chehab <mchehab@osg.samsung.com>]

Em Sun, 28 Sep 2014 23:43:07 +0300
Antti Palosaari <crope@iki.fi> escreveu:

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

Try to add a sleep between each scan trial. As far as I know, the
USB core uses the USB interval as a hint for the USB traffic to be
allocated, and then it dynamically measures the traffic to adjust
the number of allocated slots. There are 800 slots/sec on a USB 2.0
interface.

> * It is not USB bw issue as I don't have any other devices. Also, it 
> occurs during scan which indicates same.

Several boards have internal USB devices, especially on notebooks.

> * I have feeling it happens more often with newer em28xx devices, but it 
> could be due to reason I usually work with new devices.

Could be. Try to force the number of URBs and their sizes to different
values at em28xx_dvb_init(). Seek for the part of the code that calls
em28xx_alloc_urbs().

For ISOC traffic, it does:

		result = em28xx_alloc_urbs(dev, EM28XX_DIGITAL_MODE,
					   dev->dvb_xfer_bulk,
					   EM28XX_DVB_NUM_BUFS,
					   dev->dvb_max_pkt_size_isoc,
					   EM28XX_DVB_NUM_ISOC_PACKETS);

You may try to change the values for EM28XX_DVB_NUM_BUFS and
EM28XX_DVB_NUM_ISOC_PACKETS and see if this affects.

The dvb_max_pkt_size_isoc is read from the descriptors, but if the
ROM data is wrong, maybe it is higher than it should be.

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

And does PCTV 520e fail with 3.12? If so, then you could try to
bisect it.

Regards,
Mauro

> 
> regards
> Antti
>