Hello! Yes, you was right about commenting watchdog. But now I have new troubles:) 2009-02-27 03:56:53.215 fe: Adapter 1 Setting up frontend tuner 2009-02-27 03:56:53.217 fe: adapter 1 type OFDM name "Zarlink ZL10353 DVB-T" 2009-02-27 03:56:53.217 fe: adapter 1 frequency min 174000000 max 862000000 step 166667 tolerance 0 2009-02-27 03:56:53.217 fe: adapter 1 symbol rate min 0 max 0 tolerance 0 2009-02-27 03:56:53.217 dmx: Setting filter for pid 8192 pestype 20 2009-02-27 03:56:53.252 dvr: Add Section callback for PID 0 (0x0000) type 1 (PAT) 2009-02-27 03:56:53.252 dvr: Add TS callback for PID 0 (0x0000) type 9 (Reassemble) 2009-02-27 03:56:59.042 fe: Adapter 1 Status: 0x00 () 2009-02-27 03:56:59.042 dvr: lockup of DVB card detected - trying to reanimate via bouncing filter 2009-02-27 03:57:04.862 fe: Adapter 1 Status: 0x00 () 2009-02-27 03:57:04.862 dvr: lockup of DVB card detected - trying to reanimate via bouncing filter 2009-02-27 03:57:10.712 fe: Adapter 1 Status: 0x00 () 2009-02-27 03:57:10.712 dvr: lockup of DVB card detected - trying to reanimate via bouncing filter On Thu, Feb 26, 2009 at 6:38 PM, Frederik Kriewitz <frederik@kriewitz.eu>wrote:
2009/2/26 Florian Lohoff <flo@rfc822.org>:
Aborted means the watchdog killed getstream with a SIGABRT ...
I had some problems with the watchdog too. An older system with 2.6.18 Kernel completely blocked the System (no userspace threads were running for several seconds). Once it was working again the watchdog killed getstream in the middle of processing the dvb buffer overflow (EOVERFLOW error).
On another system initialisation of a "Fujitsu Siemens Activy DVB-S Budget Card" sometimes takes more than a second, resulting in the watchdog killing getstream accidentally again.
Try to disable the watchdog by commenting out init_guard_thread(); at the end of getstream.c