Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Pinnacle PCTV
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.
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 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.
To unsubscribe send a mail to email@example.com with "unsubscribe linux-dvb" as subject.
Main Index |