Every now and then (too often) I need to restart VDR because it starts to use lots of CPU time. Problem may stay hidden for week, but sometimes it happens after less than one day. VDR still works, but wastes CPU cycles. This has been happening for long time, it is not any recent problem.
--- Linux 2.6.14 PowerPC 604e
TechnoTrend DVB-C 2.1 TechniSat DVB-C CableStar2
vdr (1.3.27) subtitles (0.3.8) streamdev-server (0.3.3-pre3-geni) ---
Someone probably has got ideas about how to debug this...
Hi,
I recently built my VDR box with the following config: Suse 9.1, kernel 2.6 on PIII 550 with Nexus. ( i have to say this community is marvelous, i found help in every phase of the buliding) VDR running fine several days ago with the following plugins loaded: osdteletext, femon, dvd, subtitles and ttxtsubs. A couple of days ago i added to my config an LCD (20x4, HD44780, parallel port). I compiled LCDproc, LCDd server running fine, testing with the included lcdproc demo works ok. I added lcdproc plugin to my vdr, and i have the following problem: - when VDR starts, lcdproc connects to LCDd (i can see clients:1 on my display) - the welcome info appears on the display (Welcome to VDR, ver 1.3.36) - after about one second VDR exits without any info nor on /var/log/messages nor on VDR console - the Clients 0 message appears on the display (so the lcdproc plugin disconnencts from LCDd) - if i press the menu key when VDR starts, I have no problem entering the menu, and the menu items appears on the LCD! I can navigate through the menu items, recordings, etc, everything is displayed ok, but when I exit the VDR menu (with the back key or with starting to play a recording) VDR exits instantly. - i searched the list, but i did not find anybody meeting this kind of problem.
What I tried: - remove all the plugins except lcdproc - start LCDd with several configuration - recompiling everything (vdr, lcdproc plugin, LCDd, dvb drivers, everything - i'm desperate :) )
Anybody has a hint, what should i try?
I have another issue about recording subtitles, but let's discuss it later :)
Regards,
Füley István
oops. sorry i'm getting in the wrong thread :( ----------------------------------------------- Füley István
The answer to my yesterday's question is:
--- lcdproc-0.0.10.o/lcd.c Thu Nov 4 17:38:44 2004 +++ lcdproc-0.0.10/lcd.c Sun Jan 9 19:27:28 2005 @@ -586,7 +586,7 @@ - WeekDayName(now->tm_wday), now->tm_mday, now->tm_mon+1, now->tm_hour, now->tm_min,now->tm_sec); + *WeekDayName(now->tm_wday), now->tm_mday, now->tm_mon+1, now->tm_hour, now->tm_min,now->tm_sec);
----------------------------------------------- Füley István
Paavo Hartikainen wrote:
Every now and then (too often) I need to restart VDR because it starts to use lots of CPU time. Problem may stay hidden for week, but sometimes it happens after less than one day. VDR still works, but wastes CPU cycles. This has been happening for long time, it is not any recent problem.
Linux 2.6.14 PowerPC 604e
TechnoTrend DVB-C 2.1 TechniSat DVB-C CableStar2
vdr (1.3.27) subtitles (0.3.8) streamdev-server (0.3.3-pre3-geni)
Someone probably has got ideas about how to debug this...
What we would need to know first is which of VDR's threads actually consumes all this CPU time. Run VDR without NPTL and use 'top' to find that out (AFAIK with NPTL all threads of a given program have the same pid, so you won't be able to distinguish them in 'top'). Then look into the log file and find out which VDR thread corresponds to the pid that consumes the most CPU time.
Klaus
On Sat, Dec 03, 2005, Klaus Schmidinger wrote:
(AFAIK with NPTL all threads of a given program have the same pid, so you won't be able to distinguish them in 'top').
This is not entirely true, you can still see and distinguish the threads in htop or "ps -T u -C vdr" etc. (top does not work).
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.)
Johannes
--- vdr-1.3.37/thread.c.orig 2005-12-03 19:52:38.000000000 +0100 +++ vdr-1.3.37/thread.c 2005-12-03 20:12:47.000000000 +0100 @@ -17,6 +17,11 @@ #include <unistd.h> #include "tools.h"
+static inline pid_t gettid(void) +{ + return (pid_t) syscall(224); +} + static bool GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow) { struct timeval now; @@ -231,10 +236,10 @@ void cThread::SetDescription(const char void *cThread::StartThread(cThread *Thread) { if (Thread->description) - dsyslog("%s thread started (pid=%d, tid=%ld)", Thread->description, getpid(), pthread_self()); + dsyslog("%s thread started (pid=%d, tid=%d)", Thread->description, getpid(), gettid()); Thread->Action(); if (Thread->description) - dsyslog("%s thread ended (pid=%d, tid=%ld)", Thread->description, getpid(), pthread_self()); + dsyslog("%s thread ended (pid=%d, tid=%d)", Thread->description, getpid(), gettid()); Thread->running = false; Thread->active = false; return NULL;
Johannes Stezenbach wrote:
On Sat, Dec 03, 2005, Klaus Schmidinger wrote:
(AFAIK with NPTL all threads of a given program have the same pid, so you won't be able to distinguish them in 'top').
This is not entirely true, you can still see and distinguish the threads in htop or "ps -T u -C vdr" etc. (top does not work).
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.)
Does this "gettid" call return a different tid than "pthread_self()"?
I'm just wondering because the introduction of "pthread_self()" was one of the things we had to change to make VDR run with NPTL...
Klaus
Johannes
--- vdr-1.3.37/thread.c.orig 2005-12-03 19:52:38.000000000 +0100 +++ vdr-1.3.37/thread.c 2005-12-03 20:12:47.000000000 +0100 @@ -17,6 +17,11 @@ #include <unistd.h> #include "tools.h"
+static inline pid_t gettid(void) +{
- return (pid_t) syscall(224);
+}
static bool GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow) { struct timeval now; @@ -231,10 +236,10 @@ void cThread::SetDescription(const char void *cThread::StartThread(cThread *Thread) { if (Thread->description)
dsyslog("%s thread started (pid=%d, tid=%ld)", Thread->description, getpid(), pthread_self());
dsyslog("%s thread started (pid=%d, tid=%d)", Thread->description, getpid(), gettid());
dsyslog("%s thread ended (pid=%d, tid=%ld)", Thread->description, getpid(), pthread_self());
dsyslog("%s thread ended (pid=%d, tid=%d)", Thread->description, getpid(), gettid());
Am Sonntag, 4. Dezember 2005 10:37 schrieb Klaus Schmidinger:
Johannes Stezenbach wrote:
On Sat, Dec 03, 2005, Klaus Schmidinger wrote:
(AFAIK with NPTL all threads of a given program have the same pid, so you won't be able to distinguish them in 'top').
This is not entirely true, you can still see and distinguish the threads in htop or "ps -T u -C vdr" etc. (top does not work).
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.)
Does this "gettid" call return a different tid than "pthread_self()"?
pthread_self() sample output log [2005/12/04 11:14:02] vdr vdr[27644]: tuner on device 3 thread started (pid=27644, tid=-1265644624) sample output ps -T u -C vdr root@vdr:~# ps -T u -C vdr USER PID SPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 27644 27644 3.2 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27742 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27743 0.0 2.5 129332 26624 ? RNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27745 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27746 0.0 2.5 129332 26624 ? SNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27748 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27749 0.0 2.5 129332 26624 ? SNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27750 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27751 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27752 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27753 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh -
gettid() sample output log with Patch from Johannes Stetzenbach [2005/12/04 11:16:15] vdr vdr[29989]: tuner on device 3 thread started (pid=29989, tid=30086) sample output ps -T u -C vdr root@vdr:~# ps -T u -C vdr USER PID SPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 29989 29989 0.1 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30080 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30081 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30083 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30084 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30086 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30087 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30088 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30089 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30090 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30091 0.0 2.5 129380 26640 ? Rl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh -
my System is a NPTL only System (Linuxfromscatch System) with vdr-1.3.37.
I'm just wondering because the introduction of "pthread_self()" was one of the things we had to change to make VDR run with NPTL...
Klaus
Johannes
--- vdr-1.3.37/thread.c.orig 2005-12-03 19:52:38.000000000 +0100 +++ vdr-1.3.37/thread.c 2005-12-03 20:12:47.000000000 +0100 @@ -17,6 +17,11 @@ #include <unistd.h> #include "tools.h"
+static inline pid_t gettid(void) +{
- return (pid_t) syscall(224);
+}
static bool GetAbsTime(struct timespec *Abstime, int MillisecondsFromNow) { struct timeval now; @@ -231,10 +236,10 @@ void cThread::SetDescription(const char void *cThread::StartThread(cThread *Thread) { if (Thread->description)
dsyslog("%s thread started (pid=%d, tid=%ld)", Thread->description,getpid(), pthread_self()); + dsyslog("%s thread started (pid=%d, tid=%d)", Thread->description, getpid(), gettid()); Thread->Action(); if (Thread->description)
dsyslog("%s thread ended (pid=%d, tid=%ld)", Thread->description,getpid(), pthread_self()); + dsyslog("%s thread ended (pid=%d, tid=%d)", Thread->description, getpid(), gettid()); Thread->running = false; Thread->active = false; return NULL;
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Gerald Raaf wrote:
Am Sonntag, 4. Dezember 2005 10:37 schrieb Klaus Schmidinger:
Johannes Stezenbach wrote:
On Sat, Dec 03, 2005, Klaus Schmidinger wrote:
(AFAIK with NPTL all threads of a given program have the same pid, so you won't be able to distinguish them in 'top').
This is not entirely true, you can still see and distinguish the threads in htop or "ps -T u -C vdr" etc. (top does not work).
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.)
Does this "gettid" call return a different tid than "pthread_self()"?
pthread_self() sample output log [2005/12/04 11:14:02] vdr vdr[27644]: tuner on device 3 thread started (pid=27644, tid=-1265644624) sample output ps -T u -C vdr root@vdr:~# ps -T u -C vdr USER PID SPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 27644 27644 3.2 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27742 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27743 0.0 2.5 129332 26624 ? RNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27745 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27746 0.0 2.5 129332 26624 ? SNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27748 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27749 0.0 2.5 129332 26624 ? SNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27750 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27751 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27752 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27753 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh -
gettid() sample output log with Patch from Johannes Stetzenbach [2005/12/04 11:16:15] vdr vdr[29989]: tuner on device 3 thread started (pid=29989, tid=30086) sample output ps -T u -C vdr root@vdr:~# ps -T u -C vdr USER PID SPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 29989 29989 0.1 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30080 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30081 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30083 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30084 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30086 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30087 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30088 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30089 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30090 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30091 0.0 2.5 129380 26640 ? Rl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh -
my System is a NPTL only System (Linuxfromscatch System) with vdr-1.3.37.
Well, this shows me that on such a system all VDR threads have the same PID, but different SPIDs. I don't think that this has in any way changed through Johannes' patch.
What would be interesting would be the log excerpts corresponding to these test runs, where the VDR threads log their 'pid' and 'tid' values. Maybe you could post these, too?
Klaus
Klaus Schmidinger wrote:
Gerald Raaf wrote:
Am Sonntag, 4. Dezember 2005 10:37 schrieb Klaus Schmidinger:
Johannes Stezenbach wrote:
On Sat, Dec 03, 2005, Klaus Schmidinger wrote:
(AFAIK with NPTL all threads of a given program have the same pid, so you won't be able to distinguish them in 'top').
This is not entirely true, you can still see and distinguish the threads in htop or "ps -T u -C vdr" etc. (top does not work).
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.)
Does this "gettid" call return a different tid than "pthread_self()"?
pthread_self() sample output log [2005/12/04 11:14:02] vdr vdr[27644]: tuner on device 3 thread started (pid=27644, tid=-1265644624) sample output ps -T u -C vdr root@vdr:~# ps -T u -C vdr USER PID SPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 27644 27644 3.2 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27742 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27743 0.0 2.5 129332 26624 ? RNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27745 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27746 0.0 2.5 129332 26624 ? SNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27748 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27749 0.0 2.5 129332 26624 ? SNl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27750 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27751 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27752 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 27644 27753 0.0 2.5 129332 26624 ? Sl 11:14 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh -
gettid() sample output log with Patch from Johannes Stetzenbach [2005/12/04 11:16:15] vdr vdr[29989]: tuner on device 3 thread started (pid=29989, tid=30086) sample output ps -T u -C vdr root@vdr:~# ps -T u -C vdr USER PID SPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 29989 29989 0.1 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30080 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30081 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30083 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30084 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30086 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30087 0.0 2.5 129380 26640 ? SNl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30088 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30089 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30090 0.0 2.5 129380 26640 ? Sl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh - root 29989 30091 0.0 2.5 129380 26640 ? Rl 11:16 0:00 ./vdr -w 60 -s /usr/local/bin/stopvdr -r /usr/local/bin/record.sh -
my System is a NPTL only System (Linuxfromscatch System) with vdr-1.3.37.
Well, this shows me that on such a system all VDR threads have the same PID, but different SPIDs. I don't think that this has in any way changed through Johannes' patch.
What would be interesting would be the log excerpts corresponding to these test runs, where the VDR threads log their 'pid' and 'tid' values. Maybe you could post these, too?
Aaaahhhrrrgghhhh - right after sending this message I saw that you had actually posted these. They must have slipped by my eyes, sorry.
Klaus
On Sun, Dec 04, 2005 at 10:37:42AM +0100, Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
On Sat, Dec 03, 2005, Klaus Schmidinger wrote:
(AFAIK with NPTL all threads of a given program have the same pid, so you won't be able to distinguish them in 'top').
This is not entirely true, you can still see and distinguish the threads in htop or "ps -T u -C vdr" etc. (top does not work).
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.)
Does this "gettid" call return a different tid than "pthread_self()"?
I'm just wondering because the introduction of "pthread_self()" was one of the things we had to change to make VDR run with NPTL...
pthread_self() has to be used within programs using to identify the threads. gettid() is more a debugging aid as the return value of pthread_self() has no meaning outside the context of the running program. (Funny that glibc doesn't have a syscall wrapper for gettid(); dietlibc has.)
Johannes
Johannes Stezenbach wrote:
... pthread_self() has to be used within programs using to identify the threads. gettid() is more a debugging aid as the return value of pthread_self() has no meaning outside the context of the running program. (Funny that glibc doesn't have a syscall wrapper for gettid(); dietlibc has.)
Johannes
Thanks, this appears to work just fine.
I assume it's ok to use the SYS_gettid macro, as in
#include <sys/syscall.h>
static inline pid_t gettid(void) { return syscall(SYS_gettid); }
instead of the hardcoded 224.
Klaus
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
... pthread_self() has to be used within programs using to identify the threads. gettid() is more a debugging aid as the return value of pthread_self() has no meaning outside the context of the running program. (Funny that glibc doesn't have a syscall wrapper for gettid(); dietlibc has.)
Thanks, this appears to work just fine.
I assume it's ok to use the SYS_gettid macro, as in
#include <sys/syscall.h>
static inline pid_t gettid(void) { return syscall(SYS_gettid); }
instead of the hardcoded 224.
The man page actually suggests: http://homepages.cwi.nl/~aeb/linux/man2html/man2/gettid.2.html
#include <sys/types.h> #include <linux/unistd.h>
_syscall0(pid_t,gettid)
(I just made a mistake and included <unistd.h> instead of <linux/unistd.h> so it didn't work when I initially tested it.)
Johannes
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
... pthread_self() has to be used within programs using to identify the threads. gettid() is more a debugging aid as the return value of pthread_self() has no meaning outside the context of the running program. (Funny that glibc doesn't have a syscall wrapper for gettid(); dietlibc has.)
Thanks, this appears to work just fine.
I assume it's ok to use the SYS_gettid macro, as in
#include <sys/syscall.h>
static inline pid_t gettid(void) { return syscall(SYS_gettid); }
instead of the hardcoded 224.
The man page actually suggests: http://homepages.cwi.nl/~aeb/linux/man2html/man2/gettid.2.html
#include <sys/types.h> #include <linux/unistd.h>
_syscall0(pid_t,gettid)
(I just made a mistake and included <unistd.h> instead of <linux/unistd.h> so it didn't work when I initially tested it.)
Johannes
Ok, I'll make it that way then.
Do you think we need a fallback solution, just in case the syscall fails? Paavo Hartikainen's posting (12/05/05 03:57) would indicate that this can happen.
Maybe we should use pthread_self() in case gettid() returns -1, and use pthread_t to store such values, because it's large enough to hold pid_t as well as pthread_t.
Or should we make this system dependent (with #ifdef)? So that non-Linux systems can provide a different solution.
Klaus
On Sat, Dec 10, 2005, Klaus Schmidinger wrote:
Do you think we need a fallback solution, just in case the syscall fails? Paavo Hartikainen's posting (12/05/05 03:57) would indicate that this can happen.
Maybe we should use pthread_self() in case gettid() returns -1, and use pthread_t to store such values, because it's large enough to hold pid_t as well as pthread_t.
Or should we make this system dependent (with #ifdef)? So that non-Linux systems can provide a different solution.
I think the pthread_self() return value is pretty useless in debug output.
If gettid() fails then you probably have an old kernel and getpid() already gives you what you want (a PID you can match with top output).
Johannes
Johannes Stezenbach js@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) ---
I assumed that "make clean" is not required after patching, just "make".
Now just waiting for threads to get wildly active.
Paavo Hartikainen wrote:
Johannes Stezenbach js@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
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de writes:
What we would need to know first is which of VDR's threads actually consumes all this CPU time.
Now it seems this thread has got out of control: --- pahartik 28311 91.9 9.5 108560 13636 pts/1 R+ 20:17 168:41 ./vdr --config=sarabi-config --video=/dvb/video --plugin=streamdev-server --plugin=subtitles ---
Then look into the log file and find out which VDR thread corresponds to the pid that consumes the most CPU time.
--- Dec 5 20:17:49 sarabi vdr[28310]: streamdev-writer thread started (pid=28310, tid=-1) Dec 5 20:17:49 sarabi vdr[28312]: receiver on device 1 thread started (pid=28312, tid=-1) Dec 5 20:17:49 sarabi vdr[28311]: streamdev-livestreaming thread started (pid=28311, tid=-1) Dec 5 20:17:49 sarabi vdr[28313]: TS buffer on device 1 thread started (pid=28313, tid=-1) Dec 5 20:27:21 sarabi vdr[28312]: buffer usage: 70% (tid=1376265) Dec 5 20:27:24 sarabi vdr[28312]: buffer usage: 60% (tid=1376265) Dec 5 20:27:34 sarabi vdr[28312]: buffer usage: 70% (tid=1376265) Dec 5 20:27:39 sarabi vdr[28312]: buffer usage: 60% (tid=1376265) Dec 5 20:27:47 sarabi vdr[28312]: buffer usage: 70% (tid=1376265) Dec 5 20:27:59 sarabi vdr[28312]: buffer usage: 60% (tid=1376265) Dec 5 20:27:59 sarabi vdr[28312]: buffer usage: 70% (tid=1376265) Dec 5 20:28:46 sarabi vdr[28312]: buffer usage: 80% (tid=1376265) Dec 5 20:29:59 sarabi vdr[28312]: buffer usage: 90% (tid=1376265) ---
Several hours later... Looks like streamdev-server does not always know when to stop. It is not sending packets anymore, according to ethernet switch and iftop output. That buffer usage growing towards 100% probably is result of network being slow between client and server, it does not happen when streaming to client on LAN. Stream in question is 160 kilobits per second MPEG-2 audio layer 2 ES stream to HTTP client. Buffer reaching 100% usage does not always cause this problem of thread going wild, thread may still exit normally when other end quits.
-
Gerald Raaf -
Istvan Fuley -
Johannes Stezenbach -
Klaus Schmidinger -
Paavo Hartikainen