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

[Johannes Stezenbach <js@linuxtv.org>]

Michael Hunold wrote:
> On 18.10.2004 17:15, syrius.ml@no-log.org wrote:
> >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.

The specific problem here seems to be that the debi irq happens before
av7110->debitype is valid. Maybe this could be solved by declaring
it volatile (along with a few other related variables shared between the
two tasklets), and adding a wmb() after the assignments and before the
debi transfer is started.

@Michael: Do the psr and ssr values mean something to you and do they
look sane?

> >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.

I think this is the first DATA_MPEG_VIDEO_EVENT sent by the firmware
before things are properly initialized. It is harmless.

Johannes