LinuxTV firmware blocks all wireless connections / traffic

LinuxTV firmware blocks all wireless connections / traffic

[Clinton Meyer]

Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV.

Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE
3.5.10, kernel 2.6.27-1-mepis-smp

All three machines now have wireless blocked, either do not connect or
all packets dropped/blocked if a connection is made.

Used the resources from LinuxTV (dot) org

to get it working, they are referenced and posted as follows:
 linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware

******** *********** **********
 Quote:
In order to use the LinuxTV driver, you need to download and install
the firmware for the xc5000.

Quote:
wget  ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip
wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh
 sh extract (dot) sh
cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware
:Unquote

Note: Though the usual directory location in which the firmware file
is placed is /lib/firmware, this may differ in the case of some
distros; consult your distro's documentation for the appropriate
location.

The firmware will be added lazily (on-demand) when you first use the driver.
Drivers

The xc5000 driver needed for this WinTV-HVR-950Q is already part of
the latest Linux kernel (part of v4l-dvb drivers).

Analog support was merged into the mainline v4l-dvb tree on March 18, 2009.
:Unquote
******** *********** ********** ******** *********** **********
So on Saturday I got this up and running... and Sunday morning
recorded one show successfully that had set up on a timer.

Then set up three consecutive shows for the afternoon.
They were all part of a series on the same channel. Here are the results:

    * Show A, 2.5 hours long, 13.2gb file size, appears to be OK.
    * Show B, 2.0 hours long, 3.7gb file size, appears to be OK.
     * Show C, supposed to be 2.0 hours long, result was 2.7gb file
size, about the first hour is missing.

At about this point, I lost wireless internet connectivity on TV
recording laptop. Machine sees the access point, but won't connect.

Went to my main desktop where i had first worked with this Hauppauge
WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost
internet, even though it was right next to AP and got a very good
signal.

Thought it was maybe the AP, so switched it out for a working spare.
 Same results.
Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD
and an 8.06 Live USB stick and hit the road to go to a reliable high
speed wifi spot.
Same results... changins ISPs resulted in the same issues.
 Also same ting happened with the spare laptop, an IBM T43 Thinkpad I
had also done the "wget ... steventoth (dot)
net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip"
firmware thing to.

Was able to get one machine, while running a LIVE USB session, to
connect, but zero packets received.. ALL were blocked. The connection
information said ALL packets were dropped.
 None of the two other machines connected to wireless on a LiveCD or
LiveUSB thing too
Three machines. All different brands (HP, Dell, and IBM) with
different wifi cards. All three see the access point ESSID, but none
connect.

This does not *feel* good. What got flashed? Can this be resolved?

Came home. No difference. Grabbed a laptop that i had NOT done the
firmware thing to and that is what I am using to write this. Hooked
right up to the AP.

Please help... that is too much hardware disabled for me to think calmly.
I'd really like to make the USB tv tuner work... what a great way to
PVR / DVR, but I need wireless.

Can provide any details requested to drive this towards a fix!

Thank you,
Clinton

Re: LinuxTV firmware blocks all wireless connections / traffic

[Devin Heitmueller]

On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyer<clintonmeyer22@gmail.com> wrote:
> Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV.
>
> Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE
> 3.5.10, kernel 2.6.27-1-mepis-smp
>
> All three machines now have wireless blocked, either do not connect or
> all packets dropped/blocked if a connection is made.
>
> Used the resources from LinuxTV (dot) org
>
> to get it working, they are referenced and posted as follows:
>  linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware
>
> ******** *********** **********
>  Quote:
> In order to use the LinuxTV driver, you need to download and install
> the firmware for the xc5000.
>
> Quote:
> wget  ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip
> wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh
>  sh extract (dot) sh
> cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware
> :Unquote
>
> Note: Though the usual directory location in which the firmware file
> is placed is /lib/firmware, this may differ in the case of some
> distros; consult your distro's documentation for the appropriate
> location.
>
> The firmware will be added lazily (on-demand) when you first use the driver.
> Drivers
>
> The xc5000 driver needed for this WinTV-HVR-950Q is already part of
> the latest Linux kernel (part of v4l-dvb drivers).
>
> Analog support was merged into the mainline v4l-dvb tree on March 18, 2009.
> :Unquote
> ******** *********** ********** ******** *********** **********
> So on Saturday I got this up and running... and Sunday morning
> recorded one show successfully that had set up on a timer.
>
> Then set up three consecutive shows for the afternoon.
> They were all part of a series on the same channel. Here are the results:
>
>     * Show A, 2.5 hours long, 13.2gb file size, appears to be OK.
>     * Show B, 2.0 hours long, 3.7gb file size, appears to be OK.
>      * Show C, supposed to be 2.0 hours long, result was 2.7gb file
> size, about the first hour is missing.
>
> At about this point, I lost wireless internet connectivity on TV
> recording laptop. Machine sees the access point, but won't connect.
>
> Went to my main desktop where i had first worked with this Hauppauge
> WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost
> internet, even though it was right next to AP and got a very good
> signal.
>
> Thought it was maybe the AP, so switched it out for a working spare.
>  Same results.
> Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD
> and an 8.06 Live USB stick and hit the road to go to a reliable high
> speed wifi spot.
> Same results... changins ISPs resulted in the same issues.
>  Also same ting happened with the spare laptop, an IBM T43 Thinkpad I
> had also done the "wget ... steventoth (dot)
> net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip"
> firmware thing to.
>
> Was able to get one machine, while running a LIVE USB session, to
> connect, but zero packets received.. ALL were blocked. The connection
> information said ALL packets were dropped.
>  None of the two other machines connected to wireless on a LiveCD or
> LiveUSB thing too
> Three machines. All different brands (HP, Dell, and IBM) with
> different wifi cards. All three see the access point ESSID, but none
> connect.
>
> This does not *feel* good. What got flashed? Can this be resolved?
>
> Came home. No difference. Grabbed a laptop that i had NOT done the
> firmware thing to and that is what I am using to write this. Hooked
> right up to the AP.
>
> Please help... that is too much hardware disabled for me to think calmly.
> I'd really like to make the USB tv tuner work... what a great way to
> PVR / DVR, but I need wireless.
>
> Can provide any details requested to drive this towards a fix!
>
> Thank you,
> Clinton
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Hello Clinton,

That is indeed curious.  It's hard to imagine how there could be
interference between the V4L subsystem and the wireless subsystem,
short of hitting some sort of timing condition on crappy wireless
drivers.

Here are a few questions:

1.  You specified you followed the instructions for the firmware, but
are you running the current v4l-dvb code, or are you just using
whatever came with your Debian kernel?  If you're actually using the
1.1 Xceive firmware, I'm assuming you're still using the old code.

