[linux-dvb] Re: Pinnacle PCTV

[Michael Rickmann <mrickma@gwdg.de>]

Hello Peter,
thanks a lot for your patient help. To cut things short, it is working now 
beautifully for me, and the culprit was in my system. I decided to give up 
digging in the sources.

> 193 per second. Thus, the interrupt rate is not extraordinarily high.

It was apparent that something was mixing up DMA at the afore mentioned 
intervall of about 5 sec. When I was watching my computer 
(Athlon-700MHz, via-kx133 chipset) I realized that the hardisk light
was active at about that frequency - grabbing to a  r e i s e r f s  
partition. When I startet to record to vfat all my problems were gone. I 
guess it is the same with ext2, but I don't have any ext2 partitions large 
enough to hold a stream. I will change that as soon as possible.
Here an example log covering nearly 40 min, BBC-World again:

17:40:09 michaels kernel: bttv0: IRQ lockup, cleared int mask
17:40:09 michaels kernel: pctv debug: tasklet: no do r=0, w=0
17:47:20 michaels kernel: bt878(0): irq FBUS risc_pc=0efe6118
17:47:55 michaels kernel: bt878(0): irq FBUS risc_pc=0efe6128
17:54:07 michaels kernel: pctv debug: tasklet: no do r=3, w=2  <--offset 13:58
17:54:07 michaels kernel: pctv debug: tasklet: no do r=3, w=3
17:54:07 michaels kernel: pctv: panic, less than 188 Bytes left and no sync. 
Program me!
18:01:26 michaels kernel: bt878(0): irq FBUS risc_pc=0efe6038
18:01:26 michaels kernel: bt878(0): irq FBUS risc_pc=0efe6050
18:01:41 michaels kernel: bt878(0): irq FBUS risc_pc=0efe6040

PVAstrumento found only one spot with a stream error,

ALERT> Audio frame too long at 06:53:33.067
ALERT> Audio misalignement (at start of chunk)
ALERT> Audio misalignement (at start of chunk) 00:13:57.635    <------ no do
ALERT> 7 audio frames missing at 00:13:57.635
ALERT> 2 audio frames missing at 00:13:58.091
ALERT> 12 audio frames missing at 00:39:39.563  <-- usually happens at the end

and I am not shure that I could notice it during play back. Your driver seems 
to do fine unless some other device grabs DMA for too long.

> > 06:09:29  kernel: pctv debug: tasklet: writebuf 0, expected 3, read 1
> > 06:09:29  kernel: bt848 debug: writebuf 0, expected 3
> > 06:09:29  kernel: bt848 debug: writebuf 1, expected 0
>
> Where are these debug messages signalled?
2, 3) directly after the wake_up_interruptible before the tasklet is scheduled 
from the interrupt routine
1) at thevery beginning of the tasklet

When studying the code and doing recordings I realized two things:
1) You do not need any spinlocks in the bt848-interrupt routine and the 
tasklet when you declare writebuf volatile and, in the tasklet, work with a 
copy of it which you make at the beginning. Every time a tasklet has startet 
execution, a new interrupt will queue up another instance - at least 
kernel sources say so. Perhaps it would be more honest to use atomic 
operations on writebuf - for i386 they end up in operations on volatile.
2) The wrap around buffer in the tasklet lives on stack. It should be static, 
or put it into  the struct bt878 (see tsbuf[188] in dvb_demux.h), just in 
case somebody tries to use more than one PCTV-sat.

> > 06:09:39  kernel: pctv: panic, less than 188 Bytes left and no sync.
> > Program me!
> The (re-)synchronization code is not in a very good shape currently. In
> order to avoid falling for a 0x47 within the data stream, it wants to make
> sure there is another one exactly one TS_SIZE beyond. This is made more
> difficult by crossing buffer borders, and the buffer wraparound location.
> It also contains an error which may trigger a kernel oops.
> This message, however, is just a placeholder for a piece if synchronization
> code I never wrote.

Perhaps I can help a bit. I will have some time during next weekend to fill in 
the "less than 188 byte panic" and to make shure a sync check is done at 
every new block DMA has written. I will send it to you.
Thanks again.
Regards
Michael



--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.