hi,
after upgrading my kernel to 2.6.37 SMP PREEMPT x86_64 and switching to the in-kernel lirc devinput drivers, I have had vdr startup problems.
At some boots; typically when the system wakes up from sleep, either by RTC or by power key from the remote, VDR watchdog-restarts every 1 minute for arond 10 times (this last time, it did it 14 times). Only after that it starts properly, xine starts and picture, sound and remote control start working. When rebooting, vdr might start immediately, without this restart hassle.
Before; using the imon drivers, this problem did not occur. vdr-1.7.16, lircd from the git repo.
I don't know where to start. Is this a vdr, lirc or a driver problem, or perhaps initscript order problem? Should I try the 2.6.38-rc5, or would that be just looking for trouble?
yours, Jouni
On 16 February 2011 14:48, Jouni Karvo Jouni.Karvo@iki.fi wrote:
after upgrading my kernel to 2.6.37 SMP PREEMPT x86_64 and switching to the in-kernel lirc devinput drivers, I have had vdr startup problems.
At some boots; typically when the system wakes up from sleep, either by RTC or by power key from the remote, VDR watchdog-restarts every 1 minute for arond 10 times (this last time, it did it 14 times). Only after that it starts properly, xine starts and picture, sound and remote control start working. When rebooting, vdr might start immediately, without this restart hassle.
Presumably you can rule out lirc being the issue by changing your vdr cmdline to set --lirc=/dev/null and specify lirc on your xine frontend instead?
On Wed, Feb 16, 2011 at 6:48 AM, Jouni Karvo Jouni.Karvo@iki.fi wrote:
I don't know where to start. Is this a vdr, lirc or a driver problem, or perhaps initscript order problem? Should I try the 2.6.38-rc5, or would that be just looking for trouble?
Check the VDR log and xine log. If VDR has a problem starting, you should be able to find out why in it's log. And if it's xine related, you then check the xine log.. And so on.. Just follow the crumbs until you find the problem. Shouldn't be too hard.
On 16.02.2011 20:36, VDR User wrote:
On Wed, Feb 16, 2011 at 6:48 AM, Jouni KarvoJouni.Karvo@iki.fi wrote:
I don't know where to start. Is this a vdr, lirc or a driver problem, or perhaps initscript order problem? Should I try the 2.6.38-rc5, or would that be just looking for trouble?
Check the VDR log and xine log. If VDR has a problem starting, you should be able to find out why in it's log. And if it's xine related, you then check the xine log.. And so on.. Just follow the crumbs until you find the problem. Shouldn't be too hard.
:)
That was done already: vdr -l 3, xine --verbose=2; there is no hint on syslog or console output - except this, on the main thread:
Feb 17 16:48:57 vdr vdr: [3956] TS buffer on device 1 thread started (pid=3897, tid=3956) Feb 17 16:49:57 vdr vdr: [3897] PANIC: watchdog timer expired - exiting!
and on another occasion:
Feb 17 16:47:48 vdr vdr: [3852] cVideoRepacker: switching to MPEG1/2 mode Feb 17 16:47:48 vdr vdr: [3852] cVideoRepacker: operating in MPEG1/2 mode Feb 17 16:47:50 vdr vdr: [3820] EPGSearch: search timer update finished Feb 17 16:48:48 vdr vdr: [3794] PANIC: watchdog timer expired - exiting!
I have tried to keep things simple and to use lirc from vdr, instead of from xine. I guess I have to start studying how to use the xine plugin as remote control.
Ymph - I tried to set ulimit -c unlimited, but I cannot find the core for this, found in the log:
Feb 17 16:48:48 vdr kernel: section handler[3799]: segfault at 61 ip 000000000046188d sp 00007f59275fb4f0 error 4 in vdr-prod[400000+13d000]
(vdr-prod is the name of the "production" binary of vdr in my box) is this really a segfault inside the kernel?
This segfault does not happen nearly all the watchdog-expiration cycles.
yours, Jouni
On Thu, Feb 17, 2011 at 7:09 AM, Jouni Karvo Jouni.Karvo@iki.fi wrote:
I don't know where to start. Is this a vdr, lirc or a driver problem, or perhaps initscript order problem? Should I try the 2.6.38-rc5, or would that be just looking for trouble?
Check the VDR log and xine log. If VDR has a problem starting, you should be able to find out why in it's log. And if it's xine related, you then check the xine log.. And so on.. Just follow the crumbs until you find the problem. Shouldn't be too hard.
:)
That was done already: vdr -l 3, xine --verbose=2; there is no hint on syslog or console output - except this, on the main thread:
And what happens when you take the watchdog out of the equation? Can you manually start VDR at will without any problems?