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