Hi,

I tried to use 0.9.4, but it didn't compile with my 2.4.22 kernel.

For not doing nothing while waiting my budget card, I was doing some other research 
and tests. There is some interesting problems around the closing of the frontend. 
Looks like things are not released correctly and some others get corrupted. Let me 
explain the 3 different things I can witness:

1) With my full blown application (multithread and that setups around 12 filters 
dynamically from different threads, remove them and tune), I cannot close the 
frontend. I call the close function and no error is reported, but then I cannot 
re-open it without re-starting my application (CTRL-C). I've put dvb_frontend_debug=1 
for the dvb-core module and I don't see the call to dvb_frontend_release when I call 
close(frontEnd). Which explain why the close is ineffective. Here, I can only guess 
that it is multithreading related... note that my kernel has the preempt option 
enabled. Does the drivers support that?

2) With my test application (in attachment in the second email of that thread), if I 
open and close the frontend at each iteration of my loop, everything works great and I 
see the call to dvb_frontend_release.

3) If I put a sleep(x) after the close, and x>dvb_shutdown_timeout then the next tune 
will fail and you see the zigzag algorithm kick in trying endlessly to find a signal. 
I've put a test software that reproduce that everytime in attachment.

>From those 3 observations, I can guess there is two different bugs around the 
>frontend:

A) A critical ressource is not well protected and the kernel loses some information 
about the frontend filedescriptor after some weird combination of operation. It's 
maybe due to CONFIG_PREEMPT=y.

B) The frontend goes into a bad state after the dvb_shutdown_timeout.

I'm trying to find what's wrong in the DVB code, but if you guys can tell me what you 
think of all this, I'll be more than happy.

Thanks.

Attachment: dvbBug.tar.bz2
Description: dvbBug.tar.bz2

Reply via email to