Videotext application crashes the kernel due to DVB-demux patch

Videotext application crashes the kernel due to DVB-demux patch

[Chicken Shack]

Hi,

here is a link to a patch which breaks backwards compatibility for a
teletext software called alevt-dvb.

http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html

The kernel patch was introduced with kernel 2.6.32-rc1.
It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
author, Andreas Oberritter.

Previous help calls, not only on this list, have been ignored for
reasons that I do not know.
Even distro maintainers have given up and removed the DVB implementation
of alevt from their distro list.

Is that really what things are up to?
To pull through an API update by kernel patch, but simply dive off with
the usual "Sorry, but I don't have no time" when objections or problems
arise?

What the hell is going on in those peoples' minds?

It seems to me that the following disclaimer is worth nothing:

"If anyone has any objections, please let us know by sending a message
to: Linux Media Mailing List <linux-me...@vger.kernel.org>"

Volunteers welcome! Who please consacres some time and DVB competence to
give the appropriate hints please?

Regards

CS

P. S.: This is how the kernel crash looks like:

brian:~# alevt
alevt: SDT: service_id 0xcf24 not in PAT

sid:pmtpid:ttpid:type:provider:name:language:texttype:magazine:page

28006:100:130:1:ZDFvision:ZDF:lang=deu:type=1:magazine=1:page=  0
28011:600:630:1:ZDFvision:ZDFinfokanal:lang=deu:type=1:magazine=1:page=
0
28014:650:630:1:ZDFvision:zdf_neo:lang=deu:type=1:magazine=1:page=  0
28016:1100:630:1:ZDFvision:ZDFtheaterkanal:lang=deu:type=1:magazine=1:page=  0
28007:200:230:1:ZDFvision:3sat:lang=deu:type=1:magazine=1:page=  0
28008:300:330:1:ZDFvision:KiKa:lang=deu:type=1:magazine=1:page=  0
28017:411:8191:2:ZDFvision:DRadio Wissen:lang=:type=0:magazine=0:page=
0
28012:700:8191:2:ZDFvision:DKULTUR:lang=:type=0:magazine=0:page=  0
28013:800:8191:2:ZDFvision:DLF:lang=:type=0:magazine=0:page=  0

Using: Service ID = 28006 ; PMT PID = 100 ; TXT PID = 130 ;
Service type = 1 ; Provider Name = ZDFvision ; Service name = ZDF ;
language = deu ; Text type = 1 ; Text Magazine = 1 ; Text page =   0
alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
Getötet
brian:~# 
Message from syslogd@brian at Jan 31 19:52:33 ...
 kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 

Message from syslogd@brian at Jan 31 19:52:33 ...
 kernel:[  116.563492] last sysfs
file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/uevent

Message from syslogd@brian at Jan 31 19:52:33 ...
 kernel:[  116.563589] Process alevt (pid: 1780, ti=e7934000
task=e7915be0 task.ti=e7934000)

Message from syslogd@brian at Jan 31 19:52:33 ...
 kernel:[  116.563592] Stack:

Message from syslogd@brian at Jan 31 19:52:33 ...
 kernel:[  116.563622] Call Trace:

