Hi,
attached patch should make the rcu code NPTL compatible. Without the patch using an RCU will fail (vdr hang during startup) on an NPTL enabled system.
I have only move over L. Nussels lirc NPTL fix to the rcu code.
Greetings
Andreas
--- rcu.c.org 2005-10-21 23:29:58.000000000 +0200 +++ rcu.c 2005-10-21 23:29:36.000000000 +0200 @@ -53,7 +53,11 @@
cRcuRemote::~cRcuRemote() { + int fh = f; + f = -1; Cancel(); + if (fh >= 0) + close(fh); }
bool cRcuRemote::Ready(void) @@ -100,7 +104,6 @@
while (Running() && f >= 0) {
- LOCK_THREAD;
if (ReceiveByte(REPEATLIMIT) == 'X') { for (int i = 0; i < 6; i++) { @@ -192,7 +195,6 @@
bool cRcuRemote::SendByte(unsigned char c) { - LOCK_THREAD;
for (int retry = 5; retry--;) { if (SendByteHandshake(c)) @@ -225,7 +227,6 @@
bool cRcuRemote::Number(int n, bool Hex) { - LOCK_THREAD;
if (!Hex) { char buf[8]; @@ -248,7 +249,6 @@
bool cRcuRemote::String(char *s) { - LOCK_THREAD;
const char *chars = mode == modeH ? "0123456789ABCDEF" : "0123456789-EHLP "; int n = 0;
Andreas Share wrote:
Hi,
attached patch should make the rcu code NPTL compatible. Without the patch using an RCU will fail (vdr hang during startup) on an NPTL enabled system.
I have only move over L. Nussels lirc NPTL fix to the rcu code.
Greetings
Andreas
Have you actually tested this? I wonder if simply removing all lock calls would work, because there _is_ a thread and a foreground function that both want to transfer data...
Klaus
--- rcu.c.org 2005-10-21 23:29:58.000000000 +0200 +++ rcu.c 2005-10-21 23:29:36.000000000 +0200 @@ -53,7 +53,11 @@
cRcuRemote::~cRcuRemote() {
- int fh = f;
- f = -1; Cancel();
- if (fh >= 0)
close(fh);}
bool cRcuRemote::Ready(void) @@ -100,7 +104,6 @@
while (Running() && f >= 0) {
LOCK_THREAD; if (ReceiveByte(REPEATLIMIT) == 'X') { for (int i = 0; i < 6; i++) {@@ -192,7 +195,6 @@
bool cRcuRemote::SendByte(unsigned char c) {
LOCK_THREAD;
for (int retry = 5; retry--;) { if (SendByteHandshake(c))
@@ -225,7 +227,6 @@
bool cRcuRemote::Number(int n, bool Hex) {
LOCK_THREAD;
if (!Hex) { char buf[8];
@@ -248,7 +249,6 @@
bool cRcuRemote::String(char *s) {
LOCK_THREAD;
const char *chars = mode == modeH ? "0123456789ABCDEF" :
"0123456789-EHLP "; int n = 0;
----- Original Message ----- From: "Klaus Schmidinger" Klaus.Schmidinger@cadsoft.de To: vdr@linuxtv.org Sent: Friday, November 04, 2005 4:40 PM Subject: Re: [vdr] [PATCH] rcu NPTL fix for 1.3.34
Andreas Share wrote:
Hi,
attached patch should make the rcu code NPTL compatible. Without the patch using an RCU will fail (vdr hang during startup) on an NPTL enabled system.
I have only move over L. Nussels lirc NPTL fix to the rcu code.
Greetings
Andreas
Have you actually tested this? I wonder if simply removing all lock calls would work, because there _is_ a thread and a foreground function that both want to transfer data...
Klaus
Yes, i have tested the patch on my system. With the lock´s the rcu-code block vdr completely during startup with NPTL enabled libraries, especialy this ones in /lib/tls. LD_ASSUME_KERNEL doesn´t work for this problem, only moving the tls-folder away from /lib (and do a ldconfig afters this) have let the rcu work again on my suse 9.1.
Removing the lock in the main loop only will resolve this, but IR learning will fail, so i have removed the other locks also.
With the patch vdr/rcu (learning included) works without any sideeffect in daily use since 21.10. on my system (internal IR-Header, DBox IR Codes).
Greetings
Andreas Share
Andreas Share wrote:
Andreas Share wrote:
Hi,
attached patch should make the rcu code NPTL compatible. Without the patch using an RCU will fail (vdr hang during startup) on an NPTL enabled system.
I have only move over L. Nussels lirc NPTL fix to the rcu code.
Greetings
Andreas
Have you actually tested this? I wonder if simply removing all lock calls would work, because there _is_ a thread and a foreground function that both want to transfer data...
Klaus
Yes, i have tested the patch on my system. With the lock´s the rcu-code block vdr completely during startup with NPTL enabled libraries, especialy this ones in /lib/tls. LD_ASSUME_KERNEL doesn´t work for this problem, only moving the tls-folder away from /lib (and do a ldconfig afters this) have let the rcu work again on my suse 9.1.
Removing the lock in the main loop only will resolve this, but IR learning will fail, so i have removed the other locks also.
With the patch vdr/rcu (learning included) works without any sideeffect in daily use since 21.10. on my system (internal IR-Header, DBox IR Codes).
Greetings
Andreas Share
Well, I don't have a good feeling simply throwing out the locks here just because NPTL can't handle them.
I guess this will have to wait then until I use NPTL myself, although I don't see this happening any time soon... ;-)
Unless, of course, you can come up with a solution that still does some locking and runs with NPTL. The file handle _is_ accessed from both the foreground and the background thread, so this just can't work reliably without locking.
Klaus
Klaus Schmidinger wrote:
[...] Well, I don't have a good feeling simply throwing out the locks here just because NPTL can't handle them.
NPTL is fine. The way vdr used and maybe still uses locks at some places was/is wrong (stuff like sleeping while locked). LinuxThreads support has been removed from glibc btw. LD_ASSUME_KERNEL=... will no longer work as workaround in the future.
cu Ludwig
Ludwig Nussel wrote:
Klaus Schmidinger wrote:
[...] Well, I don't have a good feeling simply throwing out the locks here just because NPTL can't handle them.
NPTL is fine. The way vdr used and maybe still uses locks at some places was/is wrong (stuff like sleeping while locked). LinuxThreads support has been removed from glibc btw. LD_ASSUME_KERNEL=... will no longer work as workaround in the future.
Well, can you point out exactly what VDR does wrong in rcu.c? I don't think it is sleeping while locked...
Klaus
Klaus Schmidinger wrote:
Ludwig Nussel wrote:
Klaus Schmidinger wrote:
[...] Well, I don't have a good feeling simply throwing out the locks here just because NPTL can't handle them.
NPTL is fine. The way vdr used and maybe still uses locks at some places was/is wrong (stuff like sleeping while locked). LinuxThreads support has been removed from glibc btw. LD_ASSUME_KERNEL=... will no longer work as workaround in the future.
Well, can you point out exactly what VDR does wrong in rcu.c? I don't think it is sleeping while locked...
I didn't look at that specific code.
cu Ludwig
Andreas Share wrote:
Andreas Share wrote:
Hi,
attached patch should make the rcu code NPTL compatible. Without the patch using an RCU will fail (vdr hang during startup) on an NPTL enabled system.
I have only move over L. Nussels lirc NPTL fix to the rcu code.
Greetings
Andreas
Have you actually tested this? I wonder if simply removing all lock calls would work, because there _is_ a thread and a foreground function that both want to transfer data...
Klaus
Yes, i have tested the patch on my system. With the lock´s the rcu-code block vdr completely during startup with NPTL enabled libraries, especialy this ones in /lib/tls. LD_ASSUME_KERNEL doesn´t work for this problem, only moving the tls-folder away from /lib (and do a ldconfig afters this) have let the rcu work again on my suse 9.1.
Removing the lock in the main loop only will resolve this, but IR learning will fail, so i have removed the other locks also.
With the patch vdr/rcu (learning included) works without any sideeffect in daily use since 21.10. on my system (internal IR-Header, DBox IR Codes).
Greetings
Andreas Share
Well, I don't have a good feeling simply throwing out the locks here just because NPTL can't handle them.
I guess this will have to wait then until I use NPTL myself, although I don't see this happening any time soon... ;-)
Unless, of course, you can come up with a solution that still does some locking and runs with NPTL. The file handle _is_ accessed from both the foreground and the background thread, so this just can't work reliably without locking.
Klaus
Hi,
no problem for me, and because i think most other user uses lirc or the remote plugin to control vdr it is only a minor problem. So i still use rcu without the locks and wait until you use a NPTL enabled linux;)
Greetings Andreas
Andreas Share wrote:
[ ... rcu.c vs. NPTL ... ]
no problem for me, and because i think most other user uses lirc or the remote plugin to control vdr it is only a minor problem. So i still use rcu without the locks and wait until you use a NPTL enabled linux;)
Ok, so I finally switched to kernel 2.6 and the dvb-kernel driver for good, and now I get the problems with rcu.c, too.
I have modified rcu.c so that it now does all actual data transmission in the Action() function, so no more locking is necessary. Simply dropping the locking caused lots of errors like
ERROR (rcu.c,188): Invalid argument
when background and foreground thread tried to access the interface at the same time.
Maybe you'd like to take a look at the attached patch.
Klaus
Andreas Share wrote:
[ ... rcu.c vs. NPTL ... ]
no problem for me, and because i think most other user uses lirc or the remote plugin to control vdr it is only a minor problem. So i still use rcu without the locks and wait until you use a NPTL enabled linux;)
Ok, so I finally switched to kernel 2.6 and the dvb-kernel driver for good, and now I get the problems with rcu.c, too.
I have modified rcu.c so that it now does all actual data transmission in the Action() function, so no more locking is necessary. Simply dropping the locking caused lots of errors like
ERROR (rcu.c,188): Invalid argument
when background and foreground thread tried to access the interface at the same time.
Maybe you'd like to take a look at the attached patch.
Klaus
I have had the same error messages here, but i have not seen any side effect the last month. But your solution is the better way, i have tested it with NPTL, including key-learnig, works fine:)
thank you
Andreas
-
Andreas Share -
Klaus Schmidinger -
Ludwig Nussel