RFC - Flexcop Streaming watchdog (VDSB)
diff mbox

Message ID alpine.LRH.1.10.0901161548460.28478@pub2.ifh.de
State RFC
Headers show

Commit Message

Patrick Boettcher Jan. 16, 2009, 3:03 p.m. UTC
Hi lists,

For years there has been the Video Data Stream Borken-error with VDR and
Technisat cards: The error occured randomly and unfrequently. A 
work-around for that problem was to restart VDR and let the driver reset 
the pid-filtering and streaming interface.

In fact it turned out, that the problem is worse with setups not based on 
VDR and the "VDSB-error" could be really easily reproduced (I'm not sure 
if this applies to all generations on SkyStar2-card). I'm skipping the 
description of the problem here...

Attached you'll find a patch which works around the hardware bug which is 
causing VDSB-error without needing to reload the driver.

There a struct-work-watchdog looking at the number of irq-received while 
having PIDs active in the PID-filter. If no IRQs are received, the 
pid-filter-system is reset.

It seems to fix the problem and so far I've not seen any false positives 
(like resetting the pid-filter even though streaming is working fine).

Before asking to pull the patch I'd like to discuss an issue: my 
work-around is iterating over the pid-filter-list in the dvb_demux. I'm 
doing this in the struct-work-callback. In dvb_demux.c I see that this 
list is protected with a spinlock. When I now try to take the spinlock in 
the work-function I'll get a nice message saying, that I cannot do take a 
spinlock in a work-function.

What can I do? What is the proper way to protect access to this list? Is 
it needed at all?

thanks for you input in advance,
Patrick.

--
   Mail: patrick.boettcher@desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/

Comments

BOUWSMA Barry Jan. 16, 2009, 11:40 p.m. UTC | #1
On Fri, 16 Jan 2009, AlexW wrote:

> Patrick Boettcher wrote:

> > For years there has been the Video Data Stream Borken-error with VDR and
> > Technisat cards: The error occured randomly and unfrequently. A 

> > In fact it turned out, that the problem is worse with setups not based 
> > on VDR and the "VDSB-error" could be really easily reproduced (I'm not 
> > sure if this applies to all generations on SkyStar2-card). I'm 

> Which generation of cards have this problem? I did not see any VDSB with 
> my two Skystar 2.6D.

Same here -- never experienced this ever in some four-ish years
with one SkyStar2 of model long forgotten, with that card being
the primary one used whenever possible...

(in use typically several times per day, sometimes half a day
uninterrupted, but on a production machine at 2.6.14-ish)


barry bouwsma
--
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
Andy Walls Jan. 17, 2009, 3:37 a.m. UTC | #2
On Fri, 2009-01-16 at 16:03 +0100, Patrick Boettcher wrote:
> Hi lists,

> There a struct-work-watchdog looking at the number of irq-received while 
> having PIDs active in the PID-filter. If no IRQs are received, the 
> pid-filter-system is reset.
> 
> It seems to fix the problem and so far I've not seen any false positives 
> (like resetting the pid-filter even though streaming is working fine).
> 
> Before asking to pull the patch I'd like to discuss an issue: my 
> work-around is iterating over the pid-filter-list in the dvb_demux. I'm 
> doing this in the struct-work-callback. In dvb_demux.c I see that this 
> list is protected with a spinlock. When I now try to take the spinlock in 
> the work-function I'll get a nice message saying, that I cannot do take a 
> spinlock in a work-function.
> 
> What can I do?

I am surprised you cannot acquire a spinlock in a deferable work
handler.  I would not have thought this the case, but I don't know for
sure.  BTW, why are you using spin_lock_irq() to disable local
interrupts in the work handler instead of spin_lock_irqsave()?  I would
think one would only call spin_lock_irq() in the irq handler and then
under limited circumstances (I could be wrong).  

However, if you cannot take a spinlock in a work handler, then you must
acquire the spinlock in the irq handler, walk the list there to *collect
information* on the deferable work you must do, and then submit the
information about deferable work you need to do onto the work queue.

You can pass the information to the work-handler in a structure that
contains a struct work object plus the other data you need.  If you use
a single-threaded work handler, then ordering of the work is preserved
by virtue of only one thread pulling work off of the work queue.  The
normal multithreaed work-handling doesn't preserve ordering of the
deferable work.

For an example which you can look at:
In cx18, I used "work orders" that would be submitted to the deferable
work-handler.  In struct cx18, you will see an array (pool) of
epu_work_orders for each device.  All of the work handling and
scheduling is done in cx18-mailbox.c, IIRC.



> What is the proper way to protect access to this list?

To acquire the spinlock.  If you don't, you invalidate a fundamental
assumption made by other code that accesses that list.

>  Is 
> it needed at all?

I would assume yes, but I haven't inspected the dvb code to verify.

Regards,
Andy