2.  How reproducible is this?  Does it occur even if the device is
connected but you do not attempt any capturing with the device?  Does
it always drop out while capturing?

3.  What type of wireless cards are you using?  Are they implemented
over PCI, or USB?  If the wireless cards are USB based, perhaps there
is some sort of USB bandwidth issue.

4.  Are you actively watching the programs you are capturing?  Or are
you just saving the content to disk?  What application are you using
to capture the ATSC video?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Wed, Sep 09, 2009 at 05:59:07PM -0400, Devin Heitmueller wrote:
> On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyer<clintonmeyer22@gmail.com> wrote:
> > Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV.
> >
> > Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE
> > 3.5.10, kernel 2.6.27-1-mepis-smp
> >
> > All three machines now have wireless blocked, either do not connect or
> > all packets dropped/blocked if a connection is made.
> >
> > Used the resources from LinuxTV (dot) org
> >
> > to get it working, they are referenced and posted as follows:
> >  linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware
> >
> > ******** *********** **********
> >  Quote:
> > In order to use the LinuxTV driver, you need to download and install
> > the firmware for the xc5000.
> >
> > Quote:
> > wget  ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip
> > wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh
> >  sh extract (dot) sh
> > cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware
> > :Unquote
> >
> > Note: Though the usual directory location in which the firmware file
> > is placed is /lib/firmware, this may differ in the case of some
> > distros; consult your distro's documentation for the appropriate
> > location.
> >
> > The firmware will be added lazily (on-demand) when you first use the driver.
> > Drivers
> >
> > The xc5000 driver needed for this WinTV-HVR-950Q is already part of
> > the latest Linux kernel (part of v4l-dvb drivers).
> >
> > Analog support was merged into the mainline v4l-dvb tree on March 18, 2009.
> > :Unquote
> > ******** *********** ********** ******** *********** **********
> > So on Saturday I got this up and running... and Sunday morning
> > recorded one show successfully that had set up on a timer.
> >
> > Then set up three consecutive shows for the afternoon.
> > They were all part of a series on the same channel. Here are the results:
> >
> >     * Show A, 2.5 hours long, 13.2gb file size, appears to be OK.
> >     * Show B, 2.0 hours long, 3.7gb file size, appears to be OK.
> >      * Show C, supposed to be 2.0 hours long, result was 2.7gb file
> > size, about the first hour is missing.
> >
> > At about this point, I lost wireless internet connectivity on TV
> > recording laptop. Machine sees the access point, but won't connect.
> >
> > Went to my main desktop where i had first worked with this Hauppauge
> > WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost
> > internet, even though it was right next to AP and got a very good
> > signal.
> >
> > Thought it was maybe the AP, so switched it out for a working spare.
> >  Same results.
> > Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD
> > and an 8.06 Live USB stick and hit the road to go to a reliable high
> > speed wifi spot.
> > Same results... changins ISPs resulted in the same issues.
> >  Also same ting happened with the spare laptop, an IBM T43 Thinkpad I
> > had also done the "wget ... steventoth (dot)
> > net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip"
> > firmware thing to.
> >
> > Was able to get one machine, while running a LIVE USB session, to
> > connect, but zero packets received.. ALL were blocked. The connection
> > information said ALL packets were dropped.
> >  None of the two other machines connected to wireless on a LiveCD or
> > LiveUSB thing too
> > Three machines. All different brands (HP, Dell, and IBM) with
> > different wifi cards. All three see the access point ESSID, but none
> > connect.
> >
> > This does not *feel* good. What got flashed? Can this be resolved?
> >
> > Came home. No difference. Grabbed a laptop that i had NOT done the
> > firmware thing to and that is what I am using to write this. Hooked
> > right up to the AP.
> >
> > Please help... that is too much hardware disabled for me to think calmly.
> > I'd really like to make the USB tv tuner work... what a great way to
> > PVR / DVR, but I need wireless.
> >
> > Can provide any details requested to drive this towards a fix!
> >
> > Thank you,
> > Clinton
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> Hello Clinton,
> 
> That is indeed curious.  It's hard to imagine how there could be
> interference between the V4L subsystem and the wireless subsystem,
> short of hitting some sort of timing condition on crappy wireless
> drivers.
> 
> Here are a few questions:
> 
> 1.  You specified you followed the instructions for the firmware, but
> are you running the current v4l-dvb code, or are you just using
> whatever came with your Debian kernel?  If you're actually using the
> 1.1 Xceive firmware, I'm assuming you're still using the old code.
> 
> 2.  How reproducible is this?  Does it occur even if the device is
> connected but you do not attempt any capturing with the device?  Does
> it always drop out while capturing?
> 
> 3.  What type of wireless cards are you using?  Are they implemented
> over PCI, or USB?  If the wireless cards are USB based, perhaps there
> is some sort of USB bandwidth issue.
> 
> 4.  Are you actively watching the programs you are capturing?  Or are
> you just saving the content to disk?  What application are you using
> to capture the ATSC video?
> 
> Devin
> 
> -- 
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Not sure if its the same issue, but on some USB chipsets/motherboards there
definitely are problems with two or more bandwidth-demanding cards like
tuners, wireless sticks, etc. Either its a dvb-usb subsystem issue or lower
level usb problem, who knows.

See this for details, very similar case: usb wifi dongle + usb digital tuner.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/256492

My problem also described in that bug report, got all the hardware and 100%
reproducible situation, would be nice if somebody helps to debug it.

Re: LinuxTV firmware blocks all wireless connections / traffic

[Markus Rechberger]

