| Message ID | alpine.LRH.1.10.0901161548460.28478@pub2.ifh.de (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
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
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
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
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
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
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
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
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
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
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
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
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
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
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);