> thanks for you input in advance,
> Patrick.
> 
> --
>    Mail: patrick.boettcher@desy.de
>    WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/

--
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
Patrick Boettcher Jan. 17, 2009, 8:29 a.m. UTC | #3
Hi Barry,
Hi Walter,

On Sat, 17 Jan 2009, BOUWSMA Barry wrote:
>>> For years there has been the Video Data Stream Borken-error with VDR and
>>> Technisat cards: The error occured randomly and unfrequently. A
>
>>> In fact it turned out, that the problem is worse with setups not based
>>> on VDR and the "VDSB-error" could be really easily reproduced (I'm not
>>> sure if this applies to all generations on SkyStar2-card). I'm
>
>> Which generation of cards have this problem? I did not see any VDSB with
>> my two Skystar 2.6D.
>
> Same here -- never experienced this ever in some four-ish years
> with one SkyStar2 of model long forgotten, with that card being
> the primary one used whenever possible...
>
> (in use typically several times per day, sometimes half a day
> uninterrupted, but on a production machine at 2.6.14-ish)

Using VDR or a single application (like kaffeine), you most likely don't 
see the error anymore thanks to the work-around which is already in place. 
It is resetting the streaming interface at the end of a streaming-session, 
ie. when the pid-filter count is going from 1 to 0. This happens all the 
time with VDR (and similar) when it is retuning.

Now when you launch an application which is just requesting a pid and 
another one which is tuning independently, you can fall easily in this 
problem.

I have to say, that the user which showed me the problem was using the 
rev2.8 and due to the lack of time I couldn't check with other versions 
than this card yet.

But I think those kind of problems also exist for older cards.

Patrick.

PS: how to reproduce:

shell 1: $ tzap channel
shell 2: $ dvbtraffic
[lots of output that streaming is working]
shell 1: $ <C-c>
shell 1: $ tzap "channel2_which is on a different frequency"
shell 2: no output of dvbtraffic any longer... (problem)

--
   Mail: patrick.boettcher@desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
--
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
BOUWSMA Barry Jan. 17, 2009, 10:50 a.m. UTC | #4
On Sat, 17 Jan 2009, Patrick Boettcher wrote:

> > Same here -- never experienced this ever in some four-ish years
> > with one SkyStar2 of model long forgotten, with that card being

> Using VDR or a single application (like kaffeine), you most likely don't see
> the error anymore thanks to the work-around which is already in place. It is
> resetting the streaming interface at the end of a streaming-session, ie. when
> the pid-filter count is going from 1 to 0. This happens all the time with VDR
> (and similar) when it is retuning.