On Thu, Sep 10, 2009 at 11:14 AM, Aleksandr V. Piskunov
<aleksandr.v.piskunov@gmail.com> wrote:
> On Wed, Sep 09, 2009 at 05:59:07PM -0400, Devin Heitmueller wrote:
>> On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyer<clintonmeyer22@gmail.com> wrote:
>> > Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV.
>> >
>> > Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE
>> > 3.5.10, kernel 2.6.27-1-mepis-smp
>> >
>> > All three machines now have wireless blocked, either do not connect or
>> > all packets dropped/blocked if a connection is made.
>> >
>> > Used the resources from LinuxTV (dot) org
>> >
>> > to get it working, they are referenced and posted as follows:
>> >  linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware
>> >
>> > ******** *********** **********
>> >  Quote:
>> > In order to use the LinuxTV driver, you need to download and install
>> > the firmware for the xc5000.
>> >
>> > Quote:
>> > wget  ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip
>> > wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh
>> >  sh extract (dot) sh
>> > cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware
>> > :Unquote
>> >
>> > Note: Though the usual directory location in which the firmware file
>> > is placed is /lib/firmware, this may differ in the case of some
>> > distros; consult your distro's documentation for the appropriate
>> > location.
>> >
>> > The firmware will be added lazily (on-demand) when you first use the driver.
>> > Drivers
>> >
>> > The xc5000 driver needed for this WinTV-HVR-950Q is already part of
>> > the latest Linux kernel (part of v4l-dvb drivers).
>> >
>> > Analog support was merged into the mainline v4l-dvb tree on March 18, 2009.
>> > :Unquote
>> > ******** *********** ********** ******** *********** **********
>> > So on Saturday I got this up and running... and Sunday morning
>> > recorded one show successfully that had set up on a timer.
>> >
>> > Then set up three consecutive shows for the afternoon.
>> > They were all part of a series on the same channel. Here are the results:
>> >
>> >     * Show A, 2.5 hours long, 13.2gb file size, appears to be OK.
>> >     * Show B, 2.0 hours long, 3.7gb file size, appears to be OK.
>> >      * Show C, supposed to be 2.0 hours long, result was 2.7gb file
>> > size, about the first hour is missing.
>> >
>> > At about this point, I lost wireless internet connectivity on TV
>> > recording laptop. Machine sees the access point, but won't connect.
>> >
>> > Went to my main desktop where i had first worked with this Hauppauge
>> > WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost
>> > internet, even though it was right next to AP and got a very good
>> > signal.
>> >
>> > Thought it was maybe the AP, so switched it out for a working spare.
>> >  Same results.
>> > Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD
>> > and an 8.06 Live USB stick and hit the road to go to a reliable high
>> > speed wifi spot.
>> > Same results... changins ISPs resulted in the same issues.
>> >  Also same ting happened with the spare laptop, an IBM T43 Thinkpad I
>> > had also done the "wget ... steventoth (dot)
>> > net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip"
>> > firmware thing to.
>> >
>> > Was able to get one machine, while running a LIVE USB session, to
>> > connect, but zero packets received.. ALL were blocked. The connection
>> > information said ALL packets were dropped.
>> >  None of the two other machines connected to wireless on a LiveCD or
>> > LiveUSB thing too
>> > Three machines. All different brands (HP, Dell, and IBM) with
>> > different wifi cards. All three see the access point ESSID, but none
>> > connect.
>> >
>> > This does not *feel* good. What got flashed? Can this be resolved?
>> >
>> > Came home. No difference. Grabbed a laptop that i had NOT done the
>> > firmware thing to and that is what I am using to write this. Hooked
>> > right up to the AP.
>> >
>> > Please help... that is too much hardware disabled for me to think calmly.
>> > I'd really like to make the USB tv tuner work... what a great way to
>> > PVR / DVR, but I need wireless.
>> >
>> > Can provide any details requested to drive this towards a fix!
>> >
>> > Thank you,
>> > Clinton
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>>
>> Hello Clinton,
>>
>> That is indeed curious.  It's hard to imagine how there could be
>> interference between the V4L subsystem and the wireless subsystem,
>> short of hitting some sort of timing condition on crappy wireless
>> drivers.
>>
>> Here are a few questions:
>>
>> 1.  You specified you followed the instructions for the firmware, but
>> are you running the current v4l-dvb code, or are you just using
>> whatever came with your Debian kernel?  If you're actually using the
>> 1.1 Xceive firmware, I'm assuming you're still using the old code.
>>
>> 2.  How reproducible is this?  Does it occur even if the device is
>> connected but you do not attempt any capturing with the device?  Does
>> it always drop out while capturing?
>>
>> 3.  What type of wireless cards are you using?  Are they implemented
>> over PCI, or USB?  If the wireless cards are USB based, perhaps there
>> is some sort of USB bandwidth issue.
>>
>> 4.  Are you actively watching the programs you are capturing?  Or are
>> you just saving the content to disk?  What application are you using
>> to capture the ATSC video?
>>
>> Devin
>>
>> --
>> Devin J. Heitmueller - Kernel Labs
>> http://www.kernellabs.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Not sure if its the same issue, but on some USB chipsets/motherboards there
> definitely are problems with two or more bandwidth-demanding cards like
> tuners, wireless sticks, etc. Either its a dvb-usb subsystem issue or lower
> level usb problem, who knows.
>
> See this for details, very similar case: usb wifi dongle + usb digital tuner.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/256492
>
> My problem also described in that bug report, got all the hardware and 100%
> reproducible situation, would be nice if somebody helps to debug it.

can you also test this with Windows on the same board?

So far I got one report about the Zotac ION Board having such issues
although I'm
quite sure to be able to fix up that issue on it. I hope I won't have
to deal with
further boards...

Best Regards,
Markus

