Em Sun, 28 Sep 2014 23:43:07 +0300 Antti Palosaari <crope@xxxxxx> escreveu: > > > On 09/28/2014 10:57 PM, Mauro Carvalho Chehab wrote: > > Em Sun, 28 Sep 2014 21:13:59 +0300 > > Antti Palosaari <crope@xxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