Okay, I've been using `dvbstream' standalone, also modified so
that it and related utilities get an exclusive lock on the
adapter (otherwise when I'd make a mistake, the second invocation
of `dvbstream' would not only fail, but the first recording was
also messed up, so less than useless).

`scan' has also been used, although in my latest installation
(including a 12-output multiswitch), the card I have has been
unable to lock or to get error-free output from transponders at
the ends of the frequency range -- this affects at Astra 19E2
the ORF transponders among others, and at 28E many of the Channel 
4 family, while all other devices on the same multiswitch have
no difficulties at even higher frequencies and can scan the
entire range perfectly.  I've also guessed this could be due to
spiders taking up residence in the warm interior of the tuning
circuits.  Anyway, someday I'll replace this card with an -S2
or perhaps dual- hybrid- whatever is available later.


> Now when you launch an application which is just requesting a pid and another
> one which is tuning independently, you can fall easily in this problem.
> PS: how to reproduce:
> shell 1: $ tzap channel
> shell 2: $ dvbtraffic
> [lots of output that streaming is working]
> shell 1: $ <C-c>
> shell 1: $ tzap "channel2_which is on a different frequency"
> shell 2: no output of dvbtraffic any longer... (problem)

This lack-of-output is something that I've experienced with
other cards (a dvb-usb DVB-T device), which I did not
investigate further.  If I remember rightly, and with a
more recent kernel.

Note that in my `dvbstream'-exclusively use of the SkyStar2, I
have never seen the error message (since trimmed from the
quoted original post).

I'll see if I can reproduce this on my production machine once
it's idle, or if my hacks might be involved, and report back
about this...


thanks
barry bouwsma
--
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
BOUWSMA Barry Jan. 17, 2009, 12:36 p.m. UTC | #5
Following up to myself is a sign of a sick mind.

On Sat, 17 Jan 2009, BOUWSMA Barry wrote:

> > shell 1: $ tzap channel
> > shell 2: $ dvbtraffic
> > [lots of output that streaming is working]
> > shell 1: $ <C-c>
> > shell 1: $ tzap "channel2_which is on a different frequency"
> > shell 2: no output of dvbtraffic any longer... (problem)

> I'll see if I can reproduce this on my production machine once
> it's idle, or if my hacks might be involved, and report back
> about this...

Here's what I see. It may not be meaningful.  This machine
uses utilities from 2005 or so, sometimes hacked but still
based on source from 2005.

Anyway, with the SkyStar2:
szap a-channel-which-locks
dvbtraffic-card0 ==> output, whee
^C szap; dvbtraffic continues for a few seconds (timeout)
szap the-same-channel or a-different-frequency
no dvbtraffic output yet
^C szap; immediately dvbtraffic outputs again for a few secs

With a DVB-T tuner:
tzap a-channel-which-locks
dvbtraffic-card1 ==> output, yay
^C tzap; dvbtraffic continues a few seconds
tzap again
no dvbtraffic output yet
^C tzap
still no dvbtraffic output...

But no errors are thrown up, nor does anything appear logged
to the console.

However, [ts]zap are system binaries from 2004; dvbtraffic
is hacked, though I'm not sure how heavily, so I don't know
if what I see is meaningful.

Invoking `dvbtraffic' first, then `dvbstream' also produces
some results for a fraction of a second, then no `dvbtraffic'
output.


So, at this point, I don't know what to say...

barry bouwsma
--
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
Andy Walls Jan. 17, 2009, 1:18 p.m. UTC | #6
Patrick,

Please ignore my comment prior in this thread about using
spin_lock_irq() vs. spin_lock_irqsave().  Between lack of sleep and
trying to install Fedora 10 and recover my data on what now appears to
be a failing motherboard/cpu, I made an error.  I realized spinlock
functions should always disable local IRQs (*smacks forehead*).

What one has to take care with is unconditionally re-enabling local IRQs
with spin_unlock_irq().  One would think that a work handler is known to
be called in a non-irq context.  So, at the risk of being wrong again,
using spin_unlock_irq() should be OK, if spin_lock_irq() is allowed by
the kernel in a work handler context (which your experimentation
indicates that it is not).

Regards,
Andy

--
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
Luca Olivetti Jan. 17, 2009, 6:28 p.m. UTC | #7
El Sat, 17 Jan 2009 09:29:29 +0100 (CET)
Patrick Boettcher <patrick.boettcher@desy.de> escribió:

> I have to say, that the user which showed me the problem was using
> the rev2.8 and due to the lack of time I couldn't check with other
> versions than this card yet.

Well, I'm definitely seeing this with an old skystar 2 (I'm not sure
of the version but it's 3-4 years old, b2c-flexcop says it's an 'old
version') used exclusively by vdr, but then I've last updated the
driver about a year ago.
I'm not seeing it very often, but it may be because I'm not continuosly
switching channels as I did years ago.

Bye
Matthias Schwarzott Jan. 25, 2009, 9:17 p.m. UTC | #8
On Freitag, 16. Januar 2009, Patrick Boettcher wrote:

I am looking forward to test your patch.

> There a struct-work-watchdog looking at the number of irq-received while
> having PIDs active in the PID-filter. If no IRQs are received, the
> pid-filter-system is reset.
>
Very good idea.

>
> Before asking to pull the patch I'd like to discuss an issue: my
> work-around is iterating over the pid-filter-list in the dvb_demux. I'm
> doing this in the struct-work-callback. In dvb_demux.c I see that this
> list is protected with a spinlock. When I now try to take the spinlock in
> the work-function I'll get a nice message saying, that I cannot do take a
> spinlock in a work-function.
>

> What can I do? What is the proper way to protect access to this list? Is
> it needed at all?

I thought this is a perfectly legetimate usage of spinlocks. What is the exact 
wording of the message. Is it a message of lockdep, or another kind of 
message?

Does it get better using spin_lock_irqsave instead of spin_lock_irq ?

Regards
Matthias
--
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
Patrick Boettcher Jan. 26, 2009, 3:05 p.m. UTC | #9
Hi Matthias,
hi Andy,


On Sun, 25 Jan 2009, Matthias Schwarzott wrote:
>> What can I do? What is the proper way to protect access to this list? Is
>> it needed at all?
>
> I thought this is a perfectly legetimate usage of spinlocks. What is the exact
> wording of the message. Is it a message of lockdep, or another kind of
> message?
>
> Does it get better using spin_lock_irqsave instead of spin_lock_irq ?

I'll try yours suggestions this evening... along with dumping all 
error message if any.

Thanks for taking the time.

best regards
Patrick.

--
   Mail: patrick.boettcher@desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
--
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
Patrick Boettcher Feb. 9, 2009, 3:13 p.m. UTC | #10
Hi all,

On Sun, 25 Jan 2009, Matthias Schwarzott wrote:
> Does it get better using spin_lock_irqsave instead of spin_lock_irq ?

Thanks again for your input. My observation was wrong. It was not the 
spin_lock causing the problem, but a msleep which lead to the 
BUG_ON-condition....

Patrick.
--
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
BOUWSMA Barry April 25, 2009, 4:08 p.m. UTC | #11
Sorry for digging out an old message.  But...  (I also started
to write this a couple weeks back, then set it aside to do
more observation, so dates referenced may be inaccurate)


I've been intending for some time to gradually migrate my
production machine from its 2005-era solid-like-rock kernel,
to something more recent which has proved reasonably stable,
to make better use of new hardware.

This production server has one Flexcop PCI SkyStar card, and
three USB devices, with too many hacks to get things working.
The SkyStar card has been my primary card, and out of hundreds
of uses, only about two times has it failed to tune, with the
2.6.14-to-15-era kernel.

The kernel I've updated to is a 2.6.27-rc4, with patches for
things which have broken for me in a several month test period
to see if this kernel crashes on a test box.  In the meantime,
I tried an older 2.6.26-era kernel, as well as newer ones, to
the git-snapshot of the day at the time.

Unfortunately, my testing on the new kernel today on the
production server showed none of the stability I expected of
the older kernel.  I still need to do more work and verify
my observations, but my disappointment with the SkyStar on
the more recent kernel reminded me of this message, which I
had to dig out...



On Fri, 16 Jan 2009, Patrick Boettcher wrote:

> Hi lists,
> 
> For years there has been the Video Data Stream Borken-error with VDR and
> Technisat cards: The error occured randomly and unfrequently. A work-around
> for that problem was to restart VDR and let the driver reset the pid-filtering
> and streaming interface.
> 
> In fact it turned out, that the problem is worse with setups not based on VDR
> and the "VDSB-error" could be really easily reproduced (I'm not sure if this
> applies to all generations on SkyStar2-card). I'm skipping the description of
> the problem here...

Unfortunately, this (and later messages in this thread) is not
related to what I'm now seeing, oh well...


Anyway, to describe what I observed a couple weeks ago, when
swapping out a USB stick with the old 2.6.14-ish OS/kernel for
a reasonably fresh OS/kernel, without changing anything else
with the hardware:

The problem I'm experiencing is apparently DiSEqC-related, as
I'm switching between four positions.  Position 1 is Astra 19E2,
and I've noticed the problem too often with position 3, Astra 28E.

Also, while I had no new problems with position 1/4, at least
half of my attempts to use position 3/4 simply failed to tune,
so I had to stop using this card for that position.  (Positions
2/4 and 4/4 see infrequent use, exclusively with a different
device as it's only radio there of interest)


Another thing to notice is that according to `dmesg' the card
was identified incorrectly, although that did not stop it from
working:


[   14.802703] b2c2-flexcop:B2C2 FlexcopII/II(b)/III digital TV 
receiver chip loaded successfully
[   15.352877] flexcop-pci: will use the HW PID filter.
[   15.353082] flexcop-pci: card revision 2
[   15.392836] DVB: registering new adapter (FlexCop Digital TV device)
[   15.400031] b2c2-flexcop: MAC address = 00:d0:d7:0c:75:7a
[   18.683487] b2c2-flexcop: found 'ST STV0299 DVB-S' .
[   18.683787] DVB: registering adapter 1 frontend 0 (ST STV0299 DVB-S)...
[   18.685308] b2c2-flexcop: initialization of 'Air2PC/AirStar 2 
ATSC 3rd generation (HD5000)' at the 'PCI' bus controlled by a 
'FlexCopIIb' complete

I have no ATSC card!  Lawdy, have mercy!

Anyway, this appears to have been IRQ or similarly-related, as
when I swapped in a different PCI-USB adapter which didn't work
so I had to exchange its position with a sound card to get the
IRQs recognized, then things started working:

[   14.250005] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV 
receiver chip loaded successfully
[   15.469994] flexcop-pci: will use the HW PID filter.
[   15.469994] flexcop-pci: card revision 2
[   15.509998] DVB: registering new adapter (FlexCop Digital TV 
device)
[   15.519996] b2c2-flexcop: MAC address = 00:d0:d7:0c:75:7a
[   15.519996] b2c2-flexcop: i2c master_xfer failed
[   15.519996] b2c2-flexcop: i2c master_xfer failed
[   15.519996] CX24123: cx24123_i2c_readreg: reg=0x0 (error=-121)
[   15.519996] CX24123: wrong demod revision: 87
** [   15.519996] b2c2-flexcop: now doing stv0299_attach...
** [   18.710000] b2c2-flexcop: stv0299_attach succeeded...
[   18.710000] b2c2-flexcop: found 'ST STV0299 DVB-S' .
[   18.710000] DVB: registering frontend 1 (ST STV0299 DVB-S)...
[   18.710000] b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 
DVB-S' at the 'PCI' bus controlled by a 'FlexCopIIb' complete

** debuggery I added expecting it to fail


Now, while it's properly identified, it still fails to tune
reliably to position 3/4.  The following was noted when it was
identified wrong, in the same hardware configuration which worked
fine with 2.6.14-ish


Apparently with the newer kernel, the SkyStar isn't sending a
reliable DiSEqC signal all the time for position 3, and often it
slips back to receiving from position 1.

The main BBC TV services at 28E are on the same frequency as a
19E2 transponder with polish (I believe) services.  Several
attempts to get a stream from BBC One and Two (plus PMT and
related data) resulted in PID 0 from 19E with the list of
services and PIDs.

The BBC radio services are on the same frequency as ZDF, so
that often when tuning the radio, I'd get a lock, but no audio
data (the PIDs aren't shared).

A channel scan on position 3/4 showed the problem when `diff'ed 
against an older scan -- the card also is known to have problems 
at the low and high frequency extremes in my present setup, and 
sometime will be replaced...


   Scanning 10714250    h       22000
-Channel 4:10714:h:3:22000:2315:2319:9211
[...]

   Scanning 10729000    v       22000
-E4+1:10729:v:3:22000:2364:2365:8300
[...]
Did not manage to lock these two frequencies.  These are both
analogue services at 19E in case it failed to tune position 3.
Strangely, while I've had some difficulty with reliable
reception of More4 at a higher frequency, I was able to tune
directly to Channel 4 and get a minute worth of flawless stream.

   Scanning 10906000    v       22000
-ITV Channel Is:10906:v:3:22000:3328:3329:10200
Again, utterly failed to lock this transponder/position, though
it's within my problem-free range.

   Scanning 11565380 V 27500
-### SCRAMBLED!!!  #KOOPID ABB:11565:v:3:27500:0:0:8006
   Scanning 11584620 H 27500
-### SCRAMBLED!!!  #Racing UK:11584:h:3:27500:2315:2316:50600
Failed to lock these two, as well as
   Scanning 11875500    h       27500
-6200:11875:h:3:27500:0:0:6200

   Scanning 11895000    v       27500
-### SCRAMBLED!!!  #MTV ONE:11895:v:3:27500:2323:2306:7001
[...]
+### SCRAMBLED!!!  #CINECINEMA CLUB:11895:v:3:27500:166:104:8351
+### SCRAMBLED!!!  #MCM:11895:v:3:27500:161:84:8352
+### SCRAMBLED!!!  #MCM POP:11895:v:3:27500:164:96:8354
+### SCRAMBLED!!!  #TELE MAISON:11895:v:3:27500:169:116:8355
+### SCRAMBLED!!!  #VIRGIN 17:11895:v:3:27500:168:112:8358

Now this is messed up.  Instead of tuning position 3, it's
receiving the french services from 19E, position 1.

   Scanning 11953500    h       27500
-BBC NEWS:11953:h:3:27500:5000:5001:6704
Here it failed to lock this, but at the same time, it did
not lock the ZDF transponder, so I'm not sure which output
was active.

Skipping some other transponders that got no results, another
example of german Premiere appearing instead of BSkyB...

-### SCRAMBLED!!!  #Smash Hits!:12070:h:3:27500:512:660:50000
-### SCRAMBLED!!!  #FOX News:12070:h:3:27500:518:666:50007
-### SCRAMBLED!!!  #DCS24:12070:h:3:27500:0:0:50190
+### SCRAMBLED!!!  #PREMIERE START:12070:h:3:27500:3071:3072:8
+### SCRAMBLED!!!  #HEIMATKANAL:12070:h:3:27500:1279:1280:22
+### SCRAMBLED!!!  #RTL CRIME:12070:h:3:27500:1791:1792:27
also,
-### SCRAMBLED!!!  #Games Slot 1:12285:v:3:27500:0:3022:8192
+### SCRAMBLED!!!  #AB MOTEURS:12285:v:3:27500:160:80:17020
and
-### SCRAMBLED!!!  #ITV1 Central SW:12402:v:3:27500:3348:3349:12140
-ITVi Quad:12402:v:3:27500:3352:3353:12150
-12198:12402:v:3:27500:0:0:12198
-12199:12402:v:3:27500:3348:3349:12199
+### SCRAMBLED!!!  #EQUIDIA INFO:12402:v:3:27500:160:80:8701
+### SCRAMBLED!!!  #COMEDIE !:12402:v:3:27500:161:84:8702
+### SCRAMBLED!!!  #13EME RUE:12402:v:3:27500:162:88:8703
and
-Brit Hits:12480:v:3:27500:2340:2341:12080
-Brit Asia TV:12480:v:3:27500:2342:2343:12081
-Asian Star:12480:v:3:27500:0:2344:12082
+Sonnenklar TV:12480:v:3:27500:2303:2304:32
+HSE24:12480:v:3:27500:1279:1280:40


This actually seems a bit similar to what others were seeing
with other hardware I have, though in limited testing, the
same other cards are working mostly as expected for me.


Now, that above scan was a few weeks old.  I performed another
scan at position 3/4 with the kernel/hardware where the card
was properly identified.  In this case, a handful of position
3/4 transponders failed to tune, again.  However, in no cases
were services received from position 1/4 during this scan


What I still haven't done, but I could do:

* scan with the frequency lists of the four positions, but on
  a different DiSEqC input, to see if the wrong switch position
  is activated and what pattern there may be (all fail to pos.
  1/4, or failures to a random input?)
* swap the PCI slot of this card as well, and play musical
  chairs until all PCI cards are found and work
* pull my hair out and wail and moan and gnash teeth
* bisect my way back to where the SkyStar stopped tuning the
  other positions reliably
* drink beer until I forget my woe and misery and blast my brane
  with dubstep until I lose the capability of emotions
* give up on this card/server and put it in a different machine
  and see if the noted problems persist

The last option is most likely, as it's my long-term goal.  The
200MHz machine is struggling with more than one full Transport
Stream on the USB inputs, and sadly can't take as many PCI
cards as I'd like.  Also, the combination of newer kernel and
OS is taking around 10MB more of the 64MB max memory, so it's
no longer as lightweight to run swapless.


The above observations are so far, just observations, and I
don't expect anyone to be able to `fix' anything

The other DVB devices have no problems tuning reliably to the
different DiSEqC inputs with the recent kernels.  Pity that
I've identified about half a dozen things that have been
broken that I need to fix before I can consider it a plug-in
replacement for the 2005-era server.

hey, thanks for listening
barry bouwsma
--
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
Luca Olivetti April 25, 2009, 5:21 p.m. UTC | #12
En/na BOUWSMA Barry ha escrit:

> The above observations are so far, just observations, and I
> don't expect anyone to be able to `fix' anything

They're nevertheless interesting, since I'm in a similar position: my 
vdr machine is using (almost flawlessly) a Skystar 2 (though I don't 
believe in this new fangled disecq thing and I use an old fashioned 
actuator to move my dish) and it's running a 2.6.17 kernel.
I'll probably have to update one day (especially if I want to keep up 
with the "latest and greatest" vdr), but I'm not really in a hurry, even 
less so seeing your problems.

Bye
BOUWSMA Barry May 7, 2009, 11:53 a.m. UTC | #13
On Sat, 25 Apr 2009, Luca Olivetti wrote:

> > The above observations are so far, just observations, and I
> > don't expect anyone to be able to `fix' anything
> 
> They're nevertheless interesting, since I'm in a similar position: my vdr
> machine is using (almost flawlessly) a Skystar 2 (though I don't believe in
> this new fangled disecq thing and I use an old fashioned actuator to move my
> dish) and it's running a 2.6.17 kernel.

Rule number one -- never upgrade a working system ;-)
Actually, it seems to be a tradeoff -- some things get fixed,
or start working, work better, and a roughly equal number of
things break.  Make sure you can trivially revert to your
known working system, or else bite the bullet, spend time
figuring out what's broken, patch, hack, patch again, before
giving up and reverting your system...