Re: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Thu, Sep 10, 2009 at 12:58:07PM +0200, Markus Rechberger wrote:
> On Thu, Sep 10, 2009 at 11:14 AM, Aleksandr V. Piskunov
> <aleksandr.v.piskunov@gmail.com> wrote:
> > On Wed, Sep 09, 2009 at 05:59:07PM -0400, Devin Heitmueller wrote:
> >> On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyer<clintonmeyer22@gmail.com> wrote:
> >> > Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV.
> >> >
> >> > Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE
> >> > 3.5.10, kernel 2.6.27-1-mepis-smp
> >> >
> >> > All three machines now have wireless blocked, either do not connect or
> >> > all packets dropped/blocked if a connection is made.
> >> >
> >> > Used the resources from LinuxTV (dot) org
> >> >
> >> > to get it working, they are referenced and posted as follows:
> >> >  linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware
> >> >
> >> > ******** *********** **********
> >> >  Quote:
> >> > In order to use the LinuxTV driver, you need to download and install
> >> > the firmware for the xc5000.
> >> >
> >> > Quote:
> >> > wget  ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip
> >> > wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh
> >> >  sh extract (dot) sh
> >> > cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware
> >> > :Unquote
> >> >
> >> > Note: Though the usual directory location in which the firmware file
> >> > is placed is /lib/firmware, this may differ in the case of some
> >> > distros; consult your distro's documentation for the appropriate
> >> > location.
> >> >
> >> > The firmware will be added lazily (on-demand) when you first use the driver.
> >> > Drivers
> >> >
> >> > The xc5000 driver needed for this WinTV-HVR-950Q is already part of
> >> > the latest Linux kernel (part of v4l-dvb drivers).
> >> >
> >> > Analog support was merged into the mainline v4l-dvb tree on March 18, 2009.
> >> > :Unquote
> >> > ******** *********** ********** ******** *********** **********
> >> > So on Saturday I got this up and running... and Sunday morning
> >> > recorded one show successfully that had set up on a timer.
> >> >
> >> > Then set up three consecutive shows for the afternoon.
> >> > They were all part of a series on the same channel. Here are the results:
> >> >
> >> >     * Show A, 2.5 hours long, 13.2gb file size, appears to be OK.
> >> >     * Show B, 2.0 hours long, 3.7gb file size, appears to be OK.
> >> >      * Show C, supposed to be 2.0 hours long, result was 2.7gb file
> >> > size, about the first hour is missing.
> >> >
> >> > At about this point, I lost wireless internet connectivity on TV
> >> > recording laptop. Machine sees the access point, but won't connect.
> >> >
> >> > Went to my main desktop where i had first worked with this Hauppauge
> >> > WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost
> >> > internet, even though it was right next to AP and got a very good
> >> > signal.
> >> >
> >> > Thought it was maybe the AP, so switched it out for a working spare.
> >> >  Same results.
> >> > Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD
> >> > and an 8.06 Live USB stick and hit the road to go to a reliable high
> >> > speed wifi spot.
> >> > Same results... changins ISPs resulted in the same issues.
> >> >  Also same ting happened with the spare laptop, an IBM T43 Thinkpad I
> >> > had also done the "wget ... steventoth (dot)
> >> > net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip"
> >> > firmware thing to.
> >> >
> >> > Was able to get one machine, while running a LIVE USB session, to
> >> > connect, but zero packets received.. ALL were blocked. The connection
> >> > information said ALL packets were dropped.
> >> >  None of the two other machines connected to wireless on a LiveCD or
> >> > LiveUSB thing too
> >> > Three machines. All different brands (HP, Dell, and IBM) with
> >> > different wifi cards. All three see the access point ESSID, but none
> >> > connect.
> >> >
> >> > This does not *feel* good. What got flashed? Can this be resolved?
> >> >
> >> > Came home. No difference. Grabbed a laptop that i had NOT done the
> >> > firmware thing to and that is what I am using to write this. Hooked
> >> > right up to the AP.
> >> >
> >> > Please help... that is too much hardware disabled for me to think calmly.
> >> > I'd really like to make the USB tv tuner work... what a great way to
> >> > PVR / DVR, but I need wireless.
> >> >
> >> > Can provide any details requested to drive this towards a fix!
> >> >
> >> > Thank you,
> >> > Clinton
> >> > --
> >> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> >> > the body of a message to majordomo@vger.kernel.org
> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> >
> >>
> >> Hello Clinton,
> >>
> >> That is indeed curious.  It's hard to imagine how there could be
> >> interference between the V4L subsystem and the wireless subsystem,
> >> short of hitting some sort of timing condition on crappy wireless
> >> drivers.
> >>
> >> Here are a few questions:
> >>
> >> 1.  You specified you followed the instructions for the firmware, but
> >> are you running the current v4l-dvb code, or are you just using
> >> whatever came with your Debian kernel?  If you're actually using the
> >> 1.1 Xceive firmware, I'm assuming you're still using the old code.
> >>
> >> 2.  How reproducible is this?  Does it occur even if the device is
> >> connected but you do not attempt any capturing with the device?  Does
> >> it always drop out while capturing?
> >>
> >> 3.  What type of wireless cards are you using?  Are they implemented
> >> over PCI, or USB?  If the wireless cards are USB based, perhaps there
> >> is some sort of USB bandwidth issue.
> >>
> >> 4.  Are you actively watching the programs you are capturing?  Or are
> >> you just saving the content to disk?  What application are you using
> >> to capture the ATSC video?
> >>
> >> Devin
> >>
> >> --
> >> Devin J. Heitmueller - Kernel Labs
> >> http://www.kernellabs.com
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> > Not sure if its the same issue, but on some USB chipsets/motherboards there
> > definitely are problems with two or more bandwidth-demanding cards like
> > tuners, wireless sticks, etc. Either its a dvb-usb subsystem issue or lower
> > level usb problem, who knows.
> >
> > See this for details, very similar case: usb wifi dongle + usb digital tuner.
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/256492
> >
> > My problem also described in that bug report, got all the hardware and 100%
> > reproducible situation, would be nice if somebody helps to debug it.
> 
> can you also test this with Windows on the same board?
> 
> So far I got one report about the Zotac ION Board having such issues
> although I'm
> quite sure to be able to fix up that issue on it. I hope I won't have
> to deal with
> further boards...
> 

Yes, works without a glitch under Windows on the very same board.

Here is a test case:
Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners,
different demods, different bridges, etc.
Motherboard GA-MA78GM-S2H with AMD SB700 USB chipset, 2 controllers 6 ports each.
Both tuners streaming full 24mbit/s DVB-T transponder.

Now if both tuners are connected to the same USB controller, silent corruption
of TS stream occurs (a lot of random noise in picture, continuity errors, etc),
sometimes with bulk message and read register errors in kernel log. Both tuners
report decent SNR and signal, no problem with reception.

If one tuner is connected to first set of USB ports (controller #1) and another to
second set (controller #2), then both tuners work as expected, no corruption.

Same two tuners tested on the same board under windows, streaming full transponder
using VLC and BDA drivers: everything is perfect no matter what USB ports/controllers
used.

Same two tuners tested on laptop, ICH8 or ICH9 chipset, cant really remember. Everything
fine under both Linux and Windows, any combination of USB ports/controllers.

Re: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

> 
> Here is a test case:
> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners,

Err, make it: dvb_usb_af9015 and dvb_usb_ce6230

Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari]

Aleksandr V. Piskunov wrote:
>> Here is a test case:
>> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners,
> 
> Err, make it: dvb_usb_af9015 and dvb_usb_ce6230

Those both uses currently too small bulk urbs, only 512 bytes. I have 
asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one 
have answered yet (search ml back week or two). I think will increase 
those to the 8k to reduce load.

Antti
-- 
http://palosaari.fi/

Re: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote:
> Aleksandr V. Piskunov wrote:
>>> Here is a test case:
>>> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners,
>>
>> Err, make it: dvb_usb_af9015 and dvb_usb_ce6230
>
> Those both uses currently too small bulk urbs, only 512 bytes. I have  
> asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one  
> have answered yet (search ml back week or two). I think will increase  
> those to the 8k to reduce load.
>

Nice, I'm ready to test if such change helps.

Does USB subsystem provide any way to monitor current raw USB data transfer rate?

Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari]

Aleksandr V. Piskunov wrote:
> On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote:
>> Aleksandr V. Piskunov wrote:
>>>> Here is a test case:
>>>> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners,
>>> Err, make it: dvb_usb_af9015 and dvb_usb_ce6230
>> Those both uses currently too small bulk urbs, only 512 bytes. I have  
>> asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one  
>> have answered yet (search ml back week or two). I think will increase  
>> those to the 8k to reduce load.
>>
> 
> Nice, I'm ready to test if such change helps.

OK, I will make test version in couple of hours.