Message from syslogd@brian at Jan 31 19:52:33 ...
 kernel:[  116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8
e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b
46 04 8d 48 f8 <8b> 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89
50 04 89 

Message from syslogd@brian at Jan 31 19:52:33 ...
 kernel:[  116.563697] EIP: [<f8cec1b2>] dvb_demux_release+0x43/0x183
[dvb_core] SS:ESP 0068:e7935f58

Message from syslogd@brian at Jan 31 19:52:33 ...
 kernel:[  116.563706] CR2: 0000000000000000

PLEASE DO NOT IGNORE THIS MAIL!

Re: Videotext application crashes the kernel due to DVB-demux patch

[Andy Walls]

On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> Hi,
> 
> here is a link to a patch which breaks backwards compatibility for a
> teletext software called alevt-dvb.
> 
> http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> 
> The kernel patch was introduced with kernel 2.6.32-rc1.
> It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> author, Andreas Oberritter.
> 
> Previous help calls, not only on this list, have been ignored for
> reasons that I do not know.
> Even distro maintainers have given up and removed the DVB implementation
> of alevt from their distro list.
> 
> Is that really what things are up to?
> To pull through an API update by kernel patch, but simply dive off with
> the usual "Sorry, but I don't have no time" when objections or problems
> arise?

I have close to 0 time for this (I'm a volunteer who doesn't get paid
for linux work *at all*), but I will look into the problem for you.


> What the hell is going on in those peoples' minds?
> 
> It seems to me that the following disclaimer is worth nothing:
> 
> "If anyone has any objections, please let us know by sending a message
> to: Linux Media Mailing List <linux-me...@vger.kernel.org>"
> 
> Volunteers welcome! Who please consacres some time and DVB competence to
> give the appropriate hints please?
> 
> Regards
> 
> CS
> 
> P. S.: This is how the kernel crash looks like:

The information below can get me started.  Could you please provide
whole Ooops from the output dmesg or from your /var/log/messages file?

I'll try to look at this tonight.

Regards,
Andy

> brian:~# alevt
> alevt: SDT: service_id 0xcf24 not in PAT
> 
> sid:pmtpid:ttpid:type:provider:name:language:texttype:magazine:page
> 
> 28006:100:130:1:ZDFvision:ZDF:lang=deu:type=1:magazine=1:page=  0
> 28011:600:630:1:ZDFvision:ZDFinfokanal:lang=deu:type=1:magazine=1:page=
> 0
> 28014:650:630:1:ZDFvision:zdf_neo:lang=deu:type=1:magazine=1:page=  0
> 28016:1100:630:1:ZDFvision:ZDFtheaterkanal:lang=deu:type=1:magazine=1:page=  0
> 28007:200:230:1:ZDFvision:3sat:lang=deu:type=1:magazine=1:page=  0
> 28008:300:330:1:ZDFvision:KiKa:lang=deu:type=1:magazine=1:page=  0
> 28017:411:8191:2:ZDFvision:DRadio Wissen:lang=:type=0:magazine=0:page=
> 0
> 28012:700:8191:2:ZDFvision:DKULTUR:lang=:type=0:magazine=0:page=  0
> 28013:800:8191:2:ZDFvision:DLF:lang=:type=0:magazine=0:page=  0
> 
> Using: Service ID = 28006 ; PMT PID = 100 ; TXT PID = 130 ;
> Service type = 1 ; Provider Name = ZDFvision ; Service name = ZDF ;
> language = deu ; Text type = 1 ; Text Magazine = 1 ; Text page =   0
> alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> Getötet
> brian:~# 
> Message from syslogd@brian at Jan 31 19:52:33 ...
>  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> 
> Message from syslogd@brian at Jan 31 19:52:33 ...
>  kernel:[  116.563492] last sysfs
> file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/uevent
> 
> Message from syslogd@brian at Jan 31 19:52:33 ...
>  kernel:[  116.563589] Process alevt (pid: 1780, ti=e7934000
> task=e7915be0 task.ti=e7934000)
> 
> Message from syslogd@brian at Jan 31 19:52:33 ...
>  kernel:[  116.563592] Stack:
> 
> Message from syslogd@brian at Jan 31 19:52:33 ...
>  kernel:[  116.563622] Call Trace:
> 
> Message from syslogd@brian at Jan 31 19:52:33 ...
>  kernel:[  116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8
> e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b
> 46 04 8d 48 f8 <8b> 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89
> 50 04 89 
> 
> Message from syslogd@brian at Jan 31 19:52:33 ...
>  kernel:[  116.563697] EIP: [<f8cec1b2>] dvb_demux_release+0x43/0x183
> [dvb_core] SS:ESP 0068:e7935f58
> 
> Message from syslogd@brian at Jan 31 19:52:33 ...
>  kernel:[  116.563706] CR2: 0000000000000000
> 
> PLEASE DO NOT IGNORE THIS MAIL!
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Videotext application crashes the kernel due to DVB-demux patch

[Andy Walls]

On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > Hi,
> > 
> > here is a link to a patch which breaks backwards compatibility for a
> > teletext software called alevt-dvb.
> > 
> > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > 
> > The kernel patch was introduced with kernel 2.6.32-rc1.
> > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > author, Andreas Oberritter.
> > 

> > Regards
> > 
> > CS
> > 
> > P. S.: This is how the kernel crash looks like:
> 
> The information below can get me started.  Could you please provide
> whole Ooops from the output dmesg or from your /var/log/messages file?
> 
> I'll try to look at this tonight.
> 
> Regards,
> Andy
> 
> > brian:~# alevt
> > alevt: SDT: service_id 0xcf24 not in PAT
> > 
> > sid:pmtpid:ttpid:type:provider:name:language:texttype:magazine:page
> > 
> > 28006:100:130:1:ZDFvision:ZDF:lang=deu:type=1:magazine=1:page=  0
> > 28011:600:630:1:ZDFvision:ZDFinfokanal:lang=deu:type=1:magazine=1:page=
> > 0
> > 28014:650:630:1:ZDFvision:zdf_neo:lang=deu:type=1:magazine=1:page=  0
> > 28016:1100:630:1:ZDFvision:ZDFtheaterkanal:lang=deu:type=1:magazine=1:page=  0
> > 28007:200:230:1:ZDFvision:3sat:lang=deu:type=1:magazine=1:page=  0
> > 28008:300:330:1:ZDFvision:KiKa:lang=deu:type=1:magazine=1:page=  0
> > 28017:411:8191:2:ZDFvision:DRadio Wissen:lang=:type=0:magazine=0:page=
> > 0
> > 28012:700:8191:2:ZDFvision:DKULTUR:lang=:type=0:magazine=0:page=  0
> > 28013:800:8191:2:ZDFvision:DLF:lang=:type=0:magazine=0:page=  0
> > 
> > Using: Service ID = 28006 ; PMT PID = 100 ; TXT PID = 130 ;
> > Service type = 1 ; Provider Name = ZDFvision ; Service name = ZDF ;
> > language = deu ; Text type = 1 ; Text Magazine = 1 ; Text page =   0
> > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > Getötet
> > brian:~# 
> > Message from syslogd@brian at Jan 31 19:52:33 ...
> >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> > 
> > Message from syslogd@brian at Jan 31 19:52:33 ...
> >  kernel:[  116.563492] last sysfs
> > file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/uevent
> > 
> > Message from syslogd@brian at Jan 31 19:52:33 ...
> >  kernel:[  116.563589] Process alevt (pid: 1780, ti=e7934000
> > task=e7915be0 task.ti=e7934000)
> > 
> > Message from syslogd@brian at Jan 31 19:52:33 ...
> >  kernel:[  116.563592] Stack:
> > 
> > Message from syslogd@brian at Jan 31 19:52:33 ...
> >  kernel:[  116.563622] Call Trace:
> > 
> > Message from syslogd@brian at Jan 31 19:52:33 ...
> >  kernel:[  116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8
> > e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b
> > 46 04 8d 48 f8 <8b> 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89
> > 50 04 89 

> > Message from syslogd@brian at Jan 31 19:52:33 ...
> >  kernel:[  116.563697] EIP: [<f8cec1b2>] dvb_demux_release+0x43/0x183
> > [dvb_core] SS:ESP 0068:e7935f58
> > 
> > Message from syslogd@brian at Jan 31 19:52:33 ...
> >  kernel:[  116.563706] CR2: 0000000000000000

I don't have a 32 bti machine set up to compile the module and compare
the disassembly directly.  However, the kernel code above disassembles
to this, and is supposedly in dvb_demux_release() but things have been
inlined by the compiler:

  1c:	8d 56 78             	lea    0x78(%esi),%edx
  1f:	89 54 24 04          	mov    %edx,0x4(%esp)
  23:	89 d0                	mov    %edx,%eax
  25:	e8 e4 da 4c c8       	call   0xc84cdb0e
  2a:	89 f0                	mov    %esi,%eax
  2c:	e8 31 ff ff ff       	call   0xffffff62
					(dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here
					 %esi holds dmxdevfilter)
  31:	83 7e 4c 01          	cmpl   $0x1,0x4c(%esi)    if (dmxdevfilter->state < DMXDEV_STATE_SET)
  35:	76 73                	jbe    0xaa               	return 0;
  37:	83 7e 48 02          	cmpl   $0x2,0x48(%esi)    if (dmxdevfilter->type == DMXDEV_TYPE_PES)
  3b:	75 49                	jne    0x86
					(dvb_dmxdev_delete_pids() appears to be inlined starting here
					 %esi still holds dmxdevfilter)
  3d:	8b 46 04             	mov    0x4(%esi),%eax     %eax gets loaded with &dmxdevfilter->feed.ts  for list_for_each_entry_safe(feed, tmp, &dmxdevfilter->feed.ts, ...
  40:	8d 48 f8             	lea    -0x8(%eax),%ecx    %ecx is "feed" and gets loaded with the next struct dmxdev_feed pointed to by the &dmxdevfilter->feed.ts list
  43:	8b 41 08             	mov    0x8(%ecx),%eax     Oops appears to happen here: %ecx and hence "feed" was (craftily?) set to 0xfffffff8 based on CR2 above
  46:	8d 58 f8             	lea    -0x8(%eax),%ebx
  49:	8d 7e 04             	lea    0x4(%esi),%edi
  4c:	eb 28                	jmp    0x76
  4e:	8b 41 08             	mov    0x8(%ecx),%eax
  51:	8b 51 0c             	mov    0xc(%ecx),%edx
  54:	89 50 04             	mov    %edx,0x4(%eax)


So there is something wrong with the list manipulations or, if needed,
locking around the the list manipulations of the list that was
introduced in the patch you identified as the problem.  That is what is
causing the Ooops on close().  It will take a some more scrutiny to see
what exactly is wrong.


There also may be another different problem.  I note that alevt outputs
this perror() message:

	alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)

There may possibly have been an unintended change in ioctl() semantics
with the patch.  I have not investigated this at all yet.



That's all I have time for tonight.  The soonest I will be able to give
more attention to this is on Wednesday evening.

Regards,
Andy

Re: Videotext application crashes the kernel due to DVB-demux patch

[Chicken Shack]

Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > > Hi,
> > > 
> > > here is a link to a patch which breaks backwards compatibility for a
> > > teletext software called alevt-dvb.
> > > 
> > > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > > 
> > > The kernel patch was introduced with kernel 2.6.32-rc1.
> > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > > author, Andreas Oberritter.
> > > 
> 
> > > Regards
> > > 
> > > CS
> > > 
> > > P. S.: This is how the kernel crash looks like:
> > 
> > The information below can get me started.  Could you please provide
> > whole Ooops from the output dmesg or from your /var/log/messages file?
> > 
> > I'll try to look at this tonight.
> > 
> > Regards,
> > Andy
> > 
> > > brian:~# alevt
> > > alevt: SDT: service_id 0xcf24 not in PAT
> > > 
> > > sid:pmtpid:ttpid:type:provider:name:language:texttype:magazine:page
> > > 
> > > 28006:100:130:1:ZDFvision:ZDF:lang=deu:type=1:magazine=1:page=  0
> > > 28011:600:630:1:ZDFvision:ZDFinfokanal:lang=deu:type=1:magazine=1:page=
> > > 0
> > > 28014:650:630:1:ZDFvision:zdf_neo:lang=deu:type=1:magazine=1:page=  0
> > > 28016:1100:630:1:ZDFvision:ZDFtheaterkanal:lang=deu:type=1:magazine=1:page=  0
> > > 28007:200:230:1:ZDFvision:3sat:lang=deu:type=1:magazine=1:page=  0
> > > 28008:300:330:1:ZDFvision:KiKa:lang=deu:type=1:magazine=1:page=  0
> > > 28017:411:8191:2:ZDFvision:DRadio Wissen:lang=:type=0:magazine=0:page=
> > > 0
> > > 28012:700:8191:2:ZDFvision:DKULTUR:lang=:type=0:magazine=0:page=  0
> > > 28013:800:8191:2:ZDFvision:DLF:lang=:type=0:magazine=0:page=  0
> > > 
> > > Using: Service ID = 28006 ; PMT PID = 100 ; TXT PID = 130 ;
> > > Service type = 1 ; Provider Name = ZDFvision ; Service name = ZDF ;
> > > language = deu ; Text type = 1 ; Text Magazine = 1 ; Text page =   0
> > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > Getötet
> > > brian:~# 
> > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> > > 
> > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > >  kernel:[  116.563492] last sysfs
> > > file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/uevent
> > > 
> > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > >  kernel:[  116.563589] Process alevt (pid: 1780, ti=e7934000
> > > task=e7915be0 task.ti=e7934000)
> > > 
> > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > >  kernel:[  116.563592] Stack:
> > > 
> > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > >  kernel:[  116.563622] Call Trace:
> > > 
> > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > >  kernel:[  116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8
> > > e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b
> > > 46 04 8d 48 f8 <8b> 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89
> > > 50 04 89 
> 
> > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > >  kernel:[  116.563697] EIP: [<f8cec1b2>] dvb_demux_release+0x43/0x183
> > > [dvb_core] SS:ESP 0068:e7935f58
> > > 
> > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > >  kernel:[  116.563706] CR2: 0000000000000000
> 
> I don't have a 32 bti machine set up to compile the module and compare
> the disassembly directly.  However, the kernel code above disassembles
> to this, and is supposedly in dvb_demux_release() but things have been
> inlined by the compiler:
> 
>   1c:	8d 56 78             	lea    0x78(%esi),%edx
>   1f:	89 54 24 04          	mov    %edx,0x4(%esp)
>   23:	89 d0                	mov    %edx,%eax
>   25:	e8 e4 da 4c c8       	call   0xc84cdb0e
>   2a:	89 f0                	mov    %esi,%eax
>   2c:	e8 31 ff ff ff       	call   0xffffff62
> 					(dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here
> 					 %esi holds dmxdevfilter)
>   31:	83 7e 4c 01          	cmpl   $0x1,0x4c(%esi)    if (dmxdevfilter->state < DMXDEV_STATE_SET)
>   35:	76 73                	jbe    0xaa               	return 0;
>   37:	83 7e 48 02          	cmpl   $0x2,0x48(%esi)    if (dmxdevfilter->type == DMXDEV_TYPE_PES)
>   3b:	75 49                	jne    0x86
> 					(dvb_dmxdev_delete_pids() appears to be inlined starting here
> 					 %esi still holds dmxdevfilter)
>   3d:	8b 46 04             	mov    0x4(%esi),%eax     %eax gets loaded with &dmxdevfilter->feed.ts  for list_for_each_entry_safe(feed, tmp, &dmxdevfilter->feed.ts, ...
>   40:	8d 48 f8             	lea    -0x8(%eax),%ecx    %ecx is "feed" and gets loaded with the next struct dmxdev_feed pointed to by the &dmxdevfilter->feed.ts list
>   43:	8b 41 08             	mov    0x8(%ecx),%eax     Oops appears to happen here: %ecx and hence "feed" was (craftily?) set to 0xfffffff8 based on CR2 above
>   46:	8d 58 f8             	lea    -0x8(%eax),%ebx
>   49:	8d 7e 04             	lea    0x4(%esi),%edi
>   4c:	eb 28                	jmp    0x76
>   4e:	8b 41 08             	mov    0x8(%ecx),%eax
>   51:	8b 51 0c             	mov    0xc(%ecx),%edx
>   54:	89 50 04             	mov    %edx,0x4(%eax)
> 
> 
> So there is something wrong with the list manipulations or, if needed,
> locking around the the list manipulations of the list that was
> introduced in the patch you identified as the problem.  That is what is
> causing the Ooops on close().  It will take a some more scrutiny to see
> what exactly is wrong.
> 
> 
> There also may be another different problem.  I note that alevt outputs
> this perror() message:
> 
> 	alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)

> There may possibly have been an unintended change in ioctl() semantics
> with the patch.  I have not investigated this at all yet.


Voila!

This is the context of the perror message:

a. this is the title of the function:

static int vbi_dvb_open(struct vbi *vbi, const char *vbi_name,
	const char *channel, char *outfile, u_int16_t sid, int ttpid)

b. and this is the immediate context of the perror message:

	memset(&filterpar, 0, sizeof(filterpar));
	filterpar.pid = vbi->ttpid;
        filterpar.input = DMX_IN_FRONTEND;
        filterpar.output = DMX_OUT_TAP;
        filterpar.pes_type = DMX_PES_OTHER;
        filterpar.flags = DMX_IMMEDIATE_START;
        if (ioctl(vbi->fd, DMX_SET_PES_FILTER, &filterpar) < 0) {
        error("ioctl: DMX_SET_PES_FILTER %s (%u)", strerror(errno),
errno);
        goto outerr;
        }
	return 0;

 outerr:
	close(vbi->fd);
	vbi->fd = -1;
	return -1;
}

If you compare that to other teletext applications you will easily find
out that there is absolutely nothing irregular about it: all standard
calls, free from bugs or syntax errors.

So the incriminated patch (see Internet link above) is something like a
trojan horse, a virus. It is definitely not a valid extension of the DVB
demux device.

a. What is the "Invalid argument"?
b. And what does "22" mean?

The answers lie in the incriminated kernel patch (see Internet link
above), but definitely NOT in the application (alevt-dvb).

Thanks for your engagement, Andy!
It's a golden donation to have people like you around!

I really wonder for what three valid signatures (i. e. Signed-off-by)
are here for if the people in question obviously do not know, comprehend
or understand what they are doing!

Under normal conditions the intention of more than one signature is a
kind of control function. But how can one execute control over a kernel
changeset if the profound competence is missing??


> That's all I have time for tonight.  The soonest I will be able to give
> more attention to this is on Wednesday evening.
> 
> Regards,
> Andy
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards

CS

Re: Videotext application crashes the kernel due to DVB-demux patch

[Andy Walls]

On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > > > Hi,
> > > > 
> > > > here is a link to a patch which breaks backwards compatibility for a
> > > > teletext software called alevt-dvb.
> > > > 
> > > > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > > > 
> > > > The kernel patch was introduced with kernel 2.6.32-rc1.
> > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > > > author, Andreas Oberritter.
> > > > 
> > 
> > > > Regards
> > > > 
> > > > CS
> > > > 
> > > > P. S.: This is how the kernel crash looks like:
> > > 
> > > The information below can get me started.  Could you please provide
> > > whole Ooops from the output dmesg or from your /var/log/messages file?
> > > 
> > > I'll try to look at this tonight.
> > > 
> > > Regards,
> > > Andy
> > > 
> > > > brian:~# alevt
> > > > alevt: SDT: service_id 0xcf24 not in PAT

> > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > > Getötet
> > > > brian:~# 
> > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> > > > 
> > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > >  kernel:[  116.563492] last sysfs
> > > > file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/uevent
> > > > 
> > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > >  kernel:[  116.563589] Process alevt (pid: 1780, ti=e7934000
> > > > task=e7915be0 task.ti=e7934000)
> > > > 
> > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > >  kernel:[  116.563592] Stack:
> > > > 
> > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > >  kernel:[  116.563622] Call Trace:
> > > > 
> > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > >  kernel:[  116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8
> > > > e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b
> > > > 46 04 8d 48 f8 <8b> 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89
> > > > 50 04 89 
> > 
> > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > >  kernel:[  116.563697] EIP: [<f8cec1b2>] dvb_demux_release+0x43/0x183
> > > > [dvb_core] SS:ESP 0068:e7935f58
> > > > 
> > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > >  kernel:[  116.563706] CR2: 0000000000000000
> > 
> > I don't have a 32 bti machine set up to compile the module and compare
> > the disassembly directly.  However, the kernel code above disassembles
> > to this, and is supposedly in dvb_demux_release() but things have been
> > inlined by the compiler:
> > 
> >   1c:	8d 56 78             	lea    0x78(%esi),%edx
> >   1f:	89 54 24 04          	mov    %edx,0x4(%esp)
> >   23:	89 d0                	mov    %edx,%eax
> >   25:	e8 e4 da 4c c8       	call   0xc84cdb0e
> >   2a:	89 f0                	mov    %esi,%eax
> >   2c:	e8 31 ff ff ff       	call   0xffffff62
> > 					(dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here
> > 					 %esi holds dmxdevfilter)
> >   31:	83 7e 4c 01          	cmpl   $0x1,0x4c(%esi)    if (dmxdevfilter->state < DMXDEV_STATE_SET)
> >   35:	76 73                	jbe    0xaa               	return 0;
> >   37:	83 7e 48 02          	cmpl   $0x2,0x48(%esi)    if (dmxdevfilter->type == DMXDEV_TYPE_PES)
> >   3b:	75 49                	jne    0x86
> > 					(dvb_dmxdev_delete_pids() appears to be inlined starting here
> > 					 %esi still holds dmxdevfilter)
> >   3d:	8b 46 04             	mov    0x4(%esi),%eax     %eax gets loaded with &dmxdevfilter->feed.ts  for list_for_each_entry_safe(feed, tmp, &dmxdevfilter->feed.ts, ...
> >   40:	8d 48 f8             	lea    -0x8(%eax),%ecx    %ecx is "feed" and gets loaded with the next struct dmxdev_feed pointed to by the &dmxdevfilter->feed.ts list
> >   43:	8b 41 08             	mov    0x8(%ecx),%eax     Oops appears to happen here: %ecx and hence "feed" was (craftily?) set to 0xfffffff8 based on CR2 above
> >   46:	8d 58 f8             	lea    -0x8(%eax),%ebx
> >   49:	8d 7e 04             	lea    0x4(%esi),%edi
> >   4c:	eb 28                	jmp    0x76
> >   4e:	8b 41 08             	mov    0x8(%ecx),%eax
> >   51:	8b 51 0c             	mov    0xc(%ecx),%edx
> >   54:	89 50 04             	mov    %edx,0x4(%eax)
> > 
> > 
> > So there is something wrong with the list manipulations or, if needed,
> > locking around the the list manipulations of the list that was
> > introduced in the patch you identified as the problem.  That is what is
> > causing the Ooops on close().  It will take a some more scrutiny to see
> > what exactly is wrong.

With further thought, a very likely of a list's "next" pointer being
NULL would be either:

1. Failing to init the "struct list_head" dmxdevfilter->feed.ts after
dmxdevfilter is first kzalloc()'ed.

2. The other member of the dmxdevfilter->feed union being set to NULL
unexpectedly.  (less likely)

I'll look at these possibilities on Wednesday evening.


> > There also may be another different problem.  I note that alevt outputs
> > this perror() message:
> > 
> > 	alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> 
> > There may possibly have been an unintended change in ioctl() semantics
> > with the patch.  I have not investigated this at all yet.
> 
> 
> Voila!
> 
> This is the context of the perror message:
> 
> a. this is the title of the function:
> 
> static int vbi_dvb_open(struct vbi *vbi, const char *vbi_name,
> 	const char *channel, char *outfile, u_int16_t sid, int ttpid)
> 
> b. and this is the immediate context of the perror message:
> 
> 	memset(&filterpar, 0, sizeof(filterpar));
> 	filterpar.pid = vbi->ttpid;
>         filterpar.input = DMX_IN_FRONTEND;
>         filterpar.output = DMX_OUT_TAP;
>         filterpar.pes_type = DMX_PES_OTHER;
>         filterpar.flags = DMX_IMMEDIATE_START;
>         if (ioctl(vbi->fd, DMX_SET_PES_FILTER, &filterpar) < 0) {
>         error("ioctl: DMX_SET_PES_FILTER %s (%u)", strerror(errno),
> errno);
>         goto outerr;
>         }
> 	return 0;
> 
>  outerr:
> 	close(vbi->fd);
> 	vbi->fd = -1;
> 	return -1;
> }
> 
> If you compare that to other teletext applications you will easily find
> out that there is absolutely nothing irregular about it: all standard
> calls, free from bugs or syntax errors.


OK.  Thank you for hunting down the application call into the driver.
That should reduce the time to find the cause


> a. What is the "Invalid argument"?
> b. And what does "22" mean?

22 is the errno value for EINVAL which means loosely mean "Invalid
Argument", but can often be used when something internally is just
"Invalid".

/usr/include/asm-generic/errno-base.h:#define	EINVAL		22	/* Invalid argument */

Given the ioctl() call you've documented above, it should be easy enough
to find where in the DVB subsystem the EINVAL is coming from.  And it is
likely that it is coming from code added by the patch, but I won't know
until I can examine further.


> Thanks for your engagement, Andy!

You're welcome.


> It's a golden donation to have people like you around!

Thank you.

Regards,
Andy

Re: Videotext application crashes the kernel due to DVB-demux patch

[hermann pitton]

Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > > > > Hi,
> > > > > 
> > > > > here is a link to a patch which breaks backwards compatibility for a
> > > > > teletext software called alevt-dvb.
> > > > > 
> > > > > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > > > > 
> > > > > The kernel patch was introduced with kernel 2.6.32-rc1.
> > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > > > > author, Andreas Oberritter.
> > > > > 
> > > 
> > > > > Regards
> > > > > 
> > > > > CS
> > > > > 
> > > > > P. S.: This is how the kernel crash looks like:
> > > > 
> > > > The information below can get me started.  Could you please provide
> > > > whole Ooops from the output dmesg or from your /var/log/messages file?
> > > > 
> > > > I'll try to look at this tonight.
> > > > 
> > > > Regards,
> > > > Andy
> > > > 
> > > > > brian:~# alevt
> > > > > alevt: SDT: service_id 0xcf24 not in PAT
> 
> > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > > > Getötet
> > > > > brian:~# 
> > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> > > > > 
> > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > >  kernel:[  116.563492] last sysfs
> > > > > file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/uevent
> > > > > 
> > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > >  kernel:[  116.563589] Process alevt (pid: 1780, ti=e7934000
> > > > > task=e7915be0 task.ti=e7934000)
> > > > > 
> > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > >  kernel:[  116.563592] Stack:
> > > > > 
> > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > >  kernel:[  116.563622] Call Trace:
> > > > > 
> > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > >  kernel:[  116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8
> > > > > e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b
> > > > > 46 04 8d 48 f8 <8b> 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89
> > > > > 50 04 89 
> > > 
> > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > >  kernel:[  116.563697] EIP: [<f8cec1b2>] dvb_demux_release+0x43/0x183
> > > > > [dvb_core] SS:ESP 0068:e7935f58
> > > > > 
> > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > >  kernel:[  116.563706] CR2: 0000000000000000
> > > 
> > > I don't have a 32 bti machine set up to compile the module and compare
> > > the disassembly directly.  However, the kernel code above disassembles
> > > to this, and is supposedly in dvb_demux_release() but things have been
> > > inlined by the compiler:
> > > 
> > >   1c:	8d 56 78             	lea    0x78(%esi),%edx
> > >   1f:	89 54 24 04          	mov    %edx,0x4(%esp)
> > >   23:	89 d0                	mov    %edx,%eax
> > >   25:	e8 e4 da 4c c8       	call   0xc84cdb0e
> > >   2a:	89 f0                	mov    %esi,%eax
> > >   2c:	e8 31 ff ff ff       	call   0xffffff62
> > > 					(dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here
> > > 					 %esi holds dmxdevfilter)
> > >   31:	83 7e 4c 01          	cmpl   $0x1,0x4c(%esi)    if (dmxdevfilter->state < DMXDEV_STATE_SET)
> > >   35:	76 73                	jbe    0xaa               	return 0;
> > >   37:	83 7e 48 02          	cmpl   $0x2,0x48(%esi)    if (dmxdevfilter->type == DMXDEV_TYPE_PES)
> > >   3b:	75 49                	jne    0x86
> > > 					(dvb_dmxdev_delete_pids() appears to be inlined starting here
> > > 					 %esi still holds dmxdevfilter)
> > >   3d:	8b 46 04             	mov    0x4(%esi),%eax     %eax gets loaded with &dmxdevfilter->feed.ts  for list_for_each_entry_safe(feed, tmp, &dmxdevfilter->feed.ts, ...
> > >   40:	8d 48 f8             	lea    -0x8(%eax),%ecx    %ecx is "feed" and gets loaded with the next struct dmxdev_feed pointed to by the &dmxdevfilter->feed.ts list
> > >   43:	8b 41 08             	mov    0x8(%ecx),%eax     Oops appears to happen here: %ecx and hence "feed" was (craftily?) set to 0xfffffff8 based on CR2 above
> > >   46:	8d 58 f8             	lea    -0x8(%eax),%ebx
> > >   49:	8d 7e 04             	lea    0x4(%esi),%edi
> > >   4c:	eb 28                	jmp    0x76
> > >   4e:	8b 41 08             	mov    0x8(%ecx),%eax
> > >   51:	8b 51 0c             	mov    0xc(%ecx),%edx
> > >   54:	89 50 04             	mov    %edx,0x4(%eax)
> > > 
> > > 
> > > So there is something wrong with the list manipulations or, if needed,
> > > locking around the the list manipulations of the list that was
> > > introduced in the patch you identified as the problem.  That is what is
> > > causing the Ooops on close().  It will take a some more scrutiny to see
> > > what exactly is wrong.
> 
> With further thought, a very likely of a list's "next" pointer being
> NULL would be either:
> 
> 1. Failing to init the "struct list_head" dmxdevfilter->feed.ts after
> dmxdevfilter is first kzalloc()'ed.
> 
> 2. The other member of the dmxdevfilter->feed union being set to NULL
> unexpectedly.  (less likely)
> 
> I'll look at these possibilities on Wednesday evening.
> 
> 
> > > There also may be another different problem.  I note that alevt outputs
> > > this perror() message:
> > > 
> > > 	alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > 
> > > There may possibly have been an unintended change in ioctl() semantics
> > > with the patch.  I have not investigated this at all yet.
> > 
> > 
> > Voila!
> > 
> > This is the context of the perror message:
> > 
> > a. this is the title of the function:
> > 
> > static int vbi_dvb_open(struct vbi *vbi, const char *vbi_name,
> > 	const char *channel, char *outfile, u_int16_t sid, int ttpid)
> > 
> > b. and this is the immediate context of the perror message:
> > 
> > 	memset(&filterpar, 0, sizeof(filterpar));
> > 	filterpar.pid = vbi->ttpid;
> >         filterpar.input = DMX_IN_FRONTEND;
> >         filterpar.output = DMX_OUT_TAP;
> >         filterpar.pes_type = DMX_PES_OTHER;
> >         filterpar.flags = DMX_IMMEDIATE_START;
> >         if (ioctl(vbi->fd, DMX_SET_PES_FILTER, &filterpar) < 0) {
> >         error("ioctl: DMX_SET_PES_FILTER %s (%u)", strerror(errno),
> > errno);
> >         goto outerr;
> >         }
> > 	return 0;
> > 
> >  outerr:
> > 	close(vbi->fd);
> > 	vbi->fd = -1;
> > 	return -1;
> > }
> > 
> > If you compare that to other teletext applications you will easily find
> > out that there is absolutely nothing irregular about it: all standard
> > calls, free from bugs or syntax errors.
> 
> 
> OK.  Thank you for hunting down the application call into the driver.
> That should reduce the time to find the cause
> 
> 
> > a. What is the "Invalid argument"?
> > b. And what does "22" mean?
> 
> 22 is the errno value for EINVAL which means loosely mean "Invalid
> Argument", but can often be used when something internally is just
> "Invalid".
> 
> /usr/include/asm-generic/errno-base.h:#define	EINVAL		22	/* Invalid argument */
> 
> Given the ioctl() call you've documented above, it should be easy enough
> to find where in the DVB subsystem the EINVAL is coming from.  And it is
> likely that it is coming from code added by the patch, but I won't know
> until I can examine further.
> 
> 
> > Thanks for your engagement, Andy!
> 
> You're welcome.
> 
> 
> > It's a golden donation to have people like you around!
> 
> Thank you.
> 
> Regards,
> Andy

Hi Andy,

take care, such golden donations can turn into golden showers very soon.

Prefer to stay with the original author.

I think he is still alive ;)

Cheers,
Hermann

Re: Videotext application crashes the kernel due to DVB-demux patch

[Andy Walls]

On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> > > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > here is a link to a patch which breaks backwards compatibility for a
> > > > > > teletext software called alevt-dvb.
> > > > > > 
> > > > > > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > > > > > 
> > > > > > The kernel patch was introduced with kernel 2.6.32-rc1.
> > > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > > > > > author, Andreas Oberritter.
> > > > > > 
> > > > 
> > > > > > Regards
> > > > > > 
> > > > > > CS
> > > > > > 
> > > > > > P. S.: This is how the kernel crash looks like:
> > > > > 
> > > > > The information below can get me started.  Could you please provide
> > > > > whole Ooops from the output dmesg or from your /var/log/messages file?
> > > > > 
> > > > > I'll try to look at this tonight.
> > > > > 
> > > > > Regards,
> > > > > Andy
> > > > > 
> > > > > > brian:~# alevt
> > > > > > alevt: SDT: service_id 0xcf24 not in PAT
> > 
> > > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > > > > Getötet
> > > > > > brian:~# 
> > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> > > > > > 
> > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > >  kernel:[  116.563492] last sysfs
> > > > > > file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/uevent
> > > > > > 
> > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > >  kernel:[  116.563589] Process alevt (pid: 1780, ti=e7934000
> > > > > > task=e7915be0 task.ti=e7934000)
> > > > > > 
> > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > >  kernel:[  116.563592] Stack:
> > > > > > 
> > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > >  kernel:[  116.563622] Call Trace:
> > > > > > 
> > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > >  kernel:[  116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8
> > > > > > e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b
> > > > > > 46 04 8d 48 f8 <8b> 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89
> > > > > > 50 04 89 
> > > > 
> > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > >  kernel:[  116.563697] EIP: [<f8cec1b2>] dvb_demux_release+0x43/0x183
> > > > > > [dvb_core] SS:ESP 0068:e7935f58
> > > > > > 
> > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > >  kernel:[  116.563706] CR2: 0000000000000000
> > > > 
> > > > I don't have a 32 bti machine set up to compile the module and compare
> > > > the disassembly directly.  However, the kernel code above disassembles
> > > > to this, and is supposedly in dvb_demux_release() but things have been
> > > > inlined by the compiler:
> > > > 
> > > >   1c:	8d 56 78             	lea    0x78(%esi),%edx
> > > >   1f:	89 54 24 04          	mov    %edx,0x4(%esp)
> > > >   23:	89 d0                	mov    %edx,%eax
> > > >   25:	e8 e4 da 4c c8       	call   0xc84cdb0e
> > > >   2a:	89 f0                	mov    %esi,%eax
> > > >   2c:	e8 31 ff ff ff       	call   0xffffff62
> > > > 					(dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here
> > > > 					 %esi holds dmxdevfilter)
> > > >   31:	83 7e 4c 01          	cmpl   $0x1,0x4c(%esi)    if (dmxdevfilter->state < DMXDEV_STATE_SET)
> > > >   35:	76 73                	jbe    0xaa               	return 0;
> > > >   37:	83 7e 48 02          	cmpl   $0x2,0x48(%esi)    if (dmxdevfilter->type == DMXDEV_TYPE_PES)
> > > >   3b:	75 49                	jne    0x86
> > > > 					(dvb_dmxdev_delete_pids() appears to be inlined starting here
> > > > 					 %esi still holds dmxdevfilter)
> > > >   3d:	8b 46 04             	mov    0x4(%esi),%eax     %eax gets loaded with &dmxdevfilter->feed.ts  for list_for_each_entry_safe(feed, tmp, &dmxdevfilter->feed.ts, ...
> > > >   40:	8d 48 f8             	lea    -0x8(%eax),%ecx    %ecx is "feed" and gets loaded with the next struct dmxdev_feed pointed to by the &dmxdevfilter->feed.ts list
> > > >   43:	8b 41 08             	mov    0x8(%ecx),%eax     Oops appears to happen here: %ecx and hence "feed" was (craftily?) set to 0xfffffff8 based on CR2 above
> > > >   46:	8d 58 f8             	lea    -0x8(%eax),%ebx
> > > >   49:	8d 7e 04             	lea    0x4(%esi),%edi
> > > >   4c:	eb 28                	jmp    0x76
> > > >   4e:	8b 41 08             	mov    0x8(%ecx),%eax
> > > >   51:	8b 51 0c             	mov    0xc(%ecx),%edx
> > > >   54:	89 50 04             	mov    %edx,0x4(%eax)
> > > > 
> > > > 
> > > > So there is something wrong with the list manipulations or, if needed,
> > > > locking around the the list manipulations of the list that was
> > > > introduced in the patch you identified as the problem.  That is what is
> > > > causing the Ooops on close().  It will take a some more scrutiny to see
> > > > what exactly is wrong.
> > 
> > With further thought, a very likely of a list's "next" pointer being
> > NULL would be either:
> > 
> > 1. Failing to init the "struct list_head" dmxdevfilter->feed.ts after
> > dmxdevfilter is first kzalloc()'ed.
> > 
> > 2. The other member of the dmxdevfilter->feed union being set to NULL
> > unexpectedly.  (less likely)
> > 
> > I'll look at these possibilities on Wednesday evening.
> > 

Schedule update: I'll be looking at this tonight (Thursday evening).
But maybe that was obvious by now....


> > > > There also may be another different problem.  I note that alevt outputs
> > > > this perror() message:
> > > > 
> > > > 	alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > 
> > > > There may possibly have been an unintended change in ioctl() semantics
> > > > with the patch.  I have not investigated this at all yet.
> > > 
> > > 
> > > Voila!
> > > 
> > > This is the context of the perror message:
> > > 
> > > a. this is the title of the function:
> > > 
> > > static int vbi_dvb_open(struct vbi *vbi, const char *vbi_name,
> > > 	const char *channel, char *outfile, u_int16_t sid, int ttpid)
> > > 
> > > b. and this is the immediate context of the perror message:
> > > 
> > > 	memset(&filterpar, 0, sizeof(filterpar));
> > > 	filterpar.pid = vbi->ttpid;
> > >         filterpar.input = DMX_IN_FRONTEND;
> > >         filterpar.output = DMX_OUT_TAP;
> > >         filterpar.pes_type = DMX_PES_OTHER;
> > >         filterpar.flags = DMX_IMMEDIATE_START;
> > >         if (ioctl(vbi->fd, DMX_SET_PES_FILTER, &filterpar) < 0) {
> > >         error("ioctl: DMX_SET_PES_FILTER %s (%u)", strerror(errno),
> > > errno);
> > >         goto outerr;
> > >         }
> > > 	return 0;
> > > 
> > >  outerr:
> > > 	close(vbi->fd);
> > > 	vbi->fd = -1;
> > > 	return -1;
> > > }
> > > 
> > > If you compare that to other teletext applications you will easily find
> > > out that there is absolutely nothing irregular about it: all standard
> > > calls, free from bugs or syntax errors.
> > 
> > 
> > OK.  Thank you for hunting down the application call into the driver.
> > That should reduce the time to find the cause
> > 
> > 
> > > a. What is the "Invalid argument"?
> > > b. And what does "22" mean?
> > 
> > 22 is the errno value for EINVAL which means loosely mean "Invalid
> > Argument", but can often be used when something internally is just
> > "Invalid".
> > 
> > /usr/include/asm-generic/errno-base.h:#define	EINVAL		22	/* Invalid argument */
> > 
> > Given the ioctl() call you've documented above, it should be easy enough
> > to find where in the DVB subsystem the EINVAL is coming from.  And it is
> > likely that it is coming from code added by the patch, but I won't know
> > until I can examine further.
> > 
> > 
> > > Thanks for your engagement, Andy!
> > 
> > You're welcome.
> > 
> > 
> > > It's a golden donation to have people like you around!
> > 
> > Thank you.
> > 
> > Regards,
> > Andy
> 
> Hi Andy,
> 
> take care, such golden donations can turn into g**** s***** very soon.
                                                 
Hi Hermann,

You might want to avoid that two-word slang phrase in polite company,
with American English speakers at least.  Unless you are trying to make
a really shocking point. ;)

Language and cultural divides can be amusing at times. :)


> 
> Prefer to stay with the original author.
> 
> I think he is still alive ;)

I've added him to the Cc: list.

Regards,
Andy

> Cheers,
> Hermann

Re: Videotext application crashes the kernel due to DVB-demux patch

[Chicken Shack]

Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:
> On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> > > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> > > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> > > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> > > > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > here is a link to a patch which breaks backwards compatibility for a
> > > > > > > teletext software called alevt-dvb.
> > > > > > > 
> > > > > > > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > > > > > > 
> > > > > > > The kernel patch was introduced with kernel 2.6.32-rc1.
> > > > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > > > > > > author, Andreas Oberritter.
> > > > > > > 
> > > > > 
> > > > > > > Regards
> > > > > > > 
> > > > > > > CS
> > > > > > > 
> > > > > > > P. S.: This is how the kernel crash looks like:
> > > > > > 
> > > > > > The information below can get me started.  Could you please provide
> > > > > > whole Ooops from the output dmesg or from your /var/log/messages file?
> > > > > > 
> > > > > > I'll try to look at this tonight.
> > > > > > 
> > > > > > Regards,
> > > > > > Andy
> > > > > > 
> > > > > > > brian:~# alevt
> > > > > > > alevt: SDT: service_id 0xcf24 not in PAT
> > > 
> > > > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > > > > > Getötet
> > > > > > > brian:~# 
> > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> > > > > > > 
> > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > >  kernel:[  116.563492] last sysfs
> > > > > > > file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/uevent
> > > > > > > 
> > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > >  kernel:[  116.563589] Process alevt (pid: 1780, ti=e7934000
> > > > > > > task=e7915be0 task.ti=e7934000)
> > > > > > > 
> > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > >  kernel:[  116.563592] Stack:
> > > > > > > 
> > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > >  kernel:[  116.563622] Call Trace:
> > > > > > > 
> > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > >  kernel:[  116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8
> > > > > > > e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b
> > > > > > > 46 04 8d 48 f8 <8b> 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89
> > > > > > > 50 04 89 
> > > > > 
> > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > >  kernel:[  116.563697] EIP: [<f8cec1b2>] dvb_demux_release+0x43/0x183
> > > > > > > [dvb_core] SS:ESP 0068:e7935f58
> > > > > > > 
> > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > >  kernel:[  116.563706] CR2: 0000000000000000
> > > > > 
> > > > > I don't have a 32 bti machine set up to compile the module and compare
> > > > > the disassembly directly.  However, the kernel code above disassembles
> > > > > to this, and is supposedly in dvb_demux_release() but things have been
> > > > > inlined by the compiler:
> > > > > 
> > > > >   1c:	8d 56 78             	lea    0x78(%esi),%edx
> > > > >   1f:	89 54 24 04          	mov    %edx,0x4(%esp)
> > > > >   23:	89 d0                	mov    %edx,%eax
> > > > >   25:	e8 e4 da 4c c8       	call   0xc84cdb0e
> > > > >   2a:	89 f0                	mov    %esi,%eax
> > > > >   2c:	e8 31 ff ff ff       	call   0xffffff62
> > > > > 					(dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here
> > > > > 					 %esi holds dmxdevfilter)
> > > > >   31:	83 7e 4c 01          	cmpl   $0x1,0x4c(%esi)    if (dmxdevfilter->state < DMXDEV_STATE_SET)
> > > > >   35:	76 73                	jbe    0xaa               	return 0;
> > > > >   37:	83 7e 48 02          	cmpl   $0x2,0x48(%esi)    if (dmxdevfilter->type == DMXDEV_TYPE_PES)
> > > > >   3b:	75 49                	jne    0x86
> > > > > 					(dvb_dmxdev_delete_pids() appears to be inlined starting here
> > > > > 					 %esi still holds dmxdevfilter)
> > > > >   3d:	8b 46 04             	mov    0x4(%esi),%eax     %eax gets loaded with &dmxdevfilter->feed.ts  for list_for_each_entry_safe(feed, tmp, &dmxdevfilter->feed.ts, ...
> > > > >   40:	8d 48 f8             	lea    -0x8(%eax),%ecx    %ecx is "feed" and gets loaded with the next struct dmxdev_feed pointed to by the &dmxdevfilter->feed.ts list
> > > > >   43:	8b 41 08             	mov    0x8(%ecx),%eax     Oops appears to happen here: %ecx and hence "feed" was (craftily?) set to 0xfffffff8 based on CR2 above
> > > > >   46:	8d 58 f8             	lea    -0x8(%eax),%ebx
> > > > >   49:	8d 7e 04             	lea    0x4(%esi),%edi
> > > > >   4c:	eb 28                	jmp    0x76
> > > > >   4e:	8b 41 08             	mov    0x8(%ecx),%eax
> > > > >   51:	8b 51 0c             	mov    0xc(%ecx),%edx
> > > > >   54:	89 50 04             	mov    %edx,0x4(%eax)
> > > > > 
> > > > > 
> > > > > So there is something wrong with the list manipulations or, if needed,
> > > > > locking around the the list manipulations of the list that was
> > > > > introduced in the patch you identified as the problem.  That is what is
> > > > > causing the Ooops on close().  It will take a some more scrutiny to see
> > > > > what exactly is wrong.
> > > 
> > > With further thought, a very likely of a list's "next" pointer being
> > > NULL would be either:
> > > 
> > > 1. Failing to init the "struct list_head" dmxdevfilter->feed.ts after
> > > dmxdevfilter is first kzalloc()'ed.
> > > 
> > > 2. The other member of the dmxdevfilter->feed union being set to NULL
> > > unexpectedly.  (less likely)
> > > 
> > > I'll look at these possibilities on Wednesday evening.
> > > 
> 
> Schedule update: I'll be looking at this tonight (Thursday evening).
> But maybe that was obvious by now....

You're talking in secret words that confuse me a bit......

So what was obvious by now???
And what are the conclusions? And what are the changesets to be made?

I think it's neither a specific application problem nor is it a specific
driver problem. It's rather a mixture of both types.
My intuition tells me furthermore that the core reason for the kernel
crash and the core reason for the hanging process when the channel is
changed are one and the same reason.
But, as I already stated, things ran fine for 9 years.

And the kernel patch itself was not correctly described. It was sold as
the extension of what you call ioctl() by adding two further commands.

But in fact it is a quite rude and radical change of the DVB demux
device's structure.
If it weren't such a radical change then the DVB implementation of alevt
would not break down just like that, after performing without any
breakdowns for over 9 years now (!).

And it is de facto highly annoying if the reaction on this faulty
behaviour is either playing it down (that's typical Chehab politics) or
diving off wordlessly (Andreas Oberritter).

And - what is the real most annoying aspect about that all:
At the top of the stairs - on the layer where L. T. decides what becomes
part of the kernel and what not:

Wouldn't it be more than cynical to talk about quality management if the
result of that quality management is that you can throw complete
applications that have performed error-free for 9 years right into the
next trashcan due to a simple kernel changeset?
What the hell is going on here?

If I could only resolve this problem on my own then I would not make
that loud noise - you can be sure about that.

All I can do is wildly guess around - and that's poor enough.

A few lines deeper you mention an "unintended change in ioctl()
semantics." What do you mean by that? You're talking in secrets again.

Do you mean "STRUCT_LIST_HEAD" or "INIT_LIST_HEAD" or stuff like that?
I haven't found that in the alevt code.
What do you mean? And, which is more important: Who can help to resolve
the issue?

And, last but not least, if you're really short in time (what you always
claim), then please do ignore Pitton's rant. He only steals time.

Looking forward to your output, Andy

Regards

CS

> > > > > There also may be another different problem.  I note that alevt outputs
> > > > > this perror() message:
> > > > > 
> > > > > 	alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > > 
> > > > > There may possibly have been an unintended change in ioctl() semantics
> > > > > with the patch.  I have not investigated this at all yet.
> > > > 
> > > > 
> > > > Voila!
> > > > 
> > > > This is the context of the perror message:
> > > > 
> > > > a. this is the title of the function:
> > > > 
> > > > static int vbi_dvb_open(struct vbi *vbi, const char *vbi_name,
> > > > 	const char *channel, char *outfile, u_int16_t sid, int ttpid)
> > > > 
> > > > b. and this is the immediate context of the perror message:
> > > > 
> > > > 	memset(&filterpar, 0, sizeof(filterpar));
> > > > 	filterpar.pid = vbi->ttpid;
> > > >         filterpar.input = DMX_IN_FRONTEND;
> > > >         filterpar.output = DMX_OUT_TAP;
> > > >         filterpar.pes_type = DMX_PES_OTHER;
> > > >         filterpar.flags = DMX_IMMEDIATE_START;
> > > >         if (ioctl(vbi->fd, DMX_SET_PES_FILTER, &filterpar) < 0) {
> > > >         error("ioctl: DMX_SET_PES_FILTER %s (%u)", strerror(errno),
> > > > errno);
> > > >         goto outerr;
> > > >         }
> > > > 	return 0;
> > > > 
> > > >  outerr:
> > > > 	close(vbi->fd);
> > > > 	vbi->fd = -1;
> > > > 	return -1;
> > > > }
> > > > 
> > > > If you compare that to other teletext applications you will easily find
> > > > out that there is absolutely nothing irregular about it: all standard
> > > > calls, free from bugs or syntax errors.
> > > 
> > > 
> > > OK.  Thank you for hunting down the application call into the driver.
> > > That should reduce the time to find the cause
> > > 
> > > 
> > > > a. What is the "Invalid argument"?
> > > > b. And what does "22" mean?
> > > 
> > > 22 is the errno value for EINVAL which means loosely mean "Invalid
> > > Argument", but can often be used when something internally is just
> > > "Invalid".
> > > 
> > > /usr/include/asm-generic/errno-base.h:#define	EINVAL		22	/* Invalid argument */
> > > 
> > > Given the ioctl() call you've documented above, it should be easy enough
> > > to find where in the DVB subsystem the EINVAL is coming from.  And it is
> > > likely that it is coming from code added by the patch, but I won't know
> > > until I can examine further.
> > > 
> > > 
> > > > Thanks for your engagement, Andy!
> > > 
> > > You're welcome.
> > > 
> > > 
> > > > It's a golden donation to have people like you around!
> > > 
> > > Thank you.
> > > 
> > > Regards,
> > > Andy
> > 
> > Hi Andy,
> > 
> > take care, such golden donations can turn into g**** s***** very soon.
>                                                  
> Hi Hermann,
> 
> You might want to avoid that two-word slang phrase in polite company,
> with American English speakers at least.  Unless you are trying to make
> a really shocking point. ;)
> 
> Language and cultural divides can be amusing at times. :)
> 
> 
> > 
> > Prefer to stay with the original author.
> > 
> > I think he is still alive ;)
> 
> I've added him to the Cc: list.
> 
> Regards,
> Andy
> 
> > Cheers,
> > Hermann
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Andy Walls]