If you don't use DiSEqC to switch between different LNBs, you
may well not have a problem.  My observations have been that
I'd had little to no difficulty with services at position 1/4,
which would be tuned by a device not supporting, or not set up
to use DiSEqC switching.


> I'll probably have to update one day (especially if I want to keep up with the
> "latest and greatest" vdr), but I'm not really in a hurry, even less so seeing
> your problems.

Rather than immediately replace this card with a DVB-S2-able
device that tunes better the frequency extremes, I decided to
pull it out and experiment a bit more, in a different box.
My observations:
 ============


Here's some more info, in case it would be of interest...

I'd suffered interrupt and other problems with the test server
I'm building, having tried the SkyStar2 2.6D card in it without
major success -- apart from most transponders on position 1/4.

Generally I'd have about a 1 in 10 to maybe 1 out of 5 chance
of success when tuning the BBC radios on position 3/4 -- usually
it would appear to lock to the ZDF transponder at position 3/4.

Attempts to tune a particular transponder at 2/4 and at 4/4
would fail around 100% of the time.

Usually my first attempt after a reboot would tune successfully.

While operating, the machine somehow got in a state where the
USB ports were no longer working completely right.  Interestingly
at this time, I'd be able to tune the SkyStar and get about a
50% success rate or better when tuning 2/4 and 3/4.  Also, one
higher-frequency transponder at 1/4 which would result in a TS
with errors (and thus errors in the radio stream audio) then
tuned cleanly.