> Does USB subsystem provide any way to monitor current raw USB data transfer rate?

I don't if there is tool for raw data analysis, but for DVB devices you 
can use dvbtraffic tool.

Antti
-- 
http://palosaari.fi/

Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari]

On 09/10/2009 04:47 PM, Antti Palosaari wrote:
> Aleksandr V. Piskunov wrote:
>> On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote:
>>> Aleksandr V. Piskunov wrote:
>>>>> Here is a test case:
>>>>> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015.
>>>>> Different tuners,
>>>> Err, make it: dvb_usb_af9015 and dvb_usb_ce6230
>>> Those both uses currently too small bulk urbs, only 512 bytes. I have
>>> asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but
>>> no-one have answered yet (search ml back week or two). I think will
>>> increase those to the 8k to reduce load.
>>>
>>
>> Nice, I'm ready to test if such change helps.
>
> OK, I will make test version in couple of hours.

Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
Now powertop shows only about 220 wakeups on my computer for the both 
sticks.
Please test and tell what powertop says:
http://linuxtv.org/hg/~anttip/urb_size/

I wonder if we can decide what URB size DVB USB drivers should follow 
and even add new module param for overriding driver default.

Antti
-- 
http://palosaari.fi/

Re: LinuxTV firmware blocks all wireless connections / traffic

[Devin Heitmueller]

On Thu, Sep 10, 2009 at 10:48 AM, Antti Palosaari<crope@iki.fi> wrote:
> Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
> Now powertop shows only about 220 wakeups on my computer for the both
> sticks.
> Please test and tell what powertop says:
> http://linuxtv.org/hg/~anttip/urb_size/
>
> I wonder if we can decide what URB size DVB USB drivers should follow and
> even add new module param for overriding driver default.
>
> Antti
> --
> http://palosaari.fi/
>

Hello Antti,

The URB size is something that varies on a device-by-device basis,
depending on the bridge chipset.   There really is no
"one-size-fits-all" value you can assume.

I usually take a look at a USB trace of the device under Windows, and
then use the same value.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari]

Devin Heitmueller wrote:
> The URB size is something that varies on a device-by-device basis,
> depending on the bridge chipset.   There really is no
> "one-size-fits-all" value you can assume.

I doubt no. I tested last week rather many USB chips and all I tested 
allowed to set it as x188 or x512 bytes. If it is set something than 
chip does not like it will give errors or packets that are not as large 
as requested. You can test that easily, look dvb-usb module debug uxfer 
and use powertop.

> I usually take a look at a USB trace of the device under Windows, and
> then use the same value.

I have seen logs where different sizes of urbs used even same chip.

regards
Antti
-- 
http://palosaari.fi/

Re: LinuxTV firmware blocks all wireless connections / traffic

[Devin Heitmueller]

On Thu, Sep 10, 2009 at 11:55 AM, Antti Palosaari<crope@iki.fi> wrote:
> Devin Heitmueller wrote:
>>
>> The URB size is something that varies on a device-by-device basis,
>> depending on the bridge chipset.   There really is no
>> "one-size-fits-all" value you can assume.
>
> I doubt no. I tested last week rather many USB chips and all I tested
> allowed to set it as x188 or x512 bytes. If it is set something than chip
> does not like it will give errors or packets that are not as large as
> requested. You can test that easily, look dvb-usb module debug uxfer and use
> powertop.
>
>> I usually take a look at a USB trace of the device under Windows, and
>> then use the same value.
>
> I have seen logs where different sizes of urbs used even same chip.

Yes, the URB size can change depending on who wrote the driver, or
what the required throughput is.  For example, the em28xx has a
different URB size depending on whether the target application is
19Mbps ATSC or 38Mbps QAM.  That just reinforces what I'm saying - the
size selected in many cases is determined by the requirements of the
chipset.

Making it some multiple of 188 for DVB is logical since that's the
MPEG packet size.  That seems pretty common in the bridges I have
worked with.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari]

Devin Heitmueller wrote:
> On Thu, Sep 10, 2009 at 11:55 AM, Antti Palosaari<crope@iki.fi> wrote:
>> Devin Heitmueller wrote:
>>> The URB size is something that varies on a device-by-device basis,
>>> depending on the bridge chipset.   There really is no
>>> "one-size-fits-all" value you can assume.
>> I doubt no. I tested last week rather many USB chips and all I tested
>> allowed to set it as x188 or x512 bytes. If it is set something than chip
>> does not like it will give errors or packets that are not as large as
>> requested. You can test that easily, look dvb-usb module debug uxfer and use
>> powertop.
>>
>>> I usually take a look at a USB trace of the device under Windows, and
>>> then use the same value.
>> I have seen logs where different sizes of urbs used even same chip.
> 
> Yes, the URB size can change depending on who wrote the driver, or
> what the required throughput is.  For example, the em28xx has a
> different URB size depending on whether the target application is
> 19Mbps ATSC or 38Mbps QAM.  That just reinforces what I'm saying - the
> size selected in many cases is determined by the requirements of the
> chipset.

Yes thats just what I tried to say for. Look my previous thread where 
all currently sizes are listed. We need to define suitable values that 
are used. For example USB2.0 DVB-C, DVB-T, ATSC and same values for 
USB1.1 too. And stream size can vary much depending used transmission 
parameters too but I think such kind resolution logic is not needed.

Currently there is almost everything between 512 to 65k used for DVB-T 
that makes huge difference to load device causing.

Does anyone know if there is some table which says what are good USB 
transmission parameters for each bandwidth needed?

> Making it some multiple of 188 for DVB is logical since that's the
> MPEG packet size.  That seems pretty common in the bridges I have
> worked with.
> 
> Devin


Antti
-- 
http://palosaari.fi/

Re: LinuxTV firmware blocks all wireless connections / traffic

[Devin Heitmueller]

On Thu, Sep 10, 2009 at 12:48 PM, Antti Palosaari<crope@iki.fi> wrote:
> Yes thats just what I tried to say for. Look my previous thread where all
> currently sizes are listed. We need to define suitable values that are used.
> For example USB2.0 DVB-C, DVB-T, ATSC and same values for USB1.1 too. And
> stream size can vary much depending used transmission parameters too but I
> think such kind resolution logic is not needed.
>
> Currently there is almost everything between 512 to 65k used for DVB-T that
> makes huge difference to load device causing.
>
> Does anyone know if there is some table which says what are good USB
> transmission parameters for each bandwidth needed?

The problem is that there cannot be any single set of rules that apply
to all devices.  For each chip, the rules are different and either
need to be reverse engineered by the maintainer or someone has to
refer to the datasheet if available.

