Re: [PATCH v3 2/3] dt-bindings: usb: renesas_usbhs: Add support for RZ/A1
On Fri, Jan 05, 2018 at 05:46:46PM -0500, Chris Brandt wrote: > Document support for RZ/A1 SoCs > > Signed-off-by: Chris Brandt> Reviewed-by: Geert Uytterhoeven > --- > v3: > * Removed "renesas,usbhs-r7s72100" Unless I am mistaken you want both renesas,usbhs-r7s72100, for the SoC and renesas,rza1-usbhs for the family[*] of SoCs (which currently only has one member upstream). Similar to the way there are per-SoC compat strings for R-Car Gen2 and Gen3 SoCs, and per-SoC family fallback compat strings to Gen2 and Gen3. The motivation for this that empirically SoC families seem to be able to share the implementation on the driver-side, so only the fallback compat strings need to be implemented in the driver by defining per-SoC compat strings we have the flexibility to implement them if differences emerge between SoCs in the same family. [*] I used the term family here to group SoCs together. I acknowledge that Renesas may not refer to them in this way. > v2: > * Added Reviewed-by > --- > Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > index 47394ab788e3..fa16d8d33815 100644 > --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > @@ -15,6 +15,7 @@ Required properties: > - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device > - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices > - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device > + - "renesas,rza1-usbhs" for RZ/A1 compatible device > > When compatible with the generic version, nodes must list the > SoC-specific version corresponding to the platform first followed > -- > 2.15.1 > > -- 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
Re: [PATCH v3 3/3] ARM: dts: r7s72100: add USB device to device tree
On Fri, Jan 05, 2018 at 05:46:47PM -0500, Chris Brandt wrote: > Add USB device support. > > Signed-off-by: Chris Brandt> Reviewed-by: Geert Uytterhoeven > --- > v3: > * Changed from "renesas,usbhs-r7s72100" to "renesas,rza1-usbhs" I think you want both. The SoC-specific compat string followed by a fallback compat string for something broader: Like this: compatible = "renesas,usbhs-r7s72100", "renesas,rza1-usbhs"; > v2: > * Node name is now generic 'usb@' > * GIC_SPI (73-32) is now just GIC_SPI 41 > * All hex number are lower case > * Added Reviewed-by > --- > arch/arm/boot/dts/r7s72100.dtsi | 20 > 1 file changed, 20 insertions(+) > > diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi > index ab9645a42eca..d94431767913 100644 > --- a/arch/arm/boot/dts/r7s72100.dtsi > +++ b/arch/arm/boot/dts/r7s72100.dtsi > @@ -667,4 +667,24 @@ > power-domains = <_clocks>; > status = "disabled"; > }; > + > + usbhs0: usb@e801 { > + compatible = "renesas,rza1-usbhs"; > + reg = <0xe801 0x1a0>; > + interrupts = ; > + clocks = <_clks R7S72100_CLK_USB0>; > + renesas,buswait = <4>; > + power-domains = <_clocks>; > + status = "disabled"; > + }; > + > + usbhs1: usb@e8207000 { > + compatible = "renesas,rza1-usbhs"; > + reg = <0xe8207000 0x1a0>; > + interrupts = ; > + clocks = <_clks R7S72100_CLK_USB1>; > + renesas,buswait = <4>; > + power-domains = <_clocks>; > + status = "disabled"; > + }; > }; > -- > 2.15.1 > > -- 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
Re: [PATCH v3 3/3] ARM: dts: r7s72100: add USB device to device tree
On Fri, Jan 5, 2018 at 11:46 PM, Chris Brandtwrote: > Add USB device support. > > Signed-off-by: Chris Brandt > Reviewed-by: Geert Uytterhoeven > --- > v3: > * Changed from "renesas,usbhs-r7s72100" to "renesas,rza1-usbhs" Please use both, cfr. my reply to the cover letter. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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
Re: [PATCH v3 0/3] usb: renesas_usbhs: Add RZ/A1 support
Hi Chris, On Fri, Jan 5, 2018 at 11:46 PM, Chris Brandtwrote: > This series adds RZ/A1 gadget support to the renesas_usbhs driver. > Basically, it's almost the same HW as the R-Car (and SH) parts. > The only real difference is the some extra registers for the PHY. > > This was tested on an RSK board by connecting to a PC as an > Ethernet CDC gadget. > > v3: > * Changed from "renesas,usbhs-r7s72100" to "renesas,rza1-usbhs" > * Removed "renesas,usbhs-r7s72100" > * Changed License of rza.c Thanks for the update, but I think there has been a misunderstanding. I didn't mean to drop "renesas,usbhs-r7s72100" everywhere, only from the matching in the driver. Summarized: 1. DT bindings should document _all_ compatible values (SoC-specific, and/or family-specific, generic, ...), 2. DTS should list _all applicable_ compatible values, ordered from most-specific to least-specific, 3. Drivers should match against the least-specific compatible value to get the job done. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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
Re: [PATCH v3 2/3] dt-bindings: usb: renesas_usbhs: Add support for RZ/A1
Hi Chris, On Fri, Jan 5, 2018 at 11:46 PM, Chris Brandtwrote: > Document support for RZ/A1 SoCs > > Signed-off-by: Chris Brandt > Reviewed-by: Geert Uytterhoeven > --- > v3: > * Removed "renesas,usbhs-r7s72100" Please don't, cfr. my reply to the cover letter. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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
Re: kernel BUG at ./include/linux/mm.h:LINE! (3)
On Fri, 29 Dec 2017 16:24:20 +0300 "Kirill A. Shutemov"wrote: > Looks like MON_IOCT_RING_SIZE reallocates ring buffer without any > serialization wrt mon_bin_vma_fault(). By the time of get_page() the page > may be freed. As an update: I tried to make a smaller test for this, but was unsuccessful so far. I'll poke a bit at it later, but it may take me some time. -- Pete -- 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
Re: [PATCH v4 14/16] phy: Add USB speed related PHY modes
Hi, On 1/5/2018 4:31 PM, Kishon Vijay Abraham I wrote: >> +enum phy_mode phy_get_mode(struct phy *phy) >> +{ >> +enum phy_mode ret; >> + >> +if (!phy || !phy->ops->get_mode) >> +return PHY_MODE_INVALID; >> + >> +mutex_lock(>mutex); >> +ret = phy->ops->get_mode(phy); > Since get_mode only has to return the phy mode, there is no need for an ops > here. Just add phy_mode in phy_attrs in set_mode and return it here. Sure, will re-send patch set with this change. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
Re: [PATCH] USB: ohci: da8xx: remove clk con_id
On 01/05/2018 07:53 PM, David Lechner wrote: The ohci-da8xx device only has one clock, so a con_id is not needed, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner--- superseded by https://marc.info/?l=linux-usb=151529526103513=2 -- 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
Re: [PATCH] USB: musb: da8xx: remove clock con_id
On 01/05/2018 07:50 PM, David Lechner wrote: There is only one clock for the DA8xx MUSB device, so we don't need the con_id, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner--- superseded by https://marc.info/?l=linux-usb=151529526103513=2 -- 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
Re: dvb usb issues since kernel 4.9
On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehabwrote: > > Em Sat, 6 Jan 2018 16:04:16 +0100 > "Josef Griebichler" escreveu: >> >> 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. Actually, you seem to have added an odd subset of the people involved. For example, Ingo - who actually committed that patch - wasn't on the cc. I do think we need to simply revert that patch. It's very simple: it has been reported to lead to actual problems for people, and we don't fix one problem and then say "well, it fixed something else" when something breaks. When something breaks, we either unbreak it, or we revert the change that caused the breakage. It's really that simple. That's what "no regressions" means. We don't accept changes that cause regressions. This one did. Linus -- 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, 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"An: "Mauro Carvalho Chehab" Cc: "Josef Griebichler" , "Greg Kroah-Hartman" , linux-usb@vger.kernel.org, "Eric Dumazet" , "Rik van Riel" , "Paolo Abeni" , "Hannes Frederic Sowa" , "Jesper Dangaard Brouer" , linux-kernel , netdev , "Jonathan Corbet" , LMML , "Peter Zijlstra" , "David Miller" , 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 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 payload. The timing information would tell us how large the latency is. In any case, you might be able to attack the problem simply by using more than 8
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 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 payload. The timing information would tell us how large the latency is. In any case, you might be able to attack the problem simply by using more than 8 buffers. With just eight 4096-byte buffers, the total pipeline capacity is only about 0.62 ms (at the maximum possible transfer rate). Increasing the number of buffers to 65 would give a capacity of 5 ms, which is probably a lot better suited for situations where completions are handled by the ksoftirqd thread. > Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP, > in order to revert the kernel logic to prioritize latency instead of > throughput. It can't be done without pervasive changes to the USB subsystem, which I would greatly prefer to avoid. Besides, this wouldn't really solve the problem. Decreasing the latency for one device will cause it to be increased for others. 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
Re: [RFC] Re: usb: gadget: ffs: Fix BUG when userland exits with submitted AIO transfers
On Fri, 1 Dec 2017 00:14:52 +, Vincent Pelletierwrote: > I'll play some more with a kernel with this patch > to see if it breaks, and will resubmit if it looks fine. Some update: this patch looks good on DWC3: both unplugging and unbinding the UDC while AOI transfers are queued works fine. What I intended to do is to also test it on DWC2, so I bought a raspberry pi zero W (ie, with embedded wifi chip on SDIO), but the fail is strong with me and I just cannot get a custom kernel build to boot (blocks right after detecting mmc0 & mmc1 and listing MMC partitions), so I could not extend my tests yet. I'll keep trying, but testers with a DWC2 or other UDC are very welcome to give that patch a try. To help with tests, here is my test scenario: On both sides: $ git clone https://github.com/vpelletier/python-functionfs.git $ mkdir venv $ virtualenv venv/ $ cd python-functionfs/ $ ../venv/bin/python setup.py install On gadget only: $ cd .. $ sudo aptitude install libaio1 $ git clone https://github.com/vpelletier/python-libaio.git $ cd python-libaio/ $ ../venv/bin/python setup.py install Create a gadget device. My cheat sheet: https://github.com/vpelletier/python-functionfs/tree/master/functionfs/tests On gadget: $ python -u slowprinter.py | venv/bin/python -u device.py /path/to/ffs_mountpoint On host (re-run after disconnects, scripts come from python-functionfs repository): $ python -u slowprinter.py | venv/bin/python -u host.py Plus udev rules to grant current host user access to the usb device. Each side should print the time from other side every second, plus some tracing blather. Test passes if gadget kernel is happy after multiple unplug/plug cycles and both ends can still communicate after re-plugging and restarting host script. Regards, -- Vincent Pelletier -- 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
Re: dvb usb issues since kernel 4.9
Em Sat, 6 Jan 2018 16:44:20 -0500 (EST) Alan Sternescreveu: > On Sat, 6 Jan 2018, Mauro Carvalho Chehab wrote: > > > Hi Josef, > > > > Em Sat, 6 Jan 2018 16:04:16 +0100 > > "Josef Griebichler" 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 > > > 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 > > > > It indirectly mentions another comment on the thread with points > > to: > > 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 > > > > 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? > > 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. 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. 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. I'm enclosing the lsusb from a S960C device, with is based on those Montage chipsets: Bus 002 Device 007: ID 0572:960c Conexant Systems (Rockwell), Inc. DVBSky S960C DVB-S2 tuner Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0572 Conexant Systems (Rockwell), Inc. idProduct 0x960c DVBSky S960C DVB-S2 tuner bcdDevice0.00 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 219 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4