So I decided to strip as much out of the machine as possible
and play a nice round of musical PCI-slots, in case there might
be a magical slot where it would work, or where I would not
be sharing the IRQ with anything.

Unfortunately, none of the four freed slots worked with the
SkyStar perfectly.  Three of them were shown by /proc/interrupts
as sharing an IRQ; the one which did not, was shown to be sharing
the IRQ, with `lspci'.

Now, I did confirm one thing -- after each reboot, all my first
tuning attempts, regardless of position 4/4, 3/4, 2/4, or 1/4,
were always successful.  This using `dvbstream'.  Any following
attempts to repeat that tuning, or tune elsewhere, failed or
had a negligible success rate, except for position 1/4.  This
appears to be the case both for cold boots from poweroff and
for warm reboots.  It doesn't appear to affect the case of the
weak radio stream, which may be near the card's weakened
sensitivity limit (it's become this way over time, it seems),
that could vary in strength during the day.

An attempt to `scan' the transponders at 3/4 got far more of
the 1/4 transponders, and failed more than not with active 3/4
frequencies.  If there's any pattern, it could be that the
successful transponders were largely vertical, with horizontal
polarised transponders rarely tuning.  The same cable feeding
a couple external USB boxen delivered clean signals on all
tuning attempts.


Probably I do need to bisect my way from 2.6.26-ish back to
2.6.14-ish to determine where things went boom.


However, I've observed that a second PCI DVB-T card (BT878-
based) has not only failed to deliver a clean signal, but has
also resulted in normally-clean signals from USB devices
becoming similarly corrupted every minute or so, so that card
will also suffer the musical-PCI-slot treatment to see if it's
an IRQ problem.

And if I motivate myself, I'll see about trying the SkyStar
in the two used slots, or trying to give it a truly-free IRQ.
By which time I'll probably have become insane trying to keep
track of which cards get which IRQs in which slots.

Man, sometimes I wish PC hardware weren't so illogical, or
that the logic were to be clearer...



Preliminary results of juggling BT878-DVB-T card -- if it is
sharing its IRQ with either my EHCI card (NEC, IRQ10), or
the sound card (CMIPCI, IRQ7) at boot, the machine will lock
up solid.  Presumably an interrupt storm, or something, as I
know little about such.  Otherwise it appears to work fine,
though with a few cards still missing.  Experimentation continues.
The corrupted streams I observed earlier haven't repeated.

Unfortunately, after quite some time, one USB device goes
wacky, some others continue to work, but no USB plug events
are recognised, `lsusb' hangs, and looks like time to reboot.  
Grrr.

barry bouwsma
--
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

Patch
diff mbox

diff -r 7981bdd4e25a linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c	Mon Jan 12 00:18:04 2009 +0000
+++ b/linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c	Fri Jan 16 15:46:32 2009 +0100
@@ -179,7 +179,7 @@ 
 
 	/* if it was the first or last feed request change the stream-status */
 	if (fc->feedcount == onoff) {
-		flexcop_rcv_data_ctrl(fc,onoff);
+		flexcop_rcv_data_ctrl(fc, onoff);
 		if (fc->stream_control) /* device specific stream control */
 			fc->stream_control(fc,onoff);
 
@@ -192,6 +192,7 @@ 
 
 	return 0;
 }
+EXPORT_SYMBOL(flexcop_pid_feed_control);
 
 void flexcop_hw_filter_init(struct flexcop_device *fc)
 {
diff -r 7981bdd4e25a linux/drivers/media/dvb/b2c2/flexcop-pci.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-pci.c	Mon Jan 12 00:18:04 2009 +0000
+++ b/linux/drivers/media/dvb/b2c2/flexcop-pci.c	Fri Jan 16 15:46:32 2009 +0100
@@ -13,9 +13,9 @@ 
 module_param(enable_pid_filtering, int, 0444);
 MODULE_PARM_DESC(enable_pid_filtering, "enable hardware pid filtering: supported values: 0 (fullts), 1");
 
-static int irq_chk_intv;
+static int irq_chk_intv = 100;
 module_param(irq_chk_intv, int, 0644);
-MODULE_PARM_DESC(irq_chk_intv, "set the interval for IRQ watchdog (currently just debugging).");
+MODULE_PARM_DESC(irq_chk_intv, "set the interval for IRQ streaming watchdog.");
 
 #ifdef CONFIG_DVB_B2C2_FLEXCOP_DEBUG
 #define dprintk(level,args...) \
@@ -34,7 +34,7 @@ 
 
 static int debug;
 module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, "set debug level (1=info,2=regs,4=TS,8=irqdma (|-able))." DEBSTATUS);
+MODULE_PARM_DESC(debug, "set debug level (1=info,2=regs,4=TS,8=irqdma,16=check (|-able))." DEBSTATUS);
 
 #define DRIVER_VERSION "0.1"
 #define DRIVER_NAME "Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver"
@@ -58,6 +58,8 @@ 
 	int active_dma1_addr; /* 0 = addr0 of dma1; 1 = addr1 of dma1 */
 	u32 last_dma1_cur_pos; /* position of the pointer last time the timer/packet irq occured */
 	int count;
+	int count_prev;
+	int stream_problem;
 
 	spinlock_t irq_lock;
 
@@ -115,18 +117,47 @@ 
 #endif
 	struct flexcop_device *fc = fc_pci->fc_dev;
 
-	flexcop_ibi_value v = fc->read_ibi_reg(fc,sram_dest_reg_714);
+	if (fc->feedcount) {
+		flexcop_ibi_value v = fc->read_ibi_reg(fc,sram_dest_reg_714);
 
-	flexcop_dump_reg(fc_pci->fc_dev,dma1_000,4);
+		//	flexcop_dump_reg(fc_pci->fc_dev,dma1_000,4);
 
-	if (v.sram_dest_reg_714.net_ovflow_error)
-		deb_chk("sram net_ovflow_error\n");
-	if (v.sram_dest_reg_714.media_ovflow_error)
-		deb_chk("sram media_ovflow_error\n");
-	if (v.sram_dest_reg_714.cai_ovflow_error)
-		deb_chk("sram cai_ovflow_error\n");
-	if (v.sram_dest_reg_714.cai_ovflow_error)
-		deb_chk("sram cai_ovflow_error\n");
+#if 0
+		deb_chk("net_ovflow_error: %d, media_ovflow_error: %d, cai_ovflow_error: %d, cao_ovflow_error: %d, sram_dma: %d, maximumfill: %d\n",
+				v.sram_dest_reg_714.net_ovflow_error,
+				v.sram_dest_reg_714.media_ovflow_error,
+				v.sram_dest_reg_714.cai_ovflow_error,
+				v.sram_dest_reg_714.cao_ovflow_error,
+				v.sram_dest_reg_714.ctrl_sramdma,
+				v.sram_dest_reg_714.ctrl_maximumfill);
+#endif
+
+		if (fc_pci->count == fc_pci->count_prev) {
+			deb_chk("no IRQ since the last time\n");
+			if (fc_pci->stream_problem++ == 3) {
+				struct dvb_demux_feed *feed;
+				int t = 0;
+
+				/* work-queue is atomic -> cannot
+				 * take the demux.lock here, but is it needed? XXX
+				 * spin_lock_irq(&fc->demux.lock); */
+				list_for_each_entry(feed, &fc->demux.feed_list, list_head) {
+					flexcop_pid_feed_control(fc, feed, 0);
+					t++;
+				}
+
+				list_for_each_entry(feed, &fc->demux.feed_list, list_head) {
+					flexcop_pid_feed_control(fc, feed, 1);
+				}
+				/* spin_unlock_irq(&fc->demux.lock); */
+
+				fc_pci->stream_problem = 0;
+			}
+		} else {
+			fc_pci->stream_problem = 0;
+			fc_pci->count_prev = fc_pci->count;
+		}
+	}
 
 	schedule_delayed_work(&fc_pci->irq_check_work,
 			msecs_to_jiffies(irq_chk_intv < 100 ? 100 : irq_chk_intv));
@@ -232,16 +263,12 @@ 
 		flexcop_dma_control_timer_irq(fc,FC_DMA_1,1);
 		deb_irq("IRQ enabled\n");
 
+		fc_pci->count_prev = fc_pci->count;
+
 //		fc_pci->active_dma1_addr = 0;
 //		flexcop_dma_control_size_irq(fc,FC_DMA_1,1);
 
-		if (irq_chk_intv > 0)
-			schedule_delayed_work(&fc_pci->irq_check_work,
-					msecs_to_jiffies(irq_chk_intv < 100 ? 100 : irq_chk_intv));
 	} else {
-		if (irq_chk_intv > 0)
-			cancel_delayed_work(&fc_pci->irq_check_work);
-
 		flexcop_dma_control_timer_irq(fc,FC_DMA_1,0);
 		deb_irq("IRQ disabled\n");
 
@@ -315,8 +342,6 @@ 
 					IRQF_SHARED, DRIVER_NAME, fc_pci)) != 0)
 		goto err_pci_iounmap;
 
-
-
 	fc_pci->init_state |= FC_PCI_INIT;
 	return ret;
 
@@ -395,6 +420,10 @@ 
 	INIT_DELAYED_WORK(&fc_pci->irq_check_work, flexcop_pci_irq_check_work);
 #endif
 
+	if (irq_chk_intv > 0)
+		schedule_delayed_work(&fc_pci->irq_check_work,
+				msecs_to_jiffies(irq_chk_intv < 100 ? 100 : irq_chk_intv));
+
 	return ret;
 
 err_fc_exit:
@@ -412,6 +441,9 @@ 
 static void flexcop_pci_remove(struct pci_dev *pdev)
 {
 	struct flexcop_pci *fc_pci = pci_get_drvdata(pdev);
+
+	if (irq_chk_intv > 0)
+		cancel_delayed_work(&fc_pci->irq_check_work);
 
 	flexcop_pci_dma_exit(fc_pci);
 	flexcop_device_exit(fc_pci->fc_dev);