[linux-dvb] Possible race condition in tuning

[Ralph Metzler <rjkm@convergence.de>]

Klaus Schmidinger writes:
 > I believe there is a possible race condition in dvb.c's 'mon_tune()'
 > function.
 > 
 > The function first sets dvb->mon_tuning=2, which triggers mon_zigzag()
 > to do its zig-zag tuning, and then sets dvb->mon_fstate=1. If the scheduler
 > switches tasks just after the dvb->mon_tuning=2 and before the dvb->mon_fstate=1,
 > and if the previous call to mon_zigzag() counted the dvb->mon_fstate all the way
 > up to 20, mon_zigzag() may fail immediately, instead of doing a zig-zag search.

How should this happen?
The process will of course be continued right after the dvb->mon_tuning=2;
How should it end up in mon_zigzag() before finishing mon_tune()?
There is no other process belonging to the same dvb structure which
calls mon_zigzag() or mon_thread(). Even if there were, it would be
stopped by the semaphore.
The only other function which messes with dvb->mon_tuning and runs in
a different process is mon_do_tune() and it also uses the semaphore.

Did your patch change anything for you?


Btw., I still cannot reproduce those "tuning problems".
I had your "ctest" running for 2 hours and had no problems. 

Do you also have those problems when not using a CAM?

I sometimes (very rarely) have problems with DiSEqC switching but only
with one specific switch. With another switch I have no problems.
But since it is connected to a different card and PC the problem could
also be there.


Ralph






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