On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote:
> Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:
> > On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> > > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> > > > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> > > > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> > > > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> > > > > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > here is a link to a patch which breaks backwards compatibility for a
> > > > > > > > teletext software called alevt-dvb.
> > > > > > > > 
> > > > > > > > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > > > > > > > 
> > > > > > > > The kernel patch was introduced with kernel 2.6.32-rc1.
> > > > > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > > > > > > > author, Andreas Oberritter.
> > > > > > > > 
> > > > > > 
> > > > > > > > Regards
> > > > > > > > 
> > > > > > > > CS
> > > > > > > > 
> > > > > > > > P. S.: This is how the kernel crash looks like:
> > > > > > > 
> > > > > > > The information below can get me started.  Could you please provide
> > > > > > > whole Ooops from the output dmesg or from your /var/log/messages file?
> > > > > > > 
> > > > > > > I'll try to look at this tonight.
> > > > > > > 
> > > > > > > Regards,
> > > > > > > Andy
> > > > > > > 
> > > > > > > > brian:~# alevt
> > > > > > > > alevt: SDT: service_id 0xcf24 not in PAT
> > > > 
> > > > > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > > > > > > Getötet
> > > > > > > > brian:~# 
> > > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > > >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 

> > > > > > So there is something wrong with the list manipulations or, if needed,
> > > > > > locking around the the list manipulations of the list that was
> > > > > > introduced in the patch you identified as the problem.  That is what is
> > > > > > causing the Ooops on close().  It will take a some more scrutiny to see
> > > > > > what exactly is wrong.
 
> > Schedule update: I'll be looking at this tonight (Thursday evening).

After investigation, my recommendation for fixing the problem is to
revert the patch that is causing the problem.

The reason for this is not that fixing the patch is impossible.
INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
demux0 device into multiple dynamically created anonymous dvr0 devices,
and that is the wrong thing to do.

I understand the need for sending a single PID TS out to an open demux0
instance as described in this email:

http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html

even though it seems like a slight abuse of the demux0 device.


But sending multiple PIDs out in a TS to the open demux0 device instance
is just an awkward way to essentially dynamically create a dvrN device
associated with filter(s) set on an open demux0 instance.

It would be better, in my opinion, to figure out a way to properly
create and/or associate a dvrN device node with a collection of demuxN
filters.

Maybe just allow creation of a logical demux1 device and dvr1 device and
the use the DVB API calls as is on the new logical devices.

I'm not a DVB apps programmer, so I don't know all the userspace needs
nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
ioctl()s.


Comments?

Regards,
Andy

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[hermann pitton]

Hi Andy,

Am Donnerstag, den 04.02.2010, 21:21 -0500 schrieb Andy Walls:
> On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote:
> > Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:
> > > On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> > > > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> > > > > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> > > > > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> > > > > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> > > > > > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > here is a link to a patch which breaks backwards compatibility for a
> > > > > > > > > teletext software called alevt-dvb.
> > > > > > > > > 
> > > > > > > > > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > > > > > > > > 
> > > > > > > > > The kernel patch was introduced with kernel 2.6.32-rc1.
> > > > > > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > > > > > > > > author, Andreas Oberritter.
> > > > > > > > > 
> > > > > > > 
> > > > > > > > > Regards
> > > > > > > > > 
> > > > > > > > > CS
> > > > > > > > > 
> > > > > > > > > P. S.: This is how the kernel crash looks like:
> > > > > > > > 
> > > > > > > > The information below can get me started.  Could you please provide
> > > > > > > > whole Ooops from the output dmesg or from your /var/log/messages file?
> > > > > > > > 
> > > > > > > > I'll try to look at this tonight.
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Andy
> > > > > > > > 
> > > > > > > > > brian:~# alevt
> > > > > > > > > alevt: SDT: service_id 0xcf24 not in PAT
> > > > > 
> > > > > > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > > > > > > > Getötet
> > > > > > > > > brian:~# 
> > > > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > > > >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> 
> > > > > > > So there is something wrong with the list manipulations or, if needed,
> > > > > > > locking around the the list manipulations of the list that was
> > > > > > > introduced in the patch you identified as the problem.  That is what is
> > > > > > > causing the Ooops on close().  It will take a some more scrutiny to see
> > > > > > > what exactly is wrong.
>  
> > > Schedule update: I'll be looking at this tonight (Thursday evening).
> 
> After investigation, my recommendation for fixing the problem is to
> revert the patch that is causing the problem.
> 
> The reason for this is not that fixing the patch is impossible.
> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
> demux0 device into multiple dynamically created anonymous dvr0 devices,
> and that is the wrong thing to do.
> 
> I understand the need for sending a single PID TS out to an open demux0
> instance as described in this email:
> 
> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
> 
> even though it seems like a slight abuse of the demux0 device.
> 
> 
> But sending multiple PIDs out in a TS to the open demux0 device instance
> is just an awkward way to essentially dynamically create a dvrN device
> associated with filter(s) set on an open demux0 instance.
> 
> It would be better, in my opinion, to figure out a way to properly
> create and/or associate a dvrN device node with a collection of demuxN
> filters.
> 
> Maybe just allow creation of a logical demux1 device and dvr1 device and
> the use the DVB API calls as is on the new logical devices.
> 
> I'm not a DVB apps programmer, so I don't know all the userspace needs
> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
> ioctl()s.
> 
> 
> Comments?
> 
> Regards,
> Andy


without looking any much closer, just at some headers that might be out
of sync,

taking the DVB patched version from here

http://pluto.blackbone-ev.de/v1/AleVT%20mit%20DVB-T.html

make
cc -O2 -s -w main.o ui.o xio.o fdset.o vbi.o cache.o help.o edline.o search.o edit.o misc.o hamm.o lang.o export.o exp-txt.o exp-html.o exp-gfx.o font.o -o alevt -L/usr/X11R6/lib -L/usr/X11R6/lib64 -lX11 -lpng -lz -lm
/usr/bin/ld: i386 architecture of input file `main.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `ui.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `xio.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `fdset.o' is incompatible with i386:x86-64 output
collect2: ld gab 1 als Ende-Status zurück
make: *** [alevt] Fehler 1

make clean
rm -f *.o page*.txt a.out core bdf2xbm font?.xbm fontsize.h Makefile.bak
rm -f alevt alevt-date alevt-cap
rm -f alevt.1x alevt-date.1 alevt-cap.1
rm -f contrib/a.out ttext-*.*
rm -f alevt.html

make
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o main.o main.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o ui.o ui.c
cc bdf2xbm.c -o bdf2xbm
./bdf2xbm font1 <vtxt-latin-1.bdf >font1.xbm
./bdf2xbm font2 <vtxt-latin-2.bdf >font2.xbm
fgrep -h "#define" font1.xbm font2.xbm >fontsize.h
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o xio.o xio.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o fdset.o fdset.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o vbi.o vbi.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o cache.o cache.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o help.o help.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o edline.o edline.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o search.o search.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o edit.o edit.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o misc.o misc.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o hamm.o hamm.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o lang.o lang.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o export.o export.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o exp-txt.o exp-txt.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o exp-html.o exp-html.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o exp-gfx.o exp-gfx.c
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o font.o font.c
cc -O2 -s -w main.o ui.o xio.o fdset.o vbi.o cache.o help.o edline.o search.o edit.o misc.o hamm.o lang.o export.o exp-txt.o exp-html.o exp-gfx.o font.o -o alevt -L/usr/X11R6/lib -L/usr/X11R6/lib64 -lX11 -lpng -lz -lm
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o alevt-date.o alevt-date.c
cc -O2 -s -w alevt-date.o vbi.o fdset.o misc.o hamm.o lang.o -o alevt-date
cc -O2 -s -w -DVERSION=\"1.6.2\" -DWITH_PNG -I/usr/X11R6/include   -c -o alevt-cap.o alevt-cap.c
cc -O2 -s -w alevt-cap.o vbi.o fdset.o misc.o hamm.o lang.o export.o exp-txt.o exp-html.o exp-gfx.o font.o -o alevt-cap -lpng -lz -lm
sed s/VERSION/1.6.2/g <alevt.1x.in >alevt.1x
sed s/VERSION/1.6.2/g <alevt-date.1.in >alevt-date.1
sed s/VERSION/1.6.2/g <alevt-cap.1.in >alevt-cap.1

./alevt -vbi /dev/dvb/adapter0/demux0 -pid 551
Using command line specified teletext PID 0x227

No problems so far on x86_64, but I can't tell yet what might be all around.

Cheers,
Hermann

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

Am Donnerstag, den 04.02.2010, 21:21 -0500 schrieb Andy Walls:
> On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote:
> > Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:
> > > On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> > > > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> > > > > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> > > > > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> > > > > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote:
> > > > > > > > On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > here is a link to a patch which breaks backwards compatibility for a
> > > > > > > > > teletext software called alevt-dvb.
> > > > > > > > > 
> > > > > > > > > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > > > > > > > > 
> > > > > > > > > The kernel patch was introduced with kernel 2.6.32-rc1.
> > > > > > > > > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > > > > > > > > author, Andreas Oberritter.
> > > > > > > > > 
> > > > > > > 
> > > > > > > > > Regards
> > > > > > > > > 
> > > > > > > > > CS
> > > > > > > > > 
> > > > > > > > > P. S.: This is how the kernel crash looks like:
> > > > > > > > 
> > > > > > > > The information below can get me started.  Could you please provide
> > > > > > > > whole Ooops from the output dmesg or from your /var/log/messages file?
> > > > > > > > 
> > > > > > > > I'll try to look at this tonight.
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Andy
> > > > > > > > 
> > > > > > > > > brian:~# alevt
> > > > > > > > > alevt: SDT: service_id 0xcf24 not in PAT
> > > > > 
> > > > > > > > > alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22)
> > > > > > > > > Getötet
> > > > > > > > > brian:~# 
> > > > > > > > > Message from syslogd@brian at Jan 31 19:52:33 ...
> > > > > > > > >  kernel:[  116.563487] Oops: 0000 [#1] PREEMPT SMP 
> 
> > > > > > > So there is something wrong with the list manipulations or, if needed,
> > > > > > > locking around the the list manipulations of the list that was
> > > > > > > introduced in the patch you identified as the problem.  That is what is
> > > > > > > causing the Ooops on close().  It will take a some more scrutiny to see
> > > > > > > what exactly is wrong.
>  
> > > Schedule update: I'll be looking at this tonight (Thursday evening).
> 
> After investigation, my recommendation for fixing the problem is to
> revert the patch that is causing the problem.
> 
> The reason for this is not that fixing the patch is impossible.
> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
> demux0 device into multiple dynamically created anonymous dvr0 devices,
> and that is the wrong thing to do.
> 
> I understand the need for sending a single PID TS out to an open demux0
> instance as described in this email:
> 
> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
> 
> even though it seems like a slight abuse of the demux0 device.
> 
> 
> But sending multiple PIDs out in a TS to the open demux0 device instance
> is just an awkward way to essentially dynamically create a dvrN device
> associated with filter(s) set on an open demux0 instance.
> 
> It would be better, in my opinion, to figure out a way to properly
> create and/or associate a dvrN device node with a collection of demuxN
> filters.
> 
> Maybe just allow creation of a logical demux1 device and dvr1 device and
> the use the DVB API calls as is on the new logical devices.
> 
> I'm not a DVB apps programmer, so I don't know all the userspace needs
> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
> ioctl()s.
> 
> 
> Comments?
> 
> Regards,
> Andy

Hi Andy,

thanks for this excellent analysis :)

kaffeine-1.0pre3, xawtv-4.0pre (->discontinued), vdr-1.6.0, mythtv-0.22:

None of them uses neither DMX_ADD_PID nor DMX_REMOVE_PID in conjunction
with DMX_OUT_TSDEMUX_TAP.

So reverting the kernel patch does not do harm to anybody.

Furthermore: If it is technically possible to send and receive, demux
and multiplex, play and record complete contents of a transponder (i. e.
multiple TS streams) by using dvbstream or mumudvb (-> 8192 command line
parameter), then I myself do not see the necessity to extend the
capabilities of one physical device dvr0 or demux0 into a multiplicity
of devices dvr0 or demux0.
The what and especially the why will remain Andreas Oberritters' secret.

However: The hanging process that alevt-dvb produces if an external
application switches to a channel belonging to a different DVB-S
transponder still remains the second problem which is not touched by
this discussion - just as a reminder for everybody!

The one who wants to use teletext under Linux is in a very bad position:

1. There seems to be a plugin for vdr that I never tried because I do
not like vdr at all.
2. alevt-dvb is officially not maintained. The last contribution by its
original author happened in 2007 with the implementation of v4l2.
3. mtt by Gerd Knorr (Hoffmann) is part of a discontinued suite called
xawtv-4.0 pre. xawtv-4.0 pre was never officially released or finished.
Especially the main program xawtv is simply unusable for modern DVB
needs.

mtt is still buggy and I do not like its design at all.
On the other hand it's not impressed or handicapped at all by the kernel
patch incriminated above. That's why I said that the problem discussed
here cannot be uniquely defined as kernel-specific.
It's also application-specific. It's simply both.
 
In some distros (Debian f. ex.) mtt does not exist officially.

Who of the people reading this feels competent enough in DVB application
programming to have a look at alevt-dvb to resolve the problem with the
hanging processes please?
Who volunteers please? Manu Abraham perhaps?

Thanks and Regards

CS

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[HoP]

Hi Chicken

>
> Furthermore: If it is technically possible to send and receive, demux
> and multiplex, play and record complete contents of a transponder (i. e.
> multiple TS streams) by using dvbstream or mumudvb (-> 8192 command line
> parameter), then I myself do not see the necessity to extend the
> capabilities of one physical device dvr0 or demux0 into a multiplicity
> of devices dvr0 or demux0.
> The what and especially the why will remain Andreas Oberritters' secret.

I can only say my 2 words regarding Andreas' patch:

At least one big DVB application is using it - enigma (originally
inside tuxbox project, later enhanced by Dream Multimedia
for theirs well-known linux based set-top-boxes Dreambox).
Those boxes are selling worlwide, so userbase is wide enough
(note: I'm not in any way connected with Dream Multimedia,
so it is only my personal feeling and/or investigation).