It comes as no surprise that there is a huge variation on the URB
sizes chosen, and there is almost certainly an opportunity for
improvement on most bridges.  I suspect the logic applied by most of
the people who wrote the bridge drivers was to find the first value
that "works" and then not do any subsequent tuning/optimization.  Like
the situation with power management or tuning time, this just doesn't
seem to have been a priority.  And given how few developers we have
actually fixing bugs, adding support for new boards, and writing new
drivers, I can hardly blame them.

Unfortunately, with limited resources, we have to pick our battles -
which is more important:  having a slightly more optimal allocation
that produces fewer wakeups?  Or getting new product XYZ to work and
fixing bugs that are highly visible to end-users?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari]

On 09/10/2009 08:17 PM, Devin Heitmueller wrote:
> On Thu, Sep 10, 2009 at 12:48 PM, Antti Palosaari<crope@iki.fi>  wrote:
>> Yes thats just what I tried to say for. Look my previous thread where all
>> currently sizes are listed. We need to define suitable values that are used.
>> For example USB2.0 DVB-C, DVB-T, ATSC and same values for USB1.1 too. And
>> stream size can vary much depending used transmission parameters too but I
>> think such kind resolution logic is not needed.
>>
>> Currently there is almost everything between 512 to 65k used for DVB-T that
>> makes huge difference to load device causing.
>>
>> Does anyone know if there is some table which says what are good USB
>> transmission parameters for each bandwidth needed?
>
> The problem is that there cannot be any single set of rules that apply
> to all devices.  For each chip, the rules are different and either
> need to be reverse engineered by the maintainer or someone has to
> refer to the datasheet if available.

Eh, not all needed, but we need some kind of rule of thumb which URB 
size is suitable for bandwidth used. 512, 8k, 16k etc. It is not wise at 
all set it to only 512 bytes when streaming whole TS example 22Mbit/sec. 
I have tested Anysee (Cypress FX2), AF9015, CE6230, RTL2831U and all 
those allowed to set URB rather freely. I haven't seen yet device which 
forces to use just one size - though it is possible there is. And no 
datasheet even needed, you can see from debug log or error code if URB 
is not suitable.
Why not set it some good value when possible? And also adding module 
parameter which overrides driver default is not hard to add, just look 
value user gives as param and round it to nearest suitable one.

> It comes as no surprise that there is a huge variation on the URB
> sizes chosen, and there is almost certainly an opportunity for
> improvement on most bridges.  I suspect the logic applied by most of
> the people who wrote the bridge drivers was to find the first value
> that "works" and then not do any subsequent tuning/optimization.  Like
> the situation with power management or tuning time, this just doesn't
> seem to have been a priority.  And given how few developers we have
> actually fixing bugs, adding support for new boards, and writing new
> drivers, I can hardly blame them.

Of course it is easiest to set as small as possible, 512 or 188 usually 
and it is working. wakeups are then very high but not much buffers needed.

> Unfortunately, with limited resources, we have to pick our battles -
> which is more important:  having a slightly more optimal allocation
> that produces fewer wakeups?  Or getting new product XYZ to work and
> fixing bugs that are highly visible to end-users?
>
> Devin
>

Antti
-- 
http://palosaari.fi/

Re: LinuxTV firmware blocks all wireless connections / traffic

[Devin Heitmueller]

On Thu, Sep 10, 2009 at 4:29 PM, Antti Palosaari<crope@iki.fi> wrote:
> Eh, not all needed, but we need some kind of rule of thumb which URB size is
> suitable for bandwidth used. 512, 8k, 16k etc. It is not wise at all set it
> to only 512 bytes when streaming whole TS example 22Mbit/sec. I have tested
> Anysee (Cypress FX2), AF9015, CE6230, RTL2831U and all those allowed to set
> URB rather freely.

If you want to pick bridges that are important to you and take the
time to optimize them better, by all means be my guest.  This is the
sort of thing that would have to be discussed with the individual
maintainers of those bridges, so you can understand what logic was
used in making the original decision (ensuring the original logic was
not done to work around some bug, etc).

> I haven't seen yet device which forces to use just one
> size - though it is possible there is.

Well, it depends on the chip.  Selecting too small a value can result
in packets getting dropped (this was a problem on em28xx until I fixed
it a few months ago).

> And no datasheet even needed, you can
> see from debug log or error code if URB is not suitable.

Well, this assumes the bridge fails gracefully, returning a failure.
Take Patrick's example, where the device returns success but then
proceed to not send back any URBs.

> Why not set it some good value when possible? And also adding module
> parameter which overrides driver default is not hard to add, just look value
> user gives as param and round it to nearest suitable one.

Frankly, I'm not really confident this provides much value.  End-users
should not really be playing around with these sorts of settings.  If
the values are wrong, a patch should be submitted and the maintainer
should fix the driver.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote:
> On 09/10/2009 04:47 PM, Antti Palosaari wrote:
>> Aleksandr V. Piskunov wrote:
>>> On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote:
>>>> Aleksandr V. Piskunov wrote:
>>>>>> Here is a test case:
>>>>>> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015.
>>>>>> Different tuners,
>>>>> Err, make it: dvb_usb_af9015 and dvb_usb_ce6230
>>>> Those both uses currently too small bulk urbs, only 512 bytes. I have
>>>> asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but
>>>> no-one have answered yet (search ml back week or two). I think will
>>>> increase those to the 8k to reduce load.
>>>>
>>>
>>> Nice, I'm ready to test if such change helps.
>>
>> OK, I will make test version in couple of hours.
>
> Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
> Now powertop shows only about 220 wakeups on my computer for the both  
> sticks.
> Please test and tell what powertop says:
> http://linuxtv.org/hg/~anttip/urb_size/
>
> I wonder if we can decide what URB size DVB USB drivers should follow  
> and even add new module param for overriding driver default.

Thanks, Antti!

Tested your branch on affected system.

Load definitely went down, from ~7000 wakeups to ~250 for each tuner
according to powertop.
Both tuners still working ok if not used simultaneously or if used the
same time on different USB controllers.

Bad news are that original problem still persists: putting both tuners
on same USB controller and zapping simultaneously corrupts stream.
Interesting observation: no matter in what sequence tuners are connected
(i.e. become adapter0 or adapter1), af9015 stream always gets heavily
distorted, visually mplayer picture becomes like 80% corrupted with
random color blocks and pixels, sound becomes a mess. At the same time
ce6230 gets slight corruption, a few discolored blocks at the time and
sound hickups.

Anyway, will try to do a few more tests:
1) Two usb flash drives on same controller calculating md5sum of 
big .iso file, to check if it is/isn't dvb-usb problem.
2) Will see if same issue persists on another PC with same motherboard
(slightly different revision) to rule out hardware issues. If I manage
to wire antenna there, that is...

