Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Carsten Koch wrote:
> 
> 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.

Have you changed the key assignments, or do you mean "Right"?

>    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?

No, I can't. I just placed a few editing marks on a long recording
and did as you described. All went perfectly well, no ARM crash at all
in 15 minutes (then the cutting process had ended).

Klaus

> 
> 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.

-- 
_______________________________________________________________

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
_______________________________________________________________



Home | Main Index | Thread Index