Of course using full TS and remuxing only in user land
is not possible way for embedded application. And if you count
that there can be more then one TS input, things are getting even worst.

And as Andy wrote:
>> But sending multiple PIDs out in a TS to the open demux0 device instance
>> is just an awkward way to essentially dynamically create a dvrN device
>> associated with filter(s) set on an open demux0 instance.
>>
>> It would be better, in my opinion, to figure out a way to properly
>> create and/or associate a dvrN device node with a collection of demuxN
>> filters.
>>
>> Maybe just allow creation of a logical demux1 device and dvr1 device and
>> the use the DVB API calls as is on the new logical devices.
>>
>> I'm not a DVB apps programmer, so I don't know all the userspace needs
>> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
>> ioctl()s.
>>
>>

Well, it is also possible way. But it expands
dvrX from usuall dvr0 to something like dvr0 ... dvr31 or so.

We definitelly need such feature.

I, personally, like DMX_OUT_TSDEMUX_TAP approach.

Rgds

/Honza

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Andy Walls]

On Fri, 2010-02-05 at 13:19 +0100, HoP wrote:
> Hi Chicken
> 
> >
> > Furthermore: If it is technically possible to send and receive, demux
> > and multiplex, play and record complete contents of a transponder (i. e.
> > multiple TS streams) by using dvbstream or mumudvb (-> 8192 command line
> > parameter), then I myself do not see the necessity to extend the
> > capabilities of one physical device dvr0 or demux0 into a multiplicity
> > of devices dvr0 or demux0.
> > The what and especially the why will remain Andreas Oberritters' secret.
> 
> I can only say my 2 words regarding Andreas' patch:
> 
> At least one big DVB application is using it - enigma (originally
> inside tuxbox project, later enhanced by Dream Multimedia
> for theirs well-known linux based set-top-boxes Dreambox).
> Those boxes are selling worlwide, so userbase is wide enough
> (note: I'm not in any way connected with Dream Multimedia,
> so it is only my personal feeling and/or investigation).
> 
> Of course using full TS and remuxing only in user land
> is not possible way for embedded application. And if you count
> that there can be more then one TS input, things are getting even worst.

Well then, it appears reverting the patch is not an option.

Time to slog through the code and fix it, I guess.


> And as Andy wrote:
> >> But sending multiple PIDs out in a TS to the open demux0 device instance
> >> is just an awkward way to essentially dynamically create a dvrN device
> >> associated with filter(s) set on an open demux0 instance.
> >>
> >> It would be better, in my opinion, to figure out a way to properly
> >> create and/or associate a dvrN device node with a collection of demuxN
> >> filters.
> >>
> >> Maybe just allow creation of a logical demux1 device and dvr1 device and
> >> the use the DVB API calls as is on the new logical devices.
> >>
> >> I'm not a DVB apps programmer, so I don't know all the userspace needs
> >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
> >> ioctl()s.
> >>
> >>
> 
> Well, it is also possible way. But it expands
> dvrX from usuall dvr0 to something like dvr0 ... dvr31 or so.
> 
> We definitelly need such feature.


I thought about this more and was thinking the device nodes presented to
userspace might look something like this:

/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/dvr0.0 (symlink to dvr0 or the other way around)
/dev/dvb/adapter0/dvr0.1
/dev/dvb/adapter0/dvr0.2
...
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/net0


So that dvr0.n was still associated with the demux0 filter settings, but
that the demux filter outputs could be steered to one of a number of
different dvr0.n devices.

That keeps dvr0.n devices as providing a TS multiplex of exactly the
PIDs one wants, allows multiple TS multiplexes to be recorded from the
originating demux0, and also allows the dvr0.n outputs to be controlled
by the originating demux0.

It would require the current DMX_SET_PES_FILTER_PARAMS ioctl()'s to be
modified, so that the output setting could include a "subaddress" (the n
in dvr0.n), but with a default of 0 for backward compatability.


> I, personally, like DMX_OUT_TSDEMUX_TAP approach.

>From what I gather, originally:

a. the demux0 device would provide a single PID stream (not a TS but a
"section"?) with DMX_OUT_TAP

b. the dvr0 device would provide a full TS multiplex of all the PIDs
specified with DMX_OUT_TS_TAP

c. a dvr node always delivered a TS and an open demux instance always
delivered a non-TS stream


So the problems were, I think:

a. No way to capture more than one TS from an originating demux.  So
userspace could not re-multiplex PIDs together easily(?).

b. No way to capture more than one TS multiplex from an originating
demux.  No way for userspace to easily capture separate TV programs from
a single multiplex, into separate TS multiplexes each containing only
the related PID for each spearate TV program (i.e. audio and video PIDs)



Problem a. was solved by the DMX_OUT_TSDEMUX_TAP change.  That was a
very simple patch and appear fairly straight forward.  It changes the
type of output one can get from an open demux0 instance from just
"section" to also include a single PID TS.  IMO, that change looks like
a conveient shortcut to avoid dealing with how to implement multiple dvr
nodes per originating demux.  But that's OK, if your userspace app just
needs one PID per TS:  mplayer playing audio and video from one TV
program (?)


Problem b. was solved by the DMX_ADD_PID, DMX_REMOVE_PID patch.  This
allows an open demux instance to now not only send a TS, but also send
multiple PIDs in that TS, essentially creating an output of the kind one
would see at a dvr0 node.


So my thinking at this point is why dance around the issue?  The
requirement appears to be to set up multiple dvr type feeds for
userspace from a single originating demux.

I would want to take the time to audit the code and fix the problems
with the DMX_ADD_PID, DMX_REMOVE_PID patch, if it were not used by any
popular userspace apps and if there were something that made more sense.

Regards,
Andy

> Rgds
> 
> /Honza

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Andreas Oberritter]

Hello Andy,

Andy Walls wrote:
> After investigation, my recommendation for fixing the problem is to
> revert the patch that is causing the problem.
> 
> The reason for this is not that fixing the patch is impossible.
> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
> demux0 device into multiple dynamically created anonymous dvr0 devices,
> and that is the wrong thing to do.

why exactly do you think this is wrong?

> I understand the need for sending a single PID TS out to an open demux0
> instance as described in this email:
> 
> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
> 
> even though it seems like a slight abuse of the demux0 device.

How so? It's all about reading demultiplexed packets, which is exactly
what a demux is good for. There is btw. no other way for multiple
readers to receive TS packets without implementing a second demux
layer in a userspace daemon, which must then be used by all readers.
This would needlessly create quite some overhead on high bandwidth
services.

> But sending multiple PIDs out in a TS to the open demux0 device instance
> is just an awkward way to essentially dynamically create a dvrN device
> associated with filter(s) set on an open demux0 instance.

Actually it makes dvrN obsolete, but it must of course be kept for
backwards compatibility.

> It would be better, in my opinion, to figure out a way to properly
> create and/or associate a dvrN device node with a collection of demuxN
> filters.

Would this involve running mknod for every recording you start?

> Maybe just allow creation of a logical demux1 device and dvr1 device and
> the use the DVB API calls as is on the new logical devices.

A demux device (and dvr respectively) represents a transport stream
input. Hardware with multiple transport stream inputs (read: embedded
set top boxes) already has multiple demux and dvr devices.

> I'm not a DVB apps programmer, so I don't know all the userspace needs
> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
> ioctl()s.

The need for such an interface was already pointed out and discussed
back in 2006:
http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html

As Honza noted, these ioctls are used by enigma2 and, in general, by
software running on Dream Multimedia set top boxes. I'm sure, other
projects are going to adopt this interface sooner or later. It is
still quite new after all.

Regards,
Andreas

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Mauro Carvalho Chehab]

Andreas Oberritter wrote:
> Hello Andy,
> 
> Andy Walls wrote:
>> After investigation, my recommendation for fixing the problem is to
>> revert the patch that is causing the problem.

Well, the patch were already added on an upstream kernel, so just reverting it
will cause regressions.

If it is just aletv-dvb that broke, it seems better to fix it than to cause 
even more troubles by reverting two new ioctls.

>> The reason for this is not that fixing the patch is impossible.

Why? Where exactly the breakage happened?

>> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
>> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
>> demux0 device into multiple dynamically created anonymous dvr0 devices,
>> and that is the wrong thing to do.
> 
> why exactly do you think this is wrong?
> 
>> I understand the need for sending a single PID TS out to an open demux0
>> instance as described in this email:
>>
>> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
>>
>> even though it seems like a slight abuse of the demux0 device.
> 
> How so? It's all about reading demultiplexed packets, which is exactly
> what a demux is good for. There is btw. no other way for multiple
> readers to receive TS packets without implementing a second demux
> layer in a userspace daemon, which must then be used by all readers.
> This would needlessly create quite some overhead on high bandwidth
> services.
>> But sending multiple PIDs out in a TS to the open demux0 device instance
>> is just an awkward way to essentially dynamically create a dvrN device
>> associated with filter(s) set on an open demux0 instance.
> 
> Actually it makes dvrN obsolete, but it must of course be kept for
> backwards compatibility.
> 
>> It would be better, in my opinion, to figure out a way to properly
>> create and/or associate a dvrN device node with a collection of demuxN
>> filters.
> 
> Would this involve running mknod for every recording you start?
> 
>> Maybe just allow creation of a logical demux1 device and dvr1 device and
>> the use the DVB API calls as is on the new logical devices.
> 
> A demux device (and dvr respectively) represents a transport stream
> input. Hardware with multiple transport stream inputs (read: embedded
> set top boxes) already has multiple demux and dvr devices.


Andreas arguments makes sense to me.

 
>> I'm not a DVB apps programmer, so I don't know all the userspace needs
>> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
>> ioctl()s.
> 
> The need for such an interface was already pointed out and discussed
> back in 2006:
> http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html
> 
> As Honza noted, these ioctls are used by enigma2 and, in general, by
> software running on Dream Multimedia set top boxes. I'm sure, other
> projects are going to adopt this interface sooner or later. It is
> still quite new after all.


It seems too late for me to revert it. So, we need to figure out a way
to workaround it or to fix the applications that got broken by this change.

-- 

Cheers,
Mauro

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

Am Freitag, den 05.02.2010, 11:28 -0200 schrieb Mauro Carvalho Chehab:
> Andreas Oberritter wrote:
> > Hello Andy,
> > 
> > Andy Walls wrote:
> >> After investigation, my recommendation for fixing the problem is to
> >> revert the patch that is causing the problem.
> 
> Well, the patch were already added on an upstream kernel, so just reverting it
> will cause regressions.
> 
> If it is just aletv-dvb that broke, it seems better to fix it than to cause 
> even more troubles by reverting two new ioctls.
> 
> >> The reason for this is not that fixing the patch is impossible.
> 
> Why? Where exactly the breakage happened?


Mauro,

alevt-dvb is the only application that is broken by that kernel patch in
question.
mtt works, but it is part of a suite of programs, it's not teletext
only.
So the architexture behind is much more complicated than alevt-dvb
itself ever was.

Conclusion: fix the application alevt-dvb is the shortest way to solve
the problem.

CS


> >> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
> >> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
> >> demux0 device into multiple dynamically created anonymous dvr0 devices,
> >> and that is the wrong thing to do.
> > 
> > why exactly do you think this is wrong?
> > 
> >> I understand the need for sending a single PID TS out to an open demux0
> >> instance as described in this email:
> >>
> >> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
> >>
> >> even though it seems like a slight abuse of the demux0 device.
> > 
> > How so? It's all about reading demultiplexed packets, which is exactly
> > what a demux is good for. There is btw. no other way for multiple
> > readers to receive TS packets without implementing a second demux
> > layer in a userspace daemon, which must then be used by all readers.
> > This would needlessly create quite some overhead on high bandwidth
> > services.
> >> But sending multiple PIDs out in a TS to the open demux0 device instance
> >> is just an awkward way to essentially dynamically create a dvrN device
> >> associated with filter(s) set on an open demux0 instance.
> > 
> > Actually it makes dvrN obsolete, but it must of course be kept for
> > backwards compatibility.
> > 
> >> It would be better, in my opinion, to figure out a way to properly
> >> create and/or associate a dvrN device node with a collection of demuxN
> >> filters.
> > 
> > Would this involve running mknod for every recording you start?
> > 
> >> Maybe just allow creation of a logical demux1 device and dvr1 device and
> >> the use the DVB API calls as is on the new logical devices.
> > 
> > A demux device (and dvr respectively) represents a transport stream
> > input. Hardware with multiple transport stream inputs (read: embedded
> > set top boxes) already has multiple demux and dvr devices.
> 
> 
> Andreas arguments makes sense to me.
> 
>  
> >> I'm not a DVB apps programmer, so I don't know all the userspace needs
> >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
> >> ioctl()s.
> > 
> > The need for such an interface was already pointed out and discussed
> > back in 2006:
> > http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html
> > 
> > As Honza noted, these ioctls are used by enigma2 and, in general, by
> > software running on Dream Multimedia set top boxes. I'm sure, other
> > projects are going to adopt this interface sooner or later. It is
> > still quite new after all.
> 
> 
> It seems too late for me to revert it. So, we need to figure out a way
> to workaround it or to fix the applications that got broken by this change.
> 

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

Am Freitag, den 05.02.2010, 11:28 -0200 schrieb Mauro Carvalho Chehab:
> Andreas Oberritter wrote:
> > Hello Andy,
> > 
> > Andy Walls wrote:
> >> After investigation, my recommendation for fixing the problem is to
> >> revert the patch that is causing the problem.
> 
> Well, the patch were already added on an upstream kernel, so just reverting it
> will cause regressions.
> 
> If it is just aletv-dvb that broke, it seems better to fix it than to cause 
> even more troubles by reverting two new ioctls.
> 
> >> The reason for this is not that fixing the patch is impossible.
> 
> Why? Where exactly the breakage happened?

Mauro,

I think the dissassembler extracts done by Andy do answer this question
already. Just go back to the first messages of that thread and you will
know where the breakage begins.
For an experienced programmer / coder it should not be too different to
draw the adequate conclusions what needs to be done.

While everybody is behaving rather passive defending the kernel status
quo, stressing the fact that this discussion is nearly one week old now:

The core questions are:

1. What is the minimum adequate requirement for alevt-dvb to conform to
the latest DVB demux design and do its work again without noise and
causing kernel oopses?

2. What is the minimum adequate requirement for alevt-dvb to stop
causing hanging processes when the transponder is changed?
In its current state the application does not seem to understand the
effects of a PMT change (->program management table).

3. Who can write / offer patches for alevt's DVB design?

Still hoping for qualified help

CS


> >> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
> >> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
> >> demux0 device into multiple dynamically created anonymous dvr0 devices,
> >> and that is the wrong thing to do.
> > 
> > why exactly do you think this is wrong?
> > 
> >> I understand the need for sending a single PID TS out to an open demux0
> >> instance as described in this email:
> >>
> >> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
> >>
> >> even though it seems like a slight abuse of the demux0 device.
> > 
> > How so? It's all about reading demultiplexed packets, which is exactly
> > what a demux is good for. There is btw. no other way for multiple
> > readers to receive TS packets without implementing a second demux
> > layer in a userspace daemon, which must then be used by all readers.
> > This would needlessly create quite some overhead on high bandwidth
> > services.
> >> But sending multiple PIDs out in a TS to the open demux0 device instance
> >> is just an awkward way to essentially dynamically create a dvrN device
> >> associated with filter(s) set on an open demux0 instance.
> > 
> > Actually it makes dvrN obsolete, but it must of course be kept for
> > backwards compatibility.
> > 
> >> It would be better, in my opinion, to figure out a way to properly
> >> create and/or associate a dvrN device node with a collection of demuxN
> >> filters.
> > 
> > Would this involve running mknod for every recording you start?
> > 
> >> Maybe just allow creation of a logical demux1 device and dvr1 device and
> >> the use the DVB API calls as is on the new logical devices.
> > 
> > A demux device (and dvr respectively) represents a transport stream
> > input. Hardware with multiple transport stream inputs (read: embedded
> > set top boxes) already has multiple demux and dvr devices.
> 
> 
> Andreas arguments makes sense to me.
> 
>  
> >> I'm not a DVB apps programmer, so I don't know all the userspace needs
> >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
> >> ioctl()s.
> > 
> > The need for such an interface was already pointed out and discussed
> > back in 2006:
> > http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html
> > 
> > As Honza noted, these ioctls are used by enigma2 and, in general, by
> > software running on Dream Multimedia set top boxes. I'm sure, other
> > projects are going to adopt this interface sooner or later. It is
> > still quite new after all.
> 
> 
> It seems too late for me to revert it. So, we need to figure out a way
> to workaround it or to fix the applications that got broken by this change.
> 

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Andy Walls]

Hi Andreas,

On Fri, 2010-02-05 at 14:19 +0100, Andreas Oberritter wrote:
> Hello Andy,
> 
> Andy Walls wrote:
> > After investigation, my recommendation for fixing the problem is to
> > revert the patch that is causing the problem.
> > 
> > The reason for this is not that fixing the patch is impossible.
> > INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in
> > conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the
> > demux0 device into multiple dynamically created anonymous dvr0 devices,
> > and that is the wrong thing to do.
> 
> why exactly do you think this is wrong?


Originally the dvr0 device provided a single TS multiplex of PIDs while
the open instances of demux0 each provided a single stream.

The end objective appears to be able to have multiple different TS
multiplexes from a single hardware (or software) demux.

IMO, the logical answer from a userspace perspective is to have multiple
dvr device nodes (eg dvr0.n) corresponding to a single originating
demux0 device node.  With each one of those dvr0.n devices configurable
essentially as before from the demux0 node, but being able to steer the
output of a filter to a dvr node other than dvr0 (e.g. dvr0.2).


The patches that added DMX_OUT_TSDEMUX_TAP and then
DMX_ADD_PID/DMX_REMOVE_PID, seemed to be avoiding implementing multiple
dvr nodes associated with a single demux node.  The end result is that
demux0, essentially a device node intended for control AFAICT, has now
been transformed to be multiple anonymous dvr device nodes.

In my opinion, that was the wrong end result.  I guess that is based on
my notion that the original Nokia/Convergence API separated control from
datastream, and these changes together do just the opposite.


> > I understand the need for sending a single PID TS out to an open demux0
> > instance as described in this email:
> > 
> > http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
> > 
> > even though it seems like a slight abuse of the demux0 device.
> 
> How so? It's all about reading demultiplexed packets, which is exactly
> what a demux is good for.

My perception was that the demux0 node was for control of the TS output
(and perhaps debug for isolating stream).  The dvr0 node was for
presenting a TS to userspace.



>  There is btw. no other way for multiple
> readers to receive TS packets without implementing a second demux
> layer in a userspace daemon, which must then be used by all readers.
> This would needlessly create quite some overhead on high bandwidth
> services.

I agree.  The DVB subsystem need a way to present multiple TS multiplexs
to userspace from a single, orginating demultiplexer.


> > But sending multiple PIDs out in a TS to the open demux0 device instance
> > is just an awkward way to essentially dynamically create a dvrN device
> > associated with filter(s) set on an open demux0 instance.
> 
> Actually it makes dvrN obsolete, but it must of course be kept for
> backwards compatibility.

Yes it does, except for write() functionality, which is only available
for dvr0 and not demux0.

It also collapses control of one demultiplexer and all the data streams
available from it down to one device node.


> > It would be better, in my opinion, to figure out a way to properly
> > create and/or associate a dvrN device node with a collection of demuxN
> > filters.
> 
> Would this involve running mknod for every recording you start?

I would think that dvb_dmxdev_init() would register a number of
DVB_DEVICE_DVR device nodes for demux0 named something like dvr0.0 (or
dvr0), dvr0.1, dvr0.2, dvr0.3, etc.  udev rules would handle device node
creation.

A module parameter could allow the user to set the number of dvr0.n
nodes to a non-default number.

Just an idea.


> > Maybe just allow creation of a logical demux1 device and dvr1 device and
> > the use the DVB API calls as is on the new logical devices.
> 
> A demux device (and dvr respectively) represents a transport stream
> input. Hardware with multiple transport stream inputs (read: embedded
> set top boxes) already has multiple demux and dvr devices.

Yes, that was a bad idea.  I agree with you: one demux device node per
input TS and demultiplexer device.


One could still have multiple dvr0.m nodes representing different filter
configurations from a demux0 node.


> > I'm not a DVB apps programmer, so I don't know all the userspace needs
> > nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID
> > ioctl()s.
> 
> The need for such an interface was already pointed out and discussed
> back in 2006:
> http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html
> 
> As Honza noted, these ioctls are used by enigma2 and, in general, by
> software running on Dream Multimedia set top boxes.

Right, so reverting the patch is not an option.

It also makes implementing multiple dvr0.n nodes for a demux0 device
node probably a waste of time at this point.

Thanks for the comments.

Regards,
Andy

>  I'm sure, other
> projects are going to adopt this interface sooner or later. It is
> still quite new after all.
> 
> Regards,
> Andreas

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Andreas Oberritter]

Andy Walls wrote:
> Originally the dvr0 device provided a single TS multiplex of PIDs while
> the open instances of demux0 each provided a single stream.
> 
> The end objective appears to be able to have multiple different TS
> multiplexes from a single hardware (or software) demux.

Right.

> IMO, the logical answer from a userspace perspective is to have multiple
> dvr device nodes (eg dvr0.n) corresponding to a single originating
> demux0 device node.  With each one of those dvr0.n devices configurable
> essentially as before from the demux0 node, but being able to steer the
> output of a filter to a dvr node other than dvr0 (e.g. dvr0.2).

This sounds like a matter of taste to me.

But anyway, your proposal would have one of two possible side effects:
You could either choose to allocate those device nodes statically,
which would create an artificial limit of filter groups on hardware,
where filters are shared between multiple inputs. Or you could create
the device nodes dynamically, which would involve waiting for udev to
create the new node between setting up the filter(s) and being able to
read data.

Another reason for the addition of the two new ioctls was, that
changing the DMX_SET_PES_FILTER control was not an option, to keep old
software running on new kernels and vice versa.

> The patches that added DMX_OUT_TSDEMUX_TAP and then
> DMX_ADD_PID/DMX_REMOVE_PID, seemed to be avoiding implementing multiple
> dvr nodes associated with a single demux node.  The end result is that
> demux0, essentially a device node intended for control AFAICT, has now
> been transformed to be multiple anonymous dvr device nodes.
> 
> In my opinion, that was the wrong end result.  I guess that is based on
> my notion that the original Nokia/Convergence API separated control from
> datastream, and these changes together do just the opposite.

That's wrong. The demuxN devices have always been used to control
filters and to read section and PES (i.e. TS payload) data streams.
The addition of DMX_OUT_TSDEMUX_TAP was just an extension to read a
third type of data from it (TS header + payload).

>>> I understand the need for sending a single PID TS out to an open demux0
>>> instance as described in this email:
>>>
>>> http://www.mail-archive.com/linux-dvb@linuxtv.org/msg29814.html
>>>
>>> even though it seems like a slight abuse of the demux0 device.
>> How so? It's all about reading demultiplexed packets, which is exactly
>> what a demux is good for.
> 
> My perception was that the demux0 node was for control of the TS output
> (and perhaps debug for isolating stream). 

