Aw: Re: dvb usb issues since kernel 4.9
Hi Linus, your patch works very good for me and others (please see https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). No errors in recordings any more. The patch was also tested on x86_64 (Revo 3700) with positive effect. I agree with the forum poster, that there's still an issue when recording and watching livetv at same time. I also get audio dropouts and audio is out of sync. According to user smp kernel 4.9.73 with your patch on rpi and according to user jahutchi kernel 4.11.12 on x86_64 have no such issues. I don't know if this dropouts are related to this topic. If of any help I could provide perf output on raspberry with libreelec and tvheadend. Regards, Josef Gesendet: Montag, 08. Januar 2018 um 23:16 Uhr Von: "Jesper Dangaard Brouer" <jbro...@redhat.com> An: "Peter Zijlstra" <pet...@infradead.org> Cc: "Josef Griebichler" <griebichler.jo...@gmx.at>, "Mauro Carvalho Chehab" <mche...@s-opensource.com>, "Alan Stern" <st...@rowland.harvard.edu>, "Greg Kroah-Hartman" <gre...@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <eduma...@google.com>, "Rik van Riel" <r...@redhat.com>, "Paolo Abeni" <pab...@redhat.com>, "Hannes Frederic Sowa" <han...@redhat.com>, linux-kernel <linux-ker...@vger.kernel.org>, netdev <net...@vger.kernel.org>, "Jonathan Corbet" <cor...@lwn.net>, LMML <linux-me...@vger.kernel.org>, "David Miller" <da...@davemloft.net>, torva...@linux-foundation.org Betreff: Re: dvb usb issues since kernel 4.9 On Mon, 8 Jan 2018 22:44:27 +0100 Peter Zijlstra <pet...@infradead.org> wrote: > On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote: > > I did expected the issue to get worse, when you load the Pi with > > network traffic, as now the softirq time-budget have to be shared > > between networking and USB/DVB. Thus, I guess you are running TCP and > > USB/mpeg2ts on the same CPU (why when you have 4 CPUs?...) > > Isn't networking also over USB on the Pi ? Darn, that is true. Looking at the dmesg output in http://ix.io/DOg: [ 0.405942] usbcore: registered new interface driver smsc95xx [ 5.821104] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 I don't know enough about USB... is it possible to control which CPU handles the individual USB ports, or on some other level (than ports)? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer[http://www.linkedin.com/in/brouer] -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: Re: dvb usb issues since kernel 4.9
No I can't sorry. There's no sat connection near to my workstation. Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr Von: "Alan Stern" <st...@rowland.harvard.edu> An: "Josef Griebichler" <griebichler.jo...@gmx.at> Cc: "Mauro Carvalho Chehab" <mche...@s-opensource.com>, "Greg Kroah-Hartman" <gre...@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <eduma...@google.com>, "Rik van Riel" <r...@redhat.com>, "Paolo Abeni" <pab...@redhat.com>, "Hannes Frederic Sowa" <han...@redhat.com>, "Jesper Dangaard Brouer" <jbro...@redhat.com>, linux-kernel <linux-ker...@vger.kernel.org>, netdev <net...@vger.kernel.org>, "Jonathan Corbet" <cor...@lwn.net>, LMML <linux-me...@vger.kernel.org>, "Peter Zijlstra" <pet...@infradead.org>, "David Miller" <da...@davemloft.net>, torva...@linux-foundation.org Betreff: Re: Aw: Re: dvb usb issues since kernel 4.9 On Mon, 8 Jan 2018, Josef Griebichler wrote: > Hi Maro, > > I tried your mentioned patch but unfortunately no real improvement for me. > dmesg http://ix.io/DOg > tvheadend service log http://ix.io/DOi[http://ix.io/DOi] > Errors during recording are still there. > Errors increase if there is additional tcp load on raspberry. > > Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs. Can you try running the same test on an x86_64 system? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: dvb usb issues since kernel 4.9
Hi Maro, I tried your mentioned patch but unfortunately no real improvement for me. dmesg http://ix.io/DOg tvheadend service log http://ix.io/DOi Errors during recording are still there. Errors increase if there is additional tcp load on raspberry. Unfortunately there's no usbmon or tshark on libreelec so I can't provide further logs. Regards, Josef > On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote: > > > > > It seems that the original patch were designed to solve some IRQ issues > > > > with network cards with causes data losses on high traffic. However, > > > > it is also causing bad effects on sustained high bandwidth demands > > > > required by DVB cards, at least on some USB host drivers. > > > > > > > > Alan/Greg/Eric/David: > > > > > > > > Any ideas about how to fix it without causing regressions to > > > > network? > > > > > > It would be good to know what hardware was involved on the x86 system > > > and to have some timing data. Can we see the output from lsusb and > > > usbmon, running on a vanilla kernel that gets plenty of video glitches? > > > > From Josef's report, and from the BZ, the affected hardware seems > > to be based on Montage Technology M88DS3103/M88TS2022 chipset. > > What type of USB host controller does the x86_64 system use? EHCI or > xHCI? I'll let Josef answer this. > > > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c, > > with shares a USB implementation that is used by a lot more drivers. > > The URB handling code is at: > > > > drivers/media/usb/dvb-usb-v2/usb_urb.c > > > > This particular driver allocates 8 buffers with 4096 bytes each > > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP. > > > > This become a popular USB hardware nowadays. I have one S960c > > myself, so I can send you the lsusb from it. You should notice, however, > > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit > > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps > > of payload after removing URB headers. > > You mentioned earlier that the driver uses bulk transfers. In USB-2.0, > the maximum possible payload data transfer rate using bulk transfers is > 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And > even this is possible only if almost nothing else is using the bus at > the same time. No, I said 58 Mbits/s (not bytes). On DVB-C and DVB-S2 specs, AFAIKT, there's no hard limit for the maximum payload data rate, although industry seems to limit it to be around 60 Mbits/s. On those standards, the maximal bit rate is defined by the modulation type and by the channel symbol rate. To give you a practical example, my DVB-S2 provider modulates each transponder with 8/PSK (3 bits/symbol), and define channels with a symbol rate of 30 Mbauds/s. So, it could, theoretically, transport a MPEG-TS stream up to 90 Mbits/s (minus headers and guard intervals). In practice, the streams there are transmitted with 58,026.5 Kbits/s. > > A 10 minutes record with the > > entire data (with typically contains 5-10 channels) can easily go > > above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if > > a usbmon dump would be useful. > > It might not be helpful at all. However, I'm not interested in the > payload data (which would be unintelligible to me anyway) but rather > the timing of URB submissions and completions. A usbmon trace which > didn't keep much of the payload data would only require on the order of > 50 MB per minute -- and Josef said that glitches usually would show up > within a minute or so. Yeah, this could help. Josef, You can get it with wireshark/tshark or tcpdump. See: https://technolinchpin.wordpress.com/2015/10/23/usb-bus-sniffers-for-linux-system/ https://wiki.wireshark.org/CaptureSetup/USB > > I'm enclosing the lsusb from a S960C device, with is based on those > > Montage chipsets: > > What I wanted to see was the output from "lsusb" on the affected > system, not the output from "lsusb -v -s B:D" on your system. > > > > Overall, this may be a very difficult problem to solve. The > > > 4cd13c21b207 commit was intended to improve throughput at the cost of > > > increased latency. But then what do you do when the latency becomes > > > too high for the video subsystem to handle? > > > > Latency can't be too high, otherwise frames will be dropped. > > Yes, that's the whole point. > > > Even if the Kernel itself doesn't drop, if the delay goes higher > > than a certain threshold, userspace will need to drop, as it > > should be presenting audio and video on real time. Yet, typically, > > userspace will delay it by one or two seconds, with would mean > > 1500-3500 buffers, with I suspect it is a lot more than the hardware > > limits. So I suspect that the hardware starves free buffers a way > > before userspace, as media hardware don't have unlimited buffers > > inside them, as they assume that the Kernel/userspace will be fast > > enough to sustain bit rates up to 66 Mbps of
Aw: Re: dvb usb issues since kernel 4.9
Hi, here I provide lsusb from my affected hardware (technotrend s2-4600). http://ix.io/DLY With this hardware I had errors when recording with tvheadend. Livetv was ok, only channel switching made some problems sometimes. Please see attached tvheadend service logs. I also provide dmesg (libreelec on rpi3 with kernel 4.14.10 with revert of the mentioned commit). http://ix.io/DM2 Regards Josef Gesendet: Sonntag, 07. Januar 2018 um 16:41 Uhr Von: "Alan Stern" <st...@rowland.harvard.edu> An: "Mauro Carvalho Chehab" <mche...@s-opensource.com> Cc: "Josef Griebichler" <griebichler.jo...@gmx.at>, "Greg Kroah-Hartman" <gre...@linuxfoundation.org>, linux-usb@vger.kernel.org, "Eric Dumazet" <eduma...@google.com>, "Rik van Riel" <r...@redhat.com>, "Paolo Abeni" <pab...@redhat.com>, "Hannes Frederic Sowa" <han...@redhat.com>, "Jesper Dangaard Brouer" <jbro...@redhat.com>, linux-kernel <linux-ker...@vger.kernel.org>, netdev <net...@vger.kernel.org>, "Jonathan Corbet" <cor...@lwn.net>, LMML <linux-me...@vger.kernel.org>, "Peter Zijlstra" <pet...@infradead.org>, "David Miller" <da...@davemloft.net>, torva...@linux-foundation.org Betreff: Re: dvb usb issues since kernel 4.9 On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote: > > > It seems that the original patch were designed to solve some IRQ issues > > > with network cards with causes data losses on high traffic. However, > > > it is also causing bad effects on sustained high bandwidth demands > > > required by DVB cards, at least on some USB host drivers. > > > > > > Alan/Greg/Eric/David: > > > > > > Any ideas about how to fix it without causing regressions to > > > network? > > > > It would be good to know what hardware was involved on the x86 system > > and to have some timing data. Can we see the output from lsusb and > > usbmon, running on a vanilla kernel that gets plenty of video glitches? > > From Josef's report, and from the BZ, the affected hardware seems > to be based on Montage Technology M88DS3103/M88TS2022 chipset. What type of USB host controller does the x86_64 system use? EHCI or xHCI? > The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c, > with shares a USB implementation that is used by a lot more drivers. > The URB handling code is at: > > drivers/media/usb/dvb-usb-v2/usb_urb.c > > This particular driver allocates 8 buffers with 4096 bytes each > for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP. > > This become a popular USB hardware nowadays. I have one S960c > myself, so I can send you the lsusb from it. You should notice, however, > that a DVB-C/DVB-S2 channel can easily provide very high sustained bit > rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps > of payload after removing URB headers. You mentioned earlier that the driver uses bulk transfers. In USB-2.0, the maximum possible payload data transfer rate using bulk transfers is 53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s). And even this is possible only if almost nothing else is using the bus at the same time. > A 10 minutes record with the > entire data (with typically contains 5-10 channels) can easily go > above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if > a usbmon dump would be useful. It might not be helpful at all. However, I'm not interested in the payload data (which would be unintelligible to me anyway) but rather the timing of URB submissions and completions. A usbmon trace which didn't keep much of the payload data would only require on the order of 50 MB per minute -- and Josef said that glitches usually would show up within a minute or so. > I'm enclosing the lsusb from a S960C device, with is based on those > Montage chipsets: What I wanted to see was the output from "lsusb" on the affected system, not the output from "lsusb -v -s B:D" on your system. > > Overall, this may be a very difficult problem to solve. The > > 4cd13c21b207 commit was intended to improve throughput at the cost of > > increased latency. But then what do you do when the latency becomes > > too high for the video subsystem to handle? > > Latency can't be too high, otherwise frames will be dropped. Yes, that's the whole point. > Even if the Kernel itself doesn't drop, if the delay goes higher > than a certain threshold, userspace will need to drop, as it > should be presenting audio and video on real time. Yet, typically, > userspace will delay it by one or two seconds, with would mean > 1500-3500 buffers, with I sus
Aw: Re: dvb usb issues since kernel 4.9
Hi, thanks for adding the people involved! Yes arm and x86 are affected. Bisecting was not done by me on a x86_64 machine on mainline kernel and not raspbian kernel (https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965). In the mentioned post you also find the bisect log. I'm using a dvb-s/s2 usb tv card (technotrend s2-4600 with firmware dvb-fe-ds3103.fw, components M88DS3103, M88TS2022), so not only dvb-c is affected. Yes kernel 4.14.10 with revert of the mentioned commit works as before on kernel 4.8 with rpi3. I hope this is of some help. Regards, Josef Hi Josef, Em Sat, 6 Jan 2018 16:04:16 +0100 "Josef Griebichler" <griebichler.jo...@gmx.at> escreveu: > Hi, > > the causing commit has been identified. > After reverting commit > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882 > its working again. Just replying to me won't magically fix this. The ones that were involved on this patch should also be c/c, plus USB people. Just added them. > Please have a look into the thread > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13[https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13] > here are several users aknowledging the revert solves their issues with usb > dvb cards. I read the entire (long) thread there. In order to make easier for the others, from what I understand, the problem happens on both x86 and arm, although almost all comments there are mentioning tests with raspbian Kernel (with uses a different USB host driver than the upstream one). It happens when watching digital TV DVB-C channels, with usually means a sustained bit rate of 11 MBps to 54 MBps. The reports mention the dvbsky, with uses USB URB bulk transfers. On every several minutes (5 to 10 mins), the stream suffer "glitches" caused by frame losses. The part of the thread that contains the bisect is at: https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965[https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965] It indirectly mentions another comment on the thread with points to: https://github.com/raspberrypi/linux/issues/2134[https://github.com/raspberrypi/linux/issues/2134] There, it says that this fix part of the issues: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4] but it affects URB packet losses on a lesser extend. The main issue is really the logic changes a the core softirq logic. Using Kernel 4.14.10 on a Raspberry Pi 3 with 4cd13c2 commit reverted fixed the issue. Joseph, is the above right? Anything else to mention? Does the same issue affect also on x86 with vanilla Kernel 4.14.10? - It seems that the original patch were designed to solve some IRQ issues with network cards with causes data losses on high traffic. However, it is also causing bad effects on sustained high bandwidth demands required by DVB cards, at least on some USB host drivers. Alan/Greg/Eric/David: Any ideas about how to fix it without causing regressions to network? Regards, Mauro > Gesendet: Sonntag, 17. Dezember 2017 um 14:27 Uhr > Von: "Mauro Carvalho Chehab" <mche...@s-opensource.com> > An: "Sean Young" <s...@mess.org> > Cc: "Josef Griebichler" <griebichler.jo...@gmx.at>, lcaumo...@gmail.com, > gre...@linuxfoundation.org, linux-me...@vger.kernel.org, > linux-usb@vger.kernel.org > Betreff: Re: dvb usb issues since kernel 4.9 > Em Sun, 17 Dec 2017 12:06:37 + > Sean Young <s...@mess.org> escreveu: > > > Hi Josef, > > Em Sun, 17 Dec 2017 11:19:38 +0100 > "Josef Griebichler" <griebichler.jo...@gmx.at> escreveu: > > > > Hello Mr. Caumont, > > > > > > since switch to kernel 4.9 there are several users which have issues with > > > their usb dvb cards. > > > Some get artifacts when watching livetv, I'm getting discontinuity errors > > > in tvheadend when recording. > > > I'm using latest test build of LibreElec with kernel 4.14.6 but the > > > issues are still there. > > > There's an librelec forum thread for this topic > > > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/[https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/] > > > and also an open kernel bug > > > https://bugzilla.kernel.org/show_bug.cgi?id=197835[https://bugzilla.kernel.org/show_bug.cgi?id=197835][https://bugzi
