[linux-dvb] SMP problems with dvb-ttpci (was: Re: testing refactoreddrivers)

[Michael Hunold <hunold-ml@web.de>]

Hi,

On 18.10.2004 17:15, syrius.ml@no-log.org wrote:
> using 2.6.9-final + SMP (no preempt, no irqbalancing, etc)
> sorry be a pain in the *beep*, but i really like to hear about
> those SMP issues.
> I understand work is being concentrated on FE_REFACTORING but i'd love
> to read about SMP.
To make it short: the current av7110 / dvb-ttpci driver is *not* SMP 
safe. Don't use it. Patches are appreciated, though.

> > From what i read in the archives a lot of people use to have
> crash/freeze.
> I'm lucky here, it doesn't freeze my system, just those messages:
> kernel: DEBI irq oops @ 2819257, psr:0x00040128, ssr:0x00800030
> kernel: dvb-ttpci: GPIO0 irq oops @ 2819322, psr:0x00040020,
> ssr:0x00800030
In short: the av7110 issues a gpio irq, so the card can read out what 
type of data the next transfer will be. Then the actual data transfer is 
started via the debi interface. The debi irq then signals when the 
transfer is finished. Both debi and gpio irq handlers are realised via 
tasklets, so they can be scheduled on different CPUs if you have a SMP 
system.

I don't have a system to investigate this by myself, but I think that 
there is a race condition with regard to the tasklets.

To solve this problem, the gpio and debi handling must be unified again, 
as it was with previous versions of the drivers, where the handling was 
done inside the irq handler directly. Both functions should be put 
inside on tasklet, but this is not trivial.

> BTW, what does that mean ? ( when loading the driver )
> dvb-ttpci: gpioirq unknown type=0 len=0
A spurious interrupt after firmware loading. Doesn't hurt, so nobody 
cared to investigate this any further.

> Ok, apart from complaining, I have to say i've upgraded to
> FE_FACTORING and it seems to be working fine.
> Thanks for your work.
Good to hear.

CU
Michael.