[linux-dvb] Re: Pinnacle PCTV

[peter.hettkamp@t-online.de (Peter Hettkamp)]

Hi Michael,

On Mon, Aug 05, 2002 at 09:18:23PM +0200, michael.smutka@ycn.com wrote:
> 
> Hi Peter
> 
>  > I suppose you are right. I know there is a condition in my current
>  > driver which causes the kernel to lock up; this is mostly triggered
>  > when the frontend loses lock.
> 
> Is it possible to reproduce? Maybe by a weak signal?
Exactly. I can easily occlude my dish. Practically every time I do this,
the kernel hangs. Occasionally this also happens while trying to tune
to a weak signal (e.g. while scanning for signals)

> 
>  > I am afraid I don't see why DvbDmxSWFilterPackets() needs to be called
>  > with interrupts disabled, can you please enlighten me?
> 
> Just pattern matching. 
> 
> DvbDmxSWFilterPackets() is called from fidbirq() and debiirq(), which
> I suppose from the function name are running in interrupt context.
Yes, these are the interrupt handlers in the siemens driver. I decided to
move this out from interrupt context and into a tasklet because I have
more work to do (the hardware does not synchronize on ts packet borders),
so I thought this might be The Better Way:-) to do this.

> 
>  > I'll just test if your patch woks with my system as well, then have it
>  > included into the experimental-pinnacle branch.
> 
> Please use spin_lock_irqsave/restore, to not annoy others, by enabling
> interrupts when they suppose they are off. I didn't think of that the
> first time.
Yes. I confess I did not see at first that your patch is in dvb_demux.c.
I did never touch this file, it was taken unchanged from the siemens driver.
So, it HAS to be _irqsave/_irqrestore, in order to integrate with the
standard driver again.

> 
>  > P.S.: I have no idea why SMP kernels lock up, but I am pretty positive
>  > I made some mistake with the spin_locks. Obviously, I do not quite
>  > understand spin_locking :-(
> 
> Since it occurs instantly on every try I think it should be something
> easy to find, like trying to aquire a lock twice.
I agree that it is probably acquiring a lock twice which causes the problem.
After all, on UP a spin_lock vanishes. I fear I will need to build a SMP
kernel with spinlock debugging enabled to find this :-(
My own spin_lock is simple: the irq handler acquires the lock, updates the
data structure, releases the lock. The tasklet takes the lock and disables
interrupts, locates the ts packet boundaries, calculates the call parameters
for the demuxer, updates the data structure, then releases the lock and
re-enables interrupts. The calls to the demuxer are done only when I have
released my own lock. So, I do not really see where I grab a lock twice.
But it may happen, of course, in those code parts I simply used without
analysing them for spin_lock mishaps. Thank you very much for pointing
this out.

Best Regards,
Peter
-- 
"Only wimps use tape backup: _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it ;)"
(Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi)


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