Being able to read section and PES data is very important for DVB
applications. This is definitely not a debugging feature. Processing
raw TS streams for other purposes than recording to disk is rarely
seen on DVB devices. It's something that mainly comes from the PC
world, which is dominated by cheap peripherials which have no or very
limited capabilities for filtering and stream processing.

> The dvr0 node was for
> presenting a TS to userspace.

Right.

>>> But sending multiple PIDs out in a TS to the open demux0 device instance
>>> is just an awkward way to essentially dynamically create a dvrN device
>>> associated with filter(s) set on an open demux0 instance.
>> Actually it makes dvrN obsolete, but it must of course be kept for
>> backwards compatibility.
> 
> Yes it does, except for write() functionality, which is only available
> for dvr0 and not demux0.

Right.

> It also collapses control of one demultiplexer and all the data streams
> available from it down to one device node.

That has already been the case for sections and PES since the first
days of the API. The only recent change is to allow multiple PIDs per
file descriptor (which only makes sense for TS, not for sections and
PES, where the PID value itself is not carried inside the payload).

>> As Honza noted, these ioctls are used by enigma2 and, in general, by
>> software running on Dream Multimedia set top boxes.
> 
> Right, so reverting the patch is not an option.
> 
> It also makes implementing multiple dvr0.n nodes for a demux0 device
> node probably a waste of time at this point.

I think so, too. But I guess it's always worth discussing alternatives.

Regards,
Andreas

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Mauro Carvalho Chehab]

Andreas Oberritter wrote:
> Andy Walls wrote:

>>> As Honza noted, these ioctls are used by enigma2 and, in general, by
>>> software running on Dream Multimedia set top boxes.
>> Right, so reverting the patch is not an option.
>>
>> It also makes implementing multiple dvr0.n nodes for a demux0 device
>> node probably a waste of time at this point.
> 
> I think so, too. But I guess it's always worth discussing alternatives.

If this discussion happened before 2.6.32 release, and provided that a different
implementation were agreed, things would be easier, as a different solution like
your proposal could be decided and used.

Now, we have already a regression on a stable kernel, and solving it by
creating another regression is not something smart to do.

>From what I understood, the regression appeared on an old, orphan
application with a non-official patch applied on it. Other applications with
similar features weren't affected. On the other hand, if the patch got reverted, 
we'll break a maintained application that is used on a great number of devices,
and whose features depend on the new ioctls.

We are too late in -rc cycle, so probably there's not enough time for
writing, test, validate any new API in time for 2.6.33 and write some compat
layer to emulate those two ioctls with a different implementation.

So, removing those two ioctls is not an option anymore.


Cheers,
Mauro

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[hermann pitton]

Hi,

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> Andreas Oberritter wrote:
> > Andy Walls wrote:
> 
> >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> >>> software running on Dream Multimedia set top boxes.
> >> Right, so reverting the patch is not an option.
> >>
> >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> >> node probably a waste of time at this point.
> > 
> > I think so, too. But I guess it's always worth discussing alternatives.
> 
> If this discussion happened before 2.6.32 release, and provided that a different
> implementation were agreed, things would be easier, as a different solution like
> your proposal could be decided and used.
> 
> Now, we have already a regression on a stable kernel, and solving it by
> creating another regression is not something smart to do.
> 
> >From what I understood, the regression appeared on an old, orphan
> application with a non-official patch applied on it. Other applications with
> similar features weren't affected. On the other hand, if the patch got reverted, 
> we'll break a maintained application that is used on a great number of devices,
> and whose features depend on the new ioctls.
> 
> We are too late in -rc cycle, so probably there's not enough time for
> writing, test, validate any new API in time for 2.6.33 and write some compat
> layer to emulate those two ioctls with a different implementation.
> 
> So, removing those two ioctls is not an option anymore.
> 
> 
> Cheers,
> Mauro

during the still ongoing v4l to v4l2 conversion, all major apps did ship
with their own headers.

Since we keep backward compat, that previously unknown to me
alevt-dvb-t, agreed it is a nice to have, should compile against the
older headers instead latest kernel headers, until someone maintains it
again and takes advantage of later improvements.

Untested, but usually we see just such.

Cheers,
Hermann

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> Andreas Oberritter wrote:
> > Andy Walls wrote:
> 
> >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> >>> software running on Dream Multimedia set top boxes.
> >> Right, so reverting the patch is not an option.
> >>
> >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> >> node probably a waste of time at this point.
> > 
> > I think so, too. But I guess it's always worth discussing alternatives.
> 
> If this discussion happened before 2.6.32 release, and provided that a different
> implementation were agreed, things would be easier, as a different solution like
> your proposal could be decided and used.


You cannot expect people reacting immediately if something is wrong.
There are and do exist enormous delays between publishing a new kernel
and the decision to use it after appropriate system or distro update.
So your expectation level is simply wrong.


> Now, we have already a regression on a stable kernel, and solving it by
> creating another regression is not something smart to do.


Yes. Trivial!


> >From what I understood, the regression appeared on an old, orphan
> application with a non-official patch applied on it. Other applications with
> similar features weren't affected. On the other hand, if the patch got reverted, 
> we'll break a maintained application that is used on a great number of devices,
> and whose features depend on the new ioctls.


It's truly amazing how the filter system of your perception works, isn't
it? :)

It's not just "an old, orphaned application with a non-official patch on
it." That's nonsense!

a. As I stated already, there do exist several patched versions of
alevt-dvb. For instance the one that Herman Pitton tested here in public
causes a closed demux device error on my machine. That means that it
does not run because xine-ui is already using the demux device.
And this phenomenon has got nothing to do with the kernel headers!
I've tried all possibilities (old kernel headers and actual ones) so I
know better than Hermann Pitton does!

And my version (and obviously the ones of Thomas Voegtle and Emil Meier
whom I helped with my tip to revert that patch) cause a kernel crash
with the actual kernel.

b. As I also stated already the other teletext application called mtt
does officially not exist except for Novell / OpenSuSe distros (at least
as far as I have seen and found out). And this one
is, as I also stated, not affected by the kernel patch. It's part of a
discontinued program suite called xawtv-4.0 pre with a very complex
infrastructure behind.

Please do not ask me why this one runs without noise - I do not know.

So AFAICS alevt-dvb is the ONLY teletext application for Linux which is
available in almost all Gnu/Linux distros.

"Other applications with similar features weren't affected."

>From where do you know that the features are "similar"?

This is a 100 % phantasy product of your mind that has got nothing to do
with existing reality, man!

Just one example: alevt-dvb has got an excellent html export filter
which makes it possible to export teletext pages as graphical html
files.
I do not know any other teletext application offering that.


> We are too late in -rc cycle, so probably there's not enough time for
> writing, test, validate any new API in time for 2.6.33 and write some compat
> layer to emulate those two ioctls with a different implementation.

Who says that a new API or an overworked API must be ready for 2.6.33?
When do you think the correct starting point must be set?
When the merge window for 2.6.34 opens or when?
Absurd argument! Not valid at all!


> So, removing those two ioctls is not an option anymore.

Yes. Conclusion??? None!

So if everybody wants to close down this discussion with that output
then you must admit (if you want it or not) that you de facto bury
teletext usage in the mud for the majority of Gnu/Linux DVB users.

So the output is more than badly disappointing.
Bye bye Teletext. Nothing for future kernels, huh?

Regards

CS

P. S.: If you continue like that you make people run away.
Instead you better should try to win people, shouldn't you?

Just see how many volunteers are here to help and then reflect
why that manpower is missing, Mauro!
Your gesture being expressed above does a lot, but it is definitely NOT
motivating to change that precarious situation.

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[hermann pitton]

Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:
> Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> > Andreas Oberritter wrote:
> > > Andy Walls wrote:
> > 
> > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> > >>> software running on Dream Multimedia set top boxes.
> > >> Right, so reverting the patch is not an option.
> > >>
> > >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> > >> node probably a waste of time at this point.
> > > 
> > > I think so, too. But I guess it's always worth discussing alternatives.
> > 
> > If this discussion happened before 2.6.32 release, and provided that a different
> > implementation were agreed, things would be easier, as a different solution like
> > your proposal could be decided and used.
> 
> 
> You cannot expect people reacting immediately if something is wrong.
> There are and do exist enormous delays between publishing a new kernel
> and the decision to use it after appropriate system or distro update.
> So your expectation level is simply wrong.
> 
> 
> > Now, we have already a regression on a stable kernel, and solving it by
> > creating another regression is not something smart to do.
> 
> 
> Yes. Trivial!
> 
> 
> > >From what I understood, the regression appeared on an old, orphan
> > application with a non-official patch applied on it. Other applications with
> > similar features weren't affected. On the other hand, if the patch got reverted, 
> > we'll break a maintained application that is used on a great number of devices,
> > and whose features depend on the new ioctls.
> 
> 
> It's truly amazing how the filter system of your perception works, isn't
> it? :)
> 
> It's not just "an old, orphaned application with a non-official patch on
> it." That's nonsense!
> 
> a. As I stated already, there do exist several patched versions of
> alevt-dvb. For instance the one that Herman Pitton tested here in public
> causes a closed demux device error on my machine. That means that it
> does not run because xine-ui is already using the demux device.
> And this phenomenon has got nothing to do with the kernel headers!
> I've tried all possibilities (old kernel headers and actual ones) so I
> know better than Hermann Pitton does!
> 
> And my version (and obviously the ones of Thomas Voegtle and Emil Meier
> whom I helped with my tip to revert that patch) cause a kernel crash
> with the actual kernel.
> 
> b. As I also stated already the other teletext application called mtt
> does officially not exist except for Novell / OpenSuSe distros (at least
> as far as I have seen and found out). And this one
> is, as I also stated, not affected by the kernel patch. It's part of a
> discontinued program suite called xawtv-4.0 pre with a very complex
> infrastructure behind.
> 
> Please do not ask me why this one runs without noise - I do not know.
> 
> So AFAICS alevt-dvb is the ONLY teletext application for Linux which is
> available in almost all Gnu/Linux distros.
> 
> "Other applications with similar features weren't affected."
> 
> >From where do you know that the features are "similar"?
> 
> This is a 100 % phantasy product of your mind that has got nothing to do
> with existing reality, man!
> 
> Just one example: alevt-dvb has got an excellent html export filter
> which makes it possible to export teletext pages as graphical html
> files.
> I do not know any other teletext application offering that.
> 
> 
> > We are too late in -rc cycle, so probably there's not enough time for
> > writing, test, validate any new API in time for 2.6.33 and write some compat
> > layer to emulate those two ioctls with a different implementation.
> 
> Who says that a new API or an overworked API must be ready for 2.6.33?
> When do you think the correct starting point must be set?
> When the merge window for 2.6.34 opens or when?
> Absurd argument! Not valid at all!
> 
> 
> > So, removing those two ioctls is not an option anymore.
> 
> Yes. Conclusion??? None!
> 
> So if everybody wants to close down this discussion with that output
> then you must admit (if you want it or not) that you de facto bury
> teletext usage in the mud for the majority of Gnu/Linux DVB users.
> 
> So the output is more than badly disappointing.
> Bye bye Teletext. Nothing for future kernels, huh?

Yes, you say it. It definitely will go away and we do have not any
influence on that! Did you not notice the very slow update rate these
days?

> Regards
> 
> CS
> 
> P. S.: If you continue like that you make people run away.
> Instead you better should try to win people, shouldn't you?
> 
> Just see how many volunteers are here to help and then reflect
> why that manpower is missing, Mauro!
> Your gesture being expressed above does a lot, but it is definitely NOT
> motivating to change that precarious situation.

Then maybe better tell what you tried already, instead leaving others
behind doing the same in vain again?

Mauro always did try to keep backward compat as much as possible and
others had to tell him better not to waste his time on it.

You hit the wrong guy again and he can't even test anything.

Cheers,
Hermann

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:
> Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:
> > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> > > Andreas Oberritter wrote:
> > > > Andy Walls wrote:
> > > 
> > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> > > >>> software running on Dream Multimedia set top boxes.
> > > >> Right, so reverting the patch is not an option.
> > > >>
> > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> > > >> node probably a waste of time at this point.
> > > > 
> > > > I think so, too. But I guess it's always worth discussing alternatives.
> > > 
> > > If this discussion happened before 2.6.32 release, and provided that a different
> > > implementation were agreed, things would be easier, as a different solution like
> > > your proposal could be decided and used.
> > 
> > 
> > You cannot expect people reacting immediately if something is wrong.
> > There are and do exist enormous delays between publishing a new kernel
> > and the decision to use it after appropriate system or distro update.
> > So your expectation level is simply wrong.
> > 
> > 
> > > Now, we have already a regression on a stable kernel, and solving it by
> > > creating another regression is not something smart to do.
> > 
> > 
> > Yes. Trivial!
> > 
> > 
> > > >From what I understood, the regression appeared on an old, orphan
> > > application with a non-official patch applied on it. Other applications with
> > > similar features weren't affected. On the other hand, if the patch got reverted, 
> > > we'll break a maintained application that is used on a great number of devices,
> > > and whose features depend on the new ioctls.
> > 
> > 
> > It's truly amazing how the filter system of your perception works, isn't
> > it? :)
> > 
> > It's not just "an old, orphaned application with a non-official patch on
> > it." That's nonsense!
> > 
> > a. As I stated already, there do exist several patched versions of
> > alevt-dvb. For instance the one that Herman Pitton tested here in public
> > causes a closed demux device error on my machine. That means that it
> > does not run because xine-ui is already using the demux device.
> > And this phenomenon has got nothing to do with the kernel headers!
> > I've tried all possibilities (old kernel headers and actual ones) so I
> > know better than Hermann Pitton does!
> > 
> > And my version (and obviously the ones of Thomas Voegtle and Emil Meier
> > whom I helped with my tip to revert that patch) cause a kernel crash
> > with the actual kernel.
> > 
> > b. As I also stated already the other teletext application called mtt
> > does officially not exist except for Novell / OpenSuSe distros (at least
> > as far as I have seen and found out). And this one
> > is, as I also stated, not affected by the kernel patch. It's part of a
> > discontinued program suite called xawtv-4.0 pre with a very complex
> > infrastructure behind.
> > 
> > Please do not ask me why this one runs without noise - I do not know.
> > 
> > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is
> > available in almost all Gnu/Linux distros.
> > 
> > "Other applications with similar features weren't affected."
> > 
> > >From where do you know that the features are "similar"?
> > 
> > This is a 100 % phantasy product of your mind that has got nothing to do
> > with existing reality, man!
> > 
> > Just one example: alevt-dvb has got an excellent html export filter
> > which makes it possible to export teletext pages as graphical html
> > files.
> > I do not know any other teletext application offering that.
> > 
> > 
> > > We are too late in -rc cycle, so probably there's not enough time for
> > > writing, test, validate any new API in time for 2.6.33 and write some compat
> > > layer to emulate those two ioctls with a different implementation.
> > 
> > Who says that a new API or an overworked API must be ready for 2.6.33?
> > When do you think the correct starting point must be set?
> > When the merge window for 2.6.34 opens or when?
> > Absurd argument! Not valid at all!
> > 
> > 
> > > So, removing those two ioctls is not an option anymore.
> > 
> > Yes. Conclusion??? None!
> > 
> > So if everybody wants to close down this discussion with that output
> > then you must admit (if you want it or not) that you de facto bury
> > teletext usage in the mud for the majority of Gnu/Linux DVB users.
> > 
> > So the output is more than badly disappointing.
> > Bye bye Teletext. Nothing for future kernels, huh?
> 
> Yes, you say it. It definitely will go away and we do have not any
> influence on that! Did you not notice the very slow update rate these
> days?

a. NOTHING "will go away". This is empty rant, nothing else it is!
In US teletext is dead, yes. In Europe analogue television is close to
dead. Yes.
But I have found no information source that teletext will disappear in
general. At least not in Europe or Germany.
So if you keep that up then prove the assertion please.

What slow update rate please?
What the hell are you talking about, man?


> > Regards
> > 
> > CS
> > 
> > P. S.: If you continue like that you make people run away.
> > Instead you better should try to win people, shouldn't you?
> > 
> > Just see how many volunteers are here to help and then reflect
> > why that manpower is missing, Mauro!
> > Your gesture being expressed above does a lot, but it is definitely NOT
> > motivating to change that precarious situation.
> 
> Then maybe better tell what you tried already, instead leaving others
> behind doing the same in vain again?

Goddamn! I've investigated a lot, and I have written down everything I
did.
See, even if you are too lazy to read all that go blame yourself for
that lazyness, but not me, OK?


> Mauro always did try to keep backward compat as much as possible and
> others had to tell him better not to waste his time on it.
> 
> You hit the wrong guy again and he can't even test anything.


All I want him is to immediately and forever stop spreading nonsense and
demotivate people and offer us all that propagandist style that I and
others do not appreciate at all.

Unfortunately I am missing the American English equivalent for
"Differenziertheit". Is it "straightforwardness"?

This is what I am missing when you start to express yourself.

Your "test" of alevt-dvb-t may serve as an example:

Noone knows your card type, noone knows your reception area,
transponder, channel. All we know from you is a pid.

And that there are versions of alevt-dvb who are incapable for parallel
tasking due to a wrong DVB patch you simply missed as a matter of fact.
So what the hell did you get at all, man?

Very low discussion level, isn't it?

I'll leave it up to that - don't want no dumb flamings at all.

Cheers

CS

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[hermann pitton]

Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack:
> Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:
> > Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:
> > > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> > > > Andreas Oberritter wrote:
> > > > > Andy Walls wrote:
> > > > 
> > > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> > > > >>> software running on Dream Multimedia set top boxes.
> > > > >> Right, so reverting the patch is not an option.
> > > > >>
> > > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> > > > >> node probably a waste of time at this point.
> > > > > 
> > > > > I think so, too. But I guess it's always worth discussing alternatives.
> > > > 
> > > > If this discussion happened before 2.6.32 release, and provided that a different
> > > > implementation were agreed, things would be easier, as a different solution like
> > > > your proposal could be decided and used.
> > > 
> > > 
> > > You cannot expect people reacting immediately if something is wrong.
> > > There are and do exist enormous delays between publishing a new kernel
> > > and the decision to use it after appropriate system or distro update.
> > > So your expectation level is simply wrong.
> > > 
> > > 
> > > > Now, we have already a regression on a stable kernel, and solving it by
> > > > creating another regression is not something smart to do.
> > > 
> > > 
> > > Yes. Trivial!
> > > 
> > > 
> > > > >From what I understood, the regression appeared on an old, orphan
> > > > application with a non-official patch applied on it. Other applications with
> > > > similar features weren't affected. On the other hand, if the patch got reverted, 
> > > > we'll break a maintained application that is used on a great number of devices,
> > > > and whose features depend on the new ioctls.
> > > 
> > > 
> > > It's truly amazing how the filter system of your perception works, isn't
> > > it? :)
> > > 
> > > It's not just "an old, orphaned application with a non-official patch on
> > > it." That's nonsense!
> > > 
> > > a. As I stated already, there do exist several patched versions of
> > > alevt-dvb. For instance the one that Herman Pitton tested here in public
> > > causes a closed demux device error on my machine. That means that it
> > > does not run because xine-ui is already using the demux device.
> > > And this phenomenon has got nothing to do with the kernel headers!
> > > I've tried all possibilities (old kernel headers and actual ones) so I
> > > know better than Hermann Pitton does!
> > > 
> > > And my version (and obviously the ones of Thomas Voegtle and Emil Meier
> > > whom I helped with my tip to revert that patch) cause a kernel crash
> > > with the actual kernel.
> > > 
> > > b. As I also stated already the other teletext application called mtt
> > > does officially not exist except for Novell / OpenSuSe distros (at least
> > > as far as I have seen and found out). And this one
> > > is, as I also stated, not affected by the kernel patch. It's part of a
> > > discontinued program suite called xawtv-4.0 pre with a very complex
> > > infrastructure behind.
> > > 
> > > Please do not ask me why this one runs without noise - I do not know.
> > > 
> > > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is
> > > available in almost all Gnu/Linux distros.
> > > 
> > > "Other applications with similar features weren't affected."
> > > 
> > > >From where do you know that the features are "similar"?
> > > 
> > > This is a 100 % phantasy product of your mind that has got nothing to do
> > > with existing reality, man!
> > > 
> > > Just one example: alevt-dvb has got an excellent html export filter
> > > which makes it possible to export teletext pages as graphical html
> > > files.
> > > I do not know any other teletext application offering that.
> > > 
> > > 
> > > > We are too late in -rc cycle, so probably there's not enough time for
> > > > writing, test, validate any new API in time for 2.6.33 and write some compat
> > > > layer to emulate those two ioctls with a different implementation.
> > > 
> > > Who says that a new API or an overworked API must be ready for 2.6.33?
> > > When do you think the correct starting point must be set?
> > > When the merge window for 2.6.34 opens or when?
> > > Absurd argument! Not valid at all!
> > > 
> > > 
> > > > So, removing those two ioctls is not an option anymore.
> > > 
> > > Yes. Conclusion??? None!
> > > 
> > > So if everybody wants to close down this discussion with that output
> > > then you must admit (if you want it or not) that you de facto bury
> > > teletext usage in the mud for the majority of Gnu/Linux DVB users.
> > > 
> > > So the output is more than badly disappointing.
> > > Bye bye Teletext. Nothing for future kernels, huh?
> > 
> > Yes, you say it. It definitely will go away and we do have not any
> > influence on that! Did you not notice the very slow update rate these
> > days?
> 
> a. NOTHING "will go away". This is empty rant, nothing else it is!
> In US teletext is dead, yes. In Europe analogue television is close to
> dead. Yes.
> But I have found no information source that teletext will disappear in
> general. At least not in Europe or Germany.
> So if you keep that up then prove the assertion please.

In the UK too. And after world war II we always followed BBC.
Not that bad ...

http://pressetext.com/news/090720037/nutzung-von-teletext-hat-den-zenit-erreicht

> What slow update rate please?
> What the hell are you talking about, man?

Previously information available there was updated within minutes, now
in best case every six hours it seems to me.

> > > Regards
> > > 
> > > CS
> > > 
> > > P. S.: If you continue like that you make people run away.
> > > Instead you better should try to win people, shouldn't you?
> > > 
> > > Just see how many volunteers are here to help and then reflect
> > > why that manpower is missing, Mauro!
> > > Your gesture being expressed above does a lot, but it is definitely NOT
> > > motivating to change that precarious situation.
> > 
> > Then maybe better tell what you tried already, instead leaving others
> > behind doing the same in vain again?
> 
> Goddamn! I've investigated a lot, and I have written down everything I
> did.
> See, even if you are too lazy to read all that go blame yourself for
> that lazyness, but not me, OK?

My, I see a difficult to identify something of code around, not in any
major distribution. One can link to any headers wanted, and scripts seem
to be wrapped around too as liked ...

