------------------------------------------------------------------------------------ Peter Dittmann APM-DS Philips Technologie GmbH Automotive Playback Modules Wetzlar / GERMANY Tel: +49 (0) 6441 3722 759 Fax: +49 (0) 6441 3722 566 E-mail: : peter.dittmann@philips.com ------------ http:\www.apm.philips.com ---------------------------------------------------------------
vdr-bounces@linuxtv.org schrieb am 24.07.2006 17:51:55:
On Mon, 24 Jul 2006 09:58:00 +0200, Peter Dittmann wrote
Had another kernel crash this morning with stuck SVDRP:
(...)
Jul 24 04:19:05 vdr vdr[1399]: connect from 127.0.0.1, port 32792 -
accepted
Jul 24 04:19:05 vdr vdr[1399]: SVDRP message: 'Infosat:Received
1490 of 1500
data blocks [ 99.33%]' Jul 24 04:19:05 vdr vdr[1399]: info: Infosat:Received 1490 of 1500
data
blocks [ 99.33%] Jul 24 04:19:05 vdr vdr[1399]: closing SVDRP connection Jul 24 04:20:05 vdr vdr[1399]: connect from 127.0.0.1, port 32793 -
accepted
Jul 24 04:20:05 vdr vdr[1399]: SVDRP message: 'Infosat:Received 1497 of 1500 data blocks [ 99.80%]' Jul 24 04:20:05 vdr vdr[1399]: info: Infosat:Received 1497 of 1500 data blocks [ 99.80%] Jul 24 04:20:05 vdr vdr[1399]: closing SVDRP connection
this seems to be VDRAdin as it's not the same 60sec raster as the
messages from infosatepg
Jul 24 04:20:41 vdr vdr[1399]: connect from 127.0.0.1, port 32794 - accepted
Jul 24 04:21:42 vdr vdr[1399]: PANIC: watchdog timer expired -
exiting!
I don't know infosatepg, but as far as I've read, it first downloads the
data
via DVB-S and then tvmovie2vdr uploads it to SVDRP. The whole process is controled by infosatepg.sh.
According to the log, infosatepg receives about 5-10 packets per minute,
so it
is most likely finished at Jul 24 04:20:41. At that time the SVDRP
upload
starts which is simply too fast.
Nope, infosatepg is not filling the data linearly. It takes around three runs here to accumulate all blocks as the FF has a high packet error rate. I'm shure that infosatepg would have been happily busy untin 4:35. This is supported by infosatepg still running and being the cause of the kernel crash once VDR has restarted.
Again: try to find out what's really happening when the watchdog is
triggered.
Use a sniffer, add some debug lines to vdr - whatever.
It's a ctvdr productive system, not much possibilities here to not break all plugin packages. However the problem seems to rise from VDRAdmin and the long timeout when adding timers. I had removed VDRAdmin already from the init and run it only during the infosatepg update time. I had strange crashes before. Especially when mp3ng plugin was running and a SVDRP message was comming in. This crashed VDR almost guaranteed. It looks like Morones mp3ng does not like messages completely. But that's different issue.
I will try to backport the SVDRP changes to my productive system and check were this leads.
regards Peter