[linux-dvb] Re: VDR's first step towards NAPI

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

Henning Holtschneider wrote:
> 
> > which contains all files modified since VDR version 0.72.
> > Please make sure you install these files over a copy of the
> > original 0.72 files.
> 
> Does this include the updated tuning code Dave Chapman wrote about in
> http://www.linuxtv.org/mailinglists/linux-dvb/msg04381.html? Channel
> switching works much better with VDR than with the driver's tool (n)tuxzap!
> I can also reproduce Peter Seyringer's initialization problem
> (http://www.linuxtv.org/mailinglists/linux-dvb/msg04385.html).

This is the "latest greatest" test version I have and contains
everything I have received from Dave. It's (of course) not yet an
"official release".

> > Other problems are that after stopping a recording from the
> > main menu, the program regularly segfaults.
> 
> I haven't been able to record anything. If I try to record the current
> channel from the menu, VDR will segfault at the end of the recording and
> the timer won't be deleted.

Same here. I haven't figured out yet why that happens.

> Setting a timer manually will result in
> outcommand error 1 and a ARM reset at the start of the recording:
> 
> Apr 22 22:20:00 vdr vdr[690]: timer 1 start
> Apr 22 22:20:00 vdr vdr[690]: switching to channel 11
> Apr 22 22:20:01 vdr kernel: outcommand error 1
> Apr 22 22:20:03 vdr last message repeated 2 times
> Apr 22 22:20:03 vdr kernel: dvb: ARM RESET

I also had these on occasion. Maybe I'm still not using the new API
the right way.

> Sometimes, I will also get the following error at the start of the
> recording:
> 
> Apr 22 22:46:00 vdr vdr[878]: timer 1 start
> Apr 22 22:46:00 vdr vdr[878]: switching to channel 8
> Apr 22 22:46:00 vdr vdr[878]: record /video/RTL/2001-04-22.22:46.99.99.rec
> Apr 22 22:46:00 vdr vdr[878]: creating directory /video/RTL
> Apr 22 22:46:00 vdr vdr[878]: creating directory /video/RTL/2001-04-
> 22.22:46.99.99.rec
> Apr 22 22:46:00 vdr vdr[878]: recording to '/video/RTL/2001-04-
> 22.22:46.99.99.rec/001.vdr'
> Apr 22 22:46:00 vdr vdr[917]: output thread started (pid=917)
> Apr 22 22:46:00 vdr vdr[918]: input thread started (pid=918)
> Apr 22 22:46:00 vdr vdr[918]: ERROR (dvbapi.c,752): Unknown error 769

This error number is defined by the driver as EBUFFEROVERFLOW and happens
at the beginning of a recording, when the driver's internal buffer hasn't
been emptied in time. I haven't figured out yet how to start the DMX when
the recording is to start (not when the channel is tuned). With DMX_OUT_TS_TAP
one can apparently only use DMX_IMMEDIATE_START.

I wonder if there is a way to tune to a channel and then (at a later time) start
recording - or do we have to know whether we will be recording when tuning the
channel, and use either DMX_IMMEDIATE_START or '0' as pesFilterParams.flags?

> After that, the screen will remain blank until I reload the driver.
> 
> How can I debug why VDR segfaults? I have never debugged multithreaded
> programs with gdb before.

Debugging VDR with gdb has often frozen my entire system. Maybe its different
with the new version of gdb that came with SuSE 7.1 on kernel 2.4, I haven't
tried that yet. If you set 

   ulimit -c unlimited

in your shell, VDR will create a core file when it segfaults. You can investigate
such a core file with

   gdb vdr core

to see where the "crash site" was. From what I've seen so far it is mostly
in the 'select()' or 'poll()' system call.

When I replay a recording the driver itself mostly bails out with the following
error messages in /var/log/messages:

Apr 22 16:58:05 video vdr[419]: replay /video/Die_große_Wochenshow-Gala/2001-04-01.20:13.99.99.rec
Apr 22 16:58:05 video vdr[419]: playing '/kls/video/Die_große_Wochenshow-Gala/2001-04-01.20:13.99.99.rec/001.vdr'
Apr 22 16:58:05 video vdr[425]: replay thread started (pid=425)
Apr 22 16:58:05 video vdr[425]: resuming replay at index 768 (0:00:30.19)
Apr 22 16:58:05 video kernel: dvb: Playing PES
Apr 22 16:58:05 video kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000104
Apr 22 16:58:05 video kernel:  printing eip:
Apr 22 16:58:05 video kernel: ca439ddc
Apr 22 16:58:05 video kernel: *pde = 00000000
Apr 22 16:58:05 video kernel: Oops: 0000
Apr 22 16:58:05 video kernel: CPU:    0
Apr 22 16:58:05 video kernel: EIP:    0010:[<ca439ddc>]
Apr 22 16:58:05 video kernel: EFLAGS: 00010206
Apr 22 16:58:05 video kernel: eax: ca466ec0   ebx: ca445020   ecx: c2d40000   edx: 00000000
Apr 22 16:58:05 video kernel: esi: 000fffff   edi: 4021b008   ebp: 00000800   esp: c2d41f1c
Apr 22 16:58:05 video kernel: ds: 0018   es: 0018   ss: 0018
Apr 22 16:58:05 video kernel: Process vdr (pid: 425, stackpage=c2d41000)
Apr 22 16:58:05 video kernel: Stack: ca445020 000fffff 4021b008 00000800 ca466ec0 00000800 00000000 00010000 
Apr 22 16:58:05 video kernel:        ca43907e 4021b008 000fffff ca4453f0 c52b8aa0 000fffff 4021b008 000fffff 
Apr 22 16:58:05 video kernel:        ca43f3d1 ca445020 4021b008 000fffff 00000800 c52b8aa0 ffffffea 00000000 
Apr 22 16:58:05 video kernel: Call Trace: [<ca445020>] [<ca466ec0>] [<ca43907e>] [<ca4453f0>] [<ca43f3d1>] [<ca445020>] [<c89080ff>] 
Apr 22 16:58:05 video kernel:        [<ca493cb4>] [sys_write+143/196] [system_call+51/64] 
Apr 22 16:58:05 video kernel: 
Apr 22 16:58:05 video kernel: Code: 8b 82 04 01 00 00 8b 8a 00 01 00 00 29 c1 89 c8 85 c0 7f 06

Maybe one of the driver developers has an idea what this could mean?

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
_______________________________________________________________


--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.