> > Mauro always did try to keep backward compat as much as possible and
> > others had to tell him better not to waste his time on it.
> > 
> > You hit the wrong guy again and he can't even test anything.
> 
> 
> All I want him is to immediately and forever stop spreading nonsense and
> demotivate people and offer us all that propagandist style that I and
> others do not appreciate at all.
> 
> Unfortunately I am missing the American English equivalent for
> "Differenziertheit". Is it "straightforwardness"?
> 
> This is what I am missing when you start to express yourself.
> 
> Your "test" of alevt-dvb-t may serve as an example:
> 
> Noone knows your card type, noone knows your reception area,
> transponder, channel. All we know from you is a pid.

You did report all that? The pid is from ZDF DVB-T from
Frankfurt/Main/Feldberg on a saa7134 Medion Quadro, should not matter at
all.

> And that there are versions of alevt-dvb who are incapable for parallel
> tasking due to a wrong DVB patch you simply missed as a matter of fact.
> So what the hell did you get at all, man?

They really do exist, or only the sripts around?

> Very low discussion level, isn't it?
> 
> I'll leave it up to that - don't want no dumb flamings at all.
> 
> Cheers
> 
> CS

Peace.

Hermann

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

[-- Attachment #1: Type: text/plain, Size: 10142 bytes --]

Am Samstag, den 06.02.2010, 01:25 +0100 schrieb hermann pitton:
> Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack:
> > Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:
> > > Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:
> > > > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> > > > > Andreas Oberritter wrote:
> > > > > > Andy Walls wrote:
> > > > > 
> > > > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> > > > > >>> software running on Dream Multimedia set top boxes.
> > > > > >> Right, so reverting the patch is not an option.
> > > > > >>
> > > > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> > > > > >> node probably a waste of time at this point.
> > > > > > 
> > > > > > I think so, too. But I guess it's always worth discussing alternatives.
> > > > > 
> > > > > If this discussion happened before 2.6.32 release, and provided that a different
> > > > > implementation were agreed, things would be easier, as a different solution like
> > > > > your proposal could be decided and used.
> > > > 
> > > > 
> > > > You cannot expect people reacting immediately if something is wrong.
> > > > There are and do exist enormous delays between publishing a new kernel
> > > > and the decision to use it after appropriate system or distro update.
> > > > So your expectation level is simply wrong.
> > > > 
> > > > 
> > > > > Now, we have already a regression on a stable kernel, and solving it by
> > > > > creating another regression is not something smart to do.
> > > > 
> > > > 
> > > > Yes. Trivial!
> > > > 
> > > > 
> > > > > >From what I understood, the regression appeared on an old, orphan
> > > > > application with a non-official patch applied on it. Other applications with
> > > > > similar features weren't affected. On the other hand, if the patch got reverted, 
> > > > > we'll break a maintained application that is used on a great number of devices,
> > > > > and whose features depend on the new ioctls.
> > > > 
> > > > 
> > > > It's truly amazing how the filter system of your perception works, isn't
> > > > it? :)
> > > > 
> > > > It's not just "an old, orphaned application with a non-official patch on
> > > > it." That's nonsense!
> > > > 
> > > > a. As I stated already, there do exist several patched versions of
> > > > alevt-dvb. For instance the one that Herman Pitton tested here in public
> > > > causes a closed demux device error on my machine. That means that it
> > > > does not run because xine-ui is already using the demux device.
> > > > And this phenomenon has got nothing to do with the kernel headers!
> > > > I've tried all possibilities (old kernel headers and actual ones) so I
> > > > know better than Hermann Pitton does!
> > > > 
> > > > And my version (and obviously the ones of Thomas Voegtle and Emil Meier
> > > > whom I helped with my tip to revert that patch) cause a kernel crash
> > > > with the actual kernel.
> > > > 
> > > > b. As I also stated already the other teletext application called mtt
> > > > does officially not exist except for Novell / OpenSuSe distros (at least
> > > > as far as I have seen and found out). And this one
> > > > is, as I also stated, not affected by the kernel patch. It's part of a
> > > > discontinued program suite called xawtv-4.0 pre with a very complex
> > > > infrastructure behind.
> > > > 
> > > > Please do not ask me why this one runs without noise - I do not know.
> > > > 
> > > > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is
> > > > available in almost all Gnu/Linux distros.
> > > > 
> > > > "Other applications with similar features weren't affected."
> > > > 
> > > > >From where do you know that the features are "similar"?
> > > > 
> > > > This is a 100 % phantasy product of your mind that has got nothing to do
> > > > with existing reality, man!
> > > > 
> > > > Just one example: alevt-dvb has got an excellent html export filter
> > > > which makes it possible to export teletext pages as graphical html
> > > > files.
> > > > I do not know any other teletext application offering that.
> > > > 
> > > > 
> > > > > We are too late in -rc cycle, so probably there's not enough time for
> > > > > writing, test, validate any new API in time for 2.6.33 and write some compat
> > > > > layer to emulate those two ioctls with a different implementation.
> > > > 
> > > > Who says that a new API or an overworked API must be ready for 2.6.33?
> > > > When do you think the correct starting point must be set?
> > > > When the merge window for 2.6.34 opens or when?
> > > > Absurd argument! Not valid at all!
> > > > 
> > > > 
> > > > > So, removing those two ioctls is not an option anymore.
> > > > 
> > > > Yes. Conclusion??? None!
> > > > 
> > > > So if everybody wants to close down this discussion with that output
> > > > then you must admit (if you want it or not) that you de facto bury
> > > > teletext usage in the mud for the majority of Gnu/Linux DVB users.
> > > > 
> > > > So the output is more than badly disappointing.
> > > > Bye bye Teletext. Nothing for future kernels, huh?
> > > 
> > > Yes, you say it. It definitely will go away and we do have not any
> > > influence on that! Did you not notice the very slow update rate these
> > > days?
> > 
> > a. NOTHING "will go away". This is empty rant, nothing else it is!
> > In US teletext is dead, yes. In Europe analogue television is close to
> > dead. Yes.
> > But I have found no information source that teletext will disappear in
> > general. At least not in Europe or Germany.
> > So if you keep that up then prove the assertion please.
> 
> In the UK too. And after world war II we always followed BBC.
> Not that bad ...
> 
> http://pressetext.com/news/090720037/nutzung-von-teletext-hat-den-zenit-erreicht
> 
> > What slow update rate please?
> > What the hell are you talking about, man?
> 
> Previously information available there was updated within minutes, now
> in best case every six hours it seems to me.
> 
> > > > Regards
> > > > 
> > > > CS
> > > > 
> > > > P. S.: If you continue like that you make people run away.
> > > > Instead you better should try to win people, shouldn't you?
> > > > 
> > > > Just see how many volunteers are here to help and then reflect
> > > > why that manpower is missing, Mauro!
> > > > Your gesture being expressed above does a lot, but it is definitely NOT
> > > > motivating to change that precarious situation.
> > > 
> > > Then maybe better tell what you tried already, instead leaving others
> > > behind doing the same in vain again?
> > 
> > Goddamn! I've investigated a lot, and I have written down everything I
> > did.
> > See, even if you are too lazy to read all that go blame yourself for
> > that lazyness, but not me, OK?
> 
> My, I see a difficult to identify something of code around, not in any
> major distribution. One can link to any headers wanted, and scripts seem
> to be wrapped around too as liked ...
> 
> > > Mauro always did try to keep backward compat as much as possible and
> > > others had to tell him better not to waste his time on it.
> > > 
> > > You hit the wrong guy again and he can't even test anything.
> > 
> > 
> > All I want him is to immediately and forever stop spreading nonsense and
> > demotivate people and offer us all that propagandist style that I and
> > others do not appreciate at all.
> > 
> > Unfortunately I am missing the American English equivalent for
> > "Differenziertheit". Is it "straightforwardness"?
> > 
> > This is what I am missing when you start to express yourself.
> > 
> > Your "test" of alevt-dvb-t may serve as an example:
> > 
> > Noone knows your card type, noone knows your reception area,
> > transponder, channel. All we know from you is a pid.
> 
> You did report all that? The pid is from ZDF DVB-T from
> Frankfurt/Main/Feldberg on a saa7134 Medion Quadro, should not matter at
> all.

I was stating 2 things for several times:

a. I am working with DVB-S equipment (Flexcop Rev. 2.8, sold as
Technisat Skystar).

b. It is not impossible to adjust the application (alevt-dvb) to the new
needs of the current demux device.

This important aspect was simply bypassed and ignored.
There is no need to bury its compatibility right into the mud.


Instead of that everybody talks about possible kernel alternatives, time
factors, incompatibilities etc. And then everybody concludes that it's
better not to change anything and buries the discussion.
And buries the teletext compatibility of future kernels without any
perspective.


I scratch my head reading all that!
How absurd! What the hell is going on in your minds?


> > And that there are versions of alevt-dvb who are incapable for parallel
> > tasking due to a wrong DVB patch you simply missed as a matter of fact.
> > So what the hell did you get at all, man?
> 
> They really do exist, or only the sripts around?


I'll attach an overworked version with all available patches that make
sense applied. This version is free from cruft and it is capable of
parallel tasking (i. e. DVB-S playback and recording plus teletext at
the same time without kernel complaints). The parallel tasking
capability has got NOTHING to do with any "scripts around".
It really sucks to put facts against written nonsense of you, Hermann,
and of MCC of course.
This is not the level of constructive elaborated discussion at all!


Some people sampled around here should _urgently_ reflect the ideals
they stand for when they perform kernel or application hacking here.

To produce kernel regressions without taking the responsibility for the
consequences is simply an intolerable behaviour.


I've always thought that Stallman hopelessly exaggerates when he is
beating his _marketing drum_ for his ideas - 
exaggeration as stylistic device.

But I have changed my mind - I think this guy is right. there is no
exaggeration at all.

And here is the link to read the context:

http://www.webmonkey.com/blog/Richard_Stallman_On_Novell__The_GPL_and_Linus_Torvalds

The _blind followers_ seem to grow instead of vanishing!

Cheers

CS


[-- Attachment #2: alevt-1.7.0.tar.bz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 80146 bytes --]

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[hermann pitton]

Am Samstag, den 06.02.2010, 09:55 +0100 schrieb Chicken Shack:
> Am Samstag, den 06.02.2010, 01:25 +0100 schrieb hermann pitton:
> > Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack:
> > > Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:
> > > > Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:
> > > > > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> > > > > > Andreas Oberritter wrote:
> > > > > > > Andy Walls wrote:
> > > > > > 
> > > > > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> > > > > > >>> software running on Dream Multimedia set top boxes.
> > > > > > >> Right, so reverting the patch is not an option.
> > > > > > >>
> > > > > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> > > > > > >> node probably a waste of time at this point.
> > > > > > > 
> > > > > > > I think so, too. But I guess it's always worth discussing alternatives.
> > > > > > 
> > > > > > If this discussion happened before 2.6.32 release, and provided that a different
> > > > > > implementation were agreed, things would be easier, as a different solution like
> > > > > > your proposal could be decided and used.
> > > > > 
> > > > > 
> > > > > You cannot expect people reacting immediately if something is wrong.
> > > > > There are and do exist enormous delays between publishing a new kernel
> > > > > and the decision to use it after appropriate system or distro update.
> > > > > So your expectation level is simply wrong.
> > > > > 
> > > > > 
> > > > > > Now, we have already a regression on a stable kernel, and solving it by
> > > > > > creating another regression is not something smart to do.
> > > > > 
> > > > > 
> > > > > Yes. Trivial!
> > > > > 
> > > > > 
> > > > > > >From what I understood, the regression appeared on an old, orphan
> > > > > > application with a non-official patch applied on it. Other applications with
> > > > > > similar features weren't affected. On the other hand, if the patch got reverted, 
> > > > > > we'll break a maintained application that is used on a great number of devices,
> > > > > > and whose features depend on the new ioctls.
> > > > > 
> > > > > 
> > > > > It's truly amazing how the filter system of your perception works, isn't
> > > > > it? :)
> > > > > 
> > > > > It's not just "an old, orphaned application with a non-official patch on
> > > > > it." That's nonsense!
> > > > > 
> > > > > a. As I stated already, there do exist several patched versions of
> > > > > alevt-dvb. For instance the one that Herman Pitton tested here in public
> > > > > causes a closed demux device error on my machine. That means that it
> > > > > does not run because xine-ui is already using the demux device.
> > > > > And this phenomenon has got nothing to do with the kernel headers!
> > > > > I've tried all possibilities (old kernel headers and actual ones) so I
> > > > > know better than Hermann Pitton does!
> > > > > 
> > > > > And my version (and obviously the ones of Thomas Voegtle and Emil Meier
> > > > > whom I helped with my tip to revert that patch) cause a kernel crash
> > > > > with the actual kernel.
> > > > > 
> > > > > b. As I also stated already the other teletext application called mtt
> > > > > does officially not exist except for Novell / OpenSuSe distros (at least
> > > > > as far as I have seen and found out). And this one
> > > > > is, as I also stated, not affected by the kernel patch. It's part of a
> > > > > discontinued program suite called xawtv-4.0 pre with a very complex
> > > > > infrastructure behind.
> > > > > 
> > > > > Please do not ask me why this one runs without noise - I do not know.
> > > > > 
> > > > > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is
> > > > > available in almost all Gnu/Linux distros.
> > > > > 
> > > > > "Other applications with similar features weren't affected."
> > > > > 
> > > > > >From where do you know that the features are "similar"?
> > > > > 
> > > > > This is a 100 % phantasy product of your mind that has got nothing to do
> > > > > with existing reality, man!
> > > > > 
> > > > > Just one example: alevt-dvb has got an excellent html export filter
> > > > > which makes it possible to export teletext pages as graphical html
> > > > > files.
> > > > > I do not know any other teletext application offering that.
> > > > > 
> > > > > 
> > > > > > We are too late in -rc cycle, so probably there's not enough time for
> > > > > > writing, test, validate any new API in time for 2.6.33 and write some compat
> > > > > > layer to emulate those two ioctls with a different implementation.
> > > > > 
> > > > > Who says that a new API or an overworked API must be ready for 2.6.33?
> > > > > When do you think the correct starting point must be set?
> > > > > When the merge window for 2.6.34 opens or when?
> > > > > Absurd argument! Not valid at all!
> > > > > 
> > > > > 
> > > > > > So, removing those two ioctls is not an option anymore.
> > > > > 
> > > > > Yes. Conclusion??? None!
> > > > > 
> > > > > So if everybody wants to close down this discussion with that output
> > > > > then you must admit (if you want it or not) that you de facto bury
> > > > > teletext usage in the mud for the majority of Gnu/Linux DVB users.
> > > > > 
> > > > > So the output is more than badly disappointing.
> > > > > Bye bye Teletext. Nothing for future kernels, huh?
> > > > 
> > > > Yes, you say it. It definitely will go away and we do have not any
> > > > influence on that! Did you not notice the very slow update rate these
> > > > days?
> > > 
> > > a. NOTHING "will go away". This is empty rant, nothing else it is!
> > > In US teletext is dead, yes. In Europe analogue television is close to
> > > dead. Yes.
> > > But I have found no information source that teletext will disappear in
> > > general. At least not in Europe or Germany.
> > > So if you keep that up then prove the assertion please.
> > 
> > In the UK too. And after world war II we always followed BBC.
> > Not that bad ...
> > 
> > http://pressetext.com/news/090720037/nutzung-von-teletext-hat-den-zenit-erreicht
> > 
> > > What slow update rate please?
> > > What the hell are you talking about, man?
> > 
> > Previously information available there was updated within minutes, now
> > in best case every six hours it seems to me.
> > 
> > > > > Regards
> > > > > 
> > > > > CS
> > > > > 
> > > > > P. S.: If you continue like that you make people run away.
> > > > > Instead you better should try to win people, shouldn't you?
> > > > > 
> > > > > Just see how many volunteers are here to help and then reflect
> > > > > why that manpower is missing, Mauro!
> > > > > Your gesture being expressed above does a lot, but it is definitely NOT
> > > > > motivating to change that precarious situation.
> > > > 
> > > > Then maybe better tell what you tried already, instead leaving others
> > > > behind doing the same in vain again?
> > > 
> > > Goddamn! I've investigated a lot, and I have written down everything I
> > > did.
> > > See, even if you are too lazy to read all that go blame yourself for
> > > that lazyness, but not me, OK?
> > 
> > My, I see a difficult to identify something of code around, not in any
> > major distribution. One can link to any headers wanted, and scripts seem
> > to be wrapped around too as liked ...
> > 
> > > > Mauro always did try to keep backward compat as much as possible and
> > > > others had to tell him better not to waste his time on it.
> > > > 
> > > > You hit the wrong guy again and he can't even test anything.
> > > 
> > > 
> > > All I want him is to immediately and forever stop spreading nonsense and
> > > demotivate people and offer us all that propagandist style that I and
> > > others do not appreciate at all.
> > > 
> > > Unfortunately I am missing the American English equivalent for
> > > "Differenziertheit". Is it "straightforwardness"?
> > > 
> > > This is what I am missing when you start to express yourself.
> > > 
> > > Your "test" of alevt-dvb-t may serve as an example:
> > > 
> > > Noone knows your card type, noone knows your reception area,
> > > transponder, channel. All we know from you is a pid.
> > 
> > You did report all that? The pid is from ZDF DVB-T from
> > Frankfurt/Main/Feldberg on a saa7134 Medion Quadro, should not matter at
> > all.
> 
> I was stating 2 things for several times:
> 
> a. I am working with DVB-S equipment (Flexcop Rev. 2.8, sold as
> Technisat Skystar).
> 
> b. It is not impossible to adjust the application (alevt-dvb) to the new
> needs of the current demux device.
> 
> This important aspect was simply bypassed and ignored.
> There is no need to bury its compatibility right into the mud.
> 
> 
> Instead of that everybody talks about possible kernel alternatives, time
> factors, incompatibilities etc. And then everybody concludes that it's
> better not to change anything and buries the discussion.
> And buries the teletext compatibility of future kernels without any
> perspective.
> 
> 
> I scratch my head reading all that!
> How absurd! What the hell is going on in your minds?
> 
> 
> > > And that there are versions of alevt-dvb who are incapable for parallel
> > > tasking due to a wrong DVB patch you simply missed as a matter of fact.
> > > So what the hell did you get at all, man?
> > 
> > They really do exist, or only the sripts around?
> 
> 
> I'll attach an overworked version with all available patches that make
> sense applied. This version is free from cruft and it is capable of
> parallel tasking (i. e. DVB-S playback and recording plus teletext at
> the same time without kernel complaints). The parallel tasking
> capability has got NOTHING to do with any "scripts around".
> It really sucks to put facts against written nonsense of you, Hermann,
> and of MCC of course.
> This is not the level of constructive elaborated discussion at all!
> 
> 
> Some people sampled around here should _urgently_ reflect the ideals
> they stand for when they perform kernel or application hacking here.
> 
> To produce kernel regressions without taking the responsibility for the
> consequences is simply an intolerable behaviour.
> 
> 
> I've always thought that Stallman hopelessly exaggerates when he is
> beating his _marketing drum_ for his ideas - 
> exaggeration as stylistic device.
> 
> But I have changed my mind - I think this guy is right. there is no
> exaggeration at all.
> 
> And here is the link to read the context:
> 
> http://www.webmonkey.com/blog/Richard_Stallman_On_Novell__The_GPL_and_Linus_Torvalds
> 
> The _blind followers_ seem to grow instead of vanishing!
> 
> Cheers
> 
> CS
> 

Hi,

I agree with much above, not all. 

1.
That previous version I tested on DVB-T, and DVB-S should not be
different here, did work on a unpatched recent F11 2.6.30, but _also_
with quite _latest_ v4l-dvb installed on a vanilla 2.6.30 something.

2.
Agreed also, one seems not to be able to escape from the hard oops by
exchanging headers on your latest version with current. Even with latest
v4l-dvb headers, which would/should come with any newer kernel in
question, it still happens. 

As long you set the -t teletext pid, your later revision 1.7.0 works for
all teletext available on the DVB-T transponder tuned in at once with
multiple instances of alevt against also latest headers.

3.
Also confirmed, your 1.7.0 version did work on a latest unpatched F11
2.6.30 without setting the teletext pid explicitly, providing the
information what else is around there, and next should allow switching
through all teletext stuff with the UI I guess.

Taking the oopses now, you are likely right, that we have a backward
compat regression here and should try to fix it.

I'm at least still available for reproducing oopses ;)

And, an app, which ever, should not to be able to get all down.

Cheers,
Hermann

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