Re: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote:
> On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote:
> > On 09/10/2009 04:47 PM, Antti Palosaari wrote:
> >> Aleksandr V. Piskunov wrote:
> >>> On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote:
> >>>> Aleksandr V. Piskunov wrote:
> >>>>>> Here is a test case:
> >>>>>> Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015.
> >>>>>> Different tuners,
> >>>>> Err, make it: dvb_usb_af9015 and dvb_usb_ce6230
> >>>> Those both uses currently too small bulk urbs, only 512 bytes. I have
> >>>> asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but
> >>>> no-one have answered yet (search ml back week or two). I think will
> >>>> increase those to the 8k to reduce load.
> >>>>
> >>>
> >>> Nice, I'm ready to test if such change helps.
> >>
> >> OK, I will make test version in couple of hours.
> >
> > Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
> > Now powertop shows only about 220 wakeups on my computer for the both  
> > sticks.
> > Please test and tell what powertop says:
> > http://linuxtv.org/hg/~anttip/urb_size/
> >
> > I wonder if we can decide what URB size DVB USB drivers should follow  
> > and even add new module param for overriding driver default.
> 
> Thanks, Antti!
> 
> Tested your branch on affected system.
> 
> Load definitely went down, from ~7000 wakeups to ~250 for each tuner
> according to powertop.
> Both tuners still working ok if not used simultaneously or if used the
> same time on different USB controllers.
> 
> Bad news are that original problem still persists: putting both tuners
> on same USB controller and zapping simultaneously corrupts stream.
> Interesting observation: no matter in what sequence tuners are connected
> (i.e. become adapter0 or adapter1), af9015 stream always gets heavily
> distorted, visually mplayer picture becomes like 80% corrupted with
> random color blocks and pixels, sound becomes a mess. At the same time
> ce6230 gets slight corruption, a few discolored blocks at the time and
> sound hickups.
> 
> Anyway, will try to do a few more tests:
> 1) Two usb flash drives on same controller calculating md5sum of 
> big .iso file, to check if it is/isn't dvb-usb problem.
> 2) Will see if same issue persists on another PC with same motherboard
> (slightly different revision) to rule out hardware issues. If I manage
> to wire antenna there, that is...

Ok, two USB flash drives on same controller, no problem when bulk reading
from both at the same time, no speed drops, no corruption.

Now if I plug ce6230 tuner, zap to channel and then start reading from 
flash drive:
* slightly corrupted TS stream
* flash drive read getting starved on bandwidth, speed drops from 10 MB/s
  to ~7 MB/s

If I plug af9015 tuner, zap and read from flash
* heavy corruption of TS stream
* flash drive read speed drops from 10 MB/s to 2(!) MB/s

Now I don't really know the USB protocol under-the-hood details, all the
different types of bandwidth, reservation and so on. But shouldn't one
480 Mbit/sec controller handle rather large number of digital tuners, each
pushing 20-25 Mbit/sec max, even considering all the overhead?

Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari]

On 09/10/2009 10:39 PM, Aleksandr V. Piskunov wrote:
> On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote:
>> On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote:
>>> Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
>>> Now powertop shows only about 220 wakeups on my computer for the both
>>> sticks.
>>> Please test and tell what powertop says:
>>> http://linuxtv.org/hg/~anttip/urb_size/
>>>
>>> I wonder if we can decide what URB size DVB USB drivers should follow
>>> and even add new module param for overriding driver default.
>>
>> Thanks, Antti!
>>
>> Tested your branch on affected system.
>>
>> Load definitely went down, from ~7000 wakeups to ~250 for each tuner
>> according to powertop.
>> Both tuners still working ok if not used simultaneously or if used the
>> same time on different USB controllers.
>>
>> Bad news are that original problem still persists: putting both tuners
>> on same USB controller and zapping simultaneously corrupts stream.
>> Interesting observation: no matter in what sequence tuners are connected
>> (i.e. become adapter0 or adapter1), af9015 stream always gets heavily
>> distorted, visually mplayer picture becomes like 80% corrupted with
>> random color blocks and pixels, sound becomes a mess. At the same time
>> ce6230 gets slight corruption, a few discolored blocks at the time and
>> sound hickups.
>>
>> Anyway, will try to do a few more tests:
>> 1) Two usb flash drives on same controller calculating md5sum of
>> big .iso file, to check if it is/isn't dvb-usb problem.
>> 2) Will see if same issue persists on another PC with same motherboard
>> (slightly different revision) to rule out hardware issues. If I manage
>> to wire antenna there, that is...
>
> Ok, two USB flash drives on same controller, no problem when bulk reading
> from both at the same time, no speed drops, no corruption.
>
> Now if I plug ce6230 tuner, zap to channel and then start reading from
> flash drive:
> * slightly corrupted TS stream
> * flash drive read getting starved on bandwidth, speed drops from 10 MB/s
>    to ~7 MB/s
>
> If I plug af9015 tuner, zap and read from flash
> * heavy corruption of TS stream
> * flash drive read speed drops from 10 MB/s to 2(!) MB/s
>
> Now I don't really know the USB protocol under-the-hood details, all the
> different types of bandwidth, reservation and so on. But shouldn't one
> 480 Mbit/sec controller handle rather large number of digital tuners, each
> pushing 20-25 Mbit/sec max, even considering all the overhead?

I have no any problems here, ce6230 and af9015 with dual tuners (3x 
DVB-T 22Mbit/sec TS streams) running same time on same bus.

One possibility is that there is RF-noise looping from device to device 
disturbing USB transfer or RF-signal. I have seen such situation when I 
connect multiple DVB-C devices to same antenna cable using cheap splitter.

Anyhow, I increased URB sizes to 65k. Now ce6230 gives 70 wakeups and 
af9015 120 wakeups - due to remote polling. You can test if you wish, 
but results are most likely same as earlier. I cannot do much more.
http://linuxtv.org/hg/~anttip/urb_size/

Antti
-- 
http://palosaari.fi/

