Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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.71] b2c2-flexcop: stv0299_attach succeeded... [ 18.71] b2c2-flexcop: found 'ST STV0299 DVB-S' . [ 18.71] DVB: registering frontend 1 (ST STV0299 DVB-S)... [ 18.71] 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
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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 -- Luca -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC - Flexcop Streaming watchdog (VDSB)
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.boettc...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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.boettc...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC - Flexcop Streaming watchdog (VDSB)
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.boettc...@desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/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 +
+++ 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.cMon Jan 12 00:18:04
2009 +
+++ b/linux/drivers/media/dvb/b2c2/flexcop-pci.cFri 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,
+
Re: [linux-dvb] RFC - Flexcop Streaming watchdog (VDSB)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
