[vdr] Re: AW: Re: ARM crashed while cutting, VDR watchdog timer failed.

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Carsten Koch wrote:
> 
> Gunter Niedermeier wrote:
> ...
> > you can easily produce an ARM crash by doing the following
> ...
> > 4. When cutting has finished, replay the new file and jump between
> >    the marks with the 7 and 9 keys, jump with the yellow and green
> >    keys ( only for testing ) and you will see that ARM crashes.
> >    There is no way to get the vdr running correctly again, until
> >    you restart the complete DBV drivers and then the vdr.
> 
> I have done one more test and this time the ARM already crashed while
> I was trying to set the second mark. With the progress bar on screen,
> I was changing rapidly between pause, slow reverse, slow forward and
> play, trying to find the best point for the second mark.
> 
> The problem may have nothing to do with cutting at all.
> It is a well-known fact that the ARM firmware produces glitches
> in playback when the OSD is on. I assume that these glitches are
> due to bugs in the firmware memory management? If that is the
> case and if that means the ARM code is randomly overwriting memory,
> then of course it is just a matter of coincidence whether this bug
> merely produces A/V glitches or a total crash.
> 
> I wonder why Klaus could not reproduce this.
> It took me less than 5 minutes to crash the ARM and I did not
> even try to. I only wanted to cut that recording.
> So far, I tried cutting 2 recordings in 2 days and I got 2 ARM
> crashes out of it. :-(
> 
> Assuming that the driver developers are unable or not willing to
> fix this, does anyone have an idea for a workaround?
> I still have hopes that an intelligently-placed usleep call in
> VDR can cure this.
> 
> Maybe the reason why Klaus is not seeing these is the fact that
> his AMD K6/II 450 is just slow enough to not push the firmware
> beyond its limits?

That's absolutely possible.

> Klaus, do you have a suggestion where I should place a usleep
> before trying again?

There is a usleep(5000) in cDvbOsd::Cmd() (file dvbosd.c). You could
try using larger values here. You could also insert the line

  if (cmd == OSD_SetBlock)

right before the usleep() call, since the OSD_SetBlock call is the only
one that takes longer.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________