em28xx: Too many ISO frames scheduled when starting stream

em28xx: Too many ISO frames scheduled when starting stream

[Antti Palosaari]

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.

Is there anyone knowing em28xx internals who wants (non surely really 
want, but hates less to start examine) to look it?

It is very near I will fork em28xx to DVB only driver and move devices 
there. Current em28xx is too complex for my taste and has had more bugs 
than any other DVB driver I have ever seen.

regards
Antti

-- 
http://palosaari.fi/

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

[Antti Palosaari]

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


> Is there anyone knowing em28xx internals who wants (non surely really
> want, but hates less to start examine) to look it?
>
> It is very near I will fork em28xx to DVB only driver and move devices
> there. Current em28xx is too complex for my taste and has had more bugs
> than any other DVB driver I have ever seen.


regards
Antti

-- 
http://palosaari.fi/

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

[Mauro Carvalho Chehab]

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.

Regards,
Mauro

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

[Antti Palosaari]

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/

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

[Mauro Carvalho Chehab]

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
>