Am Sonntag, den 07.02.2010, 04:58 +0100 schrieb hermann pitton:
> Am Samstag, den 06.02.2010, 09:55 +0100 schrieb Chicken Shack:
> > Am Samstag, den 06.02.2010, 01:25 +0100 schrieb hermann pitton:
> > > Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack:
> > > > Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton:
> > > > > Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack:
> > > > > > Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> > > > > > > Andreas Oberritter wrote:
> > > > > > > > Andy Walls wrote:
> > > > > > > 
> > > > > > > >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> > > > > > > >>> software running on Dream Multimedia set top boxes.
> > > > > > > >> Right, so reverting the patch is not an option.
> > > > > > > >>
> > > > > > > >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> > > > > > > >> node probably a waste of time at this point.
> > > > > > > > 
> > > > > > > > I think so, too. But I guess it's always worth discussing alternatives.
> > > > > > > 
> > > > > > > If this discussion happened before 2.6.32 release, and provided that a different
> > > > > > > implementation were agreed, things would be easier, as a different solution like
> > > > > > > your proposal could be decided and used.
> > > > > > 
> > > > > > 
> > > > > > You cannot expect people reacting immediately if something is wrong.
> > > > > > There are and do exist enormous delays between publishing a new kernel
> > > > > > and the decision to use it after appropriate system or distro update.
> > > > > > So your expectation level is simply wrong.
> > > > > > 
> > > > > > 
> > > > > > > Now, we have already a regression on a stable kernel, and solving it by
> > > > > > > creating another regression is not something smart to do.
> > > > > > 
> > > > > > 
> > > > > > Yes. Trivial!
> > > > > > 
> > > > > > 
> > > > > > > >From what I understood, the regression appeared on an old, orphan
> > > > > > > application with a non-official patch applied on it. Other applications with
> > > > > > > similar features weren't affected. On the other hand, if the patch got reverted, 
> > > > > > > we'll break a maintained application that is used on a great number of devices,
> > > > > > > and whose features depend on the new ioctls.
> > > > > > 
> > > > > > 
> > > > > > It's truly amazing how the filter system of your perception works, isn't
> > > > > > it? :)
> > > > > > 
> > > > > > It's not just "an old, orphaned application with a non-official patch on
> > > > > > it." That's nonsense!
> > > > > > 
> > > > > > a. As I stated already, there do exist several patched versions of
> > > > > > alevt-dvb. For instance the one that Herman Pitton tested here in public
> > > > > > causes a closed demux device error on my machine. That means that it
> > > > > > does not run because xine-ui is already using the demux device.
> > > > > > And this phenomenon has got nothing to do with the kernel headers!
> > > > > > I've tried all possibilities (old kernel headers and actual ones) so I
> > > > > > know better than Hermann Pitton does!
> > > > > > 
> > > > > > And my version (and obviously the ones of Thomas Voegtle and Emil Meier
> > > > > > whom I helped with my tip to revert that patch) cause a kernel crash
> > > > > > with the actual kernel.
> > > > > > 
> > > > > > b. As I also stated already the other teletext application called mtt
> > > > > > does officially not exist except for Novell / OpenSuSe distros (at least
> > > > > > as far as I have seen and found out). And this one
> > > > > > is, as I also stated, not affected by the kernel patch. It's part of a
> > > > > > discontinued program suite called xawtv-4.0 pre with a very complex
> > > > > > infrastructure behind.
> > > > > > 
> > > > > > Please do not ask me why this one runs without noise - I do not know.
> > > > > > 
> > > > > > So AFAICS alevt-dvb is the ONLY teletext application for Linux which is
> > > > > > available in almost all Gnu/Linux distros.
> > > > > > 
> > > > > > "Other applications with similar features weren't affected."
> > > > > > 
> > > > > > >From where do you know that the features are "similar"?
> > > > > > 
> > > > > > This is a 100 % phantasy product of your mind that has got nothing to do
> > > > > > with existing reality, man!
> > > > > > 
> > > > > > Just one example: alevt-dvb has got an excellent html export filter
> > > > > > which makes it possible to export teletext pages as graphical html
> > > > > > files.
> > > > > > I do not know any other teletext application offering that.
> > > > > > 
> > > > > > 
> > > > > > > We are too late in -rc cycle, so probably there's not enough time for
> > > > > > > writing, test, validate any new API in time for 2.6.33 and write some compat
> > > > > > > layer to emulate those two ioctls with a different implementation.
> > > > > > 
> > > > > > Who says that a new API or an overworked API must be ready for 2.6.33?
> > > > > > When do you think the correct starting point must be set?
> > > > > > When the merge window for 2.6.34 opens or when?
> > > > > > Absurd argument! Not valid at all!
> > > > > > 
> > > > > > 
> > > > > > > So, removing those two ioctls is not an option anymore.
> > > > > > 
> > > > > > Yes. Conclusion??? None!
> > > > > > 
> > > > > > So if everybody wants to close down this discussion with that output
> > > > > > then you must admit (if you want it or not) that you de facto bury
> > > > > > teletext usage in the mud for the majority of Gnu/Linux DVB users.
> > > > > > 
> > > > > > So the output is more than badly disappointing.
> > > > > > Bye bye Teletext. Nothing for future kernels, huh?
> > > > > 
> > > > > Yes, you say it. It definitely will go away and we do have not any
> > > > > influence on that! Did you not notice the very slow update rate these
> > > > > days?
> > > > 
> > > > a. NOTHING "will go away". This is empty rant, nothing else it is!
> > > > In US teletext is dead, yes. In Europe analogue television is close to
> > > > dead. Yes.
> > > > But I have found no information source that teletext will disappear in
> > > > general. At least not in Europe or Germany.
> > > > So if you keep that up then prove the assertion please.
> > > 
> > > In the UK too. And after world war II we always followed BBC.
> > > Not that bad ...
> > > 
> > > http://pressetext.com/news/090720037/nutzung-von-teletext-hat-den-zenit-erreicht
> > > 
> > > > What slow update rate please?
> > > > What the hell are you talking about, man?
> > > 
> > > Previously information available there was updated within minutes, now
> > > in best case every six hours it seems to me.
> > > 
> > > > > > Regards
> > > > > > 
> > > > > > CS
> > > > > > 
> > > > > > P. S.: If you continue like that you make people run away.
> > > > > > Instead you better should try to win people, shouldn't you?
> > > > > > 
> > > > > > Just see how many volunteers are here to help and then reflect
> > > > > > why that manpower is missing, Mauro!
> > > > > > Your gesture being expressed above does a lot, but it is definitely NOT
> > > > > > motivating to change that precarious situation.
> > > > > 
> > > > > Then maybe better tell what you tried already, instead leaving others
> > > > > behind doing the same in vain again?
> > > > 
> > > > Goddamn! I've investigated a lot, and I have written down everything I
> > > > did.
> > > > See, even if you are too lazy to read all that go blame yourself for
> > > > that lazyness, but not me, OK?
> > > 
> > > My, I see a difficult to identify something of code around, not in any
> > > major distribution. One can link to any headers wanted, and scripts seem
> > > to be wrapped around too as liked ...
> > > 
> > > > > Mauro always did try to keep backward compat as much as possible and
> > > > > others had to tell him better not to waste his time on it.
> > > > > 
> > > > > You hit the wrong guy again and he can't even test anything.
> > > > 
> > > > 
> > > > All I want him is to immediately and forever stop spreading nonsense and
> > > > demotivate people and offer us all that propagandist style that I and
> > > > others do not appreciate at all.
> > > > 
> > > > Unfortunately I am missing the American English equivalent for
> > > > "Differenziertheit". Is it "straightforwardness"?
> > > > 
> > > > This is what I am missing when you start to express yourself.
> > > > 
> > > > Your "test" of alevt-dvb-t may serve as an example:
> > > > 
> > > > Noone knows your card type, noone knows your reception area,
> > > > transponder, channel. All we know from you is a pid.
> > > 
> > > You did report all that? The pid is from ZDF DVB-T from
> > > Frankfurt/Main/Feldberg on a saa7134 Medion Quadro, should not matter at
> > > all.
> > 
> > I was stating 2 things for several times:
> > 
> > a. I am working with DVB-S equipment (Flexcop Rev. 2.8, sold as
> > Technisat Skystar).
> > 
> > b. It is not impossible to adjust the application (alevt-dvb) to the new
> > needs of the current demux device.
> > 
> > This important aspect was simply bypassed and ignored.
> > There is no need to bury its compatibility right into the mud.
> > 
> > 
> > Instead of that everybody talks about possible kernel alternatives, time
> > factors, incompatibilities etc. And then everybody concludes that it's
> > better not to change anything and buries the discussion.
> > And buries the teletext compatibility of future kernels without any
> > perspective.
> > 
> > 
> > I scratch my head reading all that!
> > How absurd! What the hell is going on in your minds?
> > 
> > 
> > > > And that there are versions of alevt-dvb who are incapable for parallel
> > > > tasking due to a wrong DVB patch you simply missed as a matter of fact.
> > > > So what the hell did you get at all, man?
> > > 
> > > They really do exist, or only the sripts around?
> > 
> > 
> > I'll attach an overworked version with all available patches that make
> > sense applied. This version is free from cruft and it is capable of
> > parallel tasking (i. e. DVB-S playback and recording plus teletext at
> > the same time without kernel complaints). The parallel tasking
> > capability has got NOTHING to do with any "scripts around".
> > It really sucks to put facts against written nonsense of you, Hermann,
> > and of MCC of course.
> > This is not the level of constructive elaborated discussion at all!
> > 
> > 
> > Some people sampled around here should _urgently_ reflect the ideals
> > they stand for when they perform kernel or application hacking here.
> > 
> > To produce kernel regressions without taking the responsibility for the
> > consequences is simply an intolerable behaviour.
> > 
> > 
> > I've always thought that Stallman hopelessly exaggerates when he is
> > beating his _marketing drum_ for his ideas - 
> > exaggeration as stylistic device.
> > 
> > But I have changed my mind - I think this guy is right. there is no
> > exaggeration at all.
> > 
> > And here is the link to read the context:
> > 
> > http://www.webmonkey.com/blog/Richard_Stallman_On_Novell__The_GPL_and_Linus_Torvalds
> > 
> > The _blind followers_ seem to grow instead of vanishing!
> > 
> > Cheers
> > 
> > CS
> > 
> 
> Hi,
> 
> I agree with much above, not all. 
> 
> 1.
> That previous version I tested on DVB-T, and DVB-S should not be
> different here, did work on a unpatched recent F11 2.6.30, but _also_
> with quite _latest_ v4l-dvb installed on a vanilla 2.6.30 something.
> 
> 2.
> Agreed also, one seems not to be able to escape from the hard oops by
> exchanging headers on your latest version with current. Even with latest
> v4l-dvb headers, which would/should come with any newer kernel in
> question, it still happens. 
> 
> As long you set the -t teletext pid, your later revision 1.7.0 works for
> all teletext available on the DVB-T transponder tuned in at once with
> multiple instances of alevt against also latest headers.
> 
> 3.
> Also confirmed, your 1.7.0 version did work on a latest unpatched F11
> 2.6.30 without setting the teletext pid explicitly, providing the
> information what else is around there, and next should allow switching
> through all teletext stuff with the UI I guess.
> 
> Taking the oopses now, you are likely right, that we have a backward
> compat regression here and should try to fix it.
> 
> I'm at least still available for reproducing oopses ;)
> 
> And, an app, which ever, should not to be able to get all down.
> 
> Cheers,
> Hermann

Hello all,

let me give you all some last rendering more precisely statements to
sharpen your minds:

1. alevt-dvb and kernel version: To get out all application features of
my last version 1.7.0 without crash there is no need to go back to
2.6.30 final:
Although being a buggy stinker and thus not part of all distros 2.6.31
final is the last official kernel with which everything is fine.

2. Although setting the -t teletext pid is the way to go without kernel
crash, you need to know the couples of teletext pids of the channels
being sampled in one transponder if you want to run multiple instances
of the same program in parallel mode.

As this is normally NOT the case, helper scripts exist who carry the
information of the outfile function (switch -o) into a graphical window
where you can start multiple windows by mouseclick.

This outfile option (-o) does NOT work as long as you are forced to give
the program the long device string (i. e. -vbi /dev/dvb/adapter0/demux0)
plus a teletext pid (f. ex. -t 230 for 3sat).
Don't ask me why this does not work - I do not know!

So in practice, running the application under a current kernel, you are
reduced to the following:

a. mandatory starting the application with the long string plus ttpid:
-vbi /dev/dvb/adapter0/demux0 -pid 230
b. no chance to start it without parameter, or by sid or by channel name
c. one teletext window per one running channel, as the program itself
does not provide you a graphical menu to allow you switching several
channels within the currently switched transponder.

This reduction WAS NOT intended.
And a kernel which can be smashed down to a point (in extreme cases,
nota bene) where nothing goes without the _violent_ hard reset button,
is not a kernel. It is a security risk instead.

3. The "discussion" that happened here shows very precisely in how far
this public list conforms to a little village carrying the unofficial
name "Absurdistan".
Yeah, it's really weird and crazy, if not to say completely insane.

It all starts up with a chief maintainer talking and writing a kind of
English which is almost unreadable and highly disgusting sometimes.
Although this chief maintainer has been doing his job for years now,
he still doesn't know what his tasks are.
Instead of trying to win qualified people and / or testers and users he
very often acts as if there would be thousands of volunteers around
stamping down each other in order to receive a chance for doing unpaid
qualified work here.
His utterances very often remind me of "Apparatschniks", who are a
certain kind of people that you very often find in petty bourgeois
politics.

For primitive structured people howling with the wolves counts more than
essence and sophistication of the contribution.


The fact that alevt-dvb crashes the current kernel is definitely a
backward compatibility issue. On the one hand.
On the other hand it is not.

It is a matter on how you define the issue. I stated that several times
- in vain!
To reduce the issue to 50 % of its real essence due to missing
application hacking skills is an insane behaviour.
It's like a row of doctors each giving perfect sounding diagnosis but
noone touching the issue and starting the therapy instead.
The white dressed people endlessly rant while the patient dies...


Here is the path to resolve the alevt-dvb issue without changing the
kernel at all:

As I stated already there is a teletext application written by Gerd
Knorr in about 2004. That was Gerd's SuSE-Novell-Phase, when he was MCCs
precedent here, v4l maintainer.

This product called mtt is worth to be examined a bit.

When you start it with -d 10 (debug) it first automatically probes all
available dvb devices to see where the card is.
Its ioctls do not imply the two new calls introduced by Andreas
Oberritters patch (how could it -> anachronism?), but I have seen stuff
like "STRUCT LIST HEAD" etc.
Having found the card it is added to the correct device and demux.
Alevt's way of performing the same task is much more primitive.
And thus buggy or, like in our specific case, susceptible to the latest
kernel changes.

To avoid hanging processes a kind of monitoring daemon is working in the
background: It's taking care of the program map table (I wrote "program
management table" in one of my previous postings and that's crap,
sorry!). It somehow (correct me if I am wrong!) makes the demux release
dependent from the current contents of the PMT.
So you can switch the channel AND change the transponder (ex.: ARD ->
ZDF) with an external application, and alevt-dvb will follow the new
transponder by reading and "advertising" the new PMT to the other
components instead of causing a hanging process not knowing how to deal
with the new PMT.


The solution of the problem, without the slightest kernel change, is:

Pump up alevt-dvb with the necessary daemons, system calls and functions
found in mtt.
The question is: Which are necessary, which are redundant?

To accomplish that I need an experienced application programmer coaching
me. I definitely cannot do that on my own. The simpler tasks to do I
already did in my version 1.7.0. But this one is not that trivial.
Without qualified coaching I am lost.

If V4L/DVB weren't a scarcities management (which it will always be as
long as MCC is maintainer here), if it were a melting pot of real
sputtering people instead, it would not be the slightest problem to
ressolve the issue.

But instead there are people here who claim to be short in time on the
one hand but are performing completely effectless "discussions" here.

And that's insane, isn't it?
And the other insane gesture is blindly pushing through kernel
changesets without caring for the consequences at all.

Close your eyes - Signed-off-by - push it through - bunk!
It's the ellbow egoism behind the gesture which is insane here.


RGDS

CS

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Andy Walls]

On Sun, 2010-02-07 at 04:58 +0100, hermann pitton wrote:
> Am Samstag, den 06.02.2010, 09:55 +0100 schrieb Chicken Shack:
> > Am Samstag, den 06.02.2010, 01:25 +0100 schrieb hermann pitton:

> 3.
> Also confirmed, your 1.7.0 version did work on a latest unpatched F11
> 2.6.30 without setting the teletext pid explicitly, providing the
> information what else is around there, and next should allow switching
> through all teletext stuff with the UI I guess.
> 
> Taking the oopses now, you are likely right, that we have a backward
> compat regression here and should try to fix it.


I'm looking at this still, just not quickly.

The over-abundance of the use of the words "demux", "dmx", "dvb",
"feed", "ts", and "sec" in the dvb-core make code analysis difficult.
I'm putting the dvb-core data structures into a UML tool, so I can get
some decent class and collaboration diagrams to have a good picture of
the relationships.

I can say that the easiest fix will most likely be that in dmxdev.h:

struct dmxdev_filter {
	...
        union {
                /* list of TS and PES feeds (struct dmxdev_feed) */
                struct list_head ts;
                struct dmx_section_feed *sec;
        } feed;
	....

"feed" should no longer be a union, or that "feed.sec" should be
converted to a list as well.

It appears under certain circumstances "feed.sec" is being set to NULL,
which corrupts the "feed.ts" list head.   The "feed.ts" list head is
being properly intiialized in dvb_demux_open(), so that's not the
problem.


Regards,
Andy



> I'm at least still available for reproducing oopses ;)
> 
> And, an app, which ever, should not to be able to get all down.
> 
> Cheers,
> Hermann

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

[-- Attachment #1: Type: text/plain, Size: 3645 bytes --]

Am Sonntag, den 07.02.2010, 09:43 -0500 schrieb Andy Walls:
> On Sun, 2010-02-07 at 04:58 +0100, hermann pitton wrote:
> > Am Samstag, den 06.02.2010, 09:55 +0100 schrieb Chicken Shack:
> > > Am Samstag, den 06.02.2010, 01:25 +0100 schrieb hermann pitton:
> 
> > 3.
> > Also confirmed, your 1.7.0 version did work on a latest unpatched F11
> > 2.6.30 without setting the teletext pid explicitly, providing the
> > information what else is around there, and next should allow switching
> > through all teletext stuff with the UI I guess.
> > 
> > Taking the oopses now, you are likely right, that we have a backward
> > compat regression here and should try to fix it.
> 
> 
> I'm looking at this still, just not quickly.
> 
> The over-abundance of the use of the words "demux", "dmx", "dvb",
> "feed", "ts", and "sec" in the dvb-core make code analysis difficult.
> I'm putting the dvb-core data structures into a UML tool, so I can get
> some decent class and collaboration diagrams to have a good picture of
> the relationships.
> 
> I can say that the easiest fix will most likely be that in dmxdev.h:
> 
> struct dmxdev_filter {
> 	...
>         union {
>                 /* list of TS and PES feeds (struct dmxdev_feed) */
>                 struct list_head ts;
>                 struct dmx_section_feed *sec;
>         } feed;
> 	....
> 
> "feed" should no longer be a union, or that "feed.sec" should be
> converted to a list as well.
> 
> It appears under certain circumstances "feed.sec" is being set to NULL,
> which corrupts the "feed.ts" list head.   The "feed.ts" list head is
> being properly intiialized in dvb_demux_open(), so that's not the
> problem.
> 
> 
> Regards,
> Andy
> 
> 
> 
> > I'm at least still available for reproducing oopses ;)
> > 
> > And, an app, which ever, should not to be able to get all down.
> > 
> > Cheers,
> > Hermann

Hi everybody,

Although quite effectless in the end I do not want to forget about
politeness and thank you for your investigation - especially Andy for
sure.

An outsider that I found by a google research, an Italian called
Francesco Lavra already resolved the kernel crash issue by a simple
one-liner that you can find easily on this today's list.

So please stop your investigation as the problem is solved already.
Alevt works without kernel crash - fantastic!
So do everything please to make this one-liner part of 2.6.33 main line
final.


However I am still alone with the other problem I always stressed:

When using alevt-dvb (I attached my overworked version 1.7.0 in earlier
mails - please do have a look at it!) the application hangs when you
decide to switch to a channel that is part of a new transponder.
The program hangs then. That means the way alevt-dvb is dealing with the
PMT (program map table) is highly incomplete.
It needs a reset function to read the new PMT when the transponder is
being changed...

I do not know how to program that simple reset function. But I know that
thsi is the definite key to resolve the issue.
PMT reading, PMT opening, PMT parsing.......
Everything is already inside of the source code of alevt-dvb.

But as soon as the transponder is being changed the program is quite
helpless - it simply does not know what to do and hangs......

This behaviour is not being shown when alevt-dvb shows teletext
addressing analogue cards (which seems to be technically something
completely different). Only the DVB part of the program behaves buggy in
that context.


And this goes to Francesco Lavra:

God bless you, Francesco!
You got it!
With a simple one-liner!
I'm breathless!

Mille grazie per questa contribuzione, Francesco! :) :) :)


