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

[Carsten Koch <Carsten.Koch@icem.de>]

Carsten Koch wrote:
...
> I tried various things both in vdr and in the driver, but so far I
> found no workaround for the ARM crash. Help and ideas appreciated.

All of that is still true, but here is additional information:

I changed VDR, so ALL ioctl calls were logged.
I noticed that all ARM crashes occured after the 
     ioctl(videoDev, OSD_SEND_CMD, &dc);
in DvbOsd::Cmd, so I inserted a move verbose
     dsyslog(LOG_INFO, "at dvbosd.c 352, %d, %d, %d, %d, %d, %d.\n", cmd, color, x0, y0, x1, y1);
before that ioctl. That statement showed, that the
ARM always crashed when processing a OSD_SetBlock
command (command code number 13):

Jan  1 23:42:36 vdr vdr[18690]: at dvbosd.c 352, 13, 636, 64, 60, 79, 75. 
Jan  1 23:42:38 vdr kernel: dvb0: ARM crashed!
Jan  1 23:42:51 vdr vdr[18690]: PANIC: watchdog timer expired - exiting!
...
Jan  1 23:45:51 vdr vdr[19067]: at dvbosd.c 352, 13, 636, 616, 60, 631, 75. 
Jan  1 23:45:55 vdr kernel: dvb0: ARM crashed!
Jan  1 23:46:06 vdr vdr[19067]: PANIC: watchdog timer expired - exiting!

Also interesting is the big delay between 
Jan  2 00:01:21 vdr vdr[19481]: at dvbosd.c 352, 20, 0, 1, 0, 0, 0. 
Jan  2 00:01:21 vdr vdr[19481]: at dvbosd.c 352, 13, 636, 64, 60, 79, 75. 
  and
Jan  2 00:01:23 vdr kernel: dvb0: ARM crashed!

as you can see, before the crash, the ARM was processing 19 commands per
second. 

Just to make 100% sure the ARM always crashes when processing a OSD_SetBlock,
I inserted a 
     dsyslog(LOG_INFO, "at dvbosd.c 362.\n");
AFTER the ioctl.

I was not surprised to see
Jan  2 00:18:36 vdr vdr[20103]: at dvbosd.c 362. 
Jan  2 00:18:36 vdr vdr[20103]: at dvbosd.c 352, 20, 0, 1, 0, 0, 0. 
Jan  2 00:18:36 vdr vdr[20103]: at dvbosd.c 362. 
Jan  2 00:18:36 vdr vdr[20103]: at dvbosd.c 352, 13, 636, 123, 27, 130, 54. 
Jan  2 00:18:38 vdr kernel: dvb0: ARM crashed!

Maybe some of you, who are also experiencing ARM crashes may want to do
the same thing (insert a dsyslog call before and after the ioctl), so we
can find out wether there is just one single cause for all ARM crashes.

All of this seems to support my initial theory that the firmware is writing 
into ARM RAM randomly due to firmware or driver bugs. When it hits something 
harmless, we see the well-known glitches, when it hits something more serious, 
we see an ARM crash.

Here is the test case that I use to easily reproduce a crash:

*  I have a recording that already has cut markers near the
   beginning an near the end.

*  I bring up that recording and press "2".
   VDR displays "Editing process started.".
  
*  I wait for that display to disappear and press "back".

*  In the recording list that appears now, I scroll back to
   the %same-name recording and press OK.

*  I press OK again to bring up the progress bar.
   The end time in the progress bar is changing while VDR
   writes the new file.

*  I press "Up" to start "fast forward" mode.
   VDR fast forwards - sometimes up to 0:0:40, sometimes up to
   a few minutes, then the ARM crashes without requiring further
   input.

Klaus, can you reproduce this?

As a workaround, I inserted a VIDEO_FREEZE ioctl before the OSD_SEND_CMD
and a VIDEO_CONTINUE after the OSD_SEND_CMD. That did not help, either.
ARM still crashes.


Carsten.