Re: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Fri, Sep 11, 2009 at 05:38:08PM +0300, Antti Palosaari wrote:
> On 09/10/2009 10:39 PM, Aleksandr V. Piskunov wrote:
>> On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote:
>>> On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote:
>>>> Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
>>>> Now powertop shows only about 220 wakeups on my computer for the both
>>>> sticks.
>>>> Please test and tell what powertop says:
>>>> http://linuxtv.org/hg/~anttip/urb_size/
>>>>
>>>> I wonder if we can decide what URB size DVB USB drivers should follow
>>>> and even add new module param for overriding driver default.
>>>
>>> Thanks, Antti!
>>>
>>> Tested your branch on affected system.
>>>
>>> Load definitely went down, from ~7000 wakeups to ~250 for each tuner
>>> according to powertop.
>>> Both tuners still working ok if not used simultaneously or if used the
>>> same time on different USB controllers.
>>>
>>> Bad news are that original problem still persists: putting both tuners
>>> on same USB controller and zapping simultaneously corrupts stream.
>>> Interesting observation: no matter in what sequence tuners are connected
>>> (i.e. become adapter0 or adapter1), af9015 stream always gets heavily
>>> distorted, visually mplayer picture becomes like 80% corrupted with
>>> random color blocks and pixels, sound becomes a mess. At the same time
>>> ce6230 gets slight corruption, a few discolored blocks at the time and
>>> sound hickups.
>>>
>>> Anyway, will try to do a few more tests:
>>> 1) Two usb flash drives on same controller calculating md5sum of
>>> big .iso file, to check if it is/isn't dvb-usb problem.
>>> 2) Will see if same issue persists on another PC with same motherboard
>>> (slightly different revision) to rule out hardware issues. If I manage
>>> to wire antenna there, that is...
>>
>> Ok, two USB flash drives on same controller, no problem when bulk reading
>> from both at the same time, no speed drops, no corruption.
>>
>> Now if I plug ce6230 tuner, zap to channel and then start reading from
>> flash drive:
>> * slightly corrupted TS stream
>> * flash drive read getting starved on bandwidth, speed drops from 10 MB/s
>>    to ~7 MB/s
>>
>> If I plug af9015 tuner, zap and read from flash
>> * heavy corruption of TS stream
>> * flash drive read speed drops from 10 MB/s to 2(!) MB/s
>>
>> Now I don't really know the USB protocol under-the-hood details, all the
>> different types of bandwidth, reservation and so on. But shouldn't one
>> 480 Mbit/sec controller handle rather large number of digital tuners, each
>> pushing 20-25 Mbit/sec max, even considering all the overhead?
>
> I have no any problems here, ce6230 and af9015 with dual tuners (3x  
> DVB-T 22Mbit/sec TS streams) running same time on same bus.
>
> One possibility is that there is RF-noise looping from device to device  
> disturbing USB transfer or RF-signal. I have seen such situation when I  
> connect multiple DVB-C devices to same antenna cable using cheap 
> splitter.
>
> Anyhow, I increased URB sizes to 65k. Now ce6230 gives 70 wakeups and  
> af9015 120 wakeups - due to remote polling. You can test if you wish,  
> but results are most likely same as earlier. I cannot do much more.
> http://linuxtv.org/hg/~anttip/urb_size/

Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs..
So using my fresh knowledge I went away and hacked ce6230 to use Isochronous
transfer endpoint instead of Bulk one. And it helped, tuner works, no
corruption with af9015 running on same controller at the same time.

Of course it isn't a fix per se, af9015 still corrupts if I start bulk
reading from a flash drive, etc. And there are no Isochronous endpoints on
af9015, so no alternative to bulk transfers :)

But at least I'm getting closer to pinpointing the real problem and so far
everything points to AMD SB700 chipset driver. Google says it has quite
some hardware bugs and several workarounds in linux drivers...

P.S. Rather unrelated question, what type of USB transfer is generally
preferred for USB media stream devices, BULK or ISOC? Antti, why did you
choose BULK for ce6230?

Re: LinuxTV firmware blocks all wireless connections / traffic

[Devin Heitmueller]

On Fri, Sep 11, 2009 at 1:50 PM, Aleksandr V. Piskunov
<aleksandr.v.piskunov@gmail.com> wrote:
> Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs..
> So using my fresh knowledge I went away and hacked ce6230 to use Isochronous
> transfer endpoint instead of Bulk one. And it helped, tuner works, no
> corruption with af9015 running on same controller at the same time.
>
> Of course it isn't a fix per se, af9015 still corrupts if I start bulk
> reading from a flash drive, etc. And there are no Isochronous endpoints on
> af9015, so no alternative to bulk transfers :)
>
> But at least I'm getting closer to pinpointing the real problem and so far
> everything points to AMD SB700 chipset driver. Google says it has quite
> some hardware bugs and several workarounds in linux drivers...
>
> P.S. Rather unrelated question, what type of USB transfer is generally
> preferred for USB media stream devices, BULK or ISOC? Antti, why did you
> choose BULK for ce6230?

The core difference between bulk and isoc is that with bulk you use
get reliable delivery, but there is no reservation of bandwidth (bulk
uses all available bandwidth).  With isoc, you have reserved the
bandwidth up front, but don't have reliable delivery (no retry
mechanism, etc).

With something like a hard drive, you want to use all available
bandwidth, and you can do retries to ensure delivery, making bulk an
appropriate choice.  However, for streaming video, you usually want
the bandwidth reserved up front, because if two devices are using the
bus then frames will get dropped (and in a realtime streaming video
device, there is no "retry" capability for dropped packets).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari]

On 09/11/2009 08:50 PM, Aleksandr V. Piskunov wrote:
> Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs..
> So using my fresh knowledge I went away and hacked ce6230 to use Isochronous
> transfer endpoint instead of Bulk one. And it helped, tuner works, no
> corruption with af9015 running on same controller at the same time.

Looks like chipset driver issue as you said.

> Of course it isn't a fix per se, af9015 still corrupts if I start bulk
> reading from a flash drive, etc. And there are no Isochronous endpoints on
> af9015, so no alternative to bulk transfers :)

y, correct. Welcome to hacking DVB drivers.

> But at least I'm getting closer to pinpointing the real problem and so far
> everything points to AMD SB700 chipset driver. Google says it has quite
> some hardware bugs and several workarounds in linux drivers...
>
> P.S. Rather unrelated question, what type of USB transfer is generally
> preferred for USB media stream devices, BULK or ISOC? Antti, why did you
> choose BULK for ce6230?

Because chipset Windows driver was using BULK. Very many, I think even 
most, DVB chipset offers both ISOC and BULK. BULK is still used 
commonly, only few drivers are using ISOC. Devin answered already why 
BULK is used generally for DVB streams. :)

I read also USB "bible" book yesterday and it says it is better to use 
biggest BULK urb supported. I want to change it biggest possible one, 
but there is other side that limits it - memory needed for buffers. 
That's why I am thinking twice whether to increase it 8k or 16k or even 
more. I currently think 16k will be good compromise for most 
configurations / devices.

Antti
-- 
http://palosaari.fi/

Re: LinuxTV firmware blocks all wireless connections / traffic

[CityK]

Aleksandr V. Piskunov wrote:
> I'm getting closer to pinpointing the real problem and so far
> everything points to AMD SB700 chipset driver. Google says it has quite
> some hardware bugs and several workarounds in linux drivers...

If your googling didn't turn them up already, here's some more threads:

http://www.mail-archive.com/search?q=SB700+&l=linux-media%40vger.kernel.org