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