Am Donnerstag 26 Mai 2005 18:12 schrieb Pietlek:

Hello everyone,

I have got a problem with runnig vdr under kernel-2.6.11.10 and glibc-2.3.90-0.20050415.3.

pietlek@home vdr-1.3.23]$ ./vdr

vdr: please turn off NPTL by setting 'export LD_ASSUME_KERNEL=2.4.1' before starting VDR

Setting LD_ASSUME_KERNEL doesn't help.

[pietlek@home vdr-1.3.23]$ LD_ASSUME_KERNEL=2.4.1 ./vdr ./vdr: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

The same is with LD_ASSUME_KERNEL=2.4.19 and vdr-2.3.24.

thx P.

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Hi,

you are using LFS or Gentoo or any other distribution with a nptl-only glibc. LD_ASSUME_KERNEL won't help you. Use VDR 1.3.24 and remove the nptl check in vdr.c. This version should work with nptl.

S.

Ulf Elsner schrieb:

Am Donnerstag, 26. Mai 2005 18:31 schrieb Sebastian Frei:

...

Am Donnerstag 26 Mai 2005 18:12 schrieb Pietlek:

[...]

...

...

pietlek@home vdr-1.3.23]$ ./vdr

vdr: please turn off NPTL by setting 'export LD_ASSUME_KERNEL=2.4.1' before starting VDR

Setting LD_ASSUME_KERNEL doesn't help.

[pietlek@home vdr-1.3.23]$ LD_ASSUME_KERNEL=2.4.1 ./vdr ./vdr: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

[...]

...

you are using LFS or Gentoo or any other distribution with a nptl-only glibc. LD_ASSUME_KERNEL won't help you. Use VDR 1.3.24 and remove the nptl check in vdr.c. This version should work with nptl.

Hello everyone,

i'm experiencing the same problem with amd64. I'm using debiam-amd64/sid and they ship a nptl-only-glibc, too. So export LD_ASSUME_KERNEL doesn't work. As Sebastian suggested I removed the nptl-check in vdr.c (actually I just commented out the exit code, so vdr is complaining but running). But it seems, as if there are still problems with nptl: sometimes vdr isn't responding to any input (keys, remote control) for several minutes and then it seems to be ok again. some recordings I made are started too late, I guess about 5 mins after the 'official' starting time. As a second system I'm running a debian-i386/sarge on the same machine. That system has both nptl and linux-threads and vdr is running perfectly! So it might be, that vdr still has problems with nptl. don't you have these problems on your system, sebastian?

cheers,

Ulf

---

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

No, VDR is running fine on i686 nptlonly here. Maybe it's because your whole box is compiled for 64bit and VDR doesn't like _that_ yet?

Cheers

Sebastian

sebastian_ml@gmx.net(Sebastian) 28.05.05 15:14

...

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Why do you quote this siganture(and all text)?

No, VDR is running fine on i686 nptlonly here. Maybe it's because your whole box is compiled for 64bit and VDR doesn't like _that_ yet?

Multitasking systems (not thread save) "degree of suffering" depends strongly on the involved hardware. Generally it can't be predicted if a higher/faster CPU is worser than a slower. But (very) mostly a faster CPU will spill up all unclean codings... Too new "threads" will spill them up, but mostly the innocent new thread will be flamed. (Example: Product works in the labor flawlesly, in the manufacturing area too, but fails at the first customer. Workarround? Wire "DTR" to "asserted" so the software thinks a V24-terminal is connected, as it was in the labor and the test area... Because of the long sleeps during the serial output, the dead locking/amok running/racing/eating all CPU tasks releases their CPU slice often enough so the other workers can deliver the data, the amok thread is waiting for.. IOW: the product worked without V24 too, but in extrem slowmotion, but there are timing checks built in (First programmers always ignored law: Never trust any code! Second programmers always ignored law: Never trust any parameters or data!), so the box dies with "timeout". Because of these "superflous" redundant time checks (we don't make any errors, so verifying parameters is waste of run and programmig time) the problem became obvious very early (actually still too late, but who is perfect?)

Rainer

Sebastian Frei schrieb:

Am Samstag 28 Mai 2005 15:01 schrieb Ulf Elsner:

...

Am Donnerstag, 26. Mai 2005 18:31 schrieb Sebastian Frei:

...

Am Donnerstag 26 Mai 2005 18:12 schrieb Pietlek:

[...]

...

...

pietlek@home vdr-1.3.23]$ ./vdr

vdr: please turn off NPTL by setting 'export LD_ASSUME_KERNEL=2.4.1' before starting VDR

Setting LD_ASSUME_KERNEL doesn't help.

[pietlek@home vdr-1.3.23]$ LD_ASSUME_KERNEL=2.4.1 ./vdr ./vdr: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

[...]

...

you are using LFS or Gentoo or any other distribution with a nptl-only glibc. LD_ASSUME_KERNEL won't help you. Use VDR 1.3.24 and remove the nptl check in vdr.c. This version should work with nptl.

Hello everyone,

i'm experiencing the same problem with amd64. I'm using debiam-amd64/sid and they ship a nptl-only-glibc, too. So export LD_ASSUME_KERNEL doesn't work. As Sebastian suggested I removed the nptl-check in vdr.c (actually I just commented out the exit code, so vdr is complaining but running). But it seems, as if there are still problems with nptl: sometimes vdr isn't responding to any input (keys, remote control) for several minutes and then it seems to be ok again.

Try disabling EPG Scan. I have this problem too with EPG scan enabled. Maybe this is a remaining NPTL bug.

S.

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Hello!

I just want to add that I read about 64bit and EPG scan at vdr-portal. But it wasn't related to nptl afaik. It just doesn't seem to work on 64bit, no matter nptl or linuxthreads are used. Examples: http://vdr-portal.de/board/thread.php?threadid=14042 http://vdr-portal.de/board/thread.php?threadid=31667 http://vdr-portal.de/board/thread.php?threadid=27845

Try recompiling VDR and plugins with this is $VDR_source/Make.config CFLAGS = -O2 -march=athlon64 -fPIC -DPIC CXXFLAGS = -O2 -march=athlon64 -fPIC -DPIC (was suggested in the second thread I just posted)

Cheers

Sebastian