[-- Attachment #2: alevt-1.7.0.tar.bz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 85333 bytes --]

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[HoP]

Hi Chicken,

>
> However I am still alone with the other problem I always stressed:
>
> When using alevt-dvb (I attached my overworked version 1.7.0 in earlier
> mails - please do have a look at it!) the application hangs when you
> decide to switch to a channel that is part of a new transponder.
> The program hangs then. That means the way alevt-dvb is dealing with the
> PMT (program map table) is highly incomplete.
> It needs a reset function to read the new PMT when the transponder is
> being changed...
>

If you tell me which application is managing channel zaping function
then we can try to find way how to signal that to alevt-dvb.

> I do not know how to program that simple reset function. But I know that
> thsi is the definite key to resolve the issue.
> PMT reading, PMT opening, PMT parsing.......
> Everything is already inside of the source code of alevt-dvb.
>

In case, if more then one DVB application is running, one is something
like "master" (which do frontend operation, ie. channel change)
and rest are slaves. So master has to signal channel/transponder change
to the all slaves. Typically, it is done by some custom specific way.
For example master can open some well-known unix socket
where all slaves are connecting and where, in case of channel change,
is sent (by master) some info about such event.

Cheers

/Honza

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

Am Sonntag, den 07.02.2010, 19:10 +0100 schrieb HoP:
> Hi Chicken,
> 
> >
> > However I am still alone with the other problem I always stressed:
> >
> > When using alevt-dvb (I attached my overworked version 1.7.0 in earlier
> > mails - please do have a look at it!) the application hangs when you
> > decide to switch to a channel that is part of a new transponder.
> > The program hangs then. That means the way alevt-dvb is dealing with the
> > PMT (program map table) is highly incomplete.
> > It needs a reset function to read the new PMT when the transponder is
> > being changed...
> >
> 
> If you tell me which application is managing channel zaping function
> then we can try to find way how to signal that to alevt-dvb.

Hi Hello Honza,

well, every application being capable of playing back DVB-TV with
in-built receiver engine could manage that.

Just the examples that I know:

1. mplayer (receiver engine is good old dvbstream from D. Chapman)
2. xine-ui (receiver engine is libxine)
3. kaffeine (dito 2.)
4. mythtv (don't know which)
5. xawtv (proprietary receiver engine)


> > I do not know how to program that simple reset function. But I know that
> > this is the definite key to resolve the issue.
> > PMT reading, PMT opening, PMT parsing.......
> > Everything is already inside of the source code of alevt-dvb.
> >
> 
> In case, if more then one DVB application is running, one is something
> like "master" (which do frontend operation, ie. channel change)
> and rest are slaves. So master has to signal channel/transponder change
> to the all slaves. Typically, it is done by some custom specific way.
> For example master can open some well-known unix socket
> where all slaves are connecting and where, in case of channel change,
> is sent (by master) some info about such event.

Yes, exactly that's the way it is! Right!

But however the "master" application is doing this tuning job, it's not
our problem issue right here.
Our problem issue right here is how to make the "slave" application
comprehend what the "master" application just managed to do.

When I was doing the code cleanup of the complete Flexcop driver series
Patrick Boettcher taught me what a software watchdog is and how it
works. The Conexant frontend / demodulator chip does not work together
with the Flexcop main chip without a software watchdog performing
reinitialization every 400 milliseconds. That came into my mind a couple
of minutes ago.

So how about giving alevt-dvb a software watchdog function that just
looks up lets say every 2 seconds whether the PMT has changed or not,
performing a reinitialisation of the PMT treatment built inside, i. e.
doing something like a restart of alevt-dvb?

Would that be a pratical solution?
Or what would be your personal proposal, Honza?

Cheers

CS

P. S.: The decisive case the program must learn to deal with is NOT a
simple channel change, as you express it above, Honza.
The proggy can already run multiple instances in parallel console
sessions if the transponder is one and the same......

The decisive case the program must learn to deal with is a combination
of channel change PLUS transponder change, which makes it necessary to
read, work over and parse a complete new PMT (program map table) causing
the UI to at least starting the main program of the new transponder
(which is ZDF f. ex. if the transponder is ZDFVision.
Everything clear so far? Questions?

> Cheers
> 
> /Honza

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[HoP]

Hi Chicken

2010/2/7 Chicken Shack <chicken.shack@gmx.de>:
> Am Sonntag, den 07.02.2010, 19:10 +0100 schrieb HoP:
>> Hi Chicken,
>>
>> >
>> > However I am still alone with the other problem I always stressed:
>> >
>> > When using alevt-dvb (I attached my overworked version 1.7.0 in earlier
>> > mails - please do have a look at it!) the application hangs when you
>> > decide to switch to a channel that is part of a new transponder.
>> > The program hangs then. That means the way alevt-dvb is dealing with the
>> > PMT (program map table) is highly incomplete.
>> > It needs a reset function to read the new PMT when the transponder is
>> > being changed...
>> >
>>
>> If you tell me which application is managing channel zaping function
>> then we can try to find way how to signal that to alevt-dvb.
>
> Hi Hello Honza,
>
> well, every application being capable of playing back DVB-TV with
> in-built receiver engine could manage that.
>
> Just the examples that I know:
>
> 1. mplayer (receiver engine is good old dvbstream from D. Chapman)
> 2. xine-ui (receiver engine is libxine)
> 3. kaffeine (dito 2.)
> 4. mythtv (don't know which)
> 5. xawtv (proprietary receiver engine)
>
>

Oki, seems you not understood me fully. I ment exactly your configuration.
I need to know:

1, which application is tuning to transponder in your case.
2, is there only one alevt-dvb instance running? Typically, there is the only
one, but, of course I can imagine you do some postprocessing of ALL
teletext services on current transponder.

>> > I do not know how to program that simple reset function. But I know that
>> > this is the definite key to resolve the issue.
>> > PMT reading, PMT opening, PMT parsing.......
>> > Everything is already inside of the source code of alevt-dvb.
>> >
>>
>> In case, if more then one DVB application is running, one is something
>> like "master" (which do frontend operation, ie. channel change)
>> and rest are slaves. So master has to signal channel/transponder change
>> to the all slaves. Typically, it is done by some custom specific way.
>> For example master can open some well-known unix socket
>> where all slaves are connecting and where, in case of channel change,
>> is sent (by master) some info about such event.
>
> Yes, exactly that's the way it is! Right!
>
> But however the "master" application is doing this tuning job, it's not
> our problem issue right here.
> Our problem issue right here is how to make the "slave" application
> comprehend what the "master" application just managed to do.
>
> When I was doing the code cleanup of the complete Flexcop driver series
> Patrick Boettcher taught me what a software watchdog is and how it
> works. The Conexant frontend / demodulator chip does not work together
> with the Flexcop main chip without a software watchdog performing
> reinitialization every 400 milliseconds. That came into my mind a couple
> of minutes ago.
>

Well, we should stay outside kernel layer. Best solution should be
to manage signalling (of transponder change and futher information)
inside userland level. And this is why I was asking who is the master
(who is doing channel change)

> So how about giving alevt-dvb a software watchdog function that just
> looks up lets say every 2 seconds whether the PMT has changed or not,
> performing a reinitialisation of the PMT treatment built inside, i. e.
> doing something like a restart of alevt-dvb?
>

To find how to catch that "PMT has changed" we have to know
who is doing such PMT change operation.

> Would that be a pratical solution?
> Or what would be your personal proposal, Honza?
>
> Cheers
>
> CS
>
> P. S.: The decisive case the program must learn to deal with is NOT a
> simple channel change, as you express it above, Honza.
> The proggy can already run multiple instances in parallel console
> sessions if the transponder is one and the same......
>
> The decisive case the program must learn to deal with is a combination
> of channel change PLUS transponder change, which makes it necessary to
> read, work over and parse a complete new PMT (program map table) causing
> the UI to at least starting the main program of the new transponder
> (which is ZDF f. ex. if the transponder is ZDFVision.
> Everything clear so far? Questions?
>

Still the only one question - how it works for you now? How do you
zap to channel right now? I expect you have some favourite application.

Cheers

/Honza

Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack]

Am Sonntag, den 07.02.2010, 20:13 +0100 schrieb HoP:
> Hi Chicken
> 
> 2010/2/7 Chicken Shack <chicken.shack@gmx.de>:
> > Am Sonntag, den 07.02.2010, 19:10 +0100 schrieb HoP:
> >> Hi Chicken,
> >>
> >> >
> >> > However I am still alone with the other problem I always stressed:
> >> >
> >> > When using alevt-dvb (I attached my overworked version 1.7.0 in earlier
> >> > mails - please do have a look at it!) the application hangs when you
> >> > decide to switch to a channel that is part of a new transponder.
> >> > The program hangs then. That means the way alevt-dvb is dealing with the
> >> > PMT (program map table) is highly incomplete.
> >> > It needs a reset function to read the new PMT when the transponder is
> >> > being changed...
> >> >
> >>
> >> If you tell me which application is managing channel zaping function
> >> then we can try to find way how to signal that to alevt-dvb.
> >
> > Hi Hello Honza,
> >
> > well, every application being capable of playing back DVB-TV with
> > in-built receiver engine could manage that.
> >
> > Just the examples that I know:
> >
> > 1. mplayer (receiver engine is good old dvbstream from D. Chapman)
> > 2. xine-ui (receiver engine is libxine)
> > 3. kaffeine (dito 2.)
> > 4. mythtv (don't know which)
> > 5. xawtv (proprietary receiver engine)
> >
> >
> 
> Oki, seems you not understood me fully. I ment exactly your configuration.
> I need to know:
> 
> 1, which application is tuning to transponder in your case.
> 2, is there only one alevt-dvb instance running? Typically, there is the only
> one, but, of course I can imagine you do some postprocessing of ALL
> teletext services on current transponder.
> 
> >> > I do not know how to program that simple reset function. But I know that
> >> > this is the definite key to resolve the issue.
> >> > PMT reading, PMT opening, PMT parsing.......
> >> > Everything is already inside of the source code of alevt-dvb.
> >> >
> >>
> >> In case, if more then one DVB application is running, one is something
> >> like "master" (which do frontend operation, ie. channel change)
> >> and rest are slaves. So master has to signal channel/transponder change
> >> to the all slaves. Typically, it is done by some custom specific way.
> >> For example master can open some well-known unix socket
> >> where all slaves are connecting and where, in case of channel change,
> >> is sent (by master) some info about such event.
> >
> > Yes, exactly that's the way it is! Right!
> >
> > But however the "master" application is doing this tuning job, it's not
> > our problem issue right here.
> > Our problem issue right here is how to make the "slave" application
> > comprehend what the "master" application just managed to do.
> >
> > When I was doing the code cleanup of the complete Flexcop driver series
> > Patrick Boettcher taught me what a software watchdog is and how it
> > works. The Conexant frontend / demodulator chip does not work together
> > with the Flexcop main chip without a software watchdog performing
> > reinitialization every 400 milliseconds. That came into my mind a couple
> > of minutes ago.
> >
> 
> Well, we should stay outside kernel layer. Best solution should be
> to manage signalling (of transponder change and futher information)
> inside userland level. And this is why I was asking who is the master
> (who is doing channel change)
> 
> > So how about giving alevt-dvb a software watchdog function that just
> > looks up lets say every 2 seconds whether the PMT has changed or not,
> > performing a reinitialisation of the PMT treatment built inside, i. e.
> > doing something like a restart of alevt-dvb?
> >
> 
> To find how to catch that "PMT has changed" we have to know
> who is doing such PMT change operation.
> 
> > Would that be a pratical solution?
> > Or what would be your personal proposal, Honza?
> >
> > Cheers
> >
> > CS
> >
> > P. S.: The decisive case the program must learn to deal with is NOT a
> > simple channel change, as you express it above, Honza.
> > The proggy can already run multiple instances in parallel console
> > sessions if the transponder is one and the same......
> >
> > The decisive case the program must learn to deal with is a combination
> > of channel change PLUS transponder change, which makes it necessary to
> > read, work over and parse a complete new PMT (program map table) causing
> > the UI to at least starting the main program of the new transponder
> > (which is ZDF f. ex. if the transponder is ZDFVision.
> > Everything clear so far? Questions?
> >
> 
> Still the only one question - how it works for you now? How do you
> zap to channel right now? I expect you have some favourite application.
> 
> Cheers
> 
> /Honza

Sorry Honza,

my current favourite application is of course xine-ui, but not the one
in the distro Debian Squeeze.

A self-debianized more recent version 0.6 instead, but definitely
xine-ui.
As alternative I sometimes use mplayer.

These two go for videostreams so far.

As far as audiostreams (DVB Radio only) are concerned I do prefer
audacious2 with its inofficial or say external DVB-plugin which you can
download at the audacious2 homepage.

So I do not use simply one application for all (as you might expect),
because xine-ui and mplayer are awfully slow for Radio streams.

I use at least 2 different ones, if not to say three, while 2 (xine and
audacious2 with DVB plugin are the preferred ones.

Does that help us so far?

I still wonder why you are asking so straightly for the master
application. Not as a matter of ignorance I wonder, but as a matter of
different experience.

If you for instance extract mtt, the videotext application from Gerd
Knorr's xawtv-4.0 pre suite and compile it without the other components
of the suite you can start it in every "master" application context you
may ever wish:
If the transponder is changed by whatever external application then mtt
follows the transponder change. While it officially belongs to xawtv as
program suite it can run autonomously outside that xawtv context.

So the "master" application in that case MUST NOT BE necessarily xawtv
doing the channel and transponder tuning.
It can be every other deliberate DVB application instead.

That's why I wonder about your questions.

CS

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[BOUWSMA Barry]

I'm not even trying to follow this discussion at all, but I
feel I have to chime in to be off-topic...

On Sat, 6 Feb 2010, hermann pitton wrote:

> > > > Bye bye Teletext. Nothing for future kernels, huh?
> > > 
> > > Yes, you say it. It definitely will go away and we do have not any
> > > influence on that! Did you not notice the very slow update rate these
> > > days?
> > 
> > a. NOTHING "will go away". This is empty rant, nothing else it is!
> > In US teletext is dead, yes. In Europe analogue television is close to
> > dead. Yes.
> > But I have found no information source that teletext will disappear in
> > general. At least not in Europe or Germany.
> > So if you keep that up then prove the assertion please.
> 
> In the UK too. And after world war II we always followed BBC.
> Not that bad ...

The BBC has switched over to ``Digital Text'' via the Red Button
service on Freeview.  This is based on MHEG, and has the advantage
that pretty much all receivers are built around a particular 
platform which specifies inclusion of the Red Button services,
a particular EPG, LCNs, and so on.  Be that platform Freeview, or
Sky, or Freesat.

This is not the case in your country -- the public broadcasters
have adopted MHP which has gone over about as well as a lead 
balloon.  There is also not a specified platform, but rather any
manufacturer can offer a receiver based on the DVB specifications.
Usually teletext support will be built-in to the decoder; also, 
most boxes pass the DVB Teletext information to the television
regenerated as the analogue VBI interval which pretty much every
set supports.

As far as I know, the proposed Eutelsat Viseo platform being 
pushed does not specify a MHP- or MHEG-based replacement for
teletext, nor am I aware of any alternative platforms to take
over and mandate a replacement of the current level teletext.

Can you even find a MHP-capable settop box in the shops today?
Also, as far as I know, the national MHP service was dropped from
terrestrial broadcasting some years ago, and at best there may
be still a regional and minimal service offered by Bayerischer
Rundfunk, but nothing like one finds on Freeview.

Conditions have diverged too much between the two countries these
days.  In the UK, Sky has a lion's share of the market, while I've
barely seen anything but a few sports bars with a Premiere 
subscription.  Also while the commercial public service 
broadcasters in the UK have relied on terrestrial service through
the country, this has not been true of the comparable private
commercial broadcasters in germany, who are not even participating
in terrestrial broadcasting outside of a handful of strategic
centres.  Also, teletext in germany is a service of the individual
broadcasters or contracted out in the commercial case, while the
Teletext and Teletext Holidays and such closing in the UK is its 
own service.


Without support already in place for a transition away from VBI-
based teletext over the coming years, I can't see it happening.
I know that Austria made a big deal of their MHP-based ORF text
service, but I don't know how great a penetration it has.  I've
read tht it requires significant bandwidth of the terrestrial
multiplexes, while conventional teletext requires around that of
an audio channel -- back when ZDFvision was sending MHP data plus
AC3 streams terrestrially, I clocked four MHP streams each with a
data rate comparable to a lower-quality audio stream, together
some twice the data rate of each of the three separate teletext
streams.



> > What slow update rate please?
> > What the hell are you talking about, man?
> 
> Previously information available there was updated within minutes, now
> in best case every six hours it seems to me.

I don't know what services you are viewing; those which I use
are updated within seconds of updated data, and happen to be the
first place I turn to for current information.  The amount and
quality of information I get from conventional teletext is far
more impressive than what I see on the BBC's Red Button service.


barry bouwsma

Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[hermann pitton]

Am Samstag, den 06.02.2010, 13:02 +0100 schrieb BOUWSMA Barry:
> I'm not even trying to follow this discussion at all, but I
> feel I have to chime in to be off-topic...
> 
> On Sat, 6 Feb 2010, hermann pitton wrote:
> 
> > > > > Bye bye Teletext. Nothing for future kernels, huh?
> > > > 
> > > > Yes, you say it. It definitely will go away and we do have not any
> > > > influence on that! Did you not notice the very slow update rate these
> > > > days?
> > > 
> > > a. NOTHING "will go away". This is empty rant, nothing else it is!
> > > In US teletext is dead, yes. In Europe analogue television is close to
> > > dead. Yes.
> > > But I have found no information source that teletext will disappear in
> > > general. At least not in Europe or Germany.
> > > So if you keep that up then prove the assertion please.
> > 
> > In the UK too. And after world war II we always followed BBC.
> > Not that bad ...
> 
> The BBC has switched over to ``Digital Text'' via the Red Button
> service on Freeview.  This is based on MHEG, and has the advantage
> that pretty much all receivers are built around a particular 
> platform which specifies inclusion of the Red Button services,
> a particular EPG, LCNs, and so on.  Be that platform Freeview, or
> Sky, or Freesat.
> 
> This is not the case in your country -- the public broadcasters
> have adopted MHP which has gone over about as well as a lead 
> balloon.  There is also not a specified platform, but rather any
> manufacturer can offer a receiver based on the DVB specifications.
> Usually teletext support will be built-in to the decoder; also, 
> most boxes pass the DVB Teletext information to the television
> regenerated as the analogue VBI interval which pretty much every
> set supports.
> 
> As far as I know, the proposed Eutelsat Viseo platform being 
> pushed does not specify a MHP- or MHEG-based replacement for
> teletext, nor am I aware of any alternative platforms to take
> over and mandate a replacement of the current level teletext.
> 
> Can you even find a MHP-capable settop box in the shops today?
> Also, as far as I know, the national MHP service was dropped from
> terrestrial broadcasting some years ago, and at best there may
> be still a regional and minimal service offered by Bayerischer
> Rundfunk, but nothing like one finds on Freeview.
> 
> Conditions have diverged too much between the two countries these
> days.  In the UK, Sky has a lion's share of the market, while I've
> barely seen anything but a few sports bars with a Premiere 
> subscription.  Also while the commercial public service 
> broadcasters in the UK have relied on terrestrial service through
> the country, this has not been true of the comparable private
> commercial broadcasters in germany, who are not even participating
> in terrestrial broadcasting outside of a handful of strategic
> centres.  Also, teletext in germany is a service of the individual
> broadcasters or contracted out in the commercial case, while the
> Teletext and Teletext Holidays and such closing in the UK is its 
> own service.
> 
> 
> Without support already in place for a transition away from VBI-
> based teletext over the coming years, I can't see it happening.
> I know that Austria made a big deal of their MHP-based ORF text
> service, but I don't know how great a penetration it has.  I've
> read tht it requires significant bandwidth of the terrestrial
> multiplexes, while conventional teletext requires around that of
> an audio channel -- back when ZDFvision was sending MHP data plus
> AC3 streams terrestrially, I clocked four MHP streams each with a
> data rate comparable to a lower-quality audio stream, together
> some twice the data rate of each of the three separate teletext
> streams.
> 
> 
> 
> > > What slow update rate please?
> > > What the hell are you talking about, man?
> > 
> > Previously information available there was updated within minutes, now
> > in best case every six hours it seems to me.
> 
> I don't know what services you are viewing; those which I use
> are updated within seconds of updated data, and happen to be the
> first place I turn to for current information.  The amount and
> quality of information I get from conventional teletext is far
> more impressive than what I see on the BBC's Red Button service.
> 
> 
> barry bouwsma

Hi Barry,

sorry for delay and thanks for your advice. I know it was already there
previously and is best we have.

ZDF is becoming very slow in updating news on page 112 and 113.

KiKa seems to be already fully commercial.

Cheers,
Hermann

Re: Videotext application crashes the kernel due to DVB-demux patch

[Mauro Carvalho Chehab]

Chicken Shack wrote:
> Hi,
> 
> here is a link to a patch which breaks backwards compatibility for a
> teletext software called alevt-dvb.
> 
> http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> 
> The kernel patch was introduced with kernel 2.6.32-rc1.
> It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> author, Andreas Oberritter.
> 
> Previous help calls, not only on this list, have been ignored for
> reasons that I do not know.
> Even distro maintainers have given up and removed the DVB implementation
> of alevt from their distro list.
> 
> Is that really what things are up to?
> To pull through an API update by kernel patch, but simply dive off with
> the usual "Sorry, but I don't have no time" when objections or problems
> arise?
> 
> What the hell is going on in those peoples' minds?
> 
> It seems to me that the following disclaimer is worth nothing:
> 
> "If anyone has any objections, please let us know by sending a message
> to: Linux Media Mailing List <linux-me...@vger.kernel.org>"
> 
> Volunteers welcome! Who please consacres some time and DVB competence to
> give the appropriate hints please?

This is the first time I've seen an email about this subject from you
at the linux-media ML. Also, I didn't noticed any report or patches from distro 
packagers about a driver issue related to videotext. Also, there were no reply 
to the announcement that the patch would be sent upstream (the email you're 
pointing). Maybe I missed something.

If you found a bug on a patch that were already applied upstream, the
better procedure is to fill a bug report at kernel.bugzilla.org. Please
enclose there the full dmesg output and any other descriptions that may
help the developers to know what card/driver/application you're using, and
how to reproduce the bug. The application logs may also be useful, but please
don't mix it together with the dmesg.

Before reporting the bug, please test the latest stable kernel version (currently 
2.6.32.7) first, to be sure that this regression weren't correct yet, or, even
better, the latest development kernel, since the bug may already be solved.

The latest development kernel is found at the -git tree:
	http://git.linuxtv.org/v4l-dvb.git

-- 

Cheers,
Mauro

Re: Videotext application crashes the kernel due to DVB-demux patch

[Chicken Shack]

Am Montag, den 01.02.2010, 11:02 -0200 schrieb Mauro Carvalho Chehab:
> Chicken Shack wrote:
> > Hi,
> > 
> > here is a link to a patch which breaks backwards compatibility for a
> > teletext software called alevt-dvb.
> > 
> > http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg04638.html
> > 
> > The kernel patch was introduced with kernel 2.6.32-rc1.
> > It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its
> > author, Andreas Oberritter.
> > 
> > Previous help calls, not only on this list, have been ignored for
> > reasons that I do not know.
> > Even distro maintainers have given up and removed the DVB implementation
> > of alevt from their distro list.
> > 
> > Is that really what things are up to?
> > To pull through an API update by kernel patch, but simply dive off with
> > the usual "Sorry, but I don't have no time" when objections or problems
> > arise?
> > 
> > What the hell is going on in those peoples' minds?
> > 
> > It seems to me that the following disclaimer is worth nothing:
> > 
> > "If anyone has any objections, please let us know by sending a message
> > to: Linux Media Mailing List <linux-me...@vger.kernel.org>"
> > 
> > Volunteers welcome! Who please consacres some time and DVB competence to
> > give the appropriate hints please?

Hello Mauro,

> 
> This is the first time I've seen an email about this subject from you
> at the linux-media ML.

A few days ago there has been some Emil Meyer mentioning the same thing
using alevt-dvb in connection with two Hauppauge DVB-T cards.

But you are highly under charge, so you cannot receive anything.

>  Also, I didn't notice any report or patches from distro 
> packagers about a driver issue related to videotext.

I got no answer from Andreas Rottmann yet. He is the Debian maintainer
of the "official" alevt-1.6.2. He spreaded a DVB-patched version under
the roof of Debian.

Concerning Gentoo I read somewhere in the Internet that the Gentoo
maintainer withdrew all DVB patches of alevt with the consequence that
you can only use this "classic" teletext app with analogue cards.

So I do neither exaggerate nor do I lie, OK?

>  Also, there were no reply 
> to the announcement that the patch would be sent upstream (the email you're 
> pointing). Maybe I missed something.

I know that I am a bit late - one point for you, mea culpa. Sorry!

> If you found a bug on a patch that were already applied upstream, the
> better procedure is to fill a bug report at kernel.bugzilla.org. Please
> enclose there the full dmesg output and any other descriptions that may
> help the developers to know what card/driver/application you're using, and
> how to reproduce the bug. The application logs may also be useful, but please
> don't mix it together with the dmesg.

This is too bureaucratic and too official - I prefer the inofficial way,
directly contacting relevant people in relevant forums.
I've been practising that for years now.

> Before reporting the bug, please test the latest stable kernel version (currently 
> 2.6.32.7) first, to be sure that this regression weren't correct yet, or, even
> better, the latest development kernel, since the bug may already be solved.

Peanuts!
I tested the latest v4l HG, and as a kind of normality, I am using the
latest rc candidate being published by Linus.

Normally that "system of early warning" works well, but sometimes you're
missing some things. That's the way it is. Shit happens.

But if too many people dive off with that typical "I do not have any
time left-gesture" then this is sonmething that really frustrates you.

> The latest development kernel is found at the -git tree:
> 	http://git.linuxtv.org/v4l-dvb.git
> 

Guess I will supply the necessary info to Andy. We will see what
happens.

Publically I want to mention the following points:

1. Within the first call of alevt-dvb you do see the printout that I
already integrated in my mail.
2. If you call alevt a second time from the command line after that it
will hang your system so that nothing goes without hard reset.
3. Having a look at the code of alevt-dvb I would say that its
DVB-implementation looks a bit crude to me.
This crudeness shows up in so far that alevt-dvb does not continue
working and does not follow if the DVB channel is being switched by some
external application like kaffeine, xine-ui, mplayer etc.

Instead alevt-dvb hangs and does not accept a normal quit (or call it
normal exit or whatever).
The only ways to get it finished then are:
a. killall -9 alevt	or
b. CTRL-C if you started alevt-dvb from the command line before.

So basically there are two problems to solve:

a. the channel change problem (i. e. NOT accepting a quit if channel is
being changed)
b. the kernel oops due to the new demux design

If both problems are solved I can publish a completely freshed up and
cleaned up version of the protagonist of all teletext programs.
The whole Linux community will be the winner of that.
There will be full analogue and DVB compatibility.

If this is no motivation, then what else is a motivation please?

Regards

CS