[linux-dvb] Re: Trouble usings AverTV dvb-t 771 (2.6.10-rc1) && PVR 2/350 (ivtv-0.2.0l) at same time

[Jan Dölle <linux-dvb@jan-doelle.de>]

Am Sonntag, 7. November 2004 23:03 schrieb Hamish Moffatt:
> 
> Hooray! Someone else has the same problem I do :-)
> I have two DVB cards in my system.
> 

Also hooray, because I start to thing, I am to stupit for all this linux  
stuff (started half year ago with debian) and have to install a M$-MC --- No, 
not realy an option ;-)

> 
> You can fiddle with the PCI latencies, using setpci or powertweak or
> similar. I never found a value that made it go away permanently. 

I know what you mean, I played also a lot with the latency but finaly I give 
up :-(

> 
> The DVB cards use the BT878 audio path to transfer data. The FIFOs are
> big enough for audio data with a reasonable PCI latency, which would be
> about 1.4 Mbit/s at CD quality rates, but instead we are transferring
> DVB data at 10+ Mbit/s through the same FIFOs. I don't think they are
> adequate, but nothing can be done.

Hell - that sounds for me, that it will be a long-term issus.

> 
> I was experiencing the lockup problem regularly. When it gets more than 20, 
> it assumes that the interrupt has locked up and will never go away.
> What I've found is that the limit of 20 consecutive interrupts is too low - 
> I increased it to 100 here and I haven't had any more problem.
> I have the driver log when it gets to more than 20, which happens
> occasionally.

Does that mean that this lockup is final fallback to prevent the system for 
IRQ disaster? What does it mean to the system I we changed the lockup to a 
higher value? Are there any results like hanging, performance issues, 
sablility or interference with other drivers?

> 
> I have been meaning to modify my kernel again to log just how many
> interrupts it got to before it cleared. It's obviously > 20 and < 100.
> 
> A quick mod to your kernel to test my theory would be to find the line
> in drivers/media/dvb/bt8xx/bt878.c in bt878_irq() which says:
> 
>                 if (count > 20) {
> 
> and increase the number.
> 
> Please let me know if this helps you. If it does, I'll propose a patch
> to linux-dvb to increase the limit.

Bingo,

I change in bt878.c:
if (bt878_verbose && count > 20) 
and
if (count > 100)
and everything look fine :-) 

I force the system roundabout 2 Hour, with multible recordings while view 
recordings .... and not lockup any more.

Very interesting is that I get not (bt878(0): irq FDSR risc_pc=xxxxxx) 
messages any more. 
But normal I should get some as before when count > 20. So maybe the message 
logging itself make the situtation also worse. This remembers me a little bit 
to my past, when I was write some DOS Driver with an Interrupt handler. The 
golden rules was: If your interrupt handler was call, leave it fast as 
possible and message logging wasn't fast. But but this was DOS and an 
ISA-Card and I have no Idea how the game is played today with Linux.

So I will force my system the next days and will see If your modifikation will 
avoid the problem. 

Thanks a lot 
Cheers Jan