Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: SMP problems with dvb-ttpci (was: Re: testing refactored drivers)
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
Home |
Main Index |
Thread Index