[vdr] Re: Avoiding NPTL problems

[Ludwig Nussel <ludwig.nussel@gmx.de>]

Klaus Schmidinger wrote:
> Since there are apparently still massive problems with running
> VDR on an NPTL system, and I currently don't plan to set up an
> NPTL system myself and spend time debugging this, and also because
> the patches suggested by Werner Fink <werner@suse.de> in the
> "Driver or VDR Problem setting and jusageing cutmarks on Nexus 2.1"
> and Ludwig Nussel <ludwig.nussel@gmx.de> in the "[PATCH] NPTL" thread
> change a bit too much for my taste (maybe that is all necessary after
> all, but I just can't verify it myself now)

If you refer to the LOCK_THREAD's, that was a brute force method to
get a feeling for what is happening. Certainly not all of them are
necessary or can at least be split into finer grained mutexes.

With regard to removing the usleeps, that's necessary as far as I
can tell since the manpage of nanosleep (usleep is wrapper for
nanosleep) says

'If the process is scheduled under a real-time policy like
SCHED_FIFO or SCHED_RR, then pauses of up to 2 ms will be performed
as busy waits with microsecond precision.'

According to this the scheduler would not switch to another thread
during the usleep which would explain why it causes hangs.

There are other usleeps in recorder.c and transfer.c and
coincidentally recording also has problems with NPTL.

> I know this is not a fix, just a workaround, but since everything appears
> to run fine with 'LD_ASSUME_KERNEL=2.4.1' I guess it is better to stop
> VDR right at the beginning than let it run a while and get into trouble
> later.

Use 2.4.21 instead, that's what I was told to use for SUSE 9.1.

> Attached is a patch against VDR 1.3.10 that implements this.
> I would appreciate if somebody with an NPTL system could check
> if this actually works.
> 
> If somebody knows of a way in which VDR could turn off NPTL at runtime,
> that would be even better. I don't believe simply doing
> 
>  setenv("LD_ASSUME_KERNEL", "2.4.1", 1);
> 
> at program start (from inside VDR) would be enough, or would it?

I doubt it since that's already decided when vdr enters main(). vdr
would need to exec itself after that. IMHO a better place for
setting the variable would be the runvdr script anyway.

cu
Ludwig

-- 
(o_  Ludwig.Nussel@gmx.de
//\  PGP Key ID: FF8135CE
V_/_ ICQ:        52166811