[vdr] VDR gets somehow stuck and consumes all CPU time

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Sat Dec 10 12:13:25 CET 2005


Paavo Hartikainen wrote:
> Johannes Stezenbach <js at linuxtv.org> writes:
> 
> 
>>The patch below might help, gettid() returns the PID of the
>>thread. (And since it's a syscall it is independent of NPTL
>>vs. linuxthreads. Tested on 2.6 only, but the gettid man page says
>>it's available in 2.4.20.  gettid() is Linux specific.)
> 
> 
> Before patch:
> ---
> Dec  3 05:27:30 sarabi vdr[22722]: tuner on device 1 thread started (pid=22722, tid=822543584)
> Dec  3 05:27:32 sarabi vdr[22722]: tuner on device 2 thread started (pid=22722, tid=814154976)
> ---
> 
> After patch:
> ---
> Dec  5 04:31:46 sarabi vdr[27624]: tuner on device 1 thread started (pid=27624, tid=-1)
> Dec  5 04:31:48 sarabi vdr[27624]: tuner on device 2 thread started (pid=27624, tid=-1)
> ---
> 
> After patch and "env LD_ASSUME_KERNEL=2.4.1":
> ---
> Dec  5 04:35:01 sarabi vdr[27641]: tuner on device 1 thread started (pid=27641, tid=-1)
> Dec  5 04:35:03 sarabi vdr[27644]: tuner on device 2 thread started (pid=27644, tid=-1)
> ---

This would indicate that the gettid() call has failed (returned -1).

What system is this happening on?
I tested it here on a SUSE 8.2 (kernel 2.4.20) and SUSE 10.0 (kernel 2.6.13),
and it worked fine on both of them. On the kernel 2.4.20 system it
returned the same value as the getpid() call, and on the 2.6.13 system
it returned pid values that were counted upwards from the main thread's
pid.

Klaus



More information